Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Wantedlyの障害対応文化とインシデントコマンダー / Wantedly Incident...
Search
Shoji Shirotori
January 17, 2024
Technology
4
2.1k
Wantedlyの障害対応文化とインシデントコマンダー / Wantedly Incident Commander
Incident Response Meetup vol.1
https://incident-response.connpass.com/event/304636/
Shoji Shirotori
January 17, 2024
Tweet
Share
More Decks by Shoji Shirotori
See All by Shoji Shirotori
Data Ingestion ETL の技術選定の変遷をADRで振り返る / Data Ingestion ETL ADRs at DataOps Night#4
irotoris
3
1.7k
オンコールよもやま話 / JAWS-UG SRE#7 OnCall Yomoyama
irotoris
1
510
SRE を実践するためのプラットフォームの作り方と技術マネジメント / Building a Platform for SRE
irotoris
3
5.6k
Other Decks in Technology
See All in Technology
Adopting Jetpack Compose in Your Existing Project - GDG DevFest Bangkok 2024
akexorcist
0
110
Application Development WG Intro at AppDeveloperCon
salaboy
0
180
ExaDB-D dbaascli で出来ること
oracle4engineer
PRO
0
3.8k
Introduction to Works of ML Engineer in LY Corporation
lycorp_recruit_jp
0
110
社内で最大の技術的負債のリファクタリングに取り組んだお話し
kidooonn
1
550
Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集
oracle4engineer
PRO
2
3.2k
SSMRunbook作成の勘所_20241120
koichiotomo
2
130
iOSチームとAndroidチームでブランチ運用が違ったので整理してます
sansantech
PRO
0
130
Engineer Career Talk
lycorp_recruit_jp
0
150
初心者向けAWS Securityの勉強会mini Security-JAWSを9ヶ月ぐらい実施してきての近況
cmusudakeisuke
0
120
誰も全体を知らない ~ ロールの垣根を超えて引き上げる開発生産性 / Boosting Development Productivity Across Roles
kakehashi
1
220
Evangelismo técnico: ¿qué, cómo y por qué?
trishagee
0
360
Featured
See All Featured
Practical Orchestrator
shlominoach
186
10k
Happy Clients
brianwarren
98
6.7k
Keith and Marios Guide to Fast Websites
keithpitt
409
22k
Imperfection Machines: The Place of Print at Facebook
scottboms
265
13k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.8k
For a Future-Friendly Web
brad_frost
175
9.4k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
410
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
Code Review Best Practice
trishagee
64
17k
Being A Developer After 40
akosma
86
590k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.9k
Transcript
© 2024 Wantedly, Inc. ウォンテッドリーの障害対応文化と インシデントコマンダー Incident Response Meetup Vol.1
Jan. 16 2024 - Shoji Shirotori @irotoris
© 2024 Wantedly, Inc. About Me Shoji Shirotori @irotoris Infrastructure
Squad at Wantedly, Inc. Infra /SRE / Data Engineer ❤ AWS, Kubernetes, BigQuery, Python, Go
© 2024 Wantedly, Inc. 究極の適材適所により、 シゴトでココロオドルひとを ふやすために Wantedlyはパーパス‧共感を軸にした、⼈と会社との出会いを2012 年から創出。 はたらくすべての⼈が共感を通じて「であい」「つながり」「つなが
りを深める」ためのビジネスSNS「Wantedly」を提供しています。 1⼈でも多くの⼈がワクワクしたり、熱中してシゴトと向き合えるよ うな世界を実現するために、国境を超えて「はたらくすべての⼈のイ ンフラ」を創っていきます。 Business 提供サービス
© 2024 Wantedly, Inc. 話すこと ウォンテッドリーにおける • 障害対応の文化 • インシデントコマンダー
• インシデントコマンダーのための備え
© 2024 Wantedly, Inc. ウォンテッドリーにおける障害対応の文化
© 2024 Wantedly, Inc. 開発組織の全体像
© 2024 Wantedly, Inc. 開発組織の全体像 プロダクト Squad / 基盤 Squad
ドメイン横断の技術領域 Chapter Squad と Chapter のマトリクス型の組織
© 2024 Wantedly, Inc. Infrastructure Squad インフラや DevOps に関わる機能とプラクティスをプラットフォームとして提供していく ※エンジニア組織は
全体で約30〜40名前後
© 2024 Wantedly, Inc. 開発と障害対応 • 障害対応の Slack #war_room に通知がくるとわらわらと人が集まる
• 基本的に開発チームがデプロイ後のモニタリングまでの DevOps を行う ◦ デプロイ後に Error Rate / Latency に問題があればデプロイしたチームが 対処する文化 • 重大なシステムアラートはオンコール担当エンジニアに直接通知される ◦ オンコール担当はエンジニア全体から募って仮想的なグループを構築 ◦ 去年はインフラだけがオンコールを持っていたが文化に合わせて拡張 ◦ このグループ内でインシデントコマンダーや障害対応を訓練
© 2024 Wantedly, Inc. エスカレーションフロー システム ユーザー カスタマーサポート プロダクト開発チーム /基盤チーム
オンコール担当 #war_room #alert 重大なアラートの み PD へ 問題が大きい 場合はエスカレ/招集
© 2024 Wantedly, Inc. 障害対応の心構え - Wantedly Engineering Hanbook https://docs.wantedly.dev/introduction/incident
© 2024 Wantedly, Inc. 障害対応の心構え - Wantedly Engineering Hanbook https://docs.wantedly.dev/introduction/incident
© 2024 Wantedly, Inc. コラム:良い文化を維持するための文化
© 2024 Wantedly, Inc. コラム:良い文化を維持するための文化
© 2024 Wantedly, Inc. コラム:良い文化を維持するための文化 所感 • 障害を起こしてしまったという自責の念、時間との戦いなどプレッシャーが高い状態 で体験したことは印象に残りやすい •
具体的な体験に裏付けられた組織文化は消えにくい • 良い文化は、その体験の再現(今回は声掛け)と社内ドキュメントに明確に残して いくことで維持できる • 実は障害対応周りの文化はすごく会社としての特性が現れたりするんじゃないかっ て思ってる
© 2024 Wantedly, Inc. ウォンテッドリーにおけるインシデントコマンダー
© 2024 Wantedly, Inc. インシデントコマンダーとは 現場指揮官(IC、incident commander) この人の仕事は、決断することです。特に、この役割の人は改善、顧客や社内と のコ ミュニケーション、調査にはかかわりません。サービス停止に関する調査を
監督する役 割であり、それだけです。インシデントの初期段階では、オンコール 担当が IC の役割を 担うことがあります。この場合、IC の役割は他の人に引き継 がれることもあり、オンコー ル担当が他の役割に適している時はなおさらです。 from O'Reilly Japan - 入門 監視 ウォンテッドリーで初めてインシデントコマンダーの概念は『入門 監視』から引用されたのが初出。2019年ごろ。
© 2024 Wantedly, Inc. ウォンテッドリーにおけるインシデントコマンダーとは • 障害対応における現場リーダー/旗振り役 • 障害を解決するために以下を行う ◦
状況整理・情報集約 ◦ 体制構築・権限移譲 ◦ 対応の実行判断および指示 • ポイント ◦ 問題の調査やコミュニケーションは直接は行わない、現場を管理監督および 意思決定をすることに集中する • 誰がやるか ◦ その時のメンバーで最適な人にその場で振る ▪ 誰もいなければその時のオンコール担当がやる
© 2024 Wantedly, Inc. 障害対応の体制 • 木村 誠明. システム障害対応の教科書 (p.58).
株式会社技術評論社 で紹介され ている例。Wantedly の障害対応もこの布陣に近い。
© 2024 Wantedly, Inc. ここがむずいよインシデントコマンダー • 必要な対応を漏れなく判断・実行していくことが難しい ◦ 状況によって行うべきことが異なる、焦ると漏れる •
対応ステータス管理が難しい ◦ 障害の影響、対応状況、アナウンス状況、作業者の状況… etc. • 判断やインシデントコマンダーを委任・交代する認知が難しい ◦ 自分はパニクってないか?事の大きさ的に他の人がやったほうがいい? • ほんとうに対応が必要な機能や重大インシデントの経験は積みにくい ◦ 重要な機能ほど対策していて障害が起きにくい
© 2024 Wantedly, Inc. まだまだむずいよインシデントコマンダー • 人が集まりすぎると余計難しくなる ◦ 対応メンバー以外は解散させることも必要 •
常に最悪ケースを考えて先を読むのが難しい ◦ 原因仮説を外したときや、ユーザー体験をなるべく保つ工夫を考えたり • 結果できる人に偏る ◦ 障害対応は時間との勝負なので、速度を考えるとできる人に偏る ◦ 属人性は組織のスケールにおいてボトルネックになる
© 2024 Wantedly, Inc. ここがむずいよインシデントコマンダー(エンジニアの声)
© 2024 Wantedly, Inc. ウォンテッドリーにおけるインシデントコマンダーの備え
© 2024 Wantedly, Inc. インシデントコマンダーのための備え 難しいなら備えよう • 障害対応フローの定義 • 障害の
Severity(重篤度)定義 • 障害対応の訓練
© 2024 Wantedly, Inc. インシデントコマンダーのための備え 障害対応フロー(アクションリスト)の定義 障害を検知してから問題解決までのアクションリストおよび判断フローを整備している。サービス初 期に最初のアクションリストができてから定期的に更新・改善している。 Markdown の他
Google Docs のテンプレートとして作成し、対応時にはコピーしてライブドキュメ ントとして使うことができる。障害対応チャンネルにピンされているので、情報整理には必ずこの Docs を使うことになる。
© 2024 Wantedly, Inc. 目次例 - 障害対応フロードキュメント ポストモーテムで対応フローやリファレンスの追加・改善が話されて 随時更新される。全員が編集、Pull Request
可能。 実質的な対応フロー兼ラ イブドキュメント
© 2024 Wantedly, Inc. ステータス欄と記録欄 - 障害対応フロードキュメント こっちはひたすら追記型 の記録部分 関係者がみてぱっと分かる
ステータス欄
© 2024 Wantedly, Inc. アクションリスト欄 - 障害対応フロードキュメント
© 2024 Wantedly, Inc. インシデントコマンダーのための備え 障害の Severity(重大度)定義 アクションリストに判断の必要があることは記載されているが、判断基準がないので判断しづらいと いう問題があった。Severity を判断軸として使うことで様々な判断をしやすくし、障害対応の効率化
を目指した。
© 2024 Wantedly, Inc. インシデントコマンダーのための備え Severity(重大度)の例。SEVに応じて必要なフローや優先度を設定。 • SEV1: ユーザーがサービスの大半の機能を長時間利用できない状態もしくはユーザーの情報 が漏洩、消失するセキュリティインシデント
• SEV2: ユーザーがコア機能を含む複数の機能を利用できない状態 • SEV3: ユーザーがコア機能以外の機能を利用できない状態 • SEV4: ユーザーが機能は利用できるが一部の動作に問題が発生していて不便を感じている 状態 ちなみに最近定義したばかりで馴染んでい るかといえばそうでもない。課題。
© 2024 Wantedly, Inc. インシデントコマンダーのための備え 障害対応の訓練 • 対応フローとドキュメントがあっても初見で本番はハードルが高い • 開発環境で過去の障害を再現させてインシデントコマンダーの訓練を積むことが有効
◦ 振り返りや感想戦を行うことで、インシデントコマンダーや対応フロー、調査デバッグと いった個々の能力に焦点を当てて訓練をする ◦ 能力は訓練は繰り返し行うことで身につく ▪ 実は過去にも訓練は行ったことがあるが 1回だけで、今回の実施は数年振りだった ▪ これから継続!
© 2024 Wantedly, Inc. インシデントコマンダーのための備え 障害対応の訓練の企画後日談 • 実は訓練したその日に本番障害が発生したが、訓練でできたことが本番ではできなかったりし た ◦
やはり繰り返し訓練が必要 • 障害の再現や模擬障害について ◦ 効果的な訓練のために壊し方を模索するためにシステム理解が深まった ◦ よくある障害パターンだと経験則から訓練で復旧成功してしまうので、壊し方のパターン はいろいろ用意して何回もやったほうがいい ◦ ISUCONっぽい
© 2024 Wantedly, Inc. まとめ • 障害対応の文化 ◦ その変化に応じて体制を変えていけ •
インシデントコマンダー ◦ 基本的にとってもむずかしい • インシデントコマンダーのための備え ◦ 対応フローの継続的な整備と訓練で強くなれ
© 2024 Wantedly, Inc. https://www.wantedly.com/projects/522096
© 2024 Wantedly, Inc. Thank you!!