ポストモーテム
tatsuyaポストモーテムをより良いものにするためのアイデア
反省会にしない
-
誰も悪くない、誰がやっても失敗した
=> 誰かを犯人にしてしまう=>次から本番環境での変更を恐れるようになる=>チャレンジする勇気を失う=>仕事へのモチベーションが下がり、組織全体の成長にも悪影響を及ぼす可能性がある
犯人を特定しなくても、犯人探しの雰囲気が漂うことで、当事者は自分が悪いのだと思い始める。ポストモーテムの場で発言が減る可能性がある。当事者が発言しないポストモーテムにどれだけの価値がある？
単に「誰かを責めない」だけでなく、「あたなは悪くない」というフォローを積極的に入れる必要がある。 -
自分たちのためではなく、外の説明のために行っている
=>外部に説明する必要は別であるかもしれないが、自分たちのためになる学びや改善をしていきたい。効果的に深堀する方法として、操作ミスやバグの混入などを引き起こしたメンタルモデルを検討してみること。
「どのような前提知識があれば自分で気づくことができたのか？」その行動の背景にある考え方を知れば、組織やプロセスの問題が浮き彫りになる。 -
インシデント対応のオペレーションを振り返る機会は、発生直後の熱量があるうちにしか作れない。
=> インシデントの原因調査や再発防止策はログやメトリクス流があれば後からでも検討可能である。なので、暑いうちにうまくいったこと、改善できることを話し合い、インシデント対応を乗り切ったチームを褒めていこう。
tatsuya
他チームが学びやすいポストモーテムとは？
読むだけで、システムの概要が理解できる
- なんのためのシステムなのか？
- どんな設計なのか？
- どんなミドルウェアを使っているのか？
問題と対応策の間に飛躍がない
- 対応策に至る制約を可能な限り明確化する
「誰しもが思う疑問の記載を省略してしまう」問題
- 当事者がポストモーテムを執筆/共有した際に、他のメンバーからの質問に対して、制約を口頭で補足して終わるから。
=> 当事者がポストモーテムを執筆。SREがポストモーテムレビューのファシリ。を行ってみる。
- 全体共有前に執筆のための会議をする
- 執筆のための会議はSREが主導する
- SREが担当する他チームも呼ぶ
会議（30分）の流れ
- 15分間黙読、質問と提案をコメントしてもらう
- SREが質問をピックアップし、執筆者に解凍してもらう
- 全ての質問が終わったら、次に提案を確認（こんな図を追加した方が良い。こんな対策はどうだろうか。）
- 会議の最後に、障害で素敵だった人を称える
- 会議終了後、当事者がコメントをベースに編集
tatsuya
ポストモーテムとして必要不可欠な要素
- 具体的な事象や状況
- 発生原因
- 発生した影響
- 発覚と対応の経緯
読み手が主題を間違えないドキュメントにすること
-サマリー
- インパクト
では、インシデントについての有益なデータを定量的に数値で記載する。
数値データの透明性のために、オリジナルデータが格納されているソースへのリンクなどがあるとより良い。
組織でどのように対応するか決めておく
具体的なアクションの箇所でType（種類）、Owner（担当）、Bug（バグ）、importande（重要度）があると良い。
- 根本原因
- トリガー
- 解決策
が書かれていること。解決に至るまでに使われたソフトウェアなども記載しておくと良い。運用の中で作成した図やドキュメントがあればこのタイミングで有効活用する。
ポストモーテム文化を根付かせるための施策
- ポストモーテムに対する報酬
- ポストモーテムのオープンな共有
- ツールやテンプレートの活用
高品質なポストモーテムを執筆したエンジニアには報酬を与えながら、皆が積極的に取り組めるようにする。
リアルタイム性を大事に
全ての対応が終わった後では分からなかったことが分からなくなる。
後々、時系列での事象確認をすることができるため、些細なアクションでも残しておくと必ず役に立つ。
どの時点で判断が行われたかを知れるのは今後の運用を改善する上で非常に価値がある
tatsuya
ポストモーテム読書会
SREチームではオンボーディングでポストモーテム読書会を実施
全部や読めない（増える）ので「おすすめ」ポストモーテムをラベルで管理
- 学びが多いもの
- 現在の構成理解につながるもの
- 障害発生時の動きとして参考になるもの
tatsuya
ポストモーテムの項目紹介
インシデントの概要
どのような内容かを要約して書く
インシデントの原因
問題の根本原因を探るため、複数回深堀して書く
フォローアップアクション
チケット化して、確実に実行できるようにする
時刻
- 発生時刻
- 検知時刻
- 解決時刻
障害の概要・障害の影響
障害が発生したサービス・プロダクトの概要、お客様への影響などを記入
暫定対応
インシデントに対して、暫定的に行った内容を記入
最初防止策
どこのプロセスに問題があったのか、根本的な原因の概要や恒久対策を記入
振り返り
うまくやれていたこと・改善点などを振り返って記入
インシデント検知時間・解決時間を改善する方法
- 静的解析ツールを導入し、CI上で実行する
- モニタリング環境の整備・追加
- オートスケールの設定を行う・閾値を最適化する
- UI/Unit test/QAのケース追加
tatsuyaGPTの書いたブログ
SREのポストモーテムの活動 〜文化をゼロから作る挑戦〜
1. 導入（問題提起と読者ターゲットの明確化）
私たちは最近、SRE（Site Reliability Engineering）チームを立ち上げました。まだまだ試行錯誤の連続で、決まった仕組みや成熟した文化があるわけではありません。
その中で最も苦労したのが、「ポストモーテム文化」を根付かせることです。障害やインシデントを単なる“トラブル”で終わらせず、組織の学びに変える仕組みがなければ、同じような問題が繰り返されてしまうと気づきました。
本記事では、SREチーム立ち上げ初期に取り組んだ「ポストモーテム活動」について、私たちのリアルな試行錯誤と学びを共有します。
今まさにSRE文化を作っている方、あるいはこれから挑戦しようとしている方にとって、少しでも参考になれば嬉しいです。
2. 背景（なぜポストモーテムに取り組むのか）
私たちがポストモーテムに本気で取り組もうと考えたきっかけは、立て続けに発生した複数の障害でした。
インシデントが起きた後、復旧に集中するあまり、原因を深く掘り下げずに「とりあえず直ったからOK」としてしまっていたことが何度かありました。そしてある日、以前起きた障害と酷似したトラブルが、別のプロダクトでも発生してしまったのです。
その時、私たちはこう気づきました。
単に復旧するだけでは不十分。
原因を深掘りし、そこから学び、仕組みに落とし込むことが本当の意味での「復旧」ではないか？
こうして私たちは、SREとして以下のようなポストモーテム文化の重要性を痛感するようになりました。
ポストモーテムの目的
責任追及ではなく、学びと改善の機会とすること
再発防止策を講じて、システムの信頼性を高めること
組織全体でナレッジを共有すること
3. 実際にやったこと（ポストモーテムの実践内容）
フォーマットの導入
まずは形から、ということでポストモーテムのフォーマットを定めました。参考にしたのは、Google SRE本で紹介されているような構成です：
What Happened：何が起きたか（事実ベースの時系列）
Impact：ユーザーや社内への影響
Root Cause：根本原因の分析（単なる操作ミスではなく構造的な原因に着目）
Detection：どうやって障害に気づいたか
Response：どのように復旧したか
Lessons Learned：学び、気づき、文化的な示唆
Action Items：再発防止策（短期・中長期）
実施の様子
最初のポストモーテムは、正直ぎこちないものでした。
障害対応をした本人が「自分の責任だと思われるのでは…」と不安そうな様子で報告していたのを今でも覚えています。
ですが、私たちは一貫して「責任追及しない」姿勢を貫きました。
誰が悪いかではなく、「なぜそれが起きたのか？」
なぜそれを検知できなかったのか？
どうすれば次は検知できるようになるか？
このような原因の構造化と再発防止への建設的な議論を繰り返す中で、少しずつ安心して振り返りができる空気が生まれていきました。
改善された点・反省点
改善されたこと
過去のトラブルと同じ原因による障害が減った
オンボーディング時に「過去のポストモーテム」がナレッジとして役立つようになった
反省点
Action Itemがうやむやになりがちだった（→Issue化・リマインドの仕組みが必要）
軽微な障害では振り返りが省略されがち（→基準の明確化を検討中）
4. 文化づくりの工夫や課題
心理的安全性を高める工夫
あえて軽い雑談から始める
「責任追及しない」ことを明言する
障害発生時のSlackログなどを振り返って、対応の良かった点も共有する
巻き込みの工夫
中には「わざわざ書く必要あるの？」「大げさじゃない？」という声もありました。
そんなときは、成功事例を可視化するようにしました。
「この振り返りをやったおかげで、似た障害が防げた」という実例を共有することで、ポストモーテムの価値がチームに伝わりやすくなりました。
5. 今後の展望と一緒にやりたいこと
ポストモーテム文化は、まだ始まったばかりです。
今後は以下のようなことにも取り組みたいと考えています：
SLO（サービスレベル目標）と連携したインシデントレビュー
振り返りを定期化し、プロダクトを横断したナレッジ共有の場を作る
「障害対応ドリル」などを通じて学びをチームで実践する
まだまだ仕組みは発展途上。だからこそ、ゼロから一緒にSRE文化を作ってくれる仲間を探しています。