定義と結論
ブレームレスポストモーテムとは、障害を起こした個人を裁く会議ではなく、同じ条件で同じ失敗が繰り返される可能性を下げるための、事実に基づく振り返りです。 「誰が押したか」を隠す必要はありませんが、「その人が不注意だった」で調査を終えません。当時見えていた情報、判断を促した条件、防御が働かなかった理由、復旧を助けた要素まで調べます。
責任をなくす考え方でもありません。担当者は事実を説明し、チームは改善項目を実行します。ただし、人間は間違えるという前提で、レビュー、権限、監視、自動化、手順の設計へ責任の焦点を広げます。結論は「もっと注意する」ではなく、確認可能な仕組みの変更です。
なぜ必要なのか
障害直後に犯人探しをすると、報告した人ほど損をします。次回から失敗、迷い、危険な兆候が隠され、正確な時系列が作れません。一方、「操作ミス」の一言で済ませると、疲労、曖昧な画面、過大な権限、検証環境の不足など、再発条件が残ります。
障害は一つの原因ではなく、複数の条件と防御の穴が同時に重なって起きることが多いため、直接のきっかけだけでなく背景まで見る必要があります。良いポストモーテムは、再発確率を下げるだけでなく、検知を早め、影響範囲を狭め、復旧を速くします。
登場人物と対象
- インシデントコマンダー: 障害対応中の判断と役割分担を統括する
- 記録担当: チャット、アラート、操作、判断を時刻付きで残す
- サービス担当者: システムの構造、変更、復旧策を説明する
- ファシリテーター: 振り返りで断罪や推測に流れないよう進行する
- 行動項目の担当者: 改善を期限までに完了し、結果を共有する
- 利用者・関係部門: 影響を受けた対象。技術症状と利用者影響を分けて記録する
小規模チームでは一人が複数役を兼ねても構いません。ただし、当事者だけで結論を決めず、第三者が読んでも経緯を再現できる文書にします。
実施の流れ
1. 対象を決める
重大障害だけでなく、長時間の復旧、データ損失、同種障害の再発、危うく事故になった事象も候補です。実施基準を先に決めると、立場の強い人に関係する障害だけ対象外になる偏りを避けられます。
2. 事実と影響を集める
開始・検知・判断・緩和・復旧の時刻、アラート、ログ、デプロイ履歴、チャットを集めます。「12:05に担当者が異常に気づいた」は事実ですが、「担当者が雑だった」は評価です。利用者数、失敗した操作、継続時間、データ整合性も可能な範囲で数値化します。
3. 時系列を共同確認する
時計のずれや記憶違いを直し、「その時点で何が分かっていたか」を記します。後から判明した原因を、当時も知っていたかのように語る後知恵バイアスを避けます。
4. 寄与要因と防御を分析する
直接要因、潜在条件、検知の遅れ、影響拡大、復旧を助けたものに分けます。「なぜ」を繰り返す方法は便利ですが、一列の根本原因に押し込めず、複数の枝を残します。
5. 行動項目を選ぶ
行動項目は、担当者、期限、完了条件を持つ小さな変更にします。
悪い例: 次から注意する
改善例: 本番DBの破壊的変更はdry-run結果を保存し、別担当者の承認後に実行する
完了条件: CIで未承認の変更が拒否されることをテストで確認する
全部を直す必要はありません。発生可能性、利用者影響、検知可能性、実装コストを見て優先順位を付けます。
6. 共有し、追跡する
文書を保存して終わりにせず、定例で未完了項目を確認します。機密情報や個人情報は除きつつ、他チームが学べる範囲を共有します。
主要な分析パターン
| 観点 | 問い | 改善例 |
|---|---|---|
| 予防 | 危険な操作を止められたか | 権限分離、入力検証、段階的リリース |
| 検知 | 利用者より先に気づけたか | SLOに基づくアラート、合成監視 |
| 影響限定 | 一部障害で済ませられたか | レート制限、機能フラグ、隔離 |
| 復旧 | 戻す手段は明確だったか | ロールバック、バックアップ復元演習 |
| 学習 | 類似サービスへ展開できるか | チェックリスト、共通基盤の修正 |
具体例：本番データの誤削除
管理画面で「テストユーザー削除」を実行したところ、本番の一部ユーザーまで削除されたとします。直接のきっかけは担当者のクリックです。しかし調査すると、環境名が小さく、本番と検証で同じ配色、削除対象件数の確認なし、権限が広い、バックアップ復元手順が未演習だったかもしれません。
この場合の改善候補は、環境ごとの外観変更、対象件数の表示、本番だけ再認証、削除ではなく論理削除、最小権限化、復元演習です。「担当者を変える」だけでは、危険な条件を次の担当者へ渡すだけです。
よくある誤解
「ブレームレスなら過失を指摘できない」
故意の違反、ハラスメント、法令違反まで免責する概念ではありません。学習の場と人事・法務の手続きを混同せず、必要なら別経路で扱います。
「根本原因を一つ見つければよい」
複雑なシステムでは、一つの原因を除いても別経路で事故が起こります。「根本原因」という言葉より、寄与要因と防御の組み合わせを見る方が実践的です。
「文書を詳しくすれば成功」
長さより、正確な影響、意思決定の背景、優先された行動項目が重要です。未完了の改善が放置されるなら、立派な文書にも効果はありません。
注意点とベストプラクティス
- 障害直後の感情が強い時間を避けつつ、記憶が薄れる前に開催する
- 個人名を不必要に強調せず、役割名を使う
- 推測には「推測」、確認済みには証拠を付ける
- 復旧を助けた良い判断も記録する
- 行動項目を増やしすぎず、高い効果が期待できるものを選ぶ
- 同種の未完了項目が繰り返される場合は、管理上の優先順位を見直す
デバッグと確認方法
ケーススタディ: 改善項目が再発防止にならない時
誤削除事故の後に「本番作業前チェックリストを追加する」と決めても、三か月後に同種事故が起きることがあります。悪い分析は、チェック欄を飛ばした担当者へ再教育を行い、同じ項目をもう一度課すことです。深夜作業、緊急復旧、画面上で環境を識別しにくい状況では、注意力に依存する防御は最も必要な時に弱くなります。
行動項目を選ぶ時は、事故経路のどこで働くか、回避できるか、壊れた時に検知できるかを確認します。良い例は、本番削除APIを既定で無効にし、対象件数を返す事前確認、時間制限付き権限、別担当の承認、削除件数アラートを組み合わせることです。チェックリストも補助にはなりますが、単独では完了条件にしません。机上演習で、急いだ担当者が手順を飛ばしても技術的防御が止めるかを試します。
改善後は項目の完了数ではなく、危険操作の拒否件数、承認に要した時間、誤検知、復元演習の所要時間を観測します。承認待ちが長すぎて緊急時に共有アカウントを使うようになれば別の危険を作っています。拒否が一度もない場合も、操作が安全になったのか監視が動いていないのかをテストで区別します。ポストモーテムは文書公開で終わらず、防御が現実の条件で働く証拠を得た時に初めて学習が閉じます。
完成後は次を確認します。
- 時系列をログや履歴で裏付けられるか
- 利用者影響と技術症状が分かれているか
- 当時の情報と後から得た情報を区別したか
- 「不注意」「知識不足」で分析が止まっていないか
- 各行動項目に担当、期限、完了条件があるか
- 再発予防だけでなく検知・影響限定・復旧も扱ったか
同じ状況を机上演習し、新しい防御が本当に止めるか試すと、改善の有効性を確認できます。
まとめ
良いポストモーテムの成果は、犯人ではなく、次の事故を防ぎやすくする具体的な変更です。 事実、当時の判断条件、複数の寄与要因、働かなかった防御を調べ、追跡可能な行動項目へ変換します。安心して失敗を共有できることと、改善を最後まで実行することはセットです。
参考資料
- Google SRE Book: Postmortem Culture
- Google SRE Workbook: Postmortem Culture
- NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide
