インシデント指揮官トレーニングの手引き

私が Hashicorp で担った最初の仕事のひとつは、社内向けのインシデント指揮官のトレーニング資料を作ることでした。 これは私自身がインシデントへの対処にあたりながら何年ものあいだ肌身に感じてきた、あらゆる類の考えをまとめ上げる良い機会となり、最高に面白いタスクでした。

以下は私の書いたトレーニング資料、ほぼそのままです。 あなたがインシデントレスポンスのポリシーを定義するにせよ、即興でインシデントレスポンスを行うにせよ、お役に立てたら幸いです。では、どうぞ！

さて、インシデント指揮官になることをお望みですね。

私たちのインシデントレスポンスのやりかたにおいては、インシデント指揮官 の存在が欠かせません。インシデント発生時に指揮をとるのは、やりがいのある仕事です。しかし、おそらくあなたの仕事で発揮したことのないようなスキルが必要になります。それはもしかすると、あなたがこれまでスキルだと思ったことすらないかもしれないようなスキルです！

このドキュメントでは、インシデント指揮官になるにはどのようなことが必要かを説明します。その後で、インシデントの最中にしばしば間違った方向へ行ってしまいがちな事柄の概要や、そのような事態に取り組むための戦略について述べていきます。

インシデント指揮官になるには、まず以下のことをやりましょう:

このドキュメントを読む。
インシデント指揮官リファレンスに親しむ。(筆者注: ここで言及しているリファレンスシートも将来ブログ記事で公開できるように、許可を得ようと試みるつもりです。基本的には、公式な手続きを解説したステップごとの指示書です)
実際のインシデントに取り組んでいるインシデント指揮官のやりかたを見て学ぶ
@inccom のSlackグループに入れてもらう

以上のステップを完了できたら、おめでとうございます！これでインシデント指揮官の仲間入りです。次に誰かが @inccom グループにpingしたら、自ら申し出て仕事を引き受けましょう。インシデント指揮官のリファレンスを参照するのを忘れずに。 Slackのどのチャネルでも start incident と叩けば出てきますから。

インシデント指揮官は何をする？

インシデント指揮官の仕事は、インシデントを解決に向けて動かしていくことです。しかし、インシデント指揮官の仕事は問題箇所を直すことではありません。

インシデント指揮官は、他に手を動かす人が誰もいない状況でもないかぎり、自分でターミナルを触ったりグラフを見たりデプロイしたりしてはいけません。特にエンジニアリングのバックグラウンドを持つ人にとっては、これはやりづらいと感じられるかもしれません。おそらくは、なんだか自分が役に立つ仕事をしていないかのような気分になるでしょう。しかし覚えておくべきことは、普段のあなたの仕事が何であれ、インシデント指揮官になったときはインシデント指揮官に徹するのがあなたの仕事だということです。

自分では何も直すことなく、インシデント対応を解決に向けて動かすにはどうしたら良いのでしょうか？まず、複数人のチームで取り組めばインシデント対応は前進します。インシデント指揮官の仕事は、チームが同じ認識を持つ状態を作り上げてキープすることです。それは集中を要する高度なタスクで、3つの要素からなります:

インシデント対応のための階層型組織を浸透させる
究極の意思決定者になる
情報展開をファシリテートする

上記について順番に解説していきましょう。

インシデント対応のための階層型組織を浸透させる

インシデント発生時は、問題に取り組む人たち全員が特定の役割を持っています。決まり事として、ロールが明示的にアサインされていない人は、問題に取り組んではいけません。関与する全ての人が、自分が何の責務を負い、誰に対し説明責任があるのかを知っていることが肝要です。

インシデントレスポンスには、早急に任命された後インシデントがクローズされるまで欠かすことのできない、4つの 主要ロール があります。インシデント指揮官リファレンスシートに詳しく書かれている通り、インシデント指揮官には、Slackチャンネルのトピックで主要ロールに誰が就いているのかを、最新の状態に保つ責務があります。

主要ロールは以下の通りです。

インシデント指揮官 (IC = Incident Commander) - あなたです！
主任SME (SME = Subject Matter Expert) - 問題に対し技術的な調査を行う
外部通信役 (External Liaison) - インシデントに関する顧客との連絡を司る
書記官 (Scribe) - Slackにインシデントに関するノートを書き、フォローアップが必要な項目を追い続ける

