トリガー条件

プロセスフロー

Day 0: インシデント発生
  └── ICがインシデントチャンネルでタイムラインを記録

Day 0-1: インシデント解決
  └── Scribeがタイムラインを整理

Day 1-3: ポストモーテムドラフト作成
  └── ICまたは指名されたメンバーがドラフトを作成
  └── 関係者にレビュー依頼

Day 3-5: ポストモーテムレビュー会議
  └── 50分の会議でドラフトをレビュー
  └── アクションアイテムの担当・期限を決定

Day 5-7: ポストモーテム確定・共有
  └── SREリードが承認
  └── 全エンジニアに共有
  └── アクションアイテムを課題管理ツールに登録

Day 7以降: アクションアイテム追跡
  └── 週次レビューで進捗確認

保管と共有

ポストモーテム: ECサイト決済障害

基本情報

• 日時: 2025-11-15 17
  - 18
  (JST)
• 影響時間: 75分
• 影響範囲: ECサイト全ユーザーの決済機能
• 重大度: SEV1
• IC: SREリード（18
  ）/ 鈴木（初動）
• ポストモーテム作成者: 鈴木

サマリー

決済マイクロサービスv3.2.0のデプロイ時に、環境固有のDB接続設定が誤ってステージング環境の値に上書きされ、全ユーザーが75分間決済不能となった。ロールバック手順にDB接続設定の復元が含まれておらず、復旧が遅延した。

影響

• ユーザー影響: 推定3,000人が決済不能
• ビジネス影響: 推定500万円の売上損失
• エラーバジェット消費: 月間バジェットの25%（Orange状態に移行）

タイムライン

根本原因

直接原因: デプロイパイプラインが環境固有の設定（DB接続文字列）をアプリケーションコードと一緒に上書きした。

根本原因（5 Whys）:

1. なぜDB設定が上書きされたか → 環境設定がアプリケーションコードと同じリポジトリに含まれていた
2. なぜ同じリポジトリに含まれていたか → 初期構築時に分離されておらず、技術負債として残っていた
3. なぜデプロイ前に検知できなかったか → デプロイパイプラインに環境設定の差分チェックがなかった
4. なぜロールバックで復旧できなかったか → ロールバック手順にDB接続設定の復元ステップがなかった
5. なぜ手順が不完全だったか → ランブックが環境設定を考慮して作成されていなかった

対応の評価

うまくいったこと:

• アラートが5分以内に発報された
• Primary on-callが5分以内に応答した
• 原因の推定が比較的速かった（10分）

うまくいかなかったこと:

• ロールバック手順にDB設定の復元が含まれていなかった（+25分の遅延）
• 環境設定の問題を切り分けるのに時間がかかった

幸運だったこと:

• 金曜夕方だったため、ピークタイムよりユーザー数が少なかった
• データの損失・破損は発生しなかった

アクションアイテム

学びと教訓

環境設定とアプリケーションコードの分離は基本的なベストプラクティスだが、初期構築時の技術負債が残っていた。「動いているから大丈夫」という判断が、いずれ大きなインシデントにつながる教訓。ロールバック手順も「アプリケーションのロールバック」だけでなく「環境全体の状態のロールバック」として設計する必要がある。

エグゼクティブダッシュボード

SREオペレーションダッシュボード

ROIレポート（半期）