プロンプトとコンテキスト
複数チーム向けのインシデントコマンドプラットフォームを設計してください。アラートの受信、インシデントの作成、対応役割の割り当て、社内外のコミュニケーションの調整、および復旧後の監査可能なタイムラインの保持が必要です。一貫性、権限、通知ストーム、および復旧目標について説明してください。
これはシステムデザイン、SRE、プラットフォーム、およびバックエンドの職種に適しています。プレッシャー下で検知、コマンド、コラボレーション、振り返りがどのように復旧可能なシステムになるかをテストします。このプラットフォームは単なるチャットではなく、責任者、状態遷移、証跡、デグラデーションパスを備えたコントロールプレーンです。通常時およびピーク時のアラートレート、同時発生インシデント数、参加者数、チャネル、保持期間を明確にしてください。
面接官が評価するポイント
- インシデント管理をモニタリング、チャット、チケットシステムから分離できているか。
- 状態、冪等性、Single Source of Truth（信頼できる唯一の情報源）、同時編集ルールを定義できているか。
- インシデントマネージャー、テックリード、コミュニケーションリード、セクレタリー（記録係）の職務を分離できているか。
- 重複排除、相関付け、通知ストーム、および認可を適切に処理できているか。
- デグラデーション、リージョン復旧、監査の完全性、保持期間を提供できているか。
- MTTA、MTTR、アラートノイズ、コミュニケーション遅延によって設計を検証できているか。
30秒での回答
「私はプラットフォームをアラート取り込み、インシデントオーケストレーション、リアルタイムコラボレーション、通知、レビュー用ストレージに分割します。取り込み層はソースと時間枠によって重複を排除します。オーケストレーションはインシデントを信頼できる唯一の情報源として扱い、監査のために状態と役割の変更をバージョニングします。インシデントマネージャーが指揮を執り、テックリードが診断し、コミュニケーションリードがステークホルダーを更新し、セクレタリーがタイムラインを維持します。イベントは再生可能なストリームが更新をプッシュする前に永続化されます。通知は優先順位付けされ、レート制限されます。リージョン障害時でも最小限のコントロールプレーンと手動フォールバックが利用可能な状態を維持し、復旧時にはタイムラインからレビューが生成されます。」
ステップごとのソリューション
ステップ 1: 境界と目標を定義する
シグナルは、メトリクス、ログ、外形監視、サポートからのエスカレーション、または人間から発生する可能性があります。プラットフォームはシグナルをインシデントと対応ワークフローに整理しますが、モニタリングの計算、チャットの保存、デプロイを代替するものではありません。インシデント作成のレイテンシ、クリティカルな通知配信、タイムラインの耐久性、リージョン復旧時間、および監査の保持期間に関する目標を設定します。
通常負荷と大規模障害を区別します。大規模障害では、毎分何万ものアラート、数百の同時インシデント、インシデントあたり数百人の参加者、SMS、メール、プッシュ通知、Webhookの同時配信が発生します。ピーク時にはバックプレッシャーと優先順位付けが必要であり、低価値の通知がコマンドアクションをブロックしないようにします。
ステップ 2: アラートの取り込み、重複排除、および相関付け
各シグナルについて、ソース、ルールバージョン、タイムスタンプ、フィンガープリント、および生のペイロードを保持します。クライアントのリトライやネットワークの再送には冪等性キーが必要です。ユニーク制約またはリースにより、単一のフィンガープリントに対する重複インシデントの作成を防ぎます。重複排除ウィンドウによって新しい障害が永続的に隠蔽されないよう、サービス、環境、時間ごとに設定します。
相関付けは、サービスのトポロジー、デプロイバージョン、リージョン、共有ラベルから開始し、インシデントマネージャーによる分割や統合を可能にします。自動相関付けでは、そのルールと根拠となる証拠を記録する必要があり、インシデントのスコープを勝手に変更してはなりません。生のアラートは不変であり、集約は派生状態です。
ステップ 3: 状態と役割のモデリング
インシデントは、検知（detected）、トリアージ中（triaged）、緩和中（mitigating）、監視中（monitoring）、解決済み（resolved）、クローズ（closed）などの状態を取ることができます。正当な遷移、実行主体（アクター）、および必要な証拠を定義します。状態は単なるブール値ではなく、影響範囲、現在の仮説、次のアクション、更新日時をまとめて記録します。
対応役割を個人IDから分離します。インシデントマネージャーは優先度と決定を担い、テックリードは調査を担当し、コミュニケーションリードは社内外のアップデートを担当し、セクレタリーはタイムラインを維持します。役割の変更により監査イベントが追記されます。リースとバージョン管理により、2人の対応者がコマンドを意図せず上書きするのを防ぎます。
ステップ 4: 信頼できる唯一の情報源を中心としたコラボレーションの構築
状態、役割、アクションアイテム、コミュニケーション要約をイベントログまたはトランザクションストアに永続化してから、バスを介してWebSocket、SSE、メール、モバイルチャネルに発行します。クライアントは楽観的にレンダリングしてもかまいませんが、バージョン競合が発生した場合はサーバーから最新の状態を再読み込みする必要があります。ブラウザのメモリが決して最終的な真実ではありません。
アクター、サーバー時刻、インシデントバージョン、アクションタイプ、要約、関連アラートをタイムラインに保存します。長大なチャットは別の場所に置くことができますが、決定事項と復旧の証跡は構造化されたタイムラインに属します。リードモデルは現在のインシデントを描画でき、リプレイによってそれを再構築することも可能です。
ステップ 5: 通知ストームとアクセスの制御
インシデントの優先度、オンコールスケジュール、チャネルの信頼性、確認応答（ACK）に基づいてレート制限を行います。低優先度のアラートは要約し、高優先度の通知にはバックオフ、エスカレーション、確認応答タイムアウトを使用します。単一のインシデントによって、1人の対応者に何百もの重複メッセージが送信されないようにします。プロバイダーの障害が状態変更をブロックしないように、通知キューをコントロールプレーンから分離します。
オブザーバー、対応者、インシデントマネージャー、コミュニケーションリード、管理者を、テナント、サービス、環境ごとに認可します。外部向けのステータスページは、影響と進捗の秘匿化されたリードプロジェクションであり、仮説、顧客データ、認証情報を公開してはなりません。閲覧やエクスポートを記録し、緊急時のブレークグラス（特権）アクセスには理由と事後レビューを要求します。
ステップ 6: デグラデーション、復旧、およびレビュー
プラットフォームで障害が発生した場合に備え、電話ブリッジ、静的ランブック、またはバックアップインシデントログを維持します。インシデントの作成、役割の割り当て、タイムラインへの書き込みを最優先で保護します。分析、検索、履歴レポートは利用不可になっても構いません。リージョン展開では、非同期レプリケーションを伴うプライマリライターやシャーディングされた書き込みを使用できますが、フェイルオーバー中の競合処理とリースの再取得について文書化しておきます。
復旧後、検知、確認、緩和、復旧、クローズの各タイムスタンプ、決定事項、アラートの質、コミュニケーション、フォローアップ作業からレビューのドラフトを作成します。元のタイムラインを上書きしてはならず、修正はバージョンを追加する形で行います。MTTA、MTTM、MTTR、重複アラート比率、役割割り当てレイテンシ、通知到達率、アクションアイテムの完了率を追跡します。
情報利得と境界
インシデントコマンドプラットフォームの価値は、すべての会話を1つのページに集約することではなく、責任範囲、状態、証拠を構造化することにあります。根本原因の正しさを保証したり、モニタリングの品質や対応者のトレーニングを代替したりすることはできません。通知、ID基盤、リージョンネットワーク、そしてプラットフォーム自体が同時に障害を起こす可能性があるため、設計には最小限のコントロールプレーンと手動フォールバックが必要です。
模範解答
「私はまず境界を定義します。プラットフォームはアラートと対応を整理し、モニタリング、デプロイ、通常のチャットは分離したままにします。目標は、作成レイテンシ、クリティカル通知の配信、タイムラインの耐久性、リージョン復旧、監査の保持です。取り込み層は生のアラートを保持し、重複排除のためにソースフィンガープリントと冪等性キーを使用します。サービス、リージョン、バージョン、トポロジーによる相関付けは説明可能かつ元に戻せるようにします。
オーケストレーション層はバージョニングされたステートマシンであり、その状態と役割の変更は耐久性のあるログに追記されます。インシデントマネージャーが決定権を持ち、テックリードが調査し、コミュニケーションリードがステークホルダーを更新し、セクレタリーが証拠を維持します。クライアントは再生可能な更新を受信し、バージョン競合時には再読み込みを行います。ブラウザのキャッシュは信頼できる情報源ではありません。コントロールアクションと通知は別々のキューを使用し、優先度、オンコール、確認応答の制限を設けます。
アクセスはテナント、サービス、環境ごとに分離され、外部向けプロジェクションはマスキングされます。リージョン障害時でも、作成、役割の割り当て、タイムラインの書き込みは利用可能な状態を維持し、検索やレポートは読み取り専用またはオフラインにデグレードします。復旧時には不変のタイムラインからレビューが生成され、MTTA、MTTR、アラートノイズ、アクション完了状況が算出されます。プラットフォーム自体が利用不可になった場合は、電話ブリッジと静的ランブックによって指揮系統を維持します。」
よくある落とし穴
- プラットフォームを単なるチャットとして扱う → 重要な状態が監査不能になる → 構造化されたステートマシンとタイムラインを使用する。
- すべてのアラートをブロードキャストする → 通知ストームがコマンドを妨害する → 重複排除、優先順位付け、確認応答、レート制限を行う。
- UI上だけで役割を管理する → 同時対応者が互いの操作を上書きしてしまう → サーバーリース、バージョン、監査イベントを使用する。
- 自動相関付けの処理をブラックボックス化する → 不適切なスコープ変更の理由が説明できない → 生のアラートと相関付けの根拠を保持する。
- 健全なリージョンのみを前提に設計する → プラットフォームの障害によってコマンド不能になる → 最小限のコントロールプレーンと手動フォールバックを提供する。
- レビュー証跡を上書きする → 決定事項やタイムスタンプを検証できなくなる → 生のログを不変に保ち、修正は追記形式で行う。
フォローアップ質問
2人のインシデントマネージャーが同時に権限を要求した場合はどうなりますか？
有効期限付きのテイクオーバーリースと単調増加バージョンを使用します。サーバーは現在のリース保持者からのコントロール書き込みのみを受け入れます。競合に敗れた対応者は再読み込みを行って現在の所有者を表示します。緊急時のブレークグラスには、認可、理由の入力、および監査が必要です。
通知プロバイダーの障害がインシデントの状態に影響を与える可能性はありますか？
通知配信を状態書き込みの前提条件にしてはなりません。まずインシデントと保留中の通知を永続化し、コントロールプレーンが使用可能な状態を維持したまま、分離されたワーカーがリトライ、チャネル切り替え、または電話プロセスのトリガーを行えるようにします。
相関付けによって新しいインシデントが隠蔽されるのを防ぐにはどうすればよいですか？
相関付けは候補としての関係性を作成するにとどめ、生のシグナルは保持します。時間、サービス、リージョン、トポロジーなどの複数の証拠ディメンションを使用します。影響度が大きいシグナルや確信度の低いシグナルには人間の確認を必須とし、ルールのバージョンや分割履歴をタイムラインに記録します。
外部向けステータスページには何を含めるべきですか？
影響範囲、現在のフェーズ、次回の更新予定時刻、復旧の進捗状況といった、プライバシーフィルタリングされたプロジェクションのみを含めます。社内の仮説、顧客識別子、認証情報、未確認の根本原因、詳細なログは、制御された内部ビューに保持します。