ポストモーテムによる再発防止の知識マップ(知識グラフ)
この記事は、障害対応を復旧で終わらせず仕組みを変えるためのポストモーテムの実務を、概念どうしの関係として整理します。ポストモーテムはblamelessの原則のもとで直接原因と寄与要因を分けて記録し、なぜなぜ分析で人の行動を終点にせず仕組みの不備まで掘ることで寄与要因を見つけます。寄与要因への対応は、効果が消えやすい弱い注意喚起ではなく、手順書を中間段階に据えつつ自動テストや監視のような機械的な対策へ引き上げることが推奨されます。寄与要因を放置すると障害は再発するため、全障害にフル実施はせず影響度と再発可能性でトリアージし、軽微なものも障害管理簿に記録します。顧客向け障害報告書は内容の多くをポストモーテムから転用しますが、責任追及と再発防止の議論が歪まないよう目的を分けて運用します。
ポストモーテム
インシデントの影響・根本原因・対応の時系列・再発防止アクションを文書化する、復旧後に行う構造化された振り返りの型。
障害の振り返り
blameless(非難しない)原則
関係者は持っていた情報の範囲で善意に基づき正しく行動したと仮定し、個人ではなく仕組みの穴を探すポストモーテムの中核原則。
非難なき振り返り
直接原因
障害を直接引き起こした技術的な事象。修正パッチが直す対象。
寄与要因
直接原因の混入・見逃し・被害拡大を許した条件。再発防止策の主な対象になる。
なぜなぜ分析(5 Whys)
「なぜ」を繰り返して原因を掘り下げる分析手法。人の行動を終点にせず、仕組みの不備まで掘ることが求められる。
強い再発防止策(機械的に防ぐ・検知する)
自動テスト・アサーション・型や設計による制約・CIのゲート・監視アラートのように、人の状態に依存せず仕組みが動く限り持続する再発防止策。
自動テスト
アサーション
監視アラート
弱い再発防止策(気をつける・周知する)
「確認を徹底する」「注意喚起する」のように人の記憶と善意に依存し、時間経過と担当者交代で効果が消えやすい再発防止策。
注意喚起
確認の徹底
中程度の再発防止策(手順書・チェックリスト)
リリースチェックリストや障害対応手順書のように、手順が守られる限り持続するが形骸化のリスクもある再発防止策。
チェックリスト
手順書化
ポストモーテム実施のトリアージ
影響度と再発可能性の組み合わせで、フル実施・簡易実施・障害管理簿への記録のみのどれで対応するかを決める運用。
影響度×再発可能性の判定
障害管理簿
軽微な障害も含め、日付・現象・原因・対処を1行または1段落で必ず記録し、数年後も全文検索できるようにする記録簿。
インシデント管理簿
障害台帳
ポストモーテムのレビュー会
初版を事前に配布し、責任判断者を参加者から外して30分程度の時間配分で寄与要因とアクションを確定する会議。
振り返り会
30分のレビュー会
顧客向け障害報告書
何が起きて、どう対処したかという説明責任を果たすために顧客へ提出する文書。内容の多くはポストモーテムから編集して作られる。
障害報告書
コードリポジトリ
ソースコードをバージョン管理するリポジトリで、ADRはこの中にコードと同じ場所で保管される。
ソースコードリポジトリ
Gitリポジトリ
非難する文化での情報隠蔽
個人を処罰する組織で、次の障害発生時に関係者から情報が出てこなくなり、原因にたどり着けなくなる状態。
犯人探しによる情報隠蔽
Azure Well-Architected Framework
Microsoftが提供する、クラウドワークロードの設計品質を高めるためのアーキテクチャガイダンス群である。
障害の再発
直接原因だけを修正し寄与要因が残ることで、同じ構造の障害が別の場所・別の時期に再び発生すること。
同種障害の再発
ポストモーテムでは、関係者が持っていた情報の範囲で正しく行動したと仮定し、個人ではなく仕組みの穴を探すblamelessの原則を採ることが推奨される
ポストモーテムは、障害を直接引き起こした技術的な事象である直接原因を記録する
ポストモーテムは、直接原因の混入・見逃し・被害拡大を許した条件である寄与要因を記録し、再発防止策の主戦場とする
寄与要因は、なぜなぜ分析で「人の行動」を終点にせず、なぜ間違いがそのまま本番に届いたかまで掘ることで見つけられる
寄与要因への対応は、気をつける・周知するではなく自動テスト・アサーション・監視のように機械的に防止・検知する対策へ引き上げることが推奨される
「気をつける・周知する」対策は人の記憶と善意に依存し、時間経過と担当者交代で効果が消えるため、寄与要因への恒久対策としては推奨されない
強い対策がすぐに打てない場合は、手順書やチェックリストを中間段階として先に置き、恒久対策である機械的な対策を期限付きのアクションとして後から実施する
個々のポストモーテムの成立に必須ではないが、チームで継続的にポストモーテムの実践を回す場合は、全障害にフル実施を義務付けると続かないため、影響度×再発可能性でのトリアージによって実施レベルを決めることが前提になる
影響が軽微でトリアージ上フル実施としない障害でも、障害管理簿への記録だけは必ず残すことが推奨される
責任判断者を入れない30分のレビュー会は、影響度×再発可能性のトリアージで「影響大・構造的」と判定されたフル実施の障害についてのみ開かれる
レビュー会は責任の判断をする立場の人を参加者に入れず、個人名が主語の発言を仕組みの主語に置き換えることでblamelessの原則を運用に落とし込む
顧客向け障害報告書は、概要・影響・時系列・直接原因・再発防止策という内容の8割を内部ポストモーテムから転用して作られる
続けるための最小テンプレートは、docs/postmortem/などリポジトリ内に日付付きファイルとして置き、コードと同じ場所でバージョン管理することが推奨される
個人を責めない原則は、責める場で情報が出てこなくなり原因究明が止まるという問題を防ぐためのものである
Azure WAFは、根本原因分析の教訓を対応プロセスの改善・可観測性の強化・設計の改善というシステムへの還元として推奨しており、機械的な対策への引き上げと同じ構図を示す
直接原因だけを直しても寄与要因が残っていれば、別の直接原因が同じ経路で入り込み障害が再発する