インシデントコマンダー

ジーン・クランツ Credit: NASA

インシデントコマンダーになりたいですか。 あなたは正しい場所にたどり着けました! インシデントコマンダーはシニアメンバーである必要はなく、必要な知識があれば誰でもなることができます(もちろんインターンも含みます)。

目的#

インシデントコマンダーの目的を1文でまとめるなら

インシデントを解決に導く

インシデントコマンダーは重大インシデント発生中に意思決定をします。 インシデントを解決するために、タスクを委譲し内容領域専門家からの意見を聞きます。 日々の地位に関係なく、重大インシデントでは最も位の高い人です。 コマンダーとしての意思決定は確定的なものです。

インシデントコマンダーとしての仕事は、他の背景情報や詳細情報を集約して明確な調整をするために、通話を聞きインシデントのSlackルームを見ます。 インシデントコマンダーは、任意のアクションの実行や修正をしたり、グラフやログの調査をすべきではないです。 それらのタスクは委譲すべきです。

インシデントコマンダーはいつでも、次のステップやバックアッププランも考慮すべきです。 実行する選択肢がなく手詰まりになるのを避けて、解決に向けて前進し続けるように心がけます。

前提条件#

インシデントコマンダーになる前に、次の基準を満たしている必要があります。 全てを満たしていなくても、トレーニングを続ける事ができるので心配しないでください。

  • 優れた口頭および書面での コミュニケーションスキルがある。
  • PagerDutyの様々なサービスがどのように連携しているかの 高レベルな知識を持っている。
  • 状況を判断して、 様々な戦術、戦略の効果の評価ができて、行動方針に対する迅速な意思決定ができる。
  • 専門家のフィードバック に耳を傾け、必要に応じてその場で計画を変更できる柔軟性がある。
  • 直近の2つの重大インシデントに、見学または対応者として関わっている。
  • 指揮を執り、CEOであっても通話の妨げとなる人を 通話から追い出す ことのできる厳格さがある。

深い技術知識は必要ありません

インシデントコマンダーはシステムの深い技術知識は必要ありません。 インシデントコマンダーはインシデント対応を調整することであって、技術的な変更を行うことではありません。 もしあなたが開発部にいなくても、インシデントコマンダーになれないと思わないでください。

責務#

インシデントの異なる役割を読んで、インシデントコマンダーに何を期待されているか、またインシデントコマンダーがやり取りする他の役割に何を期待するかを読んでください。

トレーニングプロセス#

今の所は厳密に決まっていないです。 トレーニングのためにできることを次に示します。

  • このページの残りの部分を読んでください。特に以下の項目には目を通しておいてください。

  • Failure Friday (FF)に参加してください。

    • FFをシャドウイングして、どのように実行するか確認します
    • 複数のFFの記録係になります
    • 複数のFFのインシデントコマンダーになります
  • オフィスの他の人と、"Keep Talking and Nobody Explodes" ゲームをします。

    • よりリアルな体験をするためには、電話を通して他の人とプレイします。
  • 少なくとも1週間のシフトで、現在のインシデントコマンダーをシャドウイングしてください。

    • 同じアラートを受け取り、同じ通話に参加します。
    • 現在発生しているのインシデント通話に参加し、チャットをフォローアップして、インシデントコマンダーが何をしているかをフォローします。
    • 通話の議論には参加しないでください。質問は通話が終了するまで控えておきます。
  • 少なくとも1週間のシフトで、インシデントコマンダーを逆シャドウイングします。

    • あなたがインシデント対応する必要があり、通話で議論をしますが、進め方がわからない場合は現在のインシデントコマンダーが引き継ぎます。

卒業#

トレーニング中のインシデントコマンダーと、通常のインシデントコマンダーとの違いはなんでしょうか。 答えは簡単で、インシデントコマンダーはスケジュールに基づいて行動します。

インシデントコマンダーのSlackチャネルに参加して、インシデントコマンダーのメーリングリストに追加することを忘れないでください。

