ポストモーテムは、開くのは簡単で、役に立つものにするのは難しい会議です。会議が開かれ、ドキュメントが書かれ、アクションアイテムが四つ記録され、そして六か月後に同じ障害がふたたび起きます。そのころ誰かが、まったく別のものを探している最中に、あの古いドキュメントを見つけることになります。

この話題では「非難なし」という言葉にほとんどの注目が集まります。その原則は実際に重要なのですが、失敗が起きているのはそこではありません。非難なしを厳格に守りながら、それでも何ひとつ変わらないレビューを回している組織はいくらでもあります。理由は単純で、レビューそのものを成果物として扱ってしまい、成果物を生み出すための手段として扱わなかったからです。

あなたのポストモーテムが機能しているかを確かめるテストは、恥ずかしくなるほど単純です。直近六か月に出たアクションアイテムのうち、実際に完了した割合はどれくらいですか。 答えが「ほとんど」であれば、見た目がどうであれそのプロセスは機能しています。半分を下回るなら、プロセスを運用しているのではなく会議を開いているだけであり、テンプレートを立派にしても直りません。担当者と期日がついた少数の項目のほうが、誰にも手をつける時間がない網羅的なリストより有効です。

ポストモーテムは本当は何のためにあるのか

何が起きたのかを説明するためではありません。その場にいた人たちは、インシデントが収束するころにはたいてい経緯を把握しています。

ポストモーテムが存在するのは、小さな問題が大きな問題に育つことを許した条件を見つけ出し、そのうちのいくつかを変えるためです。これは「何が壊れたのか」とは別の問いであり、その違いは書き始めた瞬間に文面へ表れます。「データベースのコネクションが枯渇した」は、壊れたものの説明です。「コネクションプールの飽和に対してアラートが一つも鳴らず、それを示したはずのダッシュボードはオンコールのランブックに載っていない」は条件の説明であり、条件には手を入れられます。

前者からは「今回は再起動で復旧した」以上の行動は出てきません。後者からは、アラートを一本足す、ランブックにダッシュボードへのリンクを一行足す、という具体的な作業が出てきます。この差が、半年後に同じことが起きるかどうかを決めます。

二つめの産物は常に過小評価されていますが、出来事についての共有された記述です。これがないと各自が自分の版を持ち続け、その版は一人ひとりがもともとシステムについて信じていた方向へ少しずつ寄っていきます。一年後には、同じ障害を一緒に経験した二つのチームが、食い違う話をして議論することになります。

非難なしには具体的な意味がある

誰も間違えなかった、という意味ではありません。手に入る情報をもとに合理的に判断した人が、結果として誤りだった行動を取ったと前提したうえで、その行動がそのときなぜ正しく見えたのかを問う、という意味です。この実践と、それに伴う失敗のパターンについては、GoogleのSREブックが詳しく解説しています。

これが単なる優しさで終わらない理由は、非難が情報を破壊するからです。インシデントが個人に貼りつく組織では、人は出来事を慎重に記述し、都合の悪く見える細部を落とし、安全に説明できるだけ理解できるまで報告を遅らせます。そうなるとレビューは、自己防衛のために編集された記述を材料にして進むことになります。これは考えうるかぎり最悪の入力です。

しかも失われるのは、価値の高い情報から順にです。判断を誤ったその瞬間に何が見えていたのか、なぜそれで十分だと思ったのか。まさにその部分が最初に削り落とされます。

実務のうえでは、非難なしは言葉づかいの性質です。「なぜサービスを再起動したのですか」は防御を招きます。「再起動を決めたとき、ダッシュボードには何が表示されていましたか」は情報を招きます。二つめの質問のほうが有用でもあります。答えが同僚についての事実ではなく、自分たちの監視についての事実になるからです。

本当に個人の働きぶりに問題があるのなら、それは別の場で直接扱ってください。インシデントレビューの中で処理するとレビューが壊れますし、そもそもその会話をするのに適した場ではありません。

学びになるタイムラインの作り方

タイムラインはドキュメントでもっとも価値の高い部分であり、同時にもっとも頻繁に書き損なわれる部分でもあります。人間が抜き取られた技術的イベントの羅列として書かれてしまうからです。

人が何を知っていて、それがいつだったのかを書いてください。「14:32にサービスを再起動した」だけでなく、その人が14:32に何を見ることができ、何が起きていると信じていたかまで書きます。手を入れられる材料はそこにあります。曖昧なダッシュボードのせいで生まれた十五分の遅れは直せる問題ですが、ただの空白として記録された十五分の遅れは直せません。

意味のあった瞬間に印をつけましょう。いつ始まったか、誰かが最初に気づいたのはいつか、適切な人が入ったのはいつか、原因が理解されたのはいつか、緩和されたのはいつか、解消したのはいつか。改善が住んでいるのはその間隔であり、検知までの時間がもっとも大きい間隔であることが非常に多いです。

