SRE 実践 #5 ポストモーテム — 非難なき振り返りとアクションアイテムの事後管理

障害は必ずまた起きます。組織が選べるのは障害の有無ではなく、同じ障害を繰り返すのか、毎回新しい障害に出会うのかです。この分かれ道を決める制度がポストモーテム(postmortem、事後分析)です。今回はポストモーテムを形式的な報告書ではなく、実際の学習装置として機能させる方法を扱います。

非難なしは温情主義ではなく情報戦略です #

ポストモーテムの第一原則は非難なし(blameless)です。障害に関与した個人を名指しして処罰しないという原則ですが、これを「優しくしよう」と理解すると本質を見失います。理由は冷徹に実用的です。

非難のある組織では情報が消えます。 コマンドを打ち間違えた人が処罰される文化なら、次の障害でその人は自分の知っていることを話しません。タイムラインは不正確になり、原因分析は上滑りし、同じ障害がまた起きます。非難なしは、正確な情報を得るために支払う対価です。

そして論理的な根拠がもうひとつあります。人のミスが可能だったこと自体がシステムの欠陥です。「A が本番で誤ったコマンドを実行した」で止まれば、アクションアイテムは「A が気をつける」になります。これは再発防止ではありません。正しい問いは次へ続きます。なぜ本番でそのコマンドが実行可能だったのか? なぜ確認のステップがなかったのか? なぜ元に戻すのが難しかったのか? 答えがシステムの改善(権限分離、確認プロンプト、ロールバックの自動化)に到達するまで「なぜ」を繰り返すのが原因分析の方法論です。

いつ書くのか — トリガーを先に決めます #

すべての問題にポストモーテムを書けば制度は形骸化し、基準がなければ大きな障害もうやむやに流れます。トリガーを明文化します。一般的な基準はこうです。

• ユーザー影響が SLO バジェットの一定割合(例: 28 日バジェットの 10%)以上を消費した障害
• データの消失または汚損が発生したすべての事象
• オンコールのエスカレーションが上位体制まで上がった障害
• 影響の大小にかかわらず、対応の過程でツールや手順の欠陥が露呈したケース(ヒヤリハットを含む)

最後の項目が重要です。実害のなかったヒヤリハット(near miss)は、最も安い授業料で同じ教訓をくれる機会です。

テンプレート — タイムラインが背骨です #

ポストモーテム文書の標準構成は次のとおりです。

タイムラインを書くときのコツは、当時知っていたことと今知っていることを区別することです。「22:14、ダッシュボードでエラー率の上昇を確認。この時点ではデプロイとの関連は不明だった」のように書けば、あとで読む人は「なぜすぐロールバックしなかったのか?」という結果論の非難ではなく、「この時点で関連に気づけるようにするには何が必要だったか」という生産的な問いへ進みます。

もうひとつ、影響のセクションをエラーバジェットにつなぎます。「この障害でバジェットの 40% が消費された」という一文は、この障害のフォローアップ作業がなぜロードマップより優先なのかを数字で説明してくれます。

アクションアイテム — ポストモーテムの成否が分かれる場所 #

ポストモーテム制度が死ぬ経路は決まっています。振り返りはよく書けたのにアクションアイテムがバックログの底に沈み、半年後に同じ障害が起き、過去の文書を開いたらまさにその再発防止策が未完了のまま残っている、という経路です。これを防ぐルールは単純ですが、強制力が必要です。

• すべてのアクションアイテムにオーナー 1 名と期限を付けます。「チームで検討」はオーナーではありません。
• 優先度を分けます。 再発を直接防ぐ項目(P0)と、あればよい項目(P1 以下)を分け、P0 はスプリントに即編入します。
• 完了率を定期的に点検します。 月次の運用レビューで「前四半期のポストモーテムのアクションアイテム完了率」を見るだけで、放置は大きく減ります。
• アクションアイテムを無限に積みません。 障害ひとつに 30 個のアクションアイテムは、何もしないと言っているのと同じです。再発防止に直接効く少数に圧縮します。

共有 — 文書は読まれて初めて資産です #

書き終えたポストモーテムをチームのフォルダに入れて終わりにしてはいけません。組織全体が閲覧できるリポジトリに集め、大きな事象はレビュー会議で一緒に読みます。他チームの障害から自分のシステムの同じ弱点を発見できることが、ポストモーテム共有の実質的な効用です。新入社員に代表的なポストモーテム数編をオンボーディング資料として渡す組織もあります。システムの実際の弱点と対応の文化をこれほどよく見せる文書はありません。

まとめ #

• 非難なしは正確な情報を得るための戦略です。非難のあるところで、タイムラインは嘘をつき始めます。
• 人のミスで分析を止めません。そのミスを可能にしたシステムの欠陥に到達するまで「なぜ」を繰り返します。
• ポストモーテムのトリガー(バジェット消費率、データ消失、ヒヤリハット)を先に明文化します。
• タイムラインは当時知っていた情報を基準に書き、影響はエラーバジェットで定量化します。
• 成否はアクションアイテムの追跡で分かれます。オーナー・期限・優先度を強制し、完了率をレビューします。
• 次回はシリーズ最終回として、繰り返しの手作業(トイル)を測定し、自動化で返済していく方法です。