1/16 (火) 開催！Incident Response Meetup vol.1

@Sansanさんオフィス

前半はいつもの気になった点のメモです。後半が感想。
ハッシュタグは #障害対応

• 木村 誠明さん（「システム障害対応の教科書」著者）
  • 障害対応→ダメージコントロールの世界
  • 障害対応教育
    • 暗黙知が殆んど、有識者はいつもいるわけではない
    • 教育が難しい
  • 障害対応の目的
    • システムを直すことではない
    • ユーザ影響の回避、低減
  • インシデントコマンダーとは
    • 必要な作業を各担当へ割り振り、実施指示を行い全体をリード
    • 復旧要件、復旧仕様を決める
  • システムの復旧が最善の道とは限らない
  • ICと作業担当者は分ける
  • 機械的な判断で人を巻き込む（人の判断をなるべくいれないことで心理的負荷を下げる）
  • 情報をフローとストックにわける
    • フローはタイムライン
    • ストックは障害レベル、事象など
  • WarRoom
    • 障害対応の専用の部屋
    • 物理、仮想は文化による
    • 不慣れなツールは使えない
  • インシデントコマンダーになるには
    • インシデントコマンダーを育てる
      • 作業担当としてオンコール参加、書記、窓口を経て
  • Q&A
    • 体系的に軍事が参考になることも
    • 障害ランクの定義により、報告ラインを定義
    • ICをスイッチするはある（宣言する）

• あんどうさん @integrated1453（株式会社ユーザベース）
  • グループ 1200名
  • エンジニア 70名
  • オンコールシフト、PagerDuty
  • 記者等に話をすることもあるので、横文字は日本語にしている（ポストモーテム→障害撲滅委員会）
  • BizメンバーのSOSはSlackからPagerDuty→運用当番
  • SRE Bookの信頼性の階層
    • monitoringが一番下
    • 検知してからエンジニアのアサインに時間がかかると障害復旧までの時間がかかる
  • 運用当番が手を動かそうとする
    – https://ueokande.github.io/incident-response-docs-ja/training/incident_commander/
  • Gatherの障害対応優先スペースに集合
  • Slackで状況をリアルタイムで更新
  • ICをSREくらい広めていきたい

• じょーしさん @paper2parasol（Sansan株式会社）
  • 最速で障害を復旧するには「事前準備」が必要
    • 役割定義、対応フロー、インシデントレベル定義、状況ボード
  • 役割と担当がわかれている
  • システム対応の指揮命令者
    • ICの多くを担っている
  • 現場指揮者
    • エンジニアに委譲
  • インシデント判断の意思決定者（Product Manager）
    • インシデントの判断
  • 作業担当
  • 顧客対応の指揮命令者の役割（PMM）
    • アナウンス
  • モニタリングで検知できたあとに、まずそうだった場合に全体に共有→システム対応の指揮命令者
  • インシデントレベルの定義
    • 事前に定義して、レベルにあわせた対応モードを定義
  • インシデント状況ボード
    • Slackの初期投稿を状況ボードとしている

• irotorisさん @irotoris（ウォンテッドリー株式会社）
  • 年末にICを増やす取り組み
  • 組織 Squad マトリクス構造
  • エンジニア組織は30〜40名程度
  • オンコール担当は仮想的なグループを構築
    • 去年はインフラだけだったので拡充した
  • オンコール担当にフォールバック
  • 専用の #war_room チャンネルに集まって対応
  • https://docs.wantedly.dev/introduction/incident
  • 間違ってもいいから呼んでといわれたのが印象的だった
  • 障害対応周りの文化は会社としての文化が影響するのでは
  • オライリーの入門・監視が参考に
  • ここがむずいよIC
    • こなせるは11%だった
  • 障害対応フローの定義
    • アクションリストを定義
  • ICを決める→一番むずかしい
  • 過去の障害を再現して訓練を積んだ
    • その夜に障害があったが、訓練と本番で異なる
  • 継続的な整備と訓練が重要

  ---

• Q&A
  • アーキテクチャ理解
    • わからなくても良い→詳しい人を呼ぶ
  • 障害時に心拍数があがる
    • 一人でやらない
  • インシデントコマンダーの選出
    • オンコール担当
    • 挙手制
    • Mgrの誰かが→指揮命令者の移譲
  • 作業者へ30分後に教えてください、なにをやるか教えてくださいは大事

  ---

https://firehydrant.com/blog/exploring-distributed-vs-centralized-incident-command-models/

• Topotalの方が共有していたポスト
• 分散型と一元型のメリデメの話
• 分散型は小さくはじめられるかわりに、swivel-chairing、回転椅子のようにタスクに集中できないという課題があるそう
  • 言語特有の表現だが、ICがメイン業務じゃないのでメイン業務とICを切り替えるコンテキストスイッチによる弊害があることを記載していた
• 一元型ではEOC（EngineeringOperationCenter）のように、インシデント専門チームがあれば、誰もが訓練されておりインシデントフローの管理ができる
  • ただ、これは高コストであることがデメリットとある
• 分散型ではじめて、自動化を進めることと訓練と学習について書かれている

感想

インシデントコマンダー（以下IC）の設置に対する各社の取り組みを聞いてみて、率直にとても勉強になった。
イベント参加している企業の規模感を伺ったわけではないが、10人程度から数十人規模のエンジニア組織を抱えており、ICが必要になってきた企業の方の参加が多かったのではと推測している。
全体を通して、インシデント発生時に、ICを機械的に選出することやRunbook（手順書のようなもの）を自動的に用意すること、役割の明確化、インシデントクラスの定義あたりを共通して皆さん仰られていた。
質問に投稿したICの選出について、オンコール担当が明確に分かれている場合には自動選出にしやすそうだが、それ以外はある一定挙手制だったり、SansanさんのようにMgrが担当しているという点は大変参考になった。
特に、Sansanさんの指揮命令者を委譲するというのは、Mgrへの負担減のためにも、不必要にMgrだけに頼らないという点や、インシデントレベルによって判断して落とすことができるという点でうまく仕組み化できてそうに感じた。

上記のTopotalの方がポストしていたICのメリデメについても読んでみたが、概ね数百人規模くらいまでは分散型のIC選出となり、ある一定はICの専門性というよりはサブスキルとして担うことになりそうと思う。
しかし、それでも部署内で訓練や学習をしつつ仕組み化を進めることで、インシデントの解像度をあげることにつなげそうではある。

コロナ禍を経験してから、超久しぶりのオフライン勉強会参加だったが、懇親会も参加して少し話ができたりして実りの多い勉強会だったように思う。
特に、インシデント対応のような機微な情報は過去あまり表立って公開されてきていないように思うし、どちらかというと対応方法によっては批判されてしまうため隠される傾向にあったまである。
そのため、このようなイベントを通じて各社の取り組みがわかるのは有り難かった。

vol2が開催されることを期待しています。登壇者の皆様＆運営の皆様、ありがとうございました！お疲れ様でした！