ブレームレスなポストモーテム

一行まとめ

ポストモーテムの目的は同じインシデントを二度と起こさないことで、その約束を守るのはアクションアイテムです。だから良いポストモーテムは人ではなくシステムを原因として書き、すべての主張を実際の記録の行で裏付け、すべての対策に「今は失敗し、直せば通る」検証コマンドを付けます。

なぜこれが必要だったのか

GoogleのSRE本第15章(Postmortem Culture)はブレームレスなポストモーテムを強調しています。理由は単純です。人を原因として書くと、次のインシデントでは誰も事実を話さなくなり、事実がなければ原因は見つかりません。「デプロイした人がミスをした」という文は何も直しません。そのミスを可能にしたシステム(設定レビューのないデプロイ、無効になったヘルスチェック、遅れて鳴るアラート)はそのまま残ります。

もっと静かな失敗もあります。アクションアイテムが「完了」で閉じられたのに、同じインシデントがまた起きることです。開けてみると、検証が「キーがあるか」しか見ていなかったり、失敗を || true で覆い隠していたり、サービスが読まない古いコピーを検査していたりします。検証が欠陥を捕まえられないなら、その対策は一度も完了していません。

どう動くのか

原因を分けます。トリガー(trigger)はインシデントを始めた変更で、たいていはデプロイ一つです。根本原因(root cause)はその変更が生んだ、それがなければインシデントが起きなかった欠陥です。たとえばデプロイ v3.2.0 がトリガーで、そのデプロイがコネクションプールを 64 から 5 に減らしたことが根本原因です。デプロイを戻せばインシデントは止まりますが、「プールサイズがレビューなしに変わりうる」という根本原因は残ります。対策は根本原因と寄与要因にかけます。寄与要因(contributing factor)はもともとあった欠陥で、インシデントに気付くのを遅らせたり(高いアラートしきい値)、防げなくしたり(無効なヘルスチェック)、大きくしたり(待機のないリトライ)したものです。三つを混ぜると対策が見当違いの場所に向かいます。

証拠は行で付けます。「最初のエラーは06:24ごろ」ではなく、ログのその行をそのまま貼ります。誰でも同じ行を探し直して確認できる必要があり、もっともらしく作り上げた行は検証で引っかかります。

対策は三つを持ちます。オーナー(人ではなくチーム)、何を変えるか、そして検証コマンドです。検証は三つの性質を持たなければなりません。

性質	意味	よくある偽物
今は失敗する	欠陥が残っていることを捕まえる	キーの存在だけを見る、`
直せば通る	正しい別の直し方も受け入れる	値一つを決め打ちした `grep -x`
自分の要因に敏感である	他の欠陥ではなく自分のものを見る	似た別のキー・古いコピーを検査

検証が対象ツリーを引数($ROOT)で受け取るように書けば、本番設定にも、インシデント当時のコピーにも、直したコピーにも同じように実行してみられます。

アクションアイテム一つはこのような形です(例のキーと基準は形式を示すだけです)。

action: 세션 저장소 연결 수를 팀 기준 이상으로
owner: platform-team
factor: example-too-small
verify: awk -F= '$1=="max_sessions" {v=$2} END {exit !(v != "" && v+0 >= 100)}' "$ROOT/etc/session.conf"

awk -F= は key=value を二つに分け、同じキーが何度も出てくると最後の値が残るように v を上書きします。これはサービスが設定を読む方式と同じです。END で基準と比較して終了コードで答えるので、パイプの後ろに付けたり || echo で包んだりしない限り、その結果がそのまま検証結果になります。この一行を ROOT=<incident-copy>、ROOT=<fixed-copy> でそれぞれ実行してみれば、検証が正直かどうか数秒でわかります。

現場で出会う姿

四半期レビュー会議で対策リストがすべて緑なのに、同じインシデントがまた起きます。開けてみると、三つの対策の検証がそれぞれ別のやり方で嘘をついています。直す順番はいつも同じです。まず検証を直して今は失敗するようにし、欠陥が残っている事実を明らかにします。その次にシステムを実際に直し、検証が正直に通るようにします。検証から直さなければ、システムを直したかどうかすらわかりません。

ブレームレスな書き方にも練習が必要です。「Aが設定を誤って入れた」を「設定変更がレビューとヘルスチェックなしに本番に入ることができた」に書き換えると、文が指し示す直す場所が人からパイプラインへ移ります。タイムラインには人の行動が残っても構いません。ただしそれは「その人がその瞬間に持っていた情報で、なぜそう判断したのか」を理解するための記録であり、原因ではありません。

次のラボでやること

決済インシデントのログ・デプロイ記録・アラートから、トリガーとなったデプロイとタイムラインの三本柱を実際の行で探し、根本原因と寄与要因を分け、対策ごとに検証コマンドを書きます。採点ツールはそのコマンドを、インシデント当時のコピー・直したコピー二つ・要因を一つだけ残したコピーに実際に実行してみます。人の名前のないポストモーテムを書き、本番設定を実際に直した後、「検証通過」なのに同じインシデントが起きた前四半期の対策を正します。