インシデントを処理する#

全てのインシデントは異なります(同じ問題を何度も繰り返し起こさない事を願います)が、それぞれのインシデントで共通した手順があります。 各ステップで使われる用語については「手順と用語」というセクションで詳しく説明します。

インシデントへの対応

把握する(Size-Up)#

何が発生しているか、それがどの程度の影響があるかを判断します。後によい意思決定ができるための、情報収集のステップです。

  1. 症状を特定する - 「なにが悪いのか?」を問う

    • 症状を特定して、専門家に情報を提供するよう依頼します。
    • 可能な限り多くの情報を収集します(この間にもインシデントは継続していることに気をつけてください)。
  2. インシデントの範囲を特定する - 「複数サービスに影響があるのか?」を問う

    • 問題の規模と、拡大しているか、バタついているか、静的なのかを判断します。
    • 事実、起こりうること、それが起こる確率を取得します。

安定させる(Stabilize)#

次のステップはインシデントを安定させることです。修正するには何ができるのかを特定して、それを実行します。

  1. 可能なアクションを見つける - 「どのような行動を取ることができるか?それのリスクは?」を問う

    • 問題を軽減できる全てのアクションを特定します。また専門家に何ができるかを問います。
    • それぞれのアクションに対するリスクを評価します。
  2. 意思決定をする - 「私たちは...を実行する」と宣言する

    • 持っている情報を元に、どのアクションを実行するか意思決定します。
    • 間違った判断をするのは、何もしないよりも良いです。悪い選択肢しかない場合はどれかを選択します。
  3. 同意を得る - 「強い異論はありますか?」を問う

    • 計画に対するサポートを集めます(下記の「意思決定時の投票」もご覧ください)
    • 反対意見を聞きます。
    • 新しい情報があるときは、計画を調整するようにします。
  4. タスクを割り当てる - 「Aさん、Bを実行してください。X分後に戻ってきます。分かりましたか?」と宣言する

    • 復旧アクションを内容領域専門家に委譲します。
    • タスクは個人に割り当てられ、タイムボックスが設定されるべきです。
    • タスクの内容を理解して、実行されているか確認します。

更新する(Update)#

修正手順が実行されているとき、対応者だけでなく組織内の他のステークホルダーにも、ステータスを提供することが重要です。

  1. 定期的な更新を提供する - 「ここにステータスの更新があります」と宣言します

    • 頻度を維持して、通話の全ての人に定期的に更新情報を提供します
    • 何が起こっていて、今何をしているかなど。
    • 更新情報は短く、事実に基づいてください。

確認する(Verify)#

復旧が実行されたら、それが成功したかどうかを確認して、そうでない場合はバックアッププランを実行します。

  1. タスクの完了状況を確認する - 「終了しましたか?」を問う
    • タスクを割り当てたひとに、タスクの完了状況を確認します。
    • もう少し時間がかかりそうな場合は、さらなる時間を与えます。
    • 問題が解決しない場合は、Size-upからやり直します。

補佐#

インシデントの補佐は、通常インシデントコマンダーのバックアップです。 しかしインシデントコマンダーとして、1人以上の補佐を指名できます。 補佐のインシデントコマンダーは、インシデントコマンダーとしての資格が必要です。 補佐に割り当てる人は、必要に応じてインシデントコマンダーのポジションになることを想定して、インシデントコマンダーとしての資格が必要になります。

コミュニケーションの責務#

インシデント発生中の情報共有は重要なプロセスです。 インシデントコマンダー(または補佐)として、必要に応じて他の人に説明する準備をすべきです。 またあなたの指示が曖昧にならないように、意図と決定事項を明確に説明する必要もあります。

対応者から情報を貰ったときは、そのメッセージを受信して理解したと応答すべきです。 対応者は確認して他のタスクに移行できます。

インシデント収束後は、トレーニング中のインシデントコマンダーに、必要だと思われる報告アクションについてコミュニケーションする必要があります。

簡潔よりも明確に

