障害対応が終わってほっとしたあと、振り返りの場がいつの間にか「誰のミスだったか」を確かめる時間になっていた、という話はよく耳にします。
そうなると、次に同じことが起きても、当事者は正直に経緯を話しにくくなる。
障害から学ぶための記録として広く使われているのが、ポストモーテム（postmortem）です。
テックリードを目指して学んでいる立場で Google の SRE 本を読むと、書き方以上に「文化」の話に紙幅が割かれていることに気づきます。
振り返りの場が、責める場になっていないか気になったことはありませんか？
ポストモーテムは「犯人探し」ではなく「原因探し」
Google の SRE 本は、ポストモーテムをインシデントとその影響、解決のために取った行動、根本原因、再発を防ぐフォローアップを書き残す記録として扱っています。
その土台にあるのが、非難しない（blameless）という前提。
同書はこれを、個人やチームを責めずに、インシデントを引き起こした要因の特定に焦点を当てる考え方として説明しています。
関わった人は、そのとき手元にあった情報のもとで正しいと思うことをした、と仮定するわけです。
問うべきは「誰が間違えたか」ではなく「なぜ正しい情報が届かなかったか」になります。
Postmortem Culture: Learning from Failure（Google SRE Book）
責めると、次の報告が遅れる
非難しない理由は、優しさのためではありません。
責められる場で経緯を話せば不利になると分かっていれば、人は小さなミスや違和感を報告しなくなる。
報告が遅れれば、同じ弱点が見過ごされたまま次の障害につながります。
非難しない文化は、システムの弱点を早く見つけるための仕組みそのものなのです。
いつ書き、何を書くか
ポストモーテムは、あらゆる不具合に書くものではありません。
SRE 本は、書くきっかけの例として次のような条件を挙げています。
- ユーザーから見える停止や劣化が、決めたしきい値を超えた
- データの損失が起きた
- オンコール担当者の介入（ロールバックやトラフィックの切り替えなど）が必要になった
- 解決までの時間が、決めたしきい値を超えた
- 監視で検知できず、人が見つけた
- 関係者から依頼があった
条件を事前に決めておくと、「今回は書くほどでもないかも」という迷いが消える。
しきい値の置き方は、どこまでの信頼性を目標にするかという SLO の考え方と地続きです。
中身は「時系列・影響・原因・次の一手」
書く中身は組織ごとにテンプレートが異なりますが、骨格はほぼ同じ。
- 何が起きたかの時系列（検知・判断・対応の記録）
- 影響の範囲と大きさ（どのユーザーに、どれくらい）
- 原因と、それを許した仕組みの穴
- 再発を防ぐためのアクションアイテム
PagerDuty が公開しているインシデント対応の手引きでは、インシデントコマンダーがポストモーテムの担当者を指名し、SEV-1 なら 3 日以内、SEV-2 なら 5 営業日以内に振り返りの会議を設定するよう定めています。
Postmortem Process（PagerDuty Incident Response）
時間が空くほど細部は忘れられるので、期限を先に決めておく価値は大きい。
アクションアイテムで「書いて終わり」を防ぐ
SRE ワークブックには、悪いポストモーテムと良いポストモーテムを並べて比べる章があります。
悪い例として挙げられているのは、個人名を出して責める書き方や、「監視を改善する」のような完了の見えないアクションアイテムでした。
良いアクションアイテムの特徴は、次の 4 つ。
- 担当者が 1 人に決まっていて、追跡用のチケットがある
- 優先度が付いていて、どれから手を付けるかが分かる
- 「どうなったら完了か」が測れる形で書かれている
- 人への注意喚起より、仕組みの修正を優先している
同書は、Google の Ben Treynor Sloss 氏による「アクションが伴わないポストモーテムは、ユーザーから見れば書かなかったのと区別がつかない」という言葉も引いています。
Postmortem Culture: Learning from Failure（The Site Reliability Workbook）
ポストモーテムの価値は、文書の出来よりもアクションアイテムが閉じたかどうかで決まると言ってよさそうです。
テックリードが整えるのは「言葉」と「追跡」
テックリードがこの文化に関われるのは、書式を配ることより、日々の言葉づかいと仕組みの側。
ワークブックは、「なぜ聞かなかったのか」ではなく「どんな兆候があり、なぜ見過ごされたのか」と問い直すよう勧めています。
振り返りの場で個人名を主語にしない、アクションアイテムをチケットにして定例で確認する、といった小さな約束を積み重ねる。
よく書けたポストモーテムを共有して称えることも、書く側の負担を報われるものに変えます。
「事実」と「好み」を分けて話すというコードレビューの約束事とも、根っこは同じでしょう。
最後に
ポストモーテムは、障害を「誰かのミス」から「仕組みの穴」に置き換えて学ぶための記録です。
書くきっかけを決め、時系列と原因を残し、担当と完了条件のあるアクションアイテムで閉じる。
その流れを下から支えているのが、責めずに問い直す言葉づかいだというのが、読み進めていちばん腑に落ちたところでした。
以上です。
コメントを残す