Postmortem Recovery Playbook：複盤之後如何把恢復動作固化下來

為什麼需要一份 postmortem recovery playbook

故障複盤（postmortem）結束後，團隊通常會產出一份原因分析和改進項目清單。但問題在於：清單貼在 Wiki 裡，幾個月後沒人記得。等到下一次事故發生時，還是手忙腳亂地翻聊天記錄、問同事「上次怎麼恢復的」。

Postmortem recovery playbook 就是把複盤裡可重複的恢復動作抽取出來，格式化為任何人（包括值班新人）都能照著執行的步驟手冊。它不取代根因分析，而是解決「恢復慢」的問題——Google 的 SRE 實踐表明，有 playbook 的服務，MTTR（平均恢復時間）能降低 50% 以上。

但很多人寫 playbook 時掉進一個坑：把複盤報告全文抄進去，沒有提取真正可執行的步驟。結果 playbook 變成另一份文檔，沒人讀，沒人用。

複盤輸入：哪些內容值得沉澱為恢復動作

不是所有複盤結論都能成為 playbook。只有滿足以下條件的動作才值得寫入：

可驗證：執行後能立即看到效果（例如重新啟動服務、切換流量、回溯版本）。
有確定性：多人在同樣條件下執行，結果一致。
有邊界：明確了觸發條件（例如「當 P99 延遲超過 500ms 持續 3 分鐘」）。

舉個例子：複盤發現“資料庫連線池耗盡導致請求排隊”，根因是程式碼中未關閉連線。這個根因本身就是修復任務，留給開發迭代。 但恢復動作可以是：「當連接池使用率 > 90% 持續 2 分鐘，自動擴容連接池上限到 200，同時觸發告警通知 DBA 介入。」這個動作就可以寫入 playbook。

常見失敗場景是團隊把「加強程式碼審查」「增加單元測試覆蓋率」這種長期改進項目也當成恢復動作。這些很重要，但不是 playbook 的內容——它們屬於改進 backlog。

筆記本上記錄的事故複盤要點和恢復動作列表，箭頭標註關鍵步驟與責任人。

恢復動作沉澱：如何從複盤報告轉換為步驟

提取恢復動作時，我推薦用「操作流程」方式來組織，而不是清單。比如：

筆記本上記錄的事故複盤要點和恢復動作列表，箭頭標註關鍵步驟與責任人。

步骤 1：确认影响范围
  - 登录 Grafana 查看全局错误率面板
  - 如果错误率 > 5%，转步骤 2；否则继续监控 10 分钟
步骤 2：执行回滚
  - 切换到上一次稳定版本标签（v2.3.1）
  - 确认部署后错误率下降至 < 1%
  - 如果回滚失败（如版本冲突），转步骤 3
步骤 3：切换流量到冷备集群
  - 修改 DNS 记录指向备用集群 IP
  - 等待 TTL 过期后验证可用性

重点在于：写清楚判断条件和备选路径。很多团队只写了“执行回滚”，但回滚本身可能失败，没有 fallback 计划就会卡住。

另一个容易失败的地方是：步骤中缺少“负责人”。比如“重启服务”这个动作，谁有权限操作？值班 SRE 还是开发工程师？在 playbook 里明确“由 on-call 工程师发起，需要安全审计授权”可以减少推诿。

告警与负责人：当 playbook 和监控联动

Playbook 不能孤立存在，它必须与告警体系绑定。做法是：在 playbook 头部标明触发此 playbook 的告警规则。例如：

告警名称：HighErrorRate
告警条件：服务错误率 > 2% 持续 5 分钟
负责人（Role）：On-Call SRE（主）, 后端服务负责人（备）
切换条件：On-Call SRE 10 分钟内未响应，自动升级给后端负责人

寫清楚負責人和升級條件，是為了避免「等待確認」導致的延遲。一個真實案例：某團隊 playbook 寫了“聯絡 DBA”，但未註明值班 DBA 是誰，結果等了 20 分鐘電話才打通。改進後，在 playbook 裡直接寫上“企業微信機器人 @DBA 值班組”，並且嵌入 5 分鐘未回復自動撥打電話的規則。

除了人，還要寫清楚工具入口。例如“執行回滾”這個動作，不能只寫“使用 CI/CD 平台”，而要具體到“登入 Jenkins（位址：xxx）選擇‘Rollback to Last Stable’參數化建置”。

下次演練：如何讓 playbook 不會變成殭屍文檔

Playbook 最大的敵人是不被使用。定期演練是唯一的解決方案。

演練的頻率取決於服務的重要性和變更頻率。我的建議是：

核心支付服務：每月演練一次
常規 API 服務：每季一次
內部工具：每半年一次

演練不一定是全流量壓測，可以是 tabletop 演練－團隊成員圍著一張 playbook，口頭走一遍步驟，發現遺漏或不明確的地方。

失敗場景：很多團隊演練只是“讀一遍”，沒有模擬異常條件。更有效的做法是：在演練中故意製造 playbook 裡沒寫到的故障點（例如警告通道本身斷開、回滾版本號寫錯），觀察實踐者是否知道如何繞過。

每次演練後，必須更新 playbook 版本號，並在團隊群組中公示改變。版本管理可以用 Git，每次提交記錄寫明「本次演練發現某步驟缺少判斷條件，已補充」。

常見迷思與邊界

**Playbook 越詳細越好？ ** 不是。超過 20 步驟的 playbook 在執行時容易失去注意力。建議控制在 10 步驟以內，必要時拆分為子 playbook（如「回滾子流程」、「擴容子流程」）。
**Playbook 一旦寫好就不改了？ ** 不可能。每次重大事故複盤後，以及每季演練後，必須修訂。
**Playbook 只適用大團隊？ ** 小團隊同樣需要。單人值班時，playbook 是防止遺忘的保單。

場景案例：一次支付逾時復原過程的 playbook 化

假設一次複盤結論：支付下單介面因 Redis 熱 key 導致快取雪崩，恢復動作是手動清除熱 key 並限流。

擷取後的 playbook 片段：

告警条件：支付下单接口 P99 延迟 > 3s
步骤：
1. 登录 Redis-cli，执行 `MEMORY USAGE payment:hot_order` 确认热 key 内存占用
2. 如果占用 > 100 MB，执行 `DEL payment:hot_order` 清除缓存（注意：会短暂增加 DB 压力）
3. 同步在网关层对 /payment/order 接口限流 50%（跳转 Nginx 限流配置页）
4. 观察 2 分钟，如果 P99 恢复 < 1s，结束；否则转步骤 5（回滚版本）
责任人：On-Call SRE

這個 playbook 避免了「先聯絡開發確認」的環節，值班人即可執行。