設問の意図と範囲
これは障害の詳細を再現して語ることを求めるものではなく、判断力とコラボレーションに関する行動面の質問です。事前に合意された発動基準が、ユーザーへの影響、対応の質、再発リスク、学習価値の評価にどのように役立つかを説明し、その判断を有益で非難のない（blameless）振り返りへと結びつけます。Google SREは、重大な望ましくない事象に対してポストモーテムを実施することを推奨しています。一般的な発動基準には、ユーザーから視認できる機能低下、データの損失、ロールバックの介入、閾値を超えた解決時間、モニタリングの失敗などが含まれます。また、あらゆるステークホルダーがポストモーテムを要求することも可能です。
面接官が評価するポイント
- 「軽微な影響」を観測可能なメトリクスと明確な閾値に落とし込めるか。
- 事象の封じ込めと学習を切り離し、ポストモーテムを責任追及や文章作成の競い合いにしない姿勢を持てるか。
- 二者択一ではなく、軽量版と完全版のスコープを提案できるか。
- アクションアイテムに担当者、期限、検証エビデンスが設定されているか。
- 敬意を持ったコミュニケーションを取り、関連チームにとっても価値のある学習にできるか。
確認すべき明確化のための質問
- 18分間に影響を受けたリクエスト、ユーザー、SLOのエラーバジェット、ビジネス価値の割合はどれくらいか？
- その事象はロールバック、手動介入、モニタリングの見落としを必要としたか、あるいは類似の障害の再発であったか？
- チームにはすでにポストモーテムの基準、重要度レベル（Severity）、アクションの追跡プロセスが存在するか？
- その結果を必要としているのは誰か、またプライバシー、コンプライアンス、社外向けコミュニケーションは関係しているか？
- 完全なレポートが必要なのか、それとも短いレビューで重要な疑問に回答できるか？
30秒の回答例
「私は『わずか18分だった』という理由だけで判断しません。影響を受けた割合、ユーザーからの視認性、エラーバジェット、ロールバック介入、モニタリングの品質、再発リスクに関する事前合意された基準を適用します。ユーザーが障害を認識しロールバックが発生したため、タイムライン、影響、対応、そして2〜3件の価値の高いアクションを含む、簡潔で非難のないレビューを少なくとも実施します。エビデンス次第で完全なレポートへと拡張します。すべてのアクションには担当者、期日、検証シグナルを設定し、完了するまでチームのバックログやオンコールプロセスで管理します。」
ステップごとの詳細解説
ステップ1：発動基準を適用する
事象を既存の重要度モデルに当てはめます：ユーザーへの影響、継続時間、エラーバジェットの消費、データの整合性、手動ロールバック、モニタリングの失敗、チーム間の連携対応などです。事象の後に特定のチームの都合で変更されないよう、閾値はインシデント発生前に定義しておきます。18分という時間だけでは結論になりません。部分的な失敗とロールバックの組み合わせは、すでに多くのチームにおける軽量レビューの発動基準を満たしています。
ステップ2：レビューの深さを選択する
完全なポストモーテムには、タイムライン、影響評価、根本原因および寄与要因、対応の有効性、再発防止策が含まれます。影響が小さく、1つの原因が明確に理解されている場合は、再発リスクを検証するために時間を30分に区切った（タイムボックス化された）レビューから開始し、エビデンスが求めた場合にのみ拡張します。軽量化とは、参加者、ページ数、アクション数を抑えることを意味し、事実の抜け漏れを意味するものではありません。
ステップ3：非難を排除し、エビデンスに基づき進める
関係者は利用可能な情報に基づいて合理的な判断を下したと前提を置き、システムがどのように失敗を誘発したか（リリースの安全策、アラート、権限、ランブック、コンテキストの不足など）を問いかけます。「誰かが確認を怠った」のような、システムの改善につながらない結論は避けます。ログ、変更履歴、コミュニケーション履歴を引用し、不明な点は推測で埋めずに不明として明記します。
ステップ4：アクションを実行可能にする
各アクションに対して、担当者、期日、優先度、依存関係、完了のエビデンスを記載します。例として、リリース前のヘルスチェック、ロールバック訓練、修正されたアラート閾値などが挙げられます。「もっと注意する」「テストを増やす」などは受け入れ基準にはなりません。アクションをバックログに登録し、合意されたSLOに照らしてレビューします。Google SREが指摘するように、フォローアップアクションのないポストモーテムは信頼性を向上させません。
ステップ5：ステークホルダー間の意見の相違を解決する
プロダクトマネージャーにはレビューのコストと再発防止の価値を説明し、長文のレポートを求めるエンジニアには影響範囲の境界を説明します。タイムボックスを提案し、まずは事実とアクションをまとめた1ページのドキュメントを公開し、エビデンスが正当化する場合にのみ拡張します。いずれかのステークホルダーがレビューに値すると判断した場合は、その理由を記録して評価に含め、役職の上下による拒否権発動を防ぎます。
ステップ6：完了の確認と共有の範囲を設定する
公開後は、アクションのステータス、アラートの再発、類似のリリース、エラーバジェットの傾向を確認します。閲覧者に応じてユーザー識別子や機密情報をマスキングしつつ、有益となるチームに結論を共有します。レビューは公の場での吊し上げになってはなりませんが、過度なアクセス制限もまた同様の失敗を引き起こす原因になります。エビデンスと最終バージョンは、将来の監査や学習のために保管します。
質の高い模範解答
「私は18分という数字だけで判断するのではなく、インシデント発生前に定義された重要度とポストモーテムの発動基準を適用します。ユーザーに見える失敗とロールバックの介入があったことから、影響、タイムライン、対応、再発リスクをカバーする、時間を区切った非難のないレビューを少なくとも実施する正当な理由があります。ログや変更履歴を引用し、根本原因と寄与要因を区別した上で、モニタリング、リリースの保護策、ランブックに構造的な欠陥が見つかった場合にのみ完全なレポートへ拡張します。各アクションには、バックログ上で担当者、期日、優先度、検証シグナルを割り当てます。プロダクトマネージャーにはコストと再発防止の価値を説明し、長文レポートを求めるエンジニアに対してはスコープを適切にコントロールし、機密情報を除いた結果を関連チームに共有します。完了のためには、アクションが終了し類似のインシデントが減少したというエビデンスが必要です。」
よくある間違い
- 影響を受けたユーザーの割合、エラーバジェット、ロールバック、モニタリングの失敗を無視し、継続時間だけで判断すること。
- ポストモーテムを責任追及の場にしてしまい、オンコール担当者が情報を隠すように仕向けてしまうこと。
- 網羅性のためだけに、担当者や完了エビデンスのない数十個のアクションをリストアップすること。
- 受け入れ基準を「テストを増やす」や「もっと慎重になる」などの曖昧な言葉に置き換えること。
- プロダクト側のステークホルダー1人が不要と言っただけでレビューを中止すること。
- アクションを追跡せず、類似のインシデントが減少したかどうかを確認せずにドキュメントを書くだけで終わること。
想定される追加質問と回答
チームに共通のポストモーテム基準がない場合はどうしますか？
ユーザーへの影響、エラーバジェット、ロールバック、モニタリング、再発リスクなど、現在のエビデンスを提示します。今回のインシデントを機に最小限の発動チェックリストを提案し、次期バージョンについてチームで合意を形成します。インシデント対応の最中に複雑なポリシーをその場で作り上げることは避けます。
レビューによって一人の人物が明らかなミスをしたことが判明した場合はどうしますか？
その判断の背景にあった情報とシステム上の制約を記録し、プロセス、ツール、トレーニングによってどのように再発を減らせるかを検討します。意図的なポリシー違反や安全性の問題については、別個のマネジメントプロセスで対応可能です。学習という目的を明確に保つため、ポストモーテム自体は非難のない状態を維持します。
短いレビューで十分であったことをどのように証明しますか？
影響、タイムライン、対応、根本原因の仮説、アクションに回答した上で、合意された期日にアクションのエビデンスと類似のメトリクスを確認する必要があります。未知の影響、チーム間の依存関係、または再発リスクがある場合はスコープを拡大すべきであり、単に分量が短いこと自体が完了を意味するわけではありません。