復旧そのものを速くしようと考える前に、この検知の間隔を見てください。多くの現場では、修正にかかった時間よりも、誰も気づいていなかった時間のほうが長くなっています。

記憶が新しいうちに、できれば一日か二日のうちに書いてください。ある瞬間に誰が何を信じていたかの記憶は、何が起きたかの記憶よりもはるかに速く薄れていきます。

根本原因がひとつであることはまれ

この言い方は、もっともらしい最初の説明で止まることを促します。しかし規模の大小を問わず、インシデントは複数の条件が同時に成立して初めて起きる連鎖です。

役に立つレビューは、代わりに寄与要因を並べます。障害を引き起こした変更、それを捕まえたはずなのに存在しなかったテスト、誰も見ていないチャンネルに飛んだアラート、以前のアーキテクチャに対しては正確だったランブック。それぞれが別々の機会であり、連鎖のたまたま先頭にあったものではなく、もっとも安く直せる二つを選ぶことができます。

この「選べる」という点が実務では効きます。原因が一つだと書かれた瞬間に対策も一つへ固定され、それが高価な対策だった場合、結局は何も実行されないまま終わります。

これは、よくある歪みも減らします。レビューが単一の根本原因を名指しするとき、その原因は非常にしばしば「人為的ミス」になります。これは説明ではなく記述であり、調査が始まるべきだったまさにその地点で調査を閉じてしまいます。

フォローアップを実際に起こす

ポストモーテムの生死が決まるのはここで、処方はまったく地味です。

項目を減らす。 完了する二件は、完了しない八件に勝ります。検知時間、影響範囲、再発確率のどれを下げるかで順位をつけ、残りは切ってください。

名前のついた担当者と期日を置く。 置き場所はドキュメントではなく、普段使っている作業トラッカーです。ポストモーテムの中だけに住む項目は計画づくりの場で見えず、仕事が実際に日程へ載るのはその場だからです。

未完了の項目を次のポストモーテムで点検する。 この習慣ひとつが、どんなテンプレートよりも効きます。終わっていないことを目に見えるようにし、つながりのない会議の連なりを一つのプロセスへ変えます。

いくつかの項目は正直に受け入れる。 約束の半分を安定して片づけるチームなら、約束を半分にすべきです。誰も予算をつけない意図を記録するのは、行動しないという決定を記録するより悪いことです。後者は少なくとも本当のことだからです。

ここから出てくる改善は、たいてい当社の災害復旧のガイドやソフトウェアテスト戦略が扱っているものと同じ系統です。より速い検知、より狭い影響範囲、そして最初に書いた本人でなくても運用できるシステムです。

Mecanik はサーバーセキュリティ分析の一環として、当社が保守するシステムでインシデントレビューを実施しています。そのほとんどに共通する型は同じです。技術的な原因はすぐに理解され、高くついたのは検知までの空白のほうでした。

よくある質問

ポストモーテムは何のために行うのですか？ 小さな問題が大きな問題に育つことを許した条件を見つけ、そのいくつかを変えるためであり、これは何が壊れたのかとは別の問いです。出来事についての共有された記述も生まれます。それがないと各自が私的な版を持ち続け、その版はもともとシステムについて信じていた方向へ寄っていきます。

非難なしとは実際には何を指しますか？ 手に入る情報をもとに合理的に判断した人が結果として誤った行動を取ったと前提し、その行動がそのときなぜ正しく見えたのかを問う、という姿勢です。重要なのは、非難が情報を破壊するからです。人は自己防衛のために記述を編集し、レビューは汚れた入力を材料にして進むことになります。

ポストモーテムで単一の根本原因を特定すべきですか？ いいえ。規模の大小を問わずインシデントは複数の条件が同時に成立する連鎖なので、寄与要因を並べるほうが有用です。連鎖の先頭にあったものではなく、もっとも安く直せる二つを選べますし、説明ではなく記述にすぎない「人為的ミス」で締めくくることも避けられます。

インシデントのタイムラインには何を含めるべきですか？ システムが何をしたかだけでなく、人が何をいつ知っていたかを含めます。いつ始まり、誰かが最初に気づいたのはいつで、適切な人が入ったのはいつか、原因が理解され、緩和され、解消したのはいつかを記録してください。改善が住むのはその間隔で、検知までの時間がたいてい最大です。

ポストモーテムのアクションアイテムはなぜ終わらないのですか？ 作業トラッカーではなくドキュメントの中に住んでいて、日程を組む場で見えないからです。項目を減らし、普段のトラッカーに名前のついた担当者と期日を置き、次のポストモーテムの冒頭で未完了の項目を点検して、終わっていないことを目に見えるようにすれば直ります。