ポストモーテム入門 - ポストモーテムとはつまり何なのか -

はじめに

DevOps / SREの文脈で出てくる事後検証イベント「ポストモーテム」についてあまり理解できていなかったので整理します。

ポストモーテムとは

概要

ポストモーテムは、障害などが発生した後、その原因分析や再発防止を行い今後への影響を小さくするための取り組みや、そこで作成される文書（本記事でこの文書のことは「ポストモーテム文書」と表現します）のことです。

詳しくは後述しますが、個人の責任を追求するのではなく、なぜそれが起き得たのかという視線で仕組みやプロセスの改善を図ることや、学習やチームの成長につなげることを目的とする点が特徴です。

言葉の意味

ポストモーテムの英語での綴りはpostmortem。

ポスト（post）はよくある接頭語で「〜の後」「次」の意味。

モーテム（mortem）はラテン語で「死」を意味する mortuus / mors 系の言葉が由来。有名な言葉で言うと、メメントモリ（Memento mori: ラテン語で「死を忘れるな／死を想え」）のmoriと同じ語源とのこと。

英語としてのpostmortemはもともと「検死解剖」「死後検証」などの意味で、そこから転じて「反省会」などの意味でも使われるようになったようです。

何が目的なの？

• 再発防止・早期検知
  • 同じ種類の問題を再発させにくい設計・運用にする
  • 再発しても早く検知して、早く復旧できるようにする
• 学習の場
  • 特定の個人が持つ知識や技術に依存した「属人化」を解消し、暗黙知を手順・監視・設計として共有する
• 社内外の信頼維持
  • 社内外に対して事実と改善を明確に説明できる状態にして、信頼を維持する

いつやるの？

ざっくり言うと、「運用を変える必要があるとき」「価値ある学びを得られそうなとき」ですが、もう少し具体的に整理します:

SLO違反が発生したとき

SLO違反が発生したということは、ユーザの体験が悪くなっているということです。
たとえば:

• レスポンスが悪い（レイテンシの増加）
• 使いたい時に使えない（可用性の低下）
• よく処理が失敗する（エラー率の上昇）

こういったユーザ体験の悪化を、「なんか最近遅い気がする」という定性的な感覚ではなく定量的な指標で測れるのがSLIであり、それを明確な目標にしたものがSLOです。

そしてSLOを運用している組織であれば、「一定水準を下回ったら、新機能のリリースよりも信頼性の向上を優先する」ような合意があるはずです。信頼性を向上させるために運用をどう改善するのか？という流れでポストモーテムを実施するのは自然なことです。

重大な障害が発生したとき

重大障害、つまり容認できないレベルの障害が起こった場合です。代表的な事例としては下記のようなものが挙げられます:

• 重要な機能が利用できない
• セキュリティインシデント
• データの整合性が崩れている

どこからが重大障害なのか、ということに関してSLOほどの明確な指標はないかもしれませんが、単に「エラーが出た」ではなく、事業や利用者に対して目に見えるダメージが出た/出かけたときには運用の見直しが必要であり、ポストモーテムの実施タイミングであると言えるでしょう。

どんな風にやるの？

個人を責めない（Blameless）で、仕組みを変える

「誰が失敗したのか」ではなく、なぜそれが起こってしまったのか（起こり得たのか）に着目する。
「人はミスをする」ことを前提に、ミスしても事故にならないための仕組みづくりをする（ガードレールを整える）

• 本番環境に大きな影響を与える操作は、限られた人や仕組みだけに権限をもたせる
• 人手に頼らず、作業を自動化する
• 間違いが早期に検知される
• 事故が起こっても影響が局所化されるようにする
• 問題が起こっても安全かつ迅速にロールバックできる

など

ポストモーテム文書

ポストモーテムでは、起こった事実の整理や今後の対策を共有するための文書を作成します。
この文書は基本的に広く共有されるべきものですが、書くべきことと書くべきではないことがあります。それらを整理します。

含むべき典型的な内容

• 問題の概要
  • 何が起きたか
    • その時の担当者にはどう見えていたか（どんな情報を知っていたか）
    • なぜその判断になったのか
  • 時系列
  • 重大度
  • 影響範囲
• 直接原因と根本原因（背景要因）
• 解決策・再発防止策
• 教訓
  • 何が上手くいって、次はどうするとよいか
• 今後どう行動・改善するかのリスト（アクションアイテム）

含むべきではない内容

• 担当者や作業者の名指しや、個人の能力に基づく評価
  • 「〇〇さんがミスをした」
  • 「担当者のスキルが低かったため発生」
• 「今後は気をつける」などの精神論
• 推測や感情的な評価と事実の混在
  • 「おそらく〇〇が原因」
  • 「〇〇の焦りが影響した」
  • 推測を書かざるを得ない場合は、仮説である旨を明記する
• 個人情報やセキュリティに関わるもの
  • 顧客などの個人情報（氏名や住所など）や、個人を特定し得るログ
  • 秘密鍵、トークン、パスワードなど
  • 脆弱性の再現手順など、悪用され得る情報は公開範囲に注意
  • 起こった事実に関するものであっても、共有される範囲を踏まえて不適切と思われるものは書かない
    • もしくは匿名化やマスクするなどの加工を行う

終わった後はどうするの？

ポストモーテム文書で策定した各アクションアイテムに、それぞれ1人のオーナーを割り当てます。
必要に応じて協力者を追加することはあってよいですが、オーナーを複数人にするのは非推奨です。責任の所在が不明になり「誰かがやるだろう」という状況を引き起こす危険があるためです。
また、明確なオーナーを割り当てないことも、責任の所在が不明になるので非推奨です。

〇〇とはどう違うの？

ポストモーテム文書と障害報告書の違い

一言で言うと、『ポストモーテム文書』は「学習」やそれにもとづく「改善」に軸足を置いた、比較的内向きの性格が強い。
『障害報告書』は外部向けに説明責任を果たすための意味合いが強い。

ポストモーテムとレトロスペクティブ・ふりかえりの違い

『ポストモーテム』は、障害やトラブルが発生した後に、その重要度に応じて行うイベント。問題の再発確率と影響度を下げることが主なゴール。
『レトロスペクティブ』や『ふりかえり』は定期的に実施されるもので、改善を小さく繰り返すことが主なゴール。