明確なコミュニケーションは簡潔なコミュニケーションよりも良いことを覚えておいてください。 応答を急ぐために、スピーチを省略したり急いだりしたいかも知れません。 しかしこれは混乱と誤解を生み、最終的に応答時間が長くなる可能性があります。 少し時間がかかる場合でも、明確なコミュニケーションを心がけてください。

インシデント通話手順と用語#

インシデントコマンダーのためのステップで、インシデント発生中に何をすべきか解説しました。

これに加えて、インシデント通話中のエチケットで、インシデントコマンダーとして従うべき追加のエチケットガイドラインがあります。

  • オンコールのインシデントコマンダーとして通話に参加した場合はアナウンスしてください。
  • 議論を手放さないでください。会話は短くするようにしてください。
  • 他の人からの意見に注意しつつ、あなたの判断が最終決定となります。
  • もし議論の妨げになる人が通話に参加してきたら追い出してください。
  • 通話の終了をアナウンスしてください。

インシデント通話中に使うべき、フレーズとパターンの例をいくつか紹介します。

通話開始のアナウンス#

重大インシデントの通話のスタート時には、インシデントコマンダーが以下のことをアナウンスします。

こちらは[名前]です。私はこの通話のインシデントコマンダーです。

これにより通話の参加者が、あなたの名前とあなたがインシデントコマンダーであることを確認します。 自分で名前を明言し、あなたがICではなくインシデントコマンダーであることを宣言します。 新しく参加した人はまだその言葉になれていません。 「コマンダー」という言葉は、あなたに権限があることが明確になります。

インシデントが発生したが、インシデントコマンダーがいない#

あなたがインシデントコマンダーの訓練をして通話に参加したとき、あなたはオンコールのインシデントコマンダーではなくても、以下のことをします。

この通話にインシデントコマンダーはいますか?

(応答なし)

返事がありません。わたしは[名前]です。今から私がこの通話のインシデントコマンダーとなります。

もしオンコールのインシデントコマンダーが後から参加する場合は、あなたの裁量で引き継ぐことができます(引き継ぎ手順は下を参照してください)。

内容領域専門家がいるか確認する#

通話中は、インシデントを解決するために、さまざまなチームから誰が対応可能かを知りたいです。 エチケットに従えば、彼ら自身がアナウンスすべきですが、あなたが後から参加することもあります。 もしチームからの代表者が必要になったら、通話でそれを訪ねてください。 もし回答がない場合は、補佐が彼らを呼び出せます。

この通話に[X]の代表はいますか?

(応答なし)

補佐、[X]のオンコールを呼び出してください。

タスクの割り当て#

もし割り当てまたはタスクが必要になったら、以下の3つのステップに従ってください。

  1. 特定の誰かにタスクを直接割り当てます。
  2. タスクのタイムボックスを何分かで決めます。
  3. 対応者が指示に応答して、理解していることを確認します。

誰かできますか

傍観者効果を引き起こすため、「誰かできますか」は言わないでください。 タスクは誰かが拾うことを期待せず、常に特定の誰かに直接割り振ります。

インシデントコマンダー: ボブ、ウェブアプリでレイテンシが高くなっている件について調べてください。3分後に結果を聞きに来ます。

ボブ: 理解しました。

何分割り当てたかを追跡して、その時間が経過したあとに確認します。 タイミングを追跡するために、補佐に手助けしてもらうことができます。

同意を得る (意思決定時の投票)#

意思決定が必要な場合は、インシデントコマンダーが判断します。 インシデントコマンダーが決定を下すと、それが最終決定となります。 もし後からきた誰かが「それが起こることは知っていた」と言っても、計画には反対できません。 それが起こらないようにインシデントコマンダーは特定の言語を使い、みんなから明示的に同意を得ます。

提案は[提案内容]です

この計画に強く反対する人はいますか?

(応答なし)

反対意見が無いようなので、この提案で進めたいと思います

