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
2k
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.5k
オンコールよもやま話 / JAWS-UG SRE#7 OnCall Yomoyama
irotoris
1
470
SRE を実践するためのプラットフォームの作り方と技術マネジメント / Building a Platform for SRE
irotoris
3
5.6k
Other Decks in Technology
See All in Technology
怖くないオフライン機能開発 〜基本的な技術で実現する現場向けオフライン機能 / Developing offline functions without fear ~ Offline functions for the field realized with basic technology
kaminashi
1
120
スタサプ ForSCHOOLアプリのシンプルな設計
recruitengineers
PRO
3
710
これはPerl? それともRuby? クイズ〜〜〜〜〜!!!- Perl or Ruby Quiz
moznion
2
2k
Cosmos DB で持続可能な RAG を実現しよう!~ AOAI Dev Day ふりかえりを添えて / Sustainable RAG with Cosmos DB with recap AOAI Dev Day
miyake
0
130
塩野義製薬様のAWS統合管理戦略:Organizations設計と運用の具体例
tkikuchi
0
220
入門 バックアップ
ryuichi1208
18
7.2k
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
5
48k
Grafana エコシステムの活用事例 on ABEMA
tetsuya28
4
540
令和最新版 Perlコーディングガイド
anatofuz
5
4k
ADRを運用して3年経った僕らの現在地
onk
PRO
13
5.9k
ドキュメントとの付き合い方を考える
leveragestech
2
150
LeSSはスクラムではない!?LeSSにおけるスクラムマスターの振る舞い方とは / Scrum Master Behavior in LeSS
toma_sm
0
210
Featured
See All Featured
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
2
310
In The Pink: A Labor of Love
frogandcode
139
22k
Making the Leap to Tech Lead
cromwellryan
131
8.9k
Designing for Performance
lara
604
68k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
4
120
How to Think Like a Performance Engineer
csswizardry
17
1k
Gamification - CAS2011
davidbonilla
80
5k
10 Git Anti Patterns You Should be Aware of
lemiorhan
653
59k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
40
2.1k
The Power of CSS Pseudo Elements
geoffreycrofte
71
5.3k
Debugging Ruby Performance
tmm1
73
12k
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!!