Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Wantedlyの障害対応文化とインシデントコマンダー / Wantedly Incident...

Wantedlyの障害対応文化とインシデントコマンダー / Wantedly Incident Commander

Shoji Shirotori

January 17, 2024
Tweet

More Decks by Shoji Shirotori

Other Decks in Technology

Transcript

  1. © 2024 Wantedly, Inc. About Me Shoji Shirotori @irotoris Infrastructure

    Squad at Wantedly, Inc. Infra /SRE / Data Engineer ❤ AWS, Kubernetes, BigQuery, Python, Go
  2. © 2024 Wantedly, Inc. 究極の適材適所により、 シゴトでココロオドルひとを ふやすために Wantedlyはパーパス‧共感を軸にした、⼈と会社との出会いを2012 年から創出。 はたらくすべての⼈が共感を通じて「であい」「つながり」「つなが

    りを深める」ためのビジネスSNS「Wantedly」を提供しています。 1⼈でも多くの⼈がワクワクしたり、熱中してシゴトと向き合えるよ うな世界を実現するために、国境を超えて「はたらくすべての⼈のイ ンフラ」を創っていきます。 Business 提供サービス
  3. © 2024 Wantedly, Inc. 開発組織の全体像 プロダクト Squad / 基盤 Squad

    ドメイン横断の技術領域 Chapter Squad と Chapter のマトリクス型の組織
  4. © 2024 Wantedly, Inc. 開発と障害対応 • 障害対応の Slack #war_room に通知がくるとわらわらと人が集まる

    • 基本的に開発チームがデプロイ後のモニタリングまでの DevOps を行う ◦ デプロイ後に Error Rate / Latency に問題があればデプロイしたチームが 対処する文化 • 重大なシステムアラートはオンコール担当エンジニアに直接通知される ◦ オンコール担当はエンジニア全体から募って仮想的なグループを構築 ◦ 去年はインフラだけがオンコールを持っていたが文化に合わせて拡張 ◦ このグループ内でインシデントコマンダーや障害対応を訓練
  5. © 2024 Wantedly, Inc. エスカレーションフロー システム ユーザー カスタマーサポート プロダクト開発チーム /基盤チーム

    オンコール担当 #war_room #alert 重大なアラートの み PD へ 問題が大きい 場合はエスカレ/招集
  6. © 2024 Wantedly, Inc. コラム:良い文化を維持するための文化 所感 • 障害を起こしてしまったという自責の念、時間との戦いなどプレッシャーが高い状態 で体験したことは印象に残りやすい •

    具体的な体験に裏付けられた組織文化は消えにくい • 良い文化は、その体験の再現(今回は声掛け)と社内ドキュメントに明確に残して いくことで維持できる • 実は障害対応周りの文化はすごく会社としての特性が現れたりするんじゃないかっ て思ってる
  7. © 2024 Wantedly, Inc. インシデントコマンダーとは 現場指揮官(IC、incident commander) この人の仕事は、決断することです。特に、この役割の人は改善、顧客や社内と のコ ミュニケーション、調査にはかかわりません。サービス停止に関する調査を

    監督する役 割であり、それだけです。インシデントの初期段階では、オンコール 担当が IC の役割を 担うことがあります。この場合、IC の役割は他の人に引き継 がれることもあり、オンコー ル担当が他の役割に適している時はなおさらです。 from O'Reilly Japan - 入門 監視 ウォンテッドリーで初めてインシデントコマンダーの概念は『入門 監視』から引用されたのが初出。2019年ごろ。
  8. © 2024 Wantedly, Inc. ウォンテッドリーにおけるインシデントコマンダーとは • 障害対応における現場リーダー/旗振り役 • 障害を解決するために以下を行う ◦

    状況整理・情報集約 ◦ 体制構築・権限移譲 ◦ 対応の実行判断および指示 • ポイント ◦ 問題の調査やコミュニケーションは直接は行わない、現場を管理監督および 意思決定をすることに集中する • 誰がやるか ◦ その時のメンバーで最適な人にその場で振る ▪ 誰もいなければその時のオンコール担当がやる
  9. © 2024 Wantedly, Inc. 障害対応の体制 • 木村 誠明. システム障害対応の教科書 (p.58).

    株式会社技術評論社 で紹介され ている例。Wantedly の障害対応もこの布陣に近い。
  10. © 2024 Wantedly, Inc. ここがむずいよインシデントコマンダー • 必要な対応を漏れなく判断・実行していくことが難しい ◦ 状況によって行うべきことが異なる、焦ると漏れる •

    対応ステータス管理が難しい ◦ 障害の影響、対応状況、アナウンス状況、作業者の状況… etc. • 判断やインシデントコマンダーを委任・交代する認知が難しい ◦ 自分はパニクってないか?事の大きさ的に他の人がやったほうがいい? • ほんとうに対応が必要な機能や重大インシデントの経験は積みにくい ◦ 重要な機能ほど対策していて障害が起きにくい
  11. © 2024 Wantedly, Inc. まだまだむずいよインシデントコマンダー • 人が集まりすぎると余計難しくなる ◦ 対応メンバー以外は解散させることも必要 •

    常に最悪ケースを考えて先を読むのが難しい ◦ 原因仮説を外したときや、ユーザー体験をなるべく保つ工夫を考えたり • 結果できる人に偏る ◦ 障害対応は時間との勝負なので、速度を考えるとできる人に偏る ◦ 属人性は組織のスケールにおいてボトルネックになる
  12. © 2024 Wantedly, Inc. インシデントコマンダーのための備え 障害対応フロー(アクションリスト)の定義 障害を検知してから問題解決までのアクションリストおよび判断フローを整備している。サービス初 期に最初のアクションリストができてから定期的に更新・改善している。 Markdown の他

    Google Docs のテンプレートとして作成し、対応時にはコピーしてライブドキュメ ントとして使うことができる。障害対応チャンネルにピンされているので、情報整理には必ずこの Docs を使うことになる。
  13. © 2024 Wantedly, Inc. インシデントコマンダーのための備え Severity(重大度)の例。SEVに応じて必要なフローや優先度を設定。 • SEV1: ユーザーがサービスの大半の機能を長時間利用できない状態もしくはユーザーの情報 が漏洩、消失するセキュリティインシデント

    • SEV2: ユーザーがコア機能を含む複数の機能を利用できない状態 • SEV3: ユーザーがコア機能以外の機能を利用できない状態 • SEV4: ユーザーが機能は利用できるが一部の動作に問題が発生していて不便を感じている 状態 ちなみに最近定義したばかりで馴染んでい るかといえばそうでもない。課題。
  14. © 2024 Wantedly, Inc. インシデントコマンダーのための備え 障害対応の訓練 • 対応フローとドキュメントがあっても初見で本番はハードルが高い • 開発環境で過去の障害を再現させてインシデントコマンダーの訓練を積むことが有効

    ◦ 振り返りや感想戦を行うことで、インシデントコマンダーや対応フロー、調査デバッグと いった個々の能力に焦点を当てて訓練をする ◦ 能力は訓練は繰り返し行うことで身につく ▪ 実は過去にも訓練は行ったことがあるが 1回だけで、今回の実施は数年振りだった ▪ これから継続!
  15. © 2024 Wantedly, Inc. インシデントコマンダーのための備え 障害対応の訓練の企画後日談 • 実は訓練したその日に本番障害が発生したが、訓練でできたことが本番ではできなかったりし た ◦

    やはり繰り返し訓練が必要 • 障害の再現や模擬障害について ◦ 効果的な訓練のために壊し方を模索するためにシステム理解が深まった ◦ よくある障害パターンだと経験則から訓練で復旧成功してしまうので、壊し方のパターン はいろいろ用意して何回もやったほうがいい ◦ ISUCONっぽい
  16. © 2024 Wantedly, Inc. まとめ • 障害対応の文化 ◦ その変化に応じて体制を変えていけ •

    インシデントコマンダー ◦ 基本的にとってもむずかしい • インシデントコマンダーのための備え ◦ 対応フローの継続的な整備と訓練で強くなれ