インシデントの最初期には、インシデント指揮官としてのあなたは、上記のうち複数のロールを兼任する必要があるかもしれません。ですが契機が来たらすみやかに、他のロールは他の人にアサインしましょう。もしくは、あなた自身が問題解決に最適な人物ならば、他の人をインシデント指揮官にアサインして、自分自身は主任SMEを務めましょう。

誰かをロールにアサインするときは、宣言的にやるのが良いです。「誰か、書記をやってくれる人はいないかな？」と尋ねる代わりに、誰か特定の人を選んで「(相手の名前)、このインシデントの書記官をやってくれないか？」と言ってみましょう。

インシデントレスポンスに4人だけでは足りないことは非常によくあります。しかし前述したように、インシデントに関与する人たち全員が、自分が何の責務を負い、誰に対し説明責任があるのかを知っていることが肝要です。このため、誰か新しい人がインシデントに取り組み始めたいというときは、その人を主要ロールにアサインするか、すでにアサインされている人の直属のロールにアサインしなければなりません。たとえば、外部連絡役が顧客とのコミュニケーションで手いっぱいになっていて助けを求めていたならば、次に相当するようなことを言ってみると良いでしょう：「(相手の名前)、これからは君は副外部通信役だ。報告先は 外部通信役 である。確認してほしい。」

誰が何に責任を持つのかについては、インシデントに関わる全員が、インシデント管理者へ最終的な判断を仰ぐ必要があります。これは究極の意思決定者たることの一部です。

柔軟さこそがあなたの特権

事前に定められたインシデントの階層型組織は、大半のシナリオに合致するようデザインされたものです。ときには、その組織構造ではあまりうまくいかないインシデントもあるでしょう。インシデント指揮官は、その時々のケースに合わせて、目の前のインシデントに一番合う形へ階層型組織を変更する権限を持ちます。慣例に固執するあまり、あなたのもたらす効果が阻害されることがないようにすることが重要です。あなたは、その場に合うようにシステムを一時的に変更する力を持つのです。

たとえば、主任SMEを複数設けるのもアリかもしれません。もしインシデントが複数システムに跨って影響するなら、各システムに対しSMEを選んでも良いでしょう。複数のSMEをアサインする手続きはSMEが一人の場合と同じですし、彼ら彼女らの責任についても同様です。こんな風に言うと良いでしょう:「(相手の名前)、これから君は (特定の責任範囲) における主任SMEである。確認してほしい。」

究極の意思決定者であれ

インシデント指揮官が「究極の意思決定者」だと言われるとき、それはなんらかのより優れた決定ができることを期待されているという意味ではありません。私たちの意味するところは、インシデント関係者の全員が、インシデント指揮官の決定を最終的で拘束力のあるものとして受け止めるということです。いつも正しい決定をすることにそこまで重きを置くのではなく、あなたが一つの決定を下すことが重要なのです。

インシデント指揮官が決断を下せる状態にあることで、他の人たちはインシデントに要求されるがままに振る舞えるようになります。果たしてあの対応でよかったんだろうかと後悔したり、メリットデメリットを検討するのに多くの時間を割いたりする代わりに、皆はあなたに重要な決断を託すことができるのです。情報さえ入手できれば、あなたはどの道に進むのが一番良いかを選ぶことができるでしょう。そしてあなたの決断は最終的で拘束力を持ちますから、決断そのものによって皆が同じ認識を持つ状態を保てるようになります。

もう一つ、前述の点ほど明確ではないけれども、究極の意思決定者としてのインシデント指揮官の恩恵があります。皆が本番環境で起きている問題について調べていたり、顧客対応に追われていたりする最中は、各人は絶え間なく他の人たちが把握していないコンテキストを構築しています。そのような人たちは自分の心理状況を十分に説明し、インシデント指揮官が素直な内容で重要な決定を下せるよう協力しましょう。これはインシデントが起きている間、情報が十分に行き渡るようにする手段の一つです。

情報展開をファシリテートせよ

情報の流れを管理することは、インシデント指揮官にとってただ一つ、最も重要な責務です。

インシデントの最中の情報というと、たいてい私たちは遠隔システムから出てくるデータや、実行するコマンドの出力結果について考えます。私たちが一番手軽に広めがちなのは、この手の情報です。しかしインシデント指揮官は、このように具体的で、見つかっている情報だけを気にしていれば良いわけではありません。

インシデントレスポンスでは、関与している人たち全員の頭の中にも情報があります。誰もが、インシデントに対して異なる視点を持っています。そして概してこの人たちは、他の人たちが探しているイメージの断片を自分が持っていることに気づいていません。したがってインシデント指揮官は常に、有用なコンテキストを皆の頭の中から引き出し、共有ナレッジの中に持ってくる機会を窺うべきです。