「皆さん賛成ですか?」と聞いてしまうと、参加者たちが互いに議論を始めたり、静かな人が発言できなくなったりします。 強く反対する人の意見を乞うことで、反対する機会が与えられますが、それは強く反対したい場合に限られます。 またこれは、最も気にしている情報(手順への反対意見)も大きくはっきりと聞くことができます。

ステータス更新#

重大インシデントの通話では、リズムを維持することが重要です。 沈黙が続いているときはいつでも、通常はあなたが誰かの返事を待っているときで、現在の状況と特別なアクションを説明することで空白時間を埋めることができます。 これはみんなに同じ認識であることを確認できます。

[X]を待っている間、現在の状況の更新情報を説明します。

私たちはSEV-1の状況にあり、[X]が原因だと考えられます。 未解決である[Y]については2分後も返ってくる結果で明らかになります。 それまでの間、問題が発生していることをツイートしました。 インシデントがまだ発生している場合は、次のツイートは10分以内に行われます。

現在、追加のアクションや提案はありますか?

スコープの縮小#

インシデントの原因を特定できれば、インシデントの通話の範囲を縮小できます。 例えば、悪いデプロイが原因だとわかれば、ネットワークエンジニアの対応者は通話に残り続ける必要はありません。 対応者は普通、特に午前3時となると、自分に関連しないことに居続けなくてもよいことに感謝します。 通話に残り続けて欲しい人をリスト化するのが良いです(退出できる人をリスト化するのではなく)。 これは誰が必要かを再認識できるだけでなく、退出できる人を忘れなくできます。

主な根本原因を特定できて、現在回復に向かっています。 補佐、記録係、サポート、そしてサイトリライアビリティエキスパートは残ってください。 その他の人はご協力感謝します。あなたの裁量で通話を抜けてください。

通話から強制的に追い出す必要はなく、選択する余地を残しておきます。 対応者はすでに起きてしまっているので、インシデントが最終的にどうなったかを確かめたい場合があります。

サブチームを作る#

複雑なインシデントに対処するときは、報告の前に特定の問題を詳細に調査するために、サブチーム(または複数のサブチーム)を作ることも大事です。 これは管理範囲を維持もできます。 サブチームを作るには、チームリーダーを指名して特定のタスクを割り当てます(通常と同じようにタイムボックスを設けます)。 そしてリーダーが連絡先で、チームからの全てのコミュニケーションはリーダーを経由することを再確認します。 チームを作る時に混乱しないように、私たちが予め用意したチーム名、Alpha、Bravo、Charlieを使います。

インシデントコマンダー: アン、Web層で発生している遅延について調査するサブチームを作りたいと思います。 必要なチームメンバーを集めてそれを調査してください。 20分後に報告をお願いします。 あなたのチームから私への報告は、全てあなたを通してください。 Web会議にはAlphaチームを使ってください。

アン: 分かりました。20分以内に更新情報を持ってきます。

あなたはチームメンバーが誰かを決める必要はありません。 彼らはすでにチーム構成があるか、またはチームが率先して自分たちでチームを構成する必要があります。 あなたはそれに応じて、チームリーダーを指名する必要があります。

指揮権の移譲#

指揮権の転送には、(その名の通り)他のインシデントコマンダーに指揮権を転送します。 指揮権の転送が行われる理由はいくつかあります。

  • コマンダーは疲れて継続ができない
  • インシデントの複雑度が変わった
  • 効果や効率のために指揮権が変更が必要
  • 個人的な緊急事態(家族の緊急事態)

引き継ぎによってきちんと処理されないと思ってはいけません。 引き継ぎを推奨します。 引き継ぎをするには、メインの通話外(例えばSlackなど)で、他のインシデントコマンダーに交代するようお願いします。 必要に応じて、彼らに感じたことを伝えます。 そして通話でアナウンスします。

この通話にいる皆さん、ここからは私が指揮権[X]を担当します

新しいインシデントコマンダーは、新しい通話に参加したときのようにアナウンスします(上を参照)。 これでみんなが、新しいコマンダーがだれだか分かります。

