# Postmortem Template — Parky ポストモーテム (RCA / Root Cause Analysis) の標準テンプレート。 SEV1/SEV2 インシデント発生時に必ず作成する。配置場所: `docs/ops/postmortems/YYYY-MM-DD-.md` > 目的: 個人攻撃ではなく、システムとプロセスの改善。**Blameless Culture** で書く。 > 「Aさんがミスした」ではなく「`X 状況下で Y を防ぐ仕組みが無かった`」と表現する。 --- ## メタ情報 | 項目 | 値 | |---|---| | **タイトル** | <一言で何が起きたか> | | **発生日時 (JST)** | YYYY-MM-DD HH:MM:SS | | **検知日時 (JST)** | YYYY-MM-DD HH:MM:SS | | **解消日時 (JST)** | YYYY-MM-DD HH:MM:SS | | **継続時間** | NN 分 | | **Severity** | SEV1 / SEV2 / SEV3 | | **影響範囲** | `api.parky.co.jp` / `admin.parky.co.jp` / mobile app / etc | | **影響ユーザー数** | 推定 NN 人 / NN req / NN session | | **検知方法** | Sentry / CF Health Check / ユーザー報告 / その他 | | **作成者** | | | **レビュアー** | | | **作成日** | YYYY-MM-DD | --- ## 1. インシデント概要 (Summary) 100 文字程度で「何が起きたか」を要約。技術詳細は後段で。 例: `2026-04-28 10:32 〜 10:45 (13分間)、api.parky.co.jp の 5xx エラー率が 0.5% → 8.2% に急増。原因は新規 deploy された wrangler.toml の binding 設定漏れ。rollback で解消。` --- ## 2. 影響 (Impact) - **ユーザー影響**: 何ができなかったか / 誰に影響したか - **ビジネス影響**: 売上 / 機会損失 / SLA 違反 / 信頼低下 - **データ影響**: 整合性 / 損失 / 漏洩 - **運用影響**: 対応に要した工数 / 後続作業への影響 定量化できるものは数値で。「不明」も明記する。 --- ## 3. タイムライン (Timeline) 時系列で実際に起きたこと + 対応を記述。**JST 時刻 + 出来事 / アクション**。 | 時刻 (JST) | イベント | |---|---| | 10:32:00 | wrangler deploy 完了 (commit abc1234) | | 10:32:15 | Workers 5xx alert が #parky-alerts に発火 | | 10:32:45 | がチャネルで応答、調査開始 | | 10:35:00 | Sentry で `STATE_HMAC_SECRET undefined` が原因と特定 | | 10:38:00 | wrangler rollback 開始 | | 10:42:00 | rollback 完了、5xx エラー率が 0.5% に復帰 | | 10:45:00 | インシデント終息確認、ステークホルダー通知 | ### 検知遅延 / 対応遅延の分析 - 検知から認知まで何分? なぜ? - 認知から対応開始まで何分? なぜ? - 対応開始から解消まで何分? なぜ? --- ## 4. 根本原因 (Root Cause) 「なぜ?」を 5 回繰り返して掘る (5 Whys)。 例: 1. **Why?** Workers が起動時に throw した 2. **Why?** `STATE_HMAC_SECRET` が undefined だった 3. **Why?** wrangler.toml の `[env.prod] vars` セクションに登録されていなかった 4. **Why?** secret は CI で `wrangler secret put` 経由で投入する設計だが、新マシンで rotate 後に prod 環境への投入がスキップされた 5. **Why?** secret rotation のチェックリストに環境別投入の項目が無かった ### 直接原因 (Trigger) 何が引き金になったか (具体的な操作 / イベント)。 ### 寄与要因 (Contributing factors) 直接原因ではないが、被害を拡大した / 検知を遅らせた要素。 例: - prod 環境ガード (GitHub Environment 承認) が未設定だったため誤 deploy がそのまま流れた - Sentry alert の SLA が 5 分間隔で集計されており、検知が遅延した - on-call rotation が無く、たまたま気付いた人が対応した --- ## 5. 解消方法 (What fixed it) 実際に効いた対応。試したけど効かなかったものも記録 (次回の参考)。 - ✅ 効いた: `wrangler rollback --env prod` で前 commit へ戻す - ❌ 試したが効かず: `wrangler secret put STATE_HMAC_SECRET --env prod` (新 deploy の方が古い deploy を上書きしないため) --- ## 6. 良かった点 (What went well) 恥ずかしがらずに書く。再発防止 / 文化醸成のため。 - Sentry alert が 15 秒で発火し、認知まで遅延がなかった - runbook の `wrangler tail` コマンドが即座に役立った - rollback 手順が docs に明記されていたため迷わなかった --- ## 7. 改善できた点 (What didn't go well) - prod 環境ガードが無く、push が即 deploy された - Sentry の Issue grouping が雑で 5xx の根本原因特定に時間を要した - on-call が居らず、たまたま気付いた人 (担当外) が対応した --- ## 8. アクションアイテム (Action items) **SMART** (Specific / Measurable / Assignable / Relevant / Time-bound) に書く。 「気をつける」「徹底する」は禁止フレーズ — 仕組みに落とす。 | ID | アクション | 担当 | 期限 | Issue / PR | |---|---|---|---|---| | AI-1 | `STATE_HMAC_SECRET` を `assertRequiredSecrets()` で起動時 assert | hf | 2026-04-30 | #N | | AI-2 | secret rotation チェックリストに「環境別投入確認」項目追加 | hf | 2026-04-29 | docs PR | | AI-3 | GitHub Environment `production` に required reviewer 設定 | hf | 2026-04-29 | UI 操作 | | AI-4 | wrangler.toml の var 不足を CI で事前検出する `assertWranglerVars()` チェック追加 | hf | 2026-05-05 | #N | | AI-5 | on-call rotation の運用開始 (週次担当指定) | hf | 2026-05-15 | docs PR | 各 AI には **Owner / 期限 / 検証方法** を必ず付ける。 --- ## 9. 教訓 / 文化的発見 (Lessons learned) 技術以外の学び。組織 / プロセス / コミュニケーション。 - secret rotation のような「滅多にやらない手順」は checklist 化が必須 - 1-dev shop でも environment guard は欠かせない - monitoring の alert 文言は対応者が次に何をすべきか書く方が良い --- ## 10. 関連リンク - 対象 commit: - Sentry issue: - Slack スレッド: - 影響を受けた endpoint の docs: - 関連 ticket: --- ## レビュー署名 - Author: - Reviewer: - Approved: --- > **このテンプレートの維持**: フィールドの過不足はレビュアーが指摘して都度更新する。 > ポストモーテムは inert artifact ではなく、改善の起点。AI が closed されるまでオーナーが追跡。