Incident Response Meetup vol.1【増枠】にオンライン参加しました

連続でSRE系のイベントに参加してきたので、そのメモです。 （というより昼の Lunch LT で紹介されていて、面白そうだったので参加してみました。）

とても忙しかったのでリモート参加でしたが、これまで聞いたことがない概念や言葉が多くて、とても勉強になりました。

勉強会URL

Incident Response Meetup vol.1【増枠】 https://incident-response.connpass.com/event/304636/ #障害対応

メモ

雑多なメモです。

• システムの障害対応の教科書という本がある（改訂版も出るようで、Amazonでは2024/04/15発売予定となっていた）

システム障害対応の教科書

【改訂新版】システム障害対応の教科書

• システム障害対応の課題としては、システムの障害はエンジニアのレベルや参加した時期に関わらず、誰でもいつでも起こりうるということ
  • RPGの序盤の街で、序盤のモンスターが出てくることがあれば、ラスボスが出てくることもあるような予測が難しいもの
• システム障害対応の難しさは、教育が難しいということ
  • 暗黙知の部分が多い、体系化されていない、非定形である、など
    • どういうことが起こりうるかを想定するのが難しい
    • どういうことが起こったらどういう対応をするのかを想定するのが難しい
  • この点の解決には形式知への変換が必要
  • 障害を解決することが目的ではなく、顧客ができない・顧客への価値提供ができていないことの解決が本質
    • 回避策があれば、障害をすぐ解消する必要はないかもしれない
• インシデントコマンダーという考え方
  • インシデントコマンダーの役割: リアルタイムの危機管理 [2023] • Asana
  • インシデントコマンダー - PagerDuty Incident Response Documentation
  • インシデント対応で明確に役割を分ける
    • インシデントコマンダーは、インシデント対応の指揮を執る
    • それ以外にも障害の実調査者・修正対応者、ユーザー対応担当者、場合によっては経営判断者など役割を明確にし、それぞれの問題に集中できる状態にする
• インシデントコマンダーを育てよう
  • インシデントコマンダーは優秀な担当者である可能性もある
  • 一方で優秀な担当者が障害対応に集中すると、他の仕事が滞ったり、他のメンバーが育たなかったりする
  • インシデントコマンダーを育てることで、障害対応の負荷を分散できる
    • ある意味で優秀な担当者であってもぐっと堪える…！
• ポストモーテムも大事
• オンコール担当のオーナーシップがなかなか難しい問題
  • 調査が早い人であれば的確に担当者に割り振ることができる、しかしそこでオーナーシップを手放してしまうケースがある
  • 調査が遅い人の場合、根本原因にたどり着けず誰を頼るべきなのかもわからなくなってしまうケースがある
  • ユーザーへの価値を下げずにみんなで対応し切るためには共通認識を持って、オーナーシップを持って対処する
• 問題が発生したらすぐ集まって同期コミュニケーションをしよう
  • 集まる場所は決めておく
• 予めフローや役割の定義は決めておく
  • 最速でサービス復旧をするための備え - Speaker Deck
• 障害訓練的な練習もしておく
  • Wantedlyの障害対応文化とインシデントコマンダー / Wantedly Incident Commander - Speaker Deck
  • ただし本番で対応する緊張感や経験からすると薄いものになってしまう
• Wantedly Engineering Handbook - Wantedly Engineering Handbook
  • 便利そう

感想

連続でSRE系のイベントに参加してきたことで、新たな概念や考え方に触れる機会があり、とても勉強になりました。 特にシステム障害対応の教育の難しさやインシデントコマンダーの重要性について学びました。 また、オーナーシップの重要性や同期コミュニケーションの必要性も再確認しました。 障害対応においては、事前の準備や練習が重要であり、それによってチーム全体の対応力を高めることができると感じました。

だいたい書きたいことは Copilot が書いてくれたので感想としてはこれで…。