こんにちは Topotal エンジニアの高谷(@nerdyboy_cool)です。
今回も「Incident Management For Operations」を題材にインシデントマネジメントサービスについて書いていきたいと思います。
前回のおさらい
前回の記事ではインシデントマネジメントの起源に触れつつ、「Reactor」と「Responder」という重要なキーワードについて取り上げました。
Reactor、Responder ともにインシデントに対して具体的なアクションを起こす人という点では共通していますが、「Responder」の方が障害に対してより責任を持った行動を取るメンバーであることがわかっていただけたかと思います。
| 項目 | Responder（レスポンダー） | Reactor（リアクター） |
|---|---|---|
| 専門性 | 特定の問題解決に対して訓練されている | 訓練されていない、準備不足 |
| 協調性 | 組織化されている、規律がある | 協調性がない |
| 問題へのアプローチの姿勢 | 統一された視点で問題に取り組む | それぞれ異なった視点で群がる・見解を持つ |
| プレッシャー下における対応 | 冷静でプレッシャーの下でも冷静に対処 | 慌てふためく、感情的になりがち |
しかし、優秀な Responder が存在するだけではインシデントを素早く・適切に収束させることはできません。 今回の記事ではインシデントにおける指揮官である Incident Commander について取り上げつつ、 Commander の仕事がいかに複雑で大変なものかということを私なり考察したいと思います。
Incident Commander とは
インシデント・コマンダー（Incident Commander; IC）は、インシデントが発生した際に、その対応を現場で指揮し、解決へと導くリーダーを指します。
インシデントが発生すると状況は「通常時(Peacetime)」から「戦時体制(Wartime)」へと移行します。このような緊急事態において、各自が勝手に動き出して統率が取れていない状態では、素早く正常な状態に戻すことはできません。
本著ではリーダー(= Commander) が行うべきことを下記のように定義しています。
- Responder グループが問題を正確に把握していることを担保する
- 主要なデータ・メトリクスから、アクションプラン構築の議論を促進する
- 時間に配慮する
- 問題を解決するのに必要なリソースプールへのアクセスをもつ
- 分野を横断したコミュニケーションを確立
- 主要プレイヤーにリアルタイムに情報提供
Commander はインシデント対応におけるオーケストレーターです。つまり、問題を直接的に解決するのではなく「情報の統制」「意思決定の促進」「組織の橋渡し」が求められます。Responder たちが最大限のパフォーマンスを発揮できるよう、情報・時間・リソース・コミュニケーションという4つの要素をマネジメントするのがCommanderの仕事となります。
Incident Commander がなぜ難しいのか
Commander に要求される能力は多種多様ですが、今回は「状況把握」というトピックに絞って難しさを考えてみたいと思います。
インシデントが発生すると、Commanderはさまざまなステークホルダーとの情報共有をしなければなりません。復旧に関するエンジニアチームとのコミュニケーションはもちろんのこと、顧客とのやりとりを担当するカスタマーサービスチーム、重要な意思決定に関する経営層とのコミュニケーションなどです。
さらに、これらのコミュニケーションは互いに依存し合っているため、完全に並行して進めることができません。Commander はインシデントを最短で収束させるべく、最適な順番で効率的なコミュニケーションを随時行っていく必要があります。大抵のケースでは、Commander の脳内メモリにこれらの情報が格納され実行されますが、インシデントという心拍数が上がるイベントにおいてミスなく行動を選択し、実行するのは非常に難しいです。
]
そして、これらの複雑なコミュニケーションを行うことができるメンバーが限られているというのも Commander をより難しいものにしています。 本著では、Commander は必ずしもその技術領域の専門家や管理職である必要はないとされていますが、実際のところ複雑なタスクを処理できるメンバーはこれらの役職についているケースが非常に多く、「Commander を担える人材が少ない」という問題が起こりがちです。
「難しさ」に対する Waroom の回答
Commander にはさまざまな情報を整理し、適切に管理・統制する責務がありますが、ストレスフルな状況下でこれを行うのは非常に難しいことです。 そのため、Waroom には「Incident State Document」というインシデント中に発生した事象を AI でまとめる機能があります。
この機能は、インシデント起票時に作成される対応用 Slack チャンネルに投稿されたメッセージをリアルタイムで要約します。これにより、インシデント中に起こったイベントを誰でも Waroom から確認できるため、Commander が情報共有に割く負担を大幅に軽減できます。 また、ドキュメントのテンプレート機能を活用すれば、要約内容を「顧客向け」の文章としても利用できます。
一方で、Incident State Document のように現在の状況を文章ベースで整理してくれる機能は存在しますが、より複雑な状況を視覚的に表現する機能はまだありません。 そこで将来的には、Commander 向けの状況整理用コンソールの実装を構想しています。その画面では、以下のような情報を視覚的に閲覧できるようにするイメージです:
- 各 Responder のタスク一覧と進行状況
- インシデント中に発生した重要イベントの記載
- ステークホルダーとの循環的で複雑なやり取りの可視化(Runbook のような直線的な進行ではなく)
加えて、タイムマネジメントなどの時間管理業務についても AI を活用して代替できるようにしたいと考えています。
この手法がうまくいけば Commander はコンソールに存在する手順を順々に実行もしくは承認していけば良いことになるので Commander 不足の問題も解決する一手となると考えています。
最後に
今回の記事では、「Commander」に求められる能力や難しさについて取り上げました。 特に、Commander がマネジメントすべきリソースのうち「情報」を、複数の相手に適切な順序・タイミングで共有する難しさについてわかっていただけたかと思います。次回は再び Incident Commander に焦点を当てつつ、メイントピックである IMS(インシデントマネジメントシステム)について取り上げていく予定です。
最後に少し宣伝をさせてください..
Topotal では「インシデント対応を楽にする」Waroom バックエンドエンジニア（Ruby on Rails）を募集しています。 最近では、Waroom をより便利に活用できるような機能として Webhook 機能を絶賛開発中です。エンジニアとしてインシデント対応中にあったらいいな！と思える機能も積極的に取り組んでいますのでぜひ、気になった方はカジュアル面談の予約をお願いします！