通話を終了する#

インシデントの終わりに、この時点で通話を終了することをアナウンスします。 そして追加の議論ができる場所の情報を提供します。 参加者に感謝するのも慣例です。

OKみなさん、これにて通話を終了します。 なにか追加の議論があればSlackで続けてください。 みなさんありがとうございました。

問題に対処する#

インシデント対応の通話はいつもスムーズに進むとは限らないので、意図的または無意識のうちに会話が脱線したときに備える必要があります。 話が脱線したとき、軌道を元に戻すためにできるいくつかの手順と用語を説明します。

順序を維持する#

多くの場合、人は通話時に互いに話したり、正しく進行するための討論が発生することがあります。 インシデントコマンダーは通話中の話す順番を維持することが大事です。 インシデントコマンダーは必要に応じて通話から追い出すことができます(たとえCEOであっても)。 しかしほとんどの場合、一度に話す人を1人にするよう注意する必要があります。 議論が討論として始まったとしても正しい場合がありますが、あまり長くならないよう注意してください。

(ノイズ)

OK、皆さん。一度に1人ずつ話してください。現在2つの選択肢があります。 1) [X]、2) [Y]

現段階で誰か他に提案したい人はいますか

...など

正解を得る#

インシデントコマンダーは質問に対する正確な答えをもらえない場合があります。 これは通常、YES/NOで答えられる質問に対して、より詳細を答えてしまう場合が多いです。 これは多くの場合、通話中のエチケットを知らない場合があります。 しかしこれが続く場合、議論を進めるためのアクションが必要になります。

インシデントコマンダー: これにより全ての人がサービスが無効化されますか?

内容領域専門家: ええと、一部の人は...

インシデントコマンダー: やめて、YES/NOで答えてください。これにより全ての人がサービスが無効化されますか?

内容領域専門家: ええと、うまくいかないかも知れない...

インシデントコマンダー: やめて、もう一度尋ねます。YESまたはNOの答えが欲しいです。これにより全ての人がサービスが無効化されますか?

内容領域専門家: ええと、私が言ったように...

インシデントコマンダー: やめて、通話を終了します。バックアップのインシデントコマンダーが[service]のバックアップオンコールを呼び出して答えを聞きます。

経営陣の乱入 - インシデントコマンダーの無視#

経営陣: インシデントコマンダーを無視して、私が言うことを実行してください!

これは極端な例ですが、「経営陣の乱入」の例を示しています。 あなたより年上の人が通話に現れ、あなたのインシデントコマンダーとしての意思決定を無視します。 これは戦時では容認できない行動です。 これは稀ですが、もし発生すればインシデント対応の障害となります。 物事を正常な軌道に戻すために、インシデントコマンダーとして尋ねられる簡単な質問があります。 「指揮を取りたいですか?」

経営陣: いいえ、私はやりたくないです。全てが止まっています。代わりにロールバックが必要です。

インシデントコマンダー: お待ちください。[経営陣]、指揮を引き継ぎたいですか?

経営陣: Yes/No

(Yesの場合) インシデントコマンダー: 分かりました。この通話の皆さん、助言しておきますが現時点で指揮は[経営陣]に移りました。彼らがこの通話でのインシデントコマンダーです。

(Noの場合) インシデントコマンダー: それなら対応をこれ以上中断させないでください。そうしないと通話から追い出します。

これにより経営陣が選択できることが明らかになりますが、そのためにインシデントコマンダーを続ける必要があります。 もし拒否されたら、彼らがその責任を負うことを伝えて、混乱を招くようなことは許されないよう伝えます。 もし彼らが続けるなら、通話から追い出します。

経営陣の乱入 - アンチモチベーション#

経営陣: 10分で解決できるよう挑戦してみましょう!

