SREにおけるポストモーテムとは
近年、システムの複雑化と規模拡大に伴い、システム障害やインシデントの発生リスクが高まっています。こうした問題を未然に防ぎ、システムの信頼性を向上させるために、SRE（Site Reliability Engineering）では、ポストモーテムと呼ばれる取り組みが重要視されています。ポストモーテムとは、システム障害やインシデントが発生した後に、その原因を徹底的に調査し、再発防止策を立案することで、システムの信頼性を向上させるための活動です。失敗を非難するのではなく、失敗から学び、組織全体の学習と成長を促進することを目的としています。
リリース管理でポストモーテムを行う理由
ポストモーテムは、サービスインパクトのあったシステム障害について実施することが一般的です。私たちはこれに加えて、リリース時に発生した問題についてもポストモーテムを行うことにしました。その理由は以下のとおりです。
1. 問題の特定と可視化
リリースに起因したシステム障害が僅かながら発生していたことから、その裏側にはシステム障害に至らない小さなヒヤリハットが潜んでいるのではないかという推測がありました。見過ごされていた問題点や潜在的なリスクを明確化することで、リリースプロセスの各段階で発生する可能性のある問題を事前に特定し、対策を講じることができます。
2. 継続的な改善
ポストモーテムの結果をもとに、継続的にプロセスや手順を見直し、改善策を実施することでリリース品質が向上します。また、リリース失敗を減らすことで、再リリースに伴うリリース担当者の負荷軽減と作業効率化を図ることができます。
3. 組織全体の学習
失敗から得た教訓を共有することで、失敗から学ぶ文化を醸成し、組織全体の学習と成長を促進します。これにより、同じミスの繰り返しを防ぎ、組織全体の知識とスキルを向上させることができます。
どのようにリリース管理のポストモーテムを実施しているか
具体的には、リリース時に発生した問題を「一部未完了」「切り戻し」「障害発生」に分類し、「一部未完了」「切り戻し」についてポストモーテムを実施しています。
一部未完了: 予定していたリリースの一部が未完了。切り戻し: リリースを中断して切り戻した。障害発生: リリースでシステム障害が発生した。障害管理で対策する
参加者の負荷という点でポストモーテムの範囲や規模は悩ましい点ではありますが、サービスインパクトは無い前提のため、障害管理と比較してコンパクトな体制としています。リリースを担当したチーム、SREチーム、有識者で「なぜなぜ分析」を行い、真因分析と再発防止策を検討します。ポストモーテムの結果については運用定例会議で報告を行い、対策妥当性についてチェックを受けます。報告書は社内ポータルに保管していつでも参照できる形にしています。
リリースポストモーテムの一例（架空の事例です）
まとめ
リリース管理にポストモーテムを導入することで、これまで顕在化していなかった以下のような問題点を可視化することができました。
構築時期が古い一部のサービスにおけるドキュメントや構成管理の不備本番環境と検証環境に差異が生じているケース リソース配分やスケジュール管理に問題のあるリリース計画
問題の解消には中長期的な対策が必要な事が多く、現時点ではリリース問題発生率の減少には至っていません。今後もポストモーテムを継続することで、持続的な改善プロセスを根付かせ、リリース品質の向上を目指していきます。
