Incident Commander
インシデントコマンダー(IC)になりたいですか? ここはまさにそのための場所です! インシデントコマンダーになるためにシニアなチームメンバーである必要はありません。必要な知識があれば誰でもなることができます(そう、インターンでも可能です!)
目的#
インシデントコマンダーの目的を一文で表すと、次のようになります:
インシデントを解決に向けて進め続けること。
インシデントコマンダーは、重大なインシデント中の意思決定者です。タスクを委任し、SMEからの意見を聞いて、インシデントを解決に導きます。彼らは日常的な役職に関係なく、重大なインシデント会議における最高位の個人となります。コマンダーとしての決定は最終的なものです。
インシデントコマンダーとしてのあなたの仕事は、会議に耳を傾け、インシデントのSlackルームを監視して、物事の明確な調整を行い、文脈や詳細を収集するために他の人を募ることです。あなたは復旧作業を行ったり、グラフを確認したり、ログを調査したりするべきではありません。これらのタスクは委任されるべきです。
インシデントコマンダーは、明確な選択肢なしで行き詰まることを避け、解決に向けて物事を進め続けるために、あらゆる機会に次のステップとバックアッププランを検討する必要があります。
前提条件#
インシデントコマンダーになる前に、以下の基準を満たしていることが期待されます。まだすべての基準を満たしていなくても心配いりません。トレーニングを続ければよいのです!
- 優れた口頭および文書によるコミュニケーションスキル。
- 異なるPagerDutyサービスがどのように相互作用するかについての概要レベルの知識を持っている。
- 状況を把握し、様々な戦術/戦略の有効性を評価し、適切な行動方針について迅速な決定を下す能力。
- 柔軟性があり、専門家のフィードバックを聞くことができ、必要に応じて計画をその場で修正できる。
- 少なくとも2回の重大なインシデント対応にオブザーバーまたは積極的な参加者として関わった経験がある。
- 威厳があり、指揮を取り、気を散らす人がいれば、それがCEOであっても会議から追い出す意志がある。
深い技術的知識は必要ありません!
インシデントコマンダーはシステムに関する深い技術的知識を必要としません。インシデントコマンダーとしてのあなたの仕事は、対応を調整することであり、技術的な変更を行うことではありません。エンジニアリング部門にいないからといって、インシデントコマンダーになれないと思わないでください!
責任#
インシデントにおける様々な役割を読んで、インシデントコマンダーに期待されることと、あなたが関わる他の役割に期待することを確認してください。
トレーニングプロセス#
現在のところ、プロセスはかなり緩やかです。以下はトレーニングのためにできることのリストです:
-
このページの残りの部分、特に以下のセクションを読んでください。
-
Failure Friday(FF)に参加してください。
- FFをシャドウイングして、どのように運営されているかを見てください。
- 複数のFFで書記官を務めてください。
- 複数のFFでインシデントコマンダーを務めてください。
-
オフィスの他の人と「Keep Talking and Nobody Explodes」というゲームをプレイしてください。
- より現実的な体験のために、Hangoutsを通じて別のオフィスの誰かとプレイしてください。
-
現在のインシデントコマンダーを、少なくとも1週間のシフト全体でシャドーイングしてください。
- 彼らがアラートを受けたときに通知を受け、同じ会議に参加してください。
- アクティブなインシデント会議に参加し、チャットをフォローし、インシデントコマンダーがなにをしているかをフォローしてください。
- 会議に積極的に参加せず、質問は最後まで取っておいてください。
-
現在のインシデントコマンダーを、少なくとも1週間のシフト全体で「逆」シャドーイングしてください。
- インシデントに対応し会議でリードを取るのはあなたですが、進め方がわからなくなった場合には、現在のインシデントコマンダーが引き継ぐことができます。
卒業#
トレーニング中のインシデントコマンダーとインシデントコマンダーの違いは何でしょうか?(これはジョークの前振りではありません)。簡単です。インシデントコマンダーは自分自身をスケジュールに入れるのです。
また、インシデントコマンダーのSlackチャンネルで自己紹介し、インシデントコマンダーのメーリングリストに追加してもらうことを忘れないでください。
インシデントの処理#
すべてのインシデントは異なります(言い換えれば、同じ問題を何度も繰り返していないことを願っています!)が、各インシデントに適用できる共通のプロセスがあります。各ステップで使用される言語については、以下の「手順と用語」セクションで詳しく説明されています。
状況把握#
状況把握では、何が起きているのか、どれだけの影響があるのかを理解します。これは後で良い決断を下すことができるように情報を収集するステップです。
-
症状を特定する。- 「何が問題ですか?」と尋ねる
- 症状が何であるかを特定し、専門家にこの情報を提供するよう依頼します。
- できるだけ多くの情報を、できるだけ早く収集します(これを行っている間もインシデントは続いていることを忘れないでください)。
-
インシデントの範囲を特定する。- 「これは複数のサービスに影響していますか?」と尋ねる
- 問題の大きさと、それが拡大しているか、変動しているか、落ち着いているかを特定します。
- 発生している事実と、これからなにが起こりうるか、そしてそれらが起こる確率を把握します。
安定化#
次のステップはインシデントを安定させることです。問題を解決するために何ができるかを決定し、アクションを実行する必要があります。
-
可能なアクションを特定する。- 「どのようなアクションを取ることができますか? それにはどれくらいリスクがありますか?」と尋ねる
- 問題を軽減するために取ることができるアクションを特定します。専門家に何をしたいか尋ねてください。
- それらの各アクションに関連するリスクを特定します。
-
決断を下す。- 「私たちは...で進めます」と言う
- 利用可能な情報に基づいて、どのアクションを取るかを決定します。
- 「間違った」決断をすることは、決断をしないよりもよいです。悪い選択肢しかない場合は、一つを選んで進めてください。
-
合意を得る。- 「強い反対はありますか?」と尋ねる
- 計画への支持を集めます(以下の「決断中の投票」を参照)。
- 反対意見を聞きます。
- 新しい情報が提示された場合、計画を調整する準備をしてください。
-
タスクを割り当てる。- 「A、BをXX分以内に実行してください。理解しましたか?」と言う
- 修復アクションをSMEに委任します。
- タスクは個人に割り当てられ、時間制限を設ける必要があります。
- タスクが理解され、実行されているか確認してください。
アップデート#
修復手順が実行されている間、対応者だけでなく、組織内の他の関係者にも状況のアップデートを提供することが重要です。
- 定期的なアップデートを提供する。- 「ステータスアップデートです:...」と言う
- リズムを維持し、会議の全員に定期的なアップデートを提供します。
- 何が起きているのか、それに対して何をしているのかなどを伝えます。
- 更新は手短に、事実に基づいたものにしてください。
検証#
修復アクションが実行された後、それらが成功したかどうかを確認し、成功していない場合はバックアッププランを進める必要があります。
- タスクの完了をフォローアップする。- 「終わりましたか?」と尋ねる
- 割り当てたタスクの完了状況を尋ねます。
- 対応者がより多くの時間を必要とする場合は、より多くの時間を与えます。
- 問題が続く場合は、状況把握のステップから再び始めます。
副指揮官#
一般的にインシデントの副指揮官は、バックアップのインシデントコマンダーです。ただし、インシデントコマンダーは、一人または複数の副指揮官を任命することができます。副指揮官はインシデントコマンダーと同等の要件を満たしている必要があり、副指揮官としてアサインされた場合、必要があればインシデントコマンダーの地位を引き継げる資格が求められる点に注意してください。
コミュニケーションの責任#
インシデント中の情報共有は重要なプロセスです。インシデントコマンダー(または副指揮官)として、必要に応じて他の人に説明する準備をしておく必要があります。また、あなたの意図と決定を明確に伝えて、あなたの命令に曖昧さを残さないようにしなければなりません。
対応者から情報を受け取った場合、あなたはその情報を受け取り、理解したことを明確に確認しましょう。そうすることで、対応者は他のタスクに移ることができます。
インシデント後には、他のトレーニング中のインシデントコマンダーと、必要と思われるデブリーフアクションについてコミュニケーションを取りましょう。
明確さは簡潔さよりも重要
明確なコミュニケーションは簡潔なコミュニケーションよりも重要であることを覚えておいてください。対応を迅速にするために、発言を省略したり急いだりする衝動に駆られるかもしれません。しかし、これは混乱や誤解を招き、最終的には対応時間を増加させる可能性があります。少し時間がかかっても、常に明確なコミュニケーションを優先してください。
インシデント会議の手順と用語#
インシデントコマンダーの手順には、インシデント中にあなたがすべきことの詳細な説明が記載されています。
さらに、通常のインシデント会議のエチケットに従うだけでなく、インシデントコマンダーとして従うべき追加のエチケットガイドラインがいくつかあります:
- オンコールのインシデントコマンダーである場合は、会議に参加したときに必ず自己紹介してください。
- 議論が手に負えなくならないようにしてください。会話を短く保ちます。
- 他の人からの反対意見に注意しますが、あなたの決定は最終的なものです。
- 誰かがあなたの会議を積極的に妨害している場合は、その人を追い出してください。
- 会議の終了を告げてください。
以下は、インシデント会議中に使用すべきフレーズとパターンの例です。
会議開始時の宣言#
重大なインシデント会議の開始時に、インシデントコマンダーは以下のように宣言しましょう:
こちらは[名前]です。私はこの会議のインシデントコマンダーです。
これにより、会議の全員にあなたの名前と、あなたが現在コマンダーであることが伝わります。新しい参加者がまだ用語に慣れていない可能性があるため、「IC」ではなく「インシデントコマンダー」として自分を識別してください。「コマンダー」という言葉は、あなたが責任者であることを非常に明確にします。
インシデント開始時、インシデントコマンダー不在#
あなたがインシデントコマンダーとしてトレーニングを受けており、会議に参加した場合、たとえあなたがオンコールのインシデントコマンダーでなくても、以下のようにするべきです:
会議にインシデントコマンダーはいますか?
(一時停止)
返答がないようなので、こちらは[名前]です。私はこの会議のインシデントコマンダーとなります。
オンコールのインシデントコマンダーが後で参加した場合、あなたの裁量で彼らに引き継ぐことができます(引き継ぎ手順については以下を参照)。
SMEが出席しているかの確認#
会議中、インシデントを解決するために様々なチームから誰が利用可能かを知りたいでしょう。エチケットとして、人々は自己紹介するべきですが、時には会議に遅れて参加することもあるでしょう。チームの代表者が必要な場合は、会議で尋ねてください。誰も答えない場合、副指揮官が連絡することができます。
[X]チームの代表者は会議に参加していますか?
(一時停止)
副指揮官、[X]のオンコール担当者に連絡してもらえますか。
タスクの割り当て#
タスクや任務を与える必要がある場合は、以下の3つのステップに従ってください:
- タスクを特定の人に直接割り当てます。
- タスクに指定した分数の時間制限を設けます。
- 対応者が指示を理解し、確認したことを確認します。
誰かが...できますか?
「誰かが...できますか?」とは決して言わないでください。これは傍観者効果につながります。タスクは常に個人に直接割り当てられるべきであり、誰かが拾ってくれることを期待して投げかけるべきではありません。
インシデントコマンダー:ボブ、Webアプリボックスの高レイテンシーを調査してください。3分後に回答を求めます。
ボブ:了解しました
割り当てた分数を追跡し、その時間後にその人に確認してください。タイミングの追跡を手伝ってもらうために副指揮官の助けを借りることができます。
合意を得る(決断中の投票)#
決断を下す必要がある場合、それはインシデントコマンダーに委ねられます。インシデントコマンダーが決断を下すと、それは最終的なものです。しかし、誰も後から計画に反対して「こうなると思っていた」などと言えないようにすることが重要です。インシデントコマンダーは、それが起こらないようにするために、そして対応の全員から暗黙の合意を得るために、きわめて独特な言語を使用します。
[(提案内容)]することを提案します。
この計画に強い反対はありますか?
(一時停止)
反対がないようなので、この提案で進めます。
「全員が同意しますか?」と尋ねると、人々が互いに話し、静かな人々が発言しないなどの状況が発生するでしょう。「強い」反対があるかどうかを尋ねると、参加者は反対する機会を与えられ、その問題について強い考えがある場合は反論できます。また、進行に対する反対意見(あなたが最も気にする情報)が明確に聞こえるようにします。
ステータスアップデート#
重大なインシデント会議中にリズムを維持することが重要です。進行中に停滞がある場合、通常は誰かからの返答を待っている間、現在の状況と未解決のアクションを説明することでギャップを埋めることができます。これにより、全員が同じ認識を持っていることを確認できます。
[X]を待っている間、現在の状況のアップデートをします。
現在、[X]が原因と思われるSEV-1の状況にあります。[Y]に対する未解決の質問があり、2分以内に回答が得られる予定です。その間、私たちは問題が発生していることをX(旧Twitter)で発信しました。10分後もインシデントが進行中であれば、再度ポストを行います。
この時点で他に追加のアクションや提案はありますか?
範囲の縮小#
インシデントの原因を特定したら、会議の範囲を縮小する時間を取ることができます。例えば、不良なデプロイが原因であると特定した場合、ネットワークエンジニアリングの対応者を会議に留める必要はありません。対応者は通常、特に午前3時の場合、自分に関係のないことのために残る必要がないことを感謝します。一般的に、会議に残る必要がある人をリストアップするのが最善です(残れる人をリストアップするのではなく)。これは必要な人を再確認するだけでなく、退席できる人を忘れないようにするためです。
主な原因を特定し、回復に向かっているので、副指揮官、書記官、サポート、SREの専門家に会議に残ってもらう必要があります。他の皆さん、対応ありがとうございました。自由に退席してください。
誰かを強制的に会議から退席させる必要はありません。選択肢を残しておいてください。時には対応者は、すでに起きているので、インシデントがどのように最終的に解決されるかを見るために残ることを選ぶ場合もあります。
サブチームの編成#
複雑なインシデントを処理する際、特定の問題をより詳細に調査し、報告する前に、サブチーム(または複数のサブチーム)を編成する必要がある場合があります。これは効果的な管理範囲を維持するためです。これを行うには、チームリーダーを割り当て、特定のタスク(通常の方法で時間制限を設ける)を与え、彼らがあなたの主要な連絡先であり、彼らのチームからのすべてのコミュニケーションはリーダーを通じて行われるべきであることを再確認します。チームを作成する際の混乱を避けるために、事前に定義されたチーム名であるAlpha、Bravo、Charlieを使用してください。
インシデントコマンダー:アン、ウェブ層での継続的なレイテンシーを調査するためのサブチームをリードしてほしいです。必要なチームを集めて調査し、20分後に報告してください。あなたのチームからのすべてのコミュニケーションはあなたを通じて行われるべきです。Alphaチームのルームと電話ブリッジを使用してください。
アン:了解しました。20分後に更新します。
各サブチームが誰で構成されるかを規定する必要はありません。彼らは既存のチーム構造を利用するか、自分でチームを編成する必要があります。あなたはこのことを踏まえてチームリーダーを選びましょう。
指揮の移譲#
指揮の移譲は、名前が示すように、別のインシデントコマンダーに指揮を移すことを含みます。指揮の移譲が行われる可能性のある理由はいくつかあります:
- コマンダーが疲労し、継続できなくなった。
- インシデントの複雑さが変化した。
- 効果や効率のために指揮の変更が必要。
- 個人的な緊急事態が発生した(例:インシデントコマンダーに家族の緊急事態が発生した)
引き継ぐことで、自分の仕事を適切に行っていないのではないかと感じることはありません。引き継ぎは奨励されています。引き継ぐためには、メインの会議とは別に(たとえばSlackを通じて)、他のインシデントコマンダーに指揮を移譲したい旨を知らせましょう。必要だと思うあらゆる情報を彼らに伝えてください。そして会議で発表してください:
会議の皆さん、この時点で指揮を[X]に引き継ぎます。
新しいインシデントコマンダーは、新しい会議に参加するかのように会議で発表するべきです(上記参照)。これにより、全員が新しいコマンダーを認識します。
なお、仮にもっと要件を満たすのある人物が現れたとしても、必ずしもインシデントコマンドの変更を意味するわけではないことに注意してください。
会議終了の合図#
インシデントの終了時には、会議を終了することを全員に告げ、フォローアップの議論がどこで行われるかについての情報を提供しましょう。また、全員に感謝するのが慣例です。
皆さん、この時点で会議を終了します。フォローアップの議論はSlackで続けてください。ありがとうございました。
問題の処理#
インシデント対応の会議では常に物事がスムーズに進むわけではないので、インシデントコマンダーとして、会話が意図的または無意識に脱線する場合に備えておく必要があります。以下は、物事が混乱したときに物事を軌道に戻すためのいくつかの手順と用語です。
秩序の維持#
会議では、人々が互いに話したり、進め方について議論が起こることがよくあります。インシデントコマンダーとして、会議での秩序を維持することが重要です。インシデントコマンダーは、必要であれば誰かを会議から退席させる権限を持っています(たとえそれがCEOであっても)。しかし、多くの場合、人々に一度に一人ずつ話すように注意するだけで十分です。ときには口論から始まったやりとりが健全な議論に発展することもありますが、あまり長く続けるべきではありません。
(ノイズ)
皆さん、一度に一人ずつ話してください。これまでのところ、進めるための2つの選択肢が聞こえています:1)[X]、2)[Y]。
この時点で他に提案したい人はいますか?
...など
明確な回答を得る#
インシデントコマンダーとして質問をしたときに、実際にはあなたの質問に答えていない回答を受け取ることがあります。よくあるのは、はい/いいえの回答を求めたときに、より詳細な説明をが返ってくるケースです。これはしばしば、その人が会議のエチケットを理解していないために発生します。しかし、それが続く場合は、前に進むために行動を起こす必要があります。
インシデントコマンダー:これはすべての人にサービスを無効にしますか?
SME:まあ...一部の人には...
インシデントコマンダー:止めてください。はい/いいえの回答が必要です。これはすべての人にサービスを無効にしますか?
SME:まあ...そうではないかもしれません...
インシデントコマンダー:止めてください。もう一度尋ねますが、「はい」または「いいえ」の2つの言葉だけを聞きたいです。これはすべての人にサービスを無効にしますか?
SME:まあ...言っていたように...
インシデントコマンダー:止めてください。会議から退席してください。バックアップのインシデントコマンダー、回答を得るために[サービス]のバックアップオンコール担当者に連絡してもらえますか。
エグゼクティブの襲来 - インシデントコマンダーの軽視#
エグゼクティブ:みんなインシデントコマンダーを無視して、私の言うことをやりなさい!
これは極端な例ですが、「エグゼクティブの襲来(Exective Swoop)」の概念を示しています。これは、平時にはあなたの上司である人が会議に参加し、インシデントコマンダーとしてのあなたの決定を上書きしはじめることです。これは戦時中には受け入れられない行動であり、指揮を執るのはインシデントコマンダーです。これはまれですが、発生すると対応プロセスを麻痺させる可能性があります。そこで、インシデントコマンダーとして物事を軌道に戻すためのシンプルな質問があります。「あなたが指揮を取りたいですか?」:
エグゼクティブ:いや、それはやっちゃ駄目でしょう。全員やめてください。そうじゃなくて、ここはロールバックしなければ。
インシデントコマンダー:お待ちください。[エグゼクティブ]、指揮を取りたいですか?
エグゼクティブ:はい/いいえ
(はいの場合)インシデントコマンダー:了解しました。会議の皆さん、この時点で指揮を[エグゼクティブ]に引き継ぎます。彼/彼女は現在この会議のインシデントコマンダーです。
(いいえの場合)インシデントコマンダー:ならば、これ以上の中断を引き起こさないでください。さもなければ会議から退席していただきます。
これにより、エグゼクティブにも責任者になり決定を下す選択肢があることが明確になりますが、そのためには彼ら自身がインシデントコマンダーとして継続する必要があります。彼らが拒否した場合、あなたが責任者であり、破壊的な中断は許容されないことを彼らに思い出させてください。彼らが続ける場合は、会議から退席させてください。
エグゼクティブの襲来 - モチベーションの低下#
エグゼクティブ:さあ頑張って、10分以内に解決してくださいね!
エグゼクティブがインシデント対応の会議を悪意を持って脱線させることはまれで、通常は善良な意図で行われます。しかし、たとえ悪気はなかったとしても、あなたの対応プロセスを脱線させ、対応者のやる気を削ぐ可能性があります。インシデントコマンダーとして、これらの状況を認識し対応する必要があります。この例は一見動機づけのように見えますが、あたかも対応者が問題を解決するために十分働いていないと仮定しているかのようで、対応プロセスにはなんの価値もありません。これに対応するには、コメントはインシデントが終わるまで取っておくべきだと思い出させるとよいでしょう。
インシデントコマンダー:インシデントの最中です。コメントはインシデント終了後まで取っておいてください。
エグゼクティブの襲来 - 情報を求める#
エグゼクティブ:影響を受けたすべての顧客のスプレッドシートをもらえますか?
エグゼクティブの襲来で最もよくあるのは、より多くの情報を求める要求です。残念ながら、インシデントの最中には、通常そのような情報を収集するためのリソースを割くことができません。インシデントコマンダーとして、あなたはエグゼクティブにこれを思い出させ、インシデントが優先されることを伝えるべきです。
インシデントコマンダー:そのリストを取得するか、インシデントを修復するか、どちらかです。両方はできません。インシデントが優先されます。
これは質問として表現されていないことに注意してください。インシデントコマンダーとして、あなたはすでに決定を下しており、単にエグゼクティブにその決定を通知しているだけです。
エグゼクティブの襲来 - 重大度に疑問を呈する#
エグゼクティブ:これは本当にSEV-1ですか?
私たちの重大度レベルは、インシデントに対して提供する対応の規模を決定します。インシデントの重大度についての会話は、急速に会議全体のリソースを消費する一方、進行中のインシデントがあるという事実を変えることはできません。インシデント会議中にインシデントの重大度について議論することはせず、考えられる最高の重大度として扱います。重大度はポストモーテム中に下げることができますが、インシデント会議中に重大度について議論して時間を無駄にすることはできません。そのため、改めてこれを伝えて物事を再び軌道に乗せてください:
インシデントコマンダー:インシデント会議中にインシデントの重大度について議論することはありません。これをSEV-1として扱っています。
好戦的な対応者#
時には、指示に従わない、かつ/または積極的にあなたの対応会議を妨害している対応者がいることがあります。おそらくこれは意図的に行われているか、または無意識に行われている可能性があります(例:騒がしい環境でミュートされていないマイクなど)。いずれの場合も、状況を解決し、手元のインシデントに戻る必要があります。その個人が妨害的であるという事実を述べ、彼らに面目を保つ方法を提供しますが、彼らが止めない場合になにが起こるかも述べてください。二度目のチャンスはなく、彼らが従わない場合は、会議から退席させてください。
あなたは妨害的です。止めてください。さもなければ会議から退席していただきます。
ポップカルチャーからの例#
PagerDutyの従業員は、すべての過去のインシデント会議にアクセスでき、自由に聞くことができます。これらの会議を公開することはできませんが、他のすべての皆さんのために、実際にテクニックが機能している実践例をポップカルチャーから紹介します。
これは映画「アポロ13」からのクリップで、ジーン・クランツ(フライトディレクター/インシデントコマンダー)がインシデントコマンドのいくつかの素晴らしい例を示しています。注目すべき点は以下の通りです:
- 部屋に入り、すぐに彼がインシデントコマンダーであることが明らかになります。騒音を鎮め、全員が注意を払っていることを確認します。
- 状況のアップデートを行い、人々が認識できるようにします。
- プロジェクターが壊れても、それを修正することに気を取られず、他のことに移ります。
- 進め方の提案を提供し、フィードバックを引き出します。
- フィードバックを冷静に聞きます。
- 対案が提起されたとき、同意し、その理由を述べます。
- 議論が起こることを許容し、すべてのポイントを聞きます。議論が手に負えなくなったとき、状況の指揮を再確立します。
- 決定内容とその理由を説明します。
- 計画の全体と決定内容を説明し、全員が同じ認識を持つようにします。
アポロ13からのもう一つのクリップです。注目すべき点は以下の通りです:
- 状況を要約し、事実を述べます。
- 様々な人からのフィードバックを聞きます。
- 信頼されているSMEが他の全員が言っていることと反対の情報を提供したとき、追加の明確化を求めます(「『すべて』とはどういう意味ですか?」)
- 機知に富んだ発言はインシデントコマンダーによって認められません(「12アンペアで掃除機を動かすことはできません!」)
- 「それで決まりですか?(That's the deal?)」...「それで決まりです」。
- 決定が下されると、次の議論に移ります。
- タスクを委任します。