During an Incident
重大インシデント発生時の対処方法に関する情報です。重大インシデントの構成については、重大度レベルの説明を参照してください。
ドキュメンテーション
自社の内部ドキュメントとして利用される場合は、このページに必要な情報がすべて網羅されていることを確認してください。たとえば、電話会議の番号、Slackチャンネル、重要なチャットコマンドなどです。次に例を示します。
#incident-chat | https://a-voip-provider.com/incident-call | +1 555 BIG FIRE (+1 555 244 3473) / PIN:123456 |
インシデントコマンダーに連絡しますか? コマンド !ic page をSlack上で実行してください |
||
エグゼクティブサマリー向けのアップデートのみが必要な場合は、#executive-summary-updates にjoinしてください。 |
セキュリティインシデントですか?
これがセキュリティインシデントである場合、Security Incident Responseプロセスに従う必要があります。
落ち着いて!#
-
インシデント会議とチャットに参加します(上記のリンクを参照)。
- 誰でも会議やチャットに参加して、インシデントを観察し、フォローすることができます。
- しかし、積極的な関与を希望する場合は、両方に参加する必要があります。何らかの理由で会議に参加できない場合は、専属の代理人が必要です。チャットルームでの話し合いが分裂すると、最終的にはまとまりがなくなりがちです。
-
会議/チャットをフォローし、すべきだと感じるコメントを追加しましょう。ただし、議論は目の前の問題に関連したものとしてください。
- あなたがSMEでない場合は、サービスのプライマリSMEを通じて、議論を絞り込んでください。一度に話し合う人が多すぎると、収拾がつかなくなる可能性があるので、可能なかぎり会議の階層構造を維持するようにする必要があります。
-
インシデントコマンダーの指示に従います。
- 会議にインシデントコマンダーがいませんか?
- Slackコマンド
!ic page
を使用して、Slack経由で手動で通知します。これにより、プライマリのインシデントコマンダーとバックアップのインシデントコマンダーが同時に呼び出されます。 - 決してインシデントコマンダーへの通知をためらわないでください。いてもらったけれども結果的には必要なかったというほうが、その逆よりもはるかに望ましいです。
- Slackコマンド
- 会議にインシデントコマンダーがいませんか?
インシデントコマンダーの手順#
できるだけ早く、できるだけ安全に、インシデントを解決しましょう。副指揮官の支援を頼ってください。あなた自身の裁量によって、関係する担当者にタスクを委任します。
-
会議とSlackで、あなたがインシデントコマンダーであり、副指揮官(通常バックアップのインシデントコマンダーでもある)や書記官を指名していることを知らせます。
-
インシデントの明らかな原因(最近のデプロイ、トラフィックの急増など)があるかどうかを特定し、関連する専門家に調査を委ねます。
- 会議にいるサービスの専門家に、分析を支援してもらいます。彼らは迅速に原因を確認できるはずですが、いつもそうだとは限りません。原因が明確に分からない場合の進め方については、インシデントコマンダーに尋ねましょう。知見を持っているサービスオーナーの助けを借りましょう。
-
調査と修正に必要なアクション(ロールバック、サービスのレートリミットなど)を特定し、関係するサービス担当者に委任します。これがすべてではありませんが、よく行われるものとして以下があります。
- 不良なデプロイ: ロールバックします。
- Webアプリケーションのスタック/クラッシュ: ローリング再起動を実行します。
- イベントフラッド: 自動スロットリングで十分であるかを確認し、十分でない場合は手動で調整します。
- データセンターの停止: 不良な状態にあるデータセンターが隔離されたことを確認します。そうでない場合は、強制的に行います。
- 通常の負荷状態におけるサービス劣化: フォレンジックデータ(ヒープダンプなど)を収集し、ローリング再起動を検討します。
-
重大度のエスカレーションについて副指揮官からの意見を聞き、公に発表する必要があるかどうかを判断し、それに応じてカスタマーリエゾンに指示します。
- 公表は、インシデントコマンダーとしてのあなたの裁量で行います。不明な場合は、一般に公表します(疑わしい場合には、発信しましょう)
-
コントロール範囲を追跡します。対応が大きくなり始めたり、インシデントが複雑になったりする場合は、より効果的な対応ができるように、サブチームを分割することを検討してください。
-
インシデントが復旧したか、復旧が進行している状態になったら、インシデントが収束し会議が終了する旨をアナウンスできます。通常、これは現時点でインシデントに対して実行すべき作業がないことを示します。
- 急を要さない議論はSlackへ移動します。
- カスタマーリエゾンがインシデントの収束を対外的に宣言するようにフォローアップします。
- インシデント後のクリーンアップ作業を特定します。
- 根底にある要因について、振り返り/分析を行う必要があるかもしれません。
-
会議が終了したら、インシデントの後からステップを開始できます。
副指揮官の手順#
あなたは、インシデントコマンダーが必要とするあらゆるサポートを行います。
-
インシデントのステータスを監視し、インシデントの重大度が上昇した場合は、インシデントコマンダーに通知します。
-
インシデントコマンダーの指示に従います。
-
会議が終了したら、インシデントの後からステップを開始できます。
書記官の手順#
Slackにあるインシデントからの重要な情報を文書化する必要があります。
-
Slackルームで、インシデントコマンダーが誰か、副指揮官が誰か、そしてあなたが書記官である旨を伝えます(まだ行われていない場合)
- 例: インシデントコマンダー:Bob Boberson / 副指揮官: Duputy Deputyson / 書記官 Writer McWriterson
-
すべての対応者が現在の状態を確認できるように、ステータス監視ボットを起動します。
- OfficerURL は、Slack のステータスを監視するのに役立ちます。
!status
- 現在のステータスを表示します。!status stalk
- 継続的にステータスを監視し、30秒ごとにルームへ報告します。
- OfficerURL は、Slack のステータスを監視するのに役立ちます。
-
重要なアクションが実行された場合、または結果が決定された場合は、Slackにメモを追加する必要があります。インシデントコマンダーの指示を待つ必要はありません。独自の判断で行なってください。
- また、Slack ルームに
TODO
のメモを追加して、後で予定されているフォローアップを示す必要があります。
- また、Slack ルームに
-
インシデントコマンダーの指示に従います。
-
会議が終了したら、インシデントの後からステップを開始できます。
対象分野の専門家(SME)の手順#
あなたの使命は、インシデントの原因を特定し、修復するためのアクションを提案・評価し、アクションの実行にあたりインシデントコマンダーを支援することです。
-
手元のあらゆるグラフまたはログを分析して、インシデントを調査します。すべての知見をインシデントコマンダーに伝えます。
- 原因がわからない場合は、それでも構いません。調査中であることを示し、インシデントコマンダーに定期的なアップデートを提供してください。
-
インシデントコマンダーに対し、解決に向けたすべての提案を行います。ただし、どう進めるかはインシデントコマンダーの決断によるもので、指示がないかぎりいかなる行動も取ってはなりません!
-
インシデントコマンダーの指示に従います。
-
会議が終了したら、インシデント後のステップを開始できます。
カスタマーリエゾンの手順#
インシデントに関する公的なメッセージを投稿するために、待機してください。
-
通常は、ステータスページを更新し、会議中の特定の時間にさまざまなアカウントから投稿を送信する必要があります。
-
インシデントコマンダーの指示に従います。
-
会議が終了したら、インシデント後のステップを開始できます。
インターナルリエゾンの手順#
内部の利害関係者にアップデートを提供し、必要に応じて追加の内部対応者を動員します。
-
インシデントコマンダーの指示に応じて、他の人物を呼び出す準備をします。
-
必要に応じて内部の利害関係者に通知し、PagerDutyのインシデントにSubscriber(購読者)を追加します。私たちは「SEV-1 Stakeholders」および「SEV-2 Stakeholders」という定義済みのチームを使用できます。
-
エグゼクティブチームにSlackで定期的なステータスアップデート(およそ30分おき)を行い、現在のステータスのエグゼクティブサマリーを提供します。なるべく簡潔にして、
@here
を使用します。 -
インシデントコマンダーの指示に従います。
-
会議が終了したら、インシデント後のステップを開始できます。