Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
Wantedlyの障害対応文化とインシデントコマンダー / Wantedly Incident...
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Shoji Shirotori
January 17, 2024
Technology
3.1k
5
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Wantedlyの障害対応文化とインシデントコマンダー / Wantedly Incident Commander
Incident Response Meetup vol.1
https://incident-response.connpass.com/event/304636/
Shoji Shirotori
January 17, 2024
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.6k
オンコールよもやま話 / JAWS-UG SRE#7 OnCall Yomoyama
irotoris
1
770
SRE を実践するためのプラットフォームの作り方と技術マネジメント / Building a Platform for SRE
irotoris
3
6.8k
Other Decks in Technology
See All in Technology
AIがGISを代替する日:〜すべてをAIが創る時代に、私たちがFOSS4Gに関わる意味〜
lehupa
1
210
企画からFlutter実装まで、1つの機能を一貫して開発したプロセスと成果物
khiroyuki1003
1
160
新米を「売り越さない」、Aurora DSQLで作る在庫ゼロ死守の限定ドロップEC
yama3133
0
180
Don't write the architecture only in the prompt.
neohsu
0
310
「いつか使う」の「いつか」は来ない 〜AI駆動開発における「作らない」判断について〜
ikki0006
0
140
Maestro MCPとClaude Code Skillsによる自律的なE2Eテスト支援
asmz
0
420
IoTとは〜? 数字で見るSORACOM UG【SORACOM UG Explorer 2026】
soracom
PRO
0
190
自律的なチームを作るためにTechPMがやらないこと
ny7760
1
520
お客様の「やりたい」の先を見通す合意形成プロセス ~裏にある課題と不安を解きほぐすコツ~
yukakoseki
0
110
新卒エンジニア、 介護士になる
ryu1013
1
690
デザインレビューは自動化できるのか?─ Flutter × Figma で UI 品質保証を考える
techiro
2
800
あなたのDartコードは丸見えかもしれない ~reFlutterで暴くFlutterアプリの中身と多層防御~
zozotech
PRO
0
780
Featured
See All Featured
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
End of SEO as We Know It (SMX Advanced Version)
ipullrank
3
4.5k
The agentic SEO stack - context over prompts
schlessera
0
1k
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.5k
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
2
510
VelocityConf: Rendering Performance Case Studies
addyosmani
331
25k
GitHub's CSS Performance
jonrohan
1033
470k
A better future with KSS
kneath
240
18k
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
970
Accessibility Awareness
sabderemane
1
290
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
1
300
Fashionably flexible responsive web design (full day workshop)
malarkey
409
67k
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!!