経営陣が意図的にインシデント対応の通話を脱線させるのは稀で、通常は善意のつもりです。 しかしこれらの善意は通話を脱線させ、対応者のやる気を失わせます。 インシデントコマンダーはそれを認識してこの状況に対応する必要があります。 上記のケースではやる気を起こさせるつもりでしょうが、対応者はすでに問題解決のために必死に対応しています。 インシデント収束までは、コメントを控えるように伝えることで対応します。

インシデントコマンダー: 私たちはインシデントの真っ最中です。コメントはインシデント収束まで控えてください。

経営陣の乱入 - 情報が欲しい#

経営陣: 影響を受ける全ての顧客のスプレッドシートはありますか?

最も多い経営陣の乱入は、さらなる情報の要求です。 残念ながら私たちはインシデントのまっただ中で、情報を収集するためのリソースがありません。 インシデントコマンダーはこの事実とインシデントを優先することを経営陣に伝えます。

インシデントコマンダー: そのリストを修正するか、インシデントに対応するかのどちらかでします。両方ではありません。インシデントを優先します。

これは質問ではなく、インシデントコマンダーとしての意思決定をすでにしてることに注意してください。 その決定事項を経営陣に伝えているだけです。

経営陣の乱入 - 深刻度に対する質問#

経営陣: これは本当にSEV-1ですか?

私たちの深刻度レベルは、インシデントへの対応規模を決定します。 深刻度についてすでに議論されており、インシデントがまだ発生中という事実は変わりません。 インシデントの通話中には深刻度について議論せず、可能な限り悪いレベルを想定します。 ポストモーテムで深刻度を下げることができますが、インシデントの通話中に深刻度を繰り返し議論して時間を無駄にはできません。 なので物事の軌道を元に戻すために、以下のことを伝えてください。

インシデントコマンダー: インシデント中は深刻度について議論しません。SEV-1として扱っています。

好戦的な対応者#

場合によっては指示に従わなかったり、積極的に通話を妨害する対応者がいます。 これは意図的に行われていることもあれば、そうでない場合もあります(騒がしい環境でマイクがミュートになってないなど)。 どちらの場合もこの状況を解決して、インシデントの対応に戻る必要があります。 個人的に問題であり、面目を保つ方法を提供しますが、それを止めないとどうなるか説明します。 もし従わない場合は、2回目のチャンスはありません。 通話から追い出してください。

インシデントコマンダー: あなたの行為は問題です。さもなくば通話から外します。

ポップカルチャーからの例#

PagerDutyの従業員は、過去の全てのインシデント通話にアクセスでき、自由に聴くことができます。 それらの通話は公開できませんが、いくつかのポップカルチャーからの例を用いて、仕事でのテクニックを示します。

これは映画「アポロ13」の場面です。 ジーン・クランツ(フライトディレクター/インシデントコマンダー)が、インシデントコマンダーの良い例を示しています。 以下に注意すべき点を示します。

  • 部屋に入ると、すぐに彼がインシデントコマンダーであることを宣言します。 騒音を静めて、全員が注意を払っていることを確認します。
  • 状態の更新情報を伝えて、人々が状況を認識できるようにします。
  • プロジェクターが壊れてましたが、それを修正せずに別の物を使います。
  • 進め方を提案し、フィードバックを引き出します。
    • フィードバックを静かに聞きます
    • 反対意見が挙げられると、彼は同意と理由を述べます。
  • 議論ができるようにして、全ての人に耳を傾けます。議論が手に負えなくなったら、状況の指揮を再度確認します。
    • 彼の意思決定とその理由を述べます
  • 彼の完全な計画と意思決定を説明して、全員が合意しています

アポロ13から別の場面です。

  • 状況を要約して、事実を述べます。
  • 様々な人からのフィードバックに耳を傾けます。
  • 信頼できる内容領域専門家が他の人に反対する情報を提供したとき、追加で説明を求めます(どういう意味か、全てか?)
  • 冗談などの発言はインシデントコマンダーに受け入れられません。(12Aでは掃除機を使えない)
  • 「それは絶対か?」「これは絶対だ」
  • 一度意思決定をすると、次の議論に進みます。
  • タスクを委任します。