誰が何に責任を持つのかについては、インシデントに関わる全員が、インシデント管理者へ最終的な判断を仰ぐ必要があります。これは究極の意思決定者たることの一部です。事前に定められたインシデントの階層型組織は、大半のシナリオに合致するようデザインされたものです。ときには、その組織構造ではあまりうまくいかないインシデントもあるでしょう。インシデント指揮官は、その時々のケースに合わせて、目の前のインシデントに一番合う形へ階層型組織を変更する権限を持ちます。慣例に固執するあまり、あなたのもたらす効果が阻害されることがないようにすることが重要です。あなたは、その場に合うようにシステムを一時的に変更する力を持つのです。主任SMEを複数設けるのもアリかもしれません。インシデントが複数システムに跨って影響するなら、各システムに対しSMEを選んでも良いでしょう。複数のSMEをアサインする手続きはSMEが一人の場合と同じですし、彼ら彼女らの責任についても同様です。おける主任SMEである。究極の意思決定者であれインシデント指揮官が「究極の意思決定者」だと言われるとき、それはなんらかのより優れた決定ができることを期待されているという意味ではありません。私たちの意味するところは、インシデント関係者の全員が、インシデント指揮官の決定を最終的で拘束力のあるものとして受け止めるということです。いつも正しい決定をすることにそこまで重きを置くのではなく、あなたが一つの決定を下すことが重要なのです。インシデント指揮官が決断を下せる状態にあることで、他の人たちはインシデントに要求されるがままに振る舞えるようになります。あの対応でよかったんだろうかと後悔したり、メリットデメリットを検討するのに多くの時間を割いたりする代わりに、皆はあなたに重要な決断を託すことができるのです。情報さえ入手できれば、あなたはどの道に進むのが一番良いかを選ぶことができるでしょう。あなたの決断は最終的で拘束力を持ちますから、決断そのものによって皆が同じ認識を持つ状態を保てるようになります。一つ、前述の点ほど明確ではないけれども、究極の意思決定者としてのインシデント指揮官の恩恵があります。皆が本番環境で起きている問題について調べていたり、顧客対応に追われていたりする最中は、各人は絶え間なく他の人たちが把握していないコンテキストを構築しています。そのような人たちは自分の心理状況を十分に説明し、インシデント指揮官が素直な内容で重要な決定を下せるよう協力しましょう。これはインシデントが起きている間、情報が十分に行き渡るようにする手段の一つです。情報展開をファシリテートせよ情報の流れを管理することは、インシデント指揮官にとってただ一つ、最も重要な責務です。インシデントの最中の情報というと、たいてい私たちは遠隔システムから出てくるデータや、実行するコマンドの出力結果について考えます。私たちが一番手軽に広めがちなのは、この手の情報です。インシデント指揮官は、このように具体的で、見つかっている情報だけを気にしていれば良いわけではありません。インシデントレスポンスでは、関与している人たち全員の頭の中にも情報があります。誰もが、インシデントに対して異なる視点を持っています。この人たちは、他の人たちが探しているイメージの断片を自分が持っていることに気づいていません。したがってインシデント指揮官は常に、有用なコンテキストを皆の頭の中から引き出し、共有ナレッジの中に持ってくる機会を窺うべきです。「シグナル」はインシデント解決に向けて利用できる情報を意味し、「ノイズ」はそうではない情報を意味します。このため、誰かに届ける必要のある情報が存在するときは、インシデント指揮官はシグナルを強化して、正しい所に届くようにしましょう。逆に、チャンネル内の誰かが関係ないシステムの挙動をアップデートしてきたり、ビデオ会議の中の誰かが重複した状況アップデートを求めてたりしていたら、ノイズを抑制するのがあなたの仕事です。簡潔にいえば、インシデント指揮官は、全てのインシデント関連のコミュニケーションチャネルを高シグナル・低ノイズな環境に保つ責任を持つのです。インシデントレスポンスが横道に逸れるときインシデントは一つ一つ異なるものですが、インシデントレスポンスの方向性が失われてしまう典型例をいくつか知っておくと便利です。これらのアンチパターンに陥っていると気づいたら、チームが元の道に戻れるよう、以下に示す戦略を適用しましょう。これは、対応者が一般的な調査領域に対して次から次へと手をつけては他へ移っているような状態です。以下のようなことに気づいたら、主題のブレが生じているサインです:対応者が、具体的に何が悪そうなのかについて考えを述べることなく、手がかりを求めていろいろなところを探し回る。問題の性質に対する考えが「たぶんAPIレイヤーが何かおかしい」程度の曖昧さに留まっている。曖昧なアイデアを行動につながる理論へ落とし込めるような推進力に欠けている。主任SMEの一連の考えについていくのが難しくなっている。主題のブレはノイズの根源です。たくさんの情報を生み出しますが、意味のある情報としてまとめられるものではありません。主題のブレに気づいたら、主任SMEに対して、どのような考えから各々のアクションを取っているのかを聞くのを始めてみると良いでしょう。「データーベースのエラーログを調べている」と言われたら、「データベースにエラーがありそうだという考えに至った理由は何かな?」といった返しをしてみます。調査の中、どのようにしてデータベースの課題から問題が引き起こされうるのかや、なぜデータベースのエラーログによって根本原因を突き止められそうなのかをを説明するよう、主任SMEたちをかき立ててみましょう。主題のブレが主任SMEからではなく他のロールの人たちから生じたのならば、その人たちの注目を主任SMEが調べていることへ向けるのが良いでしょう。主任SMEがロードバランサーの異常を調べているのに、他の誰かが「最近のデプロイで大きな変更がなかったか調べてみようか」と提案してきたら、あなたは「その前に、ロードバランサーの異常へ十分に目を通しておきたい。<主任SMEの名前>、怪しそうなログの内容を解釈するのに助けがいるんじゃないかな?」と言ってみてもよいでしょう。ある意味、主題のブレとは逆の現象です。対応者が、もはや生産的なアイデアではないにも関わらず、間違っている可能性のある特定の考えにハマってしまった状態です。視野狭窄は、調査担当者が、調査を次のフェーズへ推し進めるためのシグナルを入手し損ねた時に起こります。主題のブレとは逆の症状ではありますが、視野狭窄に対しては似たようなアプローチで取り組むことができます。調査担当者に、どのような動機から調査しているのかを詳しく説明してもらうのです。ときどき、説明を繰り返しているうちに本人たちがドツボにはまっているのに自分で気づいたりします。一つ視野狭窄を止める上で便利な戦略は、対応者に反証となるエビデンスを探してもらうことです。主任SMEが調査中に特定のコード変更がまずかったのだという考えにハマっているのだけれども、実を結ぶ様子がみられなかったら、こう尋ねてみましょう。このように概念的な見方の転換を行うことで、必然的に調査者は狭いトンネルの外のアイデアに目を向けることとなり、しばしば前進を再開することにつながります。一貫性のないメンタルモデル効果的に協業するために、インシデント対応者たちは、調査中の問題がどのようにして引き起こされうるかについて、一式のアイデアを共有している必要があります。仮説が不足していたり不十分なコミュニケーション下にあったりすると、インシデント対応は停滞する傾向にあります。インシデント指揮官にとっては、どの仮説がいま盛り上がっていて、どの仮説がすでに却下されているのか、対応者全員が同じ認識のもとにあるようにすることも仕事の一つです。どの仮説を契機に皆が調査のアクションへ向かっているのかの経過を追うのは良い考えでしょう。あなたが、なぜ主任SMEがキューイングのメトリクスについて調べているのかはっきり理解できないのであれば、先に進むより前に、おそらく彼ら彼女らの思考プロセスを説明するようお願いしてみるべきです。ときに、調査対象となるような明確な仮説がもう残っていない状態になると、インシデント対応の進捗は遅滞するか停止します。この状態が明言されないと、対応状況は主題のブレや視野狭窄に陥ってしまうことがあります。あなたが仮説の枯渇に気づいたときは、進行中の調査を一旦すべて止めてもらい、新しい仮説を得るべくブレインストーミングするよう呼びかけることが有用です。すると、一部のメンバーにはこれが時間の無駄のように感じられ、反発を受けることもあるでしょう。具体的な復旧作業に進むためには、抽象的なアイデア思考をする必要があるのです。インシデント指揮官と主任SME間の分断インシデント指揮官と主任SMEの認識がズレると、もっともまずい大惨事につながります。インシデントレスポンスでの取り組みにおける全メンバー間の関係の中で、この二者間の関係はもっとも重要なものです。実際、あまりにも大事なので、インシデント指揮官と主任SMEの関係を良好に保つことだけを目的としたプロセスがあります。インシデントの最初期、インシデント指揮官と主任SMEがビデオ通話にアサインされて参加したら、インシデント指揮官は速やかにハンズオフ状況アップデートを要請しましょう。「ハンズオフ」というからには、状況アップデートが終わるまでの間、どちらの側もキーボードを叩いたりクリックしたり、また何かを読んだりしてはいけません。両者が、完全にお互いとのコミュニケーションだけに集中する必要があるのです。この質問は、ハンズオフ状況アップデートが始まることを改めて知らせて、インシデント指揮官と主任SMEがそれに集中するよう促します。主任SMEがまだ準備できていないと言うのであれば、今から60秒後だったらできるか聞いてみましょう。現在進行形で調査中の問題によって、何人の顧客が影響を受けているか、どれくらいカスタマーエクスペリエンスに混乱が生じているかは、常に明確であるとは限りません。それでも、主任SMEに一考してもらうのは役に立つものです。この質問は、主題のブレや視野狭窄に陥るのを、未然に防ぐのに役立ちます。このさき進む道をはっきり意識できるようになります。根本原因に対する認識が薄れないうちに、問題解決の次のステップを確立する機会を設けましょう。インシデント指揮官にとっては、主任SMEの言っている次の一手が、前の二つの質問で聞いた想定影響と根本原因からみて妥当であるものかを確認することが責務です。最後に、誰かインシデント対応を進める上で有用なスキルを持った個人がいるか、主任SMEに考えてもらう機会を作ります。誰かの名前が挙がったら、全力でインシデントレスポンスのチャンネルやビデオ会議に参加してもらうよう働きかけ、さらに可能であれば、彼ら彼女らを主任SME直属のSMEに任命しましょう。インシデント指揮官リファレンスシート一貫性のある役割分担や情報のハンドリングを確かなものにするために、インシデント指揮官のリファレンスシート内に標準的な手続きを定義しました。インシデント指揮官に志願する前に、リファレンスシートを見直しましょう。読みながら、インシデント指揮官の3つの責務を思い出してください。現時点では、リファレンスシートそのものは公開がHashiCorp社内に限られているため、当記事上での公開はありません。ground)」の観点から分析しています。論文では、最も頻繁に「共通見地」が崩壊してしまうありかたの一つが記述されています。呼んでおり、これを理解し認識することで、より効果的なインシデント指揮官になれるでしょう。インシデントレスポンスで私たちが行うことは、医師が診断を下そうとするときに行うことと多くの共通点があります。両ケースとも調査者は、非常に複雑なシステムと、容赦ない時間の経過、そしてシステムの挙動を説明するにあたり限られた戦略上の兵器を手に直面することになります。このビデオはソフトウェアエンジニアではなく医学生を対象にしたものではありますが、インシデント指揮官は差分診断の原則を学び、インシデントレスポンスを体系化する上で大変な恩恵を得ることができるでしょう。@yakstcom_req_jaYakstYakstお問い合わせ。