障害が起きた直後の会議室やチャットは、たいてい人が多いのに前に進みません。
全員が同じログを眺め、同じ推測を口にして、誰も「次に何をするか」を決めないまま時間だけが溶けていく。
この状態を避けるために置かれる役割が、インシデントコマンダーです。
筆者はテックリードを目指して学んでいる立場なので、Google の SRE 本と PagerDuty が公開している対応マニュアルを読み比べて、この役割の輪郭を整理しました。
要点は、技術を一番知っている人が指揮を執るとは限らないという一点に集約されます。
インシデントコマンダーは「手を動かさない人」
まず役割の分担から確認しましょう。
Google の SRE 本は、障害対応を指揮・実作業・情報連携・記録の 4 つに分けると説明しています。
インシデントコマンダーはこのうち指揮を担当し、障害全体の状況を把握して、誰に何を任せるかを決める役割。
実際にコマンドを打つのは Ops リードの仕事で、SRE 本は「対応中にシステムへ変更を加えてよいのはこのグループだけ」とまで書いていました。
外向きの連絡係が Comms リード。
社内外への定期報告とステータスの更新は、この人がまとめて引き受けます。
さらに Planning が、バグ票の起票や引き継ぎ、通常運用からのずれの記録といった長い時間軸の仕事を担当。
この分け方の肝は、コマンダーが自分の手でデバッグしないと決めているところ。
手を動かし始めた瞬間に全体が見えなくなるので、あえて空けておく役割だと理解すると腑に落ちます。
「宣言する」ことがいちばん難しい
役割表よりも実務で効くのは、いつインシデントとして宣言するかの基準でした。
SRE 本は、別のチームを巻き込む必要があるとき、顧客に影響が出ているとき、集中して 1 時間調べても解決しないときのいずれかに当てはまるなら宣言する、という目安を挙げています。
裏を返せば、この 3 つに当てはまるのに宣言しないまま個人が抱えている時間が、いちばん危ないわけです。
宣言を早めにできるかどうかは、心理的なハードルの問題でもあります。
「大げさだと思われたくない」という感覚が働くと、基準があっても使われません。
だから SRE 本は、障害対応の手順を日常的に使うことと、役割を持ち回りにすることを勧めています。
宣言が特別な行為でなくなれば、ハードルは自然に下がるはず。
PagerDuty の対応マニュアルも同じ発想で、コマンダー役の訓練を独立したドキュメントとして公開していました。
テックリードが最初に整えるのは「引き継ぎ」
では、この役割をチームに持ち込むとき、テックリードは何から手をつけるべきでしょうか。
SRE 本が挙げるベストプラクティスのうち、準備段階で効くのは 3 つに絞れます。
- 優先順位を決める（出血を止める、サービスを戻す、証拠を残す、の順）
- 手順を先に文書化しておく（障害の最中に設計しない）
- 任せた相手の判断を信頼する（細部まで指示しない）
このうち一番忘れられがちなのが、対応が長引いたときの引き継ぎです。
指揮が明示的に引き継がれないまま担当者が疲弊していくと、誰が指揮しているのか分からない時間帯が生まれます。
SRE 本には、負荷が高くなったら役割を委譲するか、サブインシデントに分割するという考え方が示されていました。
「自分が全部見る」を諦める設計、と言い換えてもよさそうです。
引き継ぎの型といっても大げさなものは要らず、現在の仮説・試したこと・次に打つ手の 3 点を口頭で読み上げるだけでも成立します。
交代のたびに同じ 3 点を読み上げると決めておけば、記録が自然に残るという副産物もついてきますね。
残った記録は、収束後に書くポストモーテムの材料としてそのまま使えるはず。
なお、こうした運用の前提には「どこまで落ちてよいか」の合意があります。
最後に
インシデントコマンダーは、技術力の順位で決まる役割ではありません。
状況を把握し、分担を決め、外に伝えるという 3 つを引き受ける人、という定義でした。
テックリードとして最初にできるのは、宣言の基準を書き出して、引き継ぎの型を用意しておくこと。
着任直後に何から優先するかという話は、最初の 90 日の使い方を整理した記事にもつながります。
障害の最中に設計しなくて済む状態を、平時のうちに作っておきたいですね。
参考: Google SRE Book – Managing Incidents / PagerDuty Incident Response – Incident Commander
以上です。
コメントを残す