情報展開をファシリテートする上で鍵となるのは、 シグナル対ノイズ比 です。「シグナル」はインシデント解決に向けて利用できる情報を意味し、「ノイズ」はそうではない情報を意味します。このため、誰かに届ける必要のある情報が存在するときは、インシデント指揮官はシグナルを強化して、正しい所に届くようにしましょう。逆に、チャンネル内の誰かが関係ないシステムの挙動をアップデートしてきたり、ビデオ会議の中の誰かが重複した状況アップデートを求めてたりしていたら、ノイズを抑制するのがあなたの仕事です。

簡潔にいえば、インシデント指揮官は、全てのインシデント関連のコミュニケーションチャネルを高シグナル・低ノイズな環境に保つ責任を持つのです。

インシデントレスポンスが横道に逸れるとき

インシデントは一つ一つ異なるものですが、インシデントレスポンスの方向性が失われてしまう典型例をいくつか知っておくと便利です。これらのアンチパターンに陥っていると気づいたら、チームが元の道に戻れるよう、以下に示す戦略を適用しましょう。

主題がブレる

おそらく最もありがちなインシデントレスポンスのアンチパターンは 主題のブレ (thematic vagabonding) です。これは、対応者が一般的な調査領域に対して次から次へと手をつけては他へ移っているような状態です。以下のようなことに気づいたら、主題のブレが生じているサインです:

対応者が、具体的に何が悪そうなのかについて考えを述べることなく、手がかりを求めていろいろなところを探し回る。
問題の性質に対する考えが「たぶんAPIレイヤーが何かおかしい」程度の曖昧さに留まっている。曖昧なアイデアを行動につながる理論へ落とし込めるような推進力に欠けている。
主任SMEの一連の考えについていくのが難しくなっている。

主題のブレはノイズの根源です。たくさんの情報を生み出しますが、意味のある情報としてまとめられるものではありません。

もし主題のブレに気づいたら、主任SMEに対して、どのような考えから各々のアクションを取っているのかを聞くのを始めてみると良いでしょう。たとえば「データーベースのエラーログを調べている」と言われたら、「データベースにエラーがありそうだという考えに至った理由は何かな？」といった返しをしてみます。調査の中、どのようにしてデータベースの課題から問題が引き起こされうるのかや、なぜデータベースのエラーログによって根本原因を突き止められそうなのかをを説明するよう、主任SMEたちをかき立ててみましょう。

もし主題のブレが主任SMEからではなく他のロールの人たちから生じたのならば、その人たちの注目を主任SMEが調べていることへ向けるのが良いでしょう。たとえば、主任SMEがロードバランサーの異常を調べているのに、他の誰かが「最近のデプロイで大きな変更がなかったか調べてみようか」と提案してきたら、あなたは「その前に、ロードバランサーの異常へ十分に目を通しておきたい。<主任SMEの名前>、怪しそうなログの内容を解釈するのに助けがいるんじゃないかな？」と言ってみてもよいでしょう。

視野狭窄に陥る

視野狭窄 (tunnel vision) はある意味、主題のブレとは逆の現象です。対応者が、もはや生産的なアイデアではないにも関わらず、間違っている可能性のある特定の考えにハマってしまった状態です。視野狭窄は、調査担当者が、調査を次のフェーズへ推し進めるためのシグナルを入手し損ねた時に起こります。

主題のブレとは逆の症状ではありますが、視野狭窄に対しては似たようなアプローチで取り組むことができます。調査担当者に、どのような動機から調査しているのかを詳しく説明してもらうのです。ときどき、説明を繰り返しているうちに本人たちがドツボにはまっているのに自分で気づいたりします。

もう一つ視野狭窄を止める上で便利な戦略は、対応者に反証となるエビデンスを探してもらうことです。たとえば、主任SMEが調査中に特定のコード変更がまずかったのだという考えにハマっているのだけれども、実を結ぶ様子がみられなかったら、こう尋ねてみましょう。「もし、この変更が問題の原因ではないことを証明するとしたら、どうやって証明する？」このように概念的な見方の転換を行うことで、必然的に調査者は狭いトンネルの外のアイデアに目を向けることとなり、しばしば前進を再開することにつながります。

一貫性のないメンタルモデル

効果的に協業するために、インシデント対応者たちは、調査中の問題がどのようにして引き起こされうるかについて、一式のアイデアを共有している必要があります。このようなアイデアのことを 仮説 (hypotheses) と呼びます。

