こんにちは Topotal エンジニアの高谷(@nerdyboy_cool)です。
ITエンジニアなら、大なり小なりインシデント対応を経験したことがあるかと思います。
サービス障害が起きたときの復旧作業や、原因調査、事後の振り返りなど、日常的な業務の一部として取り組んでいる方も多いのではないでしょうか。 ただ、こうした馴染み深いインシデント対応にも、実は体系化されたフレームワークや手法が存在することはご存知でしょうか？
私自身、以前インシデント対応は「なんとなく」で進めていて、体系化された仕組みがあることは知りませんでした。
そこで今回は、私がインシデントレスポンスを学ぶ上で大変参考になった「Incident Management For Operations」という書籍を題材に、「IMS」「STAR」といったインシデントマネージメントの重要なトピックを数回に分けて紹介したいと思います。 同じように初めてインシデント対応を学ぶ方の参考になれば幸いです。
今回は、インシデントマネージメントの起源に触れつつ、重要な用語である「Responder」「Reactor」を取り上げます。
インシデントマネージメントの起源
インシデントマネージメントシステム（IMS）は、1970年代に南カリフォルニアを襲った一連の壊滅的な森林火災をきっかけに誕生しました。これらの森林火災では、州内外から多数の消防士が出動したものの、対応における共通のフレームワークやリーダーシップ体制が整備されておらず、甚大な被害をもたらしました。この経験を受けて、消防関係者によって緊急事態を体系的に管理するための仕組みが開発されました。
消防とITサービスには一見すると類似性がないように思えるかもしれません。しかし、「異常な状態」から「正常な状態」に回復させるという本質的な目的は同じであり、この観点から見ると両者のインシデント対応には類似性があります。
実際、著者もこのように述べています。
The great thing about IMS is that it applies to any kind of emergency response, and is blind when it comes to the nature of the problem.
(IMSの素晴らしいところは、どのような緊急事態にも対応可能で、問題の種類に関係なく適用できることです。)
私たちも、気づかないうちに緊急事態に対してリーダーシップ体制を確立し、適切な担当者を配置して対応にあたるというアプローチをとっているかと思います。今回取り上げるResponder役割も、用語は知らないにせよ実態については我々が実際にインシデントに対処する際に馴染み深いものばかりです。
この先の章では、IMSの観点から以下の点について触れていきます
- ResponderとReactorの違いについて
- 優れたResponderになるために必要なこと
今回の記事だけでも、すぐに意識・実践できるポイントがあると思います。
Responder VS Reactor
Incident response is a people to people endeavor, and therefore, the demeanor of the people and how the work together as a team is vital!
(インシデントレスポンスは人と人との取り組みであるため、人々の態度やチームとしての協力体制が重要である！)
IMS には Responder という概念が存在します。Response（反応）と聞くと、インシデントが起きた際にいち早くリアクションを起こしてくれる人のこと？と考えてしまいますが、実際には少し異なり、Responderはインシデントが起こった際に実際に対応にあたるメンバーのことを指します。一方、単に反応し、状況を悪化させてしまうメンバーのことを本著では Reactor と呼んでいます。
この Responder と Reactor の違いは下記のようになっています。
| 項目 | Responder（レスポンダー） | Reactor（リアクター） |
|---|---|---|
| 専門性 | 特定の問題解決に対して訓練されている | 訓練されていない、準備不足 |
| 協調性 | 組織化されている、規律がある | 協調性がない |
| 問題へのアプローチの姿勢 | 統一された視点で問題に取り組む | それぞれ異なった視点で群がる・見解を持つ |
| プレッシャー下における対応 | 冷静でプレッシャーの下でも冷静に対処 | 慌てふためく、感情的になりがち |
Responderはインシデントの解決に対して責任を持って行動するのに対して、Reactorは自分の関心ごとについて反応（= React）し、現場を混乱させるという風に捉えることができます。実際、私がインシデント対応について全くの無知だったころは、不適切な状況・タイミングでの情報提供や効果的でない手順による修正を連発するなど、現場を混乱させる対応をよくしていました。
平時(Peacetime) と戦時(Wartime)、そしてレシピ
では、Reactor ではなく 良き Responder になるためにはどんなことが必要なのでしょうか？
本著では下記のように記されています。
all individuals responsible for solving the problem must shift his or her thinking, decision-making, from Peacetime to Wartime
(問題解決に関わるすべての人は、その思考と意思決定を平時から戦時へと切り替えなければならない。)
Wartime とは、いわゆるサービスがダウンしたり、インフラが異常な状態を示し問題が発生している緊急モードを指します。 「そんなこと当たり前では？」と思うかもしれませんが、ここで重要な点は Peacetime と Wartime は評価される指標・目標・取り組みが根本的に異なる点です。
平時では、基本的に日常の業務から目標を達成することによって企業として収益を上げることが重要です。しかし、戦時においては「一刻も早く」状況を改善するために最良の選択をすることが評価されます。復旧までの時間を最小にし、サービスの信頼性を上げることが何よりも重要です。評価される環境・軸が根本的に異なることを認識して、我々は備えなければなりません。
しかし、マインドセットの切り替えだけでは不十分です。本著にも下記のように記されています。
Having a responder (Wartime) mentality, however, is just the tip of the iceberg when it comes to resolving IT problems. There must be a process for the responders to follow.
(しかし、レスポンダー（戦時）のメンタリティを持つことは、IT問題を解決する上では氷山の一角に過ぎない。レスポンダーが従うべきプロセスが存在しなければならない。)
皆さんも対応中には以下のようなことを実践しているかもしれません。
- 各対応者への通知やコミュニケーションパスの確立
- 顧客へのアナウンスメント
- サービスにおける重大度の設定
- 上長へのエスカレーション
- 根本原因の特定
- 復旧のための定常業務
こういった業務を事前にインシデントレスポンスにおけるフローを事前にレシピとして用意・準備しておくことが必要です。 このような整備がなければどんなに技術的に長けたメンバーでも対応ごとに質がばらつき、対応そのものを評価し改善することはできません。
もしこのような整備が行われていない場合、まずは大雑把に「重大度」を設定して、ステークホルダーに対してコミュニケーションを取るという風にルールを決めるのも良いでしょう。対応の収束後、実際に行われた「いいアクション」をレシピに追加していき「次のインシデント」に備えることで改善のプロセスを回していくことが重要です。
重大度における考え方やベストプラクティスについては弊社 @nari-ex による記事もぜひご覧ください。 インシデントの重大度（Severity）とは？組織的なインシデントレスポンスに役立つプラクティスのご紹介 - Topotal Blog
コラム: Waroom におけるレシピ
弊社では、「インシデントのつらい」を解決するインシデントマネージメントサービス Waroom(ワルーム)を提供しています。
Waroom にはこれまで紹介した「レシピ」に該当する Runbook という対応手順書をステップバイステップで実行できる機能があります。 この機能は Responder の対応時おける属人化を解決するための機能となっており、インシデント対応フローを整備したい方に最初におすすめしている機能になります。
docs.waroom.com
登録すると、デフォルト Runbook と呼ばれる手順書がすでに準備されており、自社特有の運用フローを追加していきながら、「誰でも」対応できるようにインシデントに備えることができます。インシデントごとに Runbook の出しわけができるので「認証エラー」「インフラ」など状況に応じた手順書を事前に用意することができます。
最後に
今回の記事では、「Reactor」ではなく良き「Responder」になるための重要な心構えや準備について取り上げました。馴染み深い役割でありながらも「自分は Reactor になっていないだろうか？」など気づきを得られるポイントがいくつかあったと思います。 次回は、「Responder」を束ねるリーダー「Commander」の重要性や求められる役割について取り上げる予定です。
最後に少し宣伝をさせてください..
Topotal では「インシデント対応を楽にする」Waroom バックエンドエンジニア（Ruby on Rails）を募集しています。 生成AIやSlack Appの開発など技術的に面白いトピックがたくさんあるので、興味がある方はぜひカジュアル面談のお申し込みをお願いします！
