はじめに
GMOメディアのSREチームに所属している安保です。
本記事では、私たちSREチームがポストモーテム（振り返り）の取り組みを導入した経緯と、実際にやってみて得られた学びを共有します。ポストモーテムは障害から学びを得て、組織全体の信頼性向上につなげるための重要な実践です。
この記事は、ポストモーテムをこれから導入しようとしている方や、すでに実施しているが改善したい方の参考になればと思います。また、SREチーム自身の振り返りとしても活用し、フィードバックを基に継続的に改善していく予定です。
ポストモーテムとは
ポストモーテム（Postmortem）は、システム障害やインシデント発生後に行う振り返りのことです。Google SRE Bookでは以下のように定義されています。
ポストモーテムとは、インシデント、その影響、軽減または解決のために取られた対策、根本原因、そしてインシデントの再発を防ぐためのフォローアップ対策を記録した文書です。
※AIで翻訳しました
重要なのは、個人を責めるのではなく、システムやプロセスの問題を追求することです。「誰が悪かったのか」ではなく、「なぜそれが起きたのか」「どうすれば防げたのか」を議論します。
なぜポストモーテムを始めたのか
GMOメディアのSREチームでは、以下の課題を感じていました。
- 障害対応後、根本原因の分析が不十分なまま終わってしまうことがある
- 一時対応で収まっているが、恒久対応が実施されないケースがある
- 同様の障害が再発してしまう
- 障害から得られた学びが組織全体に共有されない
これらの課題を解決し、組織全体のサイト信頼性を向上させるため、Google SRE BookのExample Postmortemを参考にしながらポストモーテムの導入を決めました。
ポストモーテムテンプレートの作成
まず、既存の障害管理システムの障害票をベースに、より詳細な分析ができるテンプレートを作成しました。
従来の障害票の課題
既存の障害票には以下のような項目がありました。
- 障害期間、影響範囲
- 経過履歴
- 原因
- 解決策
- 今後の対策
一見問題なさそうですが、実際に運用してみると以下の課題がありました。
- 根本原因の分析が浅い: 「OutOfMemoryが発生した」という表面的な原因で終わり、「なぜOutOfMemoryが発生したのか」まで掘り下げられていない
- タイムラインが不明確: 誰がいつ何をしたのかが曖昧
- 学びが記録されない: うまくいったこと、幸運だったことが記録されず、次に活かせない
- アクションプランが不明確: 「検討中」で終わっているものが多く、具体的な担当者や期限が決まっていない
新しいポストモーテムテンプレートの構成
Google SRE Bookや他社の事例を参考に、以下のようなテンプレートを作成しました。
- 要約: 1〜2行で障害の概要を記述
- 影響: ユーザー影響、収益影響、問い合わせ件数など定量的に記載
- 根本原因: 「なぜなぜ分析」を通じて特定した真の原因
- 引き金となったこと: 何が障害の直接的なトリガーとなったか
- 障害が解決された方法: どのように復旧したか
- 障害が検知された方法: 機械的な検知か、人間による検知か
- 恒久対応: 予防・運用・緩和の分類で具体的なアクション項目
-
学び:
- うまくいったこと
- うまくいかなかったこと
- 幸運だったこと（再現性なし）
- タイムライン: 時系列で詳細に記録
- 分析: なぜなぜ分析のプロセス
恒久対応の分類
恒久対応は以下のように分類することで、どの段階で対策を打つべきかを明確にしました。
- 予防（Prevent）: 障害の発生自体を防ぐ
- 運用（Process）: 運用方法の変更する
- 緩和（Mitigate）: 障害発生時の影響を小さくする
それぞれに担当者とチケットを紐付けることで、対応の追跡が可能になります。
実際にやってみた
テンプレート作成後、以下の3段階で実施しました。
第1段階: SREチーム内での試行
まずはSREチーム内で過去の障害を取り上げ、新しいテンプレートに沿ってポストモーテムを実施しました。
障害: アプリケーションサーバーの不安定（OutOfMemory）
この議論を通じて以下の気づきがありました。
- 根本原因が「OutOfMemory」だけでは不十分。なぜOutOfMemoryが発生したのかまで掘り下げる必要がある
- タイムラインを詳細に書くことで、後から見返したときに何が起きたのかが明確になる
- Slack Huddleの内容もタイムラインに含めることで、口頭でのやり取りも記録できる
- アクションプランを「誰が」「何を」「いつまでに」という形で明確にすることが重要
第2段階: SREチーム内でのテンプレート改善
テンプレートの内容や運用方法について議論を重ねました。
- ポストモーテムの粒度はどうするか（すべての障害を対象にするか、重大なもののみか）
- どのタイミングで議論するか（週次で定例化するか、障害発生時に都度行うか）
- フィードバックの収集方法
また、組織全体への啓蒙方法についても検討しました。
- まず小さく始める（特定のチームから試験的に実施）
- エレベーターピッチを作成し、「なぜポストモーテムをやるべきか」を簡潔に説明できるようにする
- 実施したポストモーテムのサマリーを共有する
第3段階: 開発チームとの合同実施
SREチーム内での試行を経て、実際の障害を題材に開発チームと合同でポストモーテムを実施しました。
※サービス名など一部表現を実際の記録から変えています
対象障害: 新機能リリースによるDB負荷増加
実施内容
- 参加者: SREチームから3名（安保がファシリテーター担当）、開発チームから3名
- 時間: 2時間（1回目は説明と分析で1時間、2回目は対策と学びで1時間）
- 形式: オンライン
障害の概要
新機能をリリース後、ある処理によりDB負荷が増加。サービス全体のレスポンスタイムが悪化しました。
なぜなぜ分析のプロセス
Q: なぜDB負荷が増加したのか？
A: 重いクエリがあると認知していたが、新規リリースを行ったため
Q: なぜクエリが重かったのか？
A: 古いデータが削除されておらず、参照レコード数が想定より多かった
Q: なぜ削除されていなかったのか？
A: インフラ構成変更に伴い、不要なデータが削除できず残ってしまった
Q: なぜ重いクエリを認識していながらリリースしたのか？
A:
- プロジェクトが遅延しており、スケジュール的な制約があった
- ビジネス側からの強い要望があった
- クエリ最適化のための実装時間が不足していた
Q: なぜインフラ構成変更時に不要なデータまで残してしまったのか？
A:
- データを識別・分類することが困難だった
- 重要なユーザーデータを含むため、安全を優先してすべてのデータを残した
- 限られたメンテナンス時間内で作業を完了させる必要があった
根本原因
議論の結果、以下の2つが根本原因として特定されました。
- 技術的な原因: インフラ構成変更時に不要なデータが削除されず、データ削除処理も追いついていなかった
- プロジェクト管理の原因: リスクを認識した上で、影響範囲の計算とカナリアリリースで対処可能と判断してリリースした。結果として事前の見積もりが不十分だった
学び
うまくいったこと:
- カナリアリリースで影響範囲を絞れた
- 24/365で監視していたため早期に気づけた
うまくいかなかったこと:
- リリースによるリソース使用量の計算が厳密にできず、ディレクターに対してサービス継続可能か判断できる説明ができなかった
- 影響範囲を事前に計算してディレクターと仕様について議論すべきだった
幸運だったこと:
- チームメンバーが常に監視していたので早めに気づけた
恒久対応
| 対応内容 | 分類 | 担当者 |
|---|---|---|
| 影響範囲を事前に計算してディレクターと仕様について議論する | 運用 | 開発 |
| 不要なデータを削除する | 予防 | 開発・インフラ |
| リソース使用量の計算式を体系的にまとめてチーム内で共有する | 運用 | 開発 |
実施して得られたフィードバック
開発チームとの合同実施後、以下のようなフィードバックをもらいました。
学びや気づき
- リソース使用量の計算式をもっと学ぶべき: 技術的な見積もりの精度を上げることの重要性を再認識
- ディレクターも一緒にやってもいい: 技術的な制約を理解してもらうためにも有効
- 障害の重要度とのバランス: 今回はチュートリアルとしては良かったが、もっと重大な障害を題材にすべきだった
改善点やアイデア
- 対象者を明確にする: エンジニアだけでなく、デザイナーやディレクターも含めるか決めるべき
- 対面でやった方が良い: 意見が出しやすく、会話のリズムが良い
- 時間配分: 障害の重要度に応じて時間を調整する（今回は2時間だったが長すぎた）
- スコープを明確にする: 技術的な側面に焦点を当てるのか、ディレクションを含めた事業全体の課題に焦点を当てるのか
今後の展開
短期的な取り組み
- フィードバックを基にテンプレートとプロセスを改善
- 重大障害発生時にポストモーテムを実施し、実績を積む
- 実施したポストモーテムのサマリーを社内で共有
中長期的な取り組み
- ポストモーテム文化の啓蒙
- エレベーターピッチを活用した説明
- 成功事例の共有
- 組織全体への展開
- AIの活用
- Amazon Bedrockなどを使った障害票からのポストモーテム自動生成
- タイムライン作成の自動化
- インシデントコマンダー制度の導入
- 障害対応の役割を明確化
- 全員がインシデントコマンダーになれる体制づくり
参考にした資料
- Google SRE Book - Example Postmortem
- Google SRE Book - Postmortem Culture
- 現場で使える！SRE・エンジニアのためのポストモーテム実践ガイド
- リリース品質を高めるポストモーテムとは
- ポストモーテムを導入して不具合に向き合う組織を作る
おわりに
ポストモーテムは単なる障害の振り返りではなく、組織が学習し続けるための仕組みです。
重要なのは以下の3点です。
- 個人を責めない: システムやプロセスの問題にフォーカスする
- 根本原因まで掘り下げる: 「なぜなぜ分析」で真の原因を特定する
- 学びを共有する: うまくいったこと、うまくいかなかったこと、幸運だったことを記録し、組織全体で共有する
GMOメディアSREチームのポストモーテムの取り組みはまだ始まったばかりです。今後もフィードバックを基に改善を続け、組織全体のサイト信頼性向上につなげていきます。
この記事が、ポストモーテムの導入を検討している方の参考になれば幸いです。また、すでに実施している方からのフィードバックもお待ちしています！
Discussion