仮説が不足していたり不十分なコミュニケーション下にあったりすると、インシデント対応は停滞する傾向にあります。インシデント指揮官にとっては、どの仮説がいま盛り上がっていて、どの仮説がすでに却下されているのか、対応者全員が同じ認識のもとにあるようにすることも仕事の一つです。さらに、どの仮説を契機に皆が調査のアクションへ向かっているのかの経過を追うのは良い考えでしょう。もしあなたが、なぜ主任SMEがキューイングのメトリクスについて調べているのかはっきり理解できないのであれば、先に進むより前に、おそらく彼ら彼女らの思考プロセスを説明するようお願いしてみるべきです。

ときに、調査対象となるような明確な仮説がもう残っていない状態になると、インシデント対応の進捗は遅滞するか停止します。この状態が明言されないと、対応状況は主題のブレや視野狭窄に陥ってしまうことがあります。あなたが仮説の枯渇に気づいたときは、進行中の調査を一旦すべて止めてもらい、新しい仮説を得るべくブレインストーミングするよう呼びかけることが有用です。すると、一部のメンバーにはこれが時間の無駄のように感じられ、反発を受けることもあるでしょう。しかし時折、具体的な復旧作業に進むためには、抽象的なアイデア思考をする必要があるのです。

インシデント指揮官と主任SME間の分断

インシデント指揮官と主任SMEの認識がズレると、もっともまずい大惨事につながります。インシデントレスポンスでの取り組みにおける全メンバー間の関係の中で、この二者間の関係はもっとも重要なものです。実際、あまりにも大事なので、インシデント指揮官と主任SMEの関係を良好に保つことだけを目的としたプロセスがあります。これを、 ハンズオフ状況アップデート (hands-off status update) と呼びます。

インシデントの最初期、インシデント指揮官と主任SMEがビデオ通話にアサインされて参加したら、インシデント指揮官は速やかにハンズオフ状況アップデートを要請しましょう。「ハンズオフ」というからには、状況アップデートが終わるまでの間、どちらの側もキーボードを叩いたりクリックしたり、また何かを読んだりしてはいけません。両者が、完全にお互いとのコミュニケーションだけに集中する必要があるのです。

ハンズオフ状況アップデートは、5つの質問から成り立ちます:

ハンズオフ状況アップデートをしたいのだが、準備は良いか？ この質問は、ハンズオフ状況アップデートが始まることを改めて知らせて、インシデント指揮官と主任SMEがそれに集中するよう促します。もし、主任SMEがまだ準備できていないと言うのであれば、今から60秒後だったらできるか聞いてみましょう。
想定できる範囲で、どのくらいの影響が出ていると思うか？ 現在進行形で調査中の問題によって、何人の顧客が影響を受けているか、どれくらいカスタマーエクスペリエンスに混乱が生じているかは、常に明確であるとは限りません。それでも、主任SMEに一考してもらうのは役に立つものです。
ありうる根本原因は何だと考えているか？ この質問は、主題のブレや視野狭窄に陥るのを、未然に防ぐのに役立ちます。主任SMEが思考プロセスを声を出して明言することにより、ビデオ会議の中の全員 (主任SMEたち自身を含む) が、このさき進む道をはっきり意識できるようになります。
次に取れる一手は？ 根本原因に対する認識が薄れないうちに、問題解決の次のステップを確立する機会を設けましょう。インシデント指揮官にとっては、主任SMEの言っている次の一手が、前の二つの質問で聞いた想定影響と根本原因からみて妥当であるものかを確認することが責務です。
協力を要請したい人はいるか？ 最後に、誰かインシデント対応を進める上で有用なスキルを持った個人がいるか、主任SMEに考えてもらう機会を作ります。誰かの名前が挙がったら、全力でインシデントレスポンスのチャンネルやビデオ会議に参加してもらうよう働きかけ、さらに可能であれば、彼ら彼女らを主任SME直属のSMEに任命しましょう。

インシデント指揮官リファレンスシート

一貫性のある役割分担や情報のハンドリングを確かなものにするために、インシデント指揮官のリファレンスシート内に標準的な手続きを定義しました。インシデント指揮官に志願する前に、リファレンスシートを見直しましょう。読みながら、インシデント指揮官の３つの責務を思い出してください。

インシデント対応のための階層型組織を浸透させる
究極の意思決定者になる
情報展開をファシリテートする

※訳注: 現時点では、リファレンスシートそのものは公開がHashiCorp社内に限られているため、当記事上での公開はありません。