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
5
2.5k
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
2.1k
オンコールよもやま話 / JAWS-UG SRE#7 OnCall Yomoyama
irotoris
1
590
SRE を実践するためのプラットフォームの作り方と技術マネジメント / Building a Platform for SRE
irotoris
3
5.9k
Other Decks in Technology
See All in Technology
雑に疎通確認だけしたい...せや!CloudShell使ったろ!
alchemy1115
0
240
テストコードにはテストの意図を込めよう(2025年版) #retechtalk / Put the intent of the test 2025
nihonbuson
PRO
10
1.9k
最近のRedmineの開発動向と次期バージョン6.1.0
vividtone
0
110
DynamoDB のデータを QuickSight で可視化する際につまづいたこと/stumbling-blocks-when-visualising-dynamodb-with-quicksight
emiki
0
170
MCP でモノが動くとおもしろい/It is interesting when things move with MCP
bitkey
3
600
Google Cloud Next 2025 Recap アプリケーション開発を加速する機能アップデート / Application development-related features of Google Cloud
ryokotmng
0
310
"発信文化"をどうやって計測する?技術広報のKPI探索記/How do we measure communication culture?
bitkey
4
340
MagicPod MCPサーバー開発の裏側とAIエージェント活用の展望
magicpod
0
270
Kaigi Effect 2025 #rubykaigi2025_after
sue445
0
170
技術選定を突き詰める 懇親会LT
okaru
2
1.2k
計装を見直してアプリケーションパフォーマンスを改善させた話
donkomura
2
170
人間性を捧げる生成AI時代の技術選定
yo4raw
1
860
Featured
See All Featured
The MySQL Ecosystem @ GitHub 2015
samlambert
251
12k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Agile that works and the tools we love
rasmusluckow
329
21k
Testing 201, or: Great Expectations
jmmastey
42
7.5k
BBQ
matthewcrist
88
9.6k
Faster Mobile Websites
deanohume
307
31k
We Have a Design System, Now What?
morganepeng
52
7.6k
The Pragmatic Product Professional
lauravandoore
33
6.6k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
21k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
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!!