プロンプトとユースケース
あなたがレビューを支援した本番インシデントについて説明してください。事実をどのように再構成し、個人の非難を避け、具体的なアクションを推進し、変更によって再発リスクが低減したことをどのように検証しましたか？回答では、プレッシャー下におけるコミュニケーション、トレードオフ、コラボレーション、そしてやり抜く力を示す必要があります。
面接官が見ているポイント
- タイムラインと証拠に基づいて、影響、意思決定、復旧について説明できるか。
- 非難のない文化（blameless culture）と説明責任の回避を区別し、システムとプロセスに焦点を当てているか。
- 「モニタリングの改善」を、担当者、期限、受け入れ基準のシグナルへと落とし込めているか。
- 自分自身の判断ミスを認め、チーム横断的なフォローアップと検証を示せているか。
回答前に確認すべき質問
- どのユーザー、SLO、またはビジネスフローが、どれくらいの期間影響を受けましたか？
- あなたはどのような役割を果たし、どの決定を直接下しましたか？
- 当時把握されていた事実はどれで、後知恵による結論はどれですか？
- アクションはどのように優先順位付けされ、担当が割り振られ、検証され、測定されましたか？
30秒の回答フレームワーク
「状況、行動、結果、ポストモーテム」の流れで回答します。まず、タイムラインに沿って影響と復旧目標を数値化し、次に自身の運用面およびコミュニケーション面での責任を説明します。レビューでは、個人の過失を追及するのではなく、観察可能なシステムの状態、シグナル、意思決定の背景について議論します。最後に、計画を優先度の高い少数のアクション（それぞれ担当者、期限、測定可能なシグナルを設定）に絞り込み、リリース、アラートのリプレイ、またはGameDayを通じて結果を検証します。
ステップごとの詳細解説
1. 事実の境界を確立する
アラート、ログ、変更履歴、ユーザーへの影響を収集し、タイムゾーンを考慮したタイムラインを構築します。観察された事実、当時立てられていた仮説、後知恵を明確に区別し、後の情報に基づいて以前の決定を不当に判断しないようにします。
2. 自身の役割を述べる
オンコールエンジニア、コーディネーター、リリース責任者、支援対応者のいずれであったかを述べ、自身の権限とエスカレーションパスを説明します。面接官が求めているのは、全員の成果の羅列ではなく、あなた自身の具体的な貢献です。
3. ヒロイズムではなく復旧プロセスを説明する
影響をどのように緩和し、リスクの高い変更を一時停止し、支援を要請し、ステークホルダーに状況を伝えたかを説明します。ロールバック、機能の縮小提供、トレードオフの受け入れを行った場合は、当時把握されていたシグナルやリスクと関連付けて説明してください。
4. 非難のない議論のルールを設定する
「不注意」や「無責任」といったレッテル貼りではなく、システムの状態、ツールのフィードバック、プロセスのギャップ、意思決定の背景に焦点を当てます。非難しない姿勢は学習の質を担保するものであり、権限管理、トレーニング、コンプライアンスに関する説明責任を免除するものではありません。
5. 変更可能なシステム要因を特定する
原因をトリガー、増幅要因、検知の遅れ、復旧の障害、組織的な制約に分解します。単一のしきい値であっても、検知のギャップとキャパシティ設計の問題の双方が関係している可能性があります。「誰かがアラートを見落とした」という理由だけに矮小化してはいけません。
6. 受け入れ可能なアクションを作成する
各アクションには、具体的な作業内容、担当者、期限、優先度、受け入れシグナルが必要です。「モニタリングの追加」をクエリ、しきい値、ルーティングルール、訓練実施日に書き直し、単なる願望が計画のように見せかけられないようにします。
7. 意見の相違に対処する
優先順位が対立した場合は、ユーザーへの影響、リスクの低減、実装コスト、依存関係に立ち返ります。却下された提案とその理由を記録し、抽象的な議論を続けるのではなく、有用であれば小規模な実験を実施します。
8. 改善のループを検証する
リリース後は、類似のアラート、復旧時間、ユーザーメトリクスを監視し、障害訓練やロールバック訓練をスケジュールします。メトリクスが改善しない場合は、アクションを再オープンします。完了とは、単にドキュメントを提出することではなく、リスクが低減した証拠があることを意味します。
トレードオフと境界線
- ポストモーテムの詳細度は、多ければ良いというわけではありません。意思決定を変えるか、リスクを低減する証拠を残します。
- 非難のない議論は情報の質を向上させますが、悪意ある行動、コンプライアンス違反、特権の濫用については、引き続き正式な調査手続きに従います。
- アクションが多すぎると実行力が分散します。リスクと可逆性に基づいてバッチごとに提供します。
- 訓練はプロセスのギャップを明らかにしますが、あらゆる極端な障害がカバーされていることを証明できるわけではありません。何が未検証のままであるかを明示してください。
実施計画と証拠
- インシデント発生後、タイムライン、影響、主要な証拠を確定させ、関係者間で確認します。
- 事実、仮説、システム要因、個人の認識を区別した、非難のないレビューを実施します。
- 担当者、期限、優先度、受け入れメトリクスを定めてアクションを追跡します。
- リリース、アラートのリプレイ、ロールバック、またはGameDayを通じてアクションを検証します。
- Google SRE Postmortem CultureおよびAWS Game Daysのガイダンスに照らして学習ループを検証します。
よくある間違いとフォローアップ質問
間違い1：個人の武勇伝を語る
シグナル、コラボレーション、システムの変更点について説明せず、徹夜での修正ばかりを強調しても、チームのリスク低減にはつながりません。
間違い2：説明責任の回避に非難のない文化を利用する
非難のないレビューは学びを守るためのものであり、権限、トレーニング、コンプライアンスの責任を免除するものではありません。事実究明と改善がどのように並行して進むかを説明してください。
間違い3：スローガンをアクションとして列挙する
「モニタリングの改善」や「テストカバレッジの向上」には、担当者も受け入れ条件もありません。これらを実行可能で測定可能なタスクに書き換えてください。
フォローアップ：担当者がアクションを拒否した場合はどうしますか？
影響の証拠とリスクの優先順位をすり合わせ、意見の相違を記録し、対立を単なる議事録のまま放置せず、レビュー期日を設定した低コストの実験を実施します。
フォローアップ：ポストモーテムが機能したことをどう証明しますか？
類似のアラート、MTTR、ロールバックの成功率、ユーザーへの影響を比較し、GameDayや障害注入を活用します。メトリクスに変化が見られない場合は、仮説とアクションを再評価します。