應急響應

Vibe Prompt

「幫我設計一個 Incident Response Playbook：偵測 → 分級 → 回應 → 修復 → 覆盤。」

Incident 分級

| 等級 | 說明 | 回應時間 | 範例 | |------|------|---------|------| | P0 | 核心服務中斷 | 5 分鐘 | 資料庫掛了 | | P1 | 主要功能受損 | 15 分鐘 | API 變慢 | | P2 | 部分功能異常 | 1 小時 | 非核心 bug | | P3 | 輕微問題 | 24 小時 | UI 小問題 |

回應流程

1. 偵測（Monitoring Alert / 用戶回報）
2. 分類（確定 severity）
3. 回應（建立 war room）
4. 診斷（查看 logs, metrics, traces）
5. 緩解（止血：rollback / feature flag / scale up）
6. 修復（根本原因修復）
7. 覆盤（撰寫 Postmortem）

Postmortem 範本

# 事後覆盤報告

## 日期：2026-07-01
## 影響：API 不可用 23 分鐘
## 根因：資料庫連線池耗盡

## 時間線
- 14:00 — 部署新版本
- 14:05 — PagerDuty 告警
- 14:07 — 工程師上線
- 14:15 — 發現 DB 連線池滿
- 14:20 — 重啟 DB 連線池 + 擴容
- 14:23 — 恢復正常
- 14:30 — 開始覆盤

## 行動項目
- [ ] 設定連線池上限監控
- [ ] 部署前自動測試連線數
- [ ] 加入準備好的 rollback 腳本
- [ ] 本週五前完成

關鍵要點

✅ 事故響應的四階段：偵測 → 回應 → 緩解 → 復原
✅ SEV 分級：SEV1（核心服務中斷）、SEV2（部分功能受損）、SEV3（輕微問題）
✅ 事後覆盤 (Postmortem) 的目標是「學到教訓」，不是「追究責任」
✅ 覆盤報告應包含：時間線、根本原因、影響範圍、改進措施
✅ 建立 Runbook（操作手冊）讓新手也能按步驟處理常見事故

事故分級與回應時間

| 等級 | 定義 | 回應時間 | 處理目標 | |:----:|------|:--------:|---------| | SEV1 | 核心服務完全中斷 | 15 分鐘 | 立即恢復 | | SEV2 | 部分功能受損或效能下降 | 30 分鐘 | 4 小時內解決 | | SEV3 | 輕微問題，不影響用戶 | 24 小時 | 下個 Sprint | | SEV4 | 非緊急改進事項 | 無 SLA | 列入 backlog |

覆盤範本

## 事故標題: [簡短描述]
- 日期: YYYY-MM-DD
- 持續時間: XX 分鐘
- SEV 等級: SEV1/SEV2
- 影響範圍: X% 用戶受影響

## 時間線
- HH:MM - 問題發生（告警觸發）
- HH:MM - On-Call 工程師接手
- HH:MM - 初步緩解措施
- HH:MM - 問題修復
- HH:MM - 驗證恢復

## 根本原因
[詳細說明]

## 改進措施
- [ ] 加入新的監控告警
- [ ] 自動化修復腳本
- [ ] 更新 Runbook

事件管理的完整流程拆解

Incident Response 不是單一行動，而是一個從偵測到覆盤的完整循環。以下是 Google SRE 定義的標準流程：

事件生命週期

偵測階段
  ├─ 監控告警（Prometheus Alert → PagerDuty）
  ├─ 用戶回報（客服轉發）
  └─ 自動化偵測（Synthetic Monitoring）

回應階段
  ├─ On-Call 工程師接手（確認告警、評估 severity）
  ├─ 建立通訊頻道（Slack channel、會議室）
  └─ 宣告事件（通知相關團隊）

緩解階段
  ├─ 止血（Rollback、Feature Flag Off、流量遷移）
  ├─ 不一定需要找到 root cause
  └─ 目標是「讓用戶恢復正常」

修復階段
  ├─ 找出根因（Root Cause Analysis）
  ├─ 開發正式修復
  └─ 部署修復版本

覆盤階段
  ├─ 撰寫 Postmortem
  ├─ 追蹤行動項目
  └─ 更新 Runbook

事件分級的實際案例

| 等級 | 實際案例 | 影響 | 回應行動 | |:----:|:--------|:----|:--------| | SEV-1 | 資料庫 master 掛了 | 所有用戶無法使用 | 立即切換到 replica，page 全部工程師 | | SEV-2 | API p95 延遲從 200ms 變成 2s | 用戶體驗變差 | On-Call 工程師 30 分鐘內上線 | | SEV-3 | 管理後台出現排版錯誤 | 內部工具問題 | 下個工作日處理 |

什麼是 Runbook？

Runbook（操作手冊）是預先寫好的故障處理腳本。例如：「如果資料庫連線數滿了，第一步做什麼、第二步做什麼」。好的 Runbook 讓沒有經驗的工程師也能依步驟處理事件。

不責備文化的實踐方式

Postmortem 的重點不是「誰的錯」，而是「系統的哪些設計讓這個錯誤可能發生」。這句話說來簡單，做起來難。具體的做法：

在覆盤報告中不寫人名——用「值班工程師」取代「John」
提問方式從「誰做了什麼」改成「為什麼當時覺得這是合理的決定」
每個行動項目的 owner 是自己選擇的，不是被指派的
管理階層不參與覆盤會議（避免權力不對等）

為什麼要學事件管理？

當服務出問題時，混亂是最大的敵人。沒有標準流程的團隊會：同時多人嘗試修復、沒有人對外溝通、修復後沒有記錄學到什麼。Incident Response 就是把混亂變成有序的 SOP。

名詞解釋

| 名詞 | 解釋 | |:----|:----| | On-Call | 輪流值班，這段時間負責處理告警 | | SEV (Severity) | 事件的嚴重等級 | | Runbook | 預先寫好的故障處理步驟 | | Postmortem | 事後覆盤報告 | | Rollback | 回到上一個正常的版本 | | Feature Flag | 功能開關，可以即時關閉有問題的功能 |

下一章預告：容量規劃

事件管理是「出了問題怎麼救」。下一章的容量規劃是「如何預防問題發生」——透過預測未來的流量成長，提前擴充基礎設施，讓問題根本不會發生。