Runbook 是凌晨三點的你最好的朋友
一句話總結：Runbook 是一份讓任何工程師都能在壓力下正確處理事故的逐步操作指引。
結論先講：凌晨三點被叫醒的時候，你的腦子只有平常的 30% 運轉能力。Runbook 就是那個替你在清醒的時候先想好所有步驟的東西。
為什麼需要 Runbook？
你有沒有這種經驗：半夜被 PagerDuty 叫醒，腦子還沒清醒，面對一個從沒見過的告警，手忙腳亂地 Google、問同事、翻聊天紀錄。花了兩個小時才搞清楚發生什麼事，然後發現修復步驟其實很簡單。
Runbook 解決的就是這個問題。它的價值是：
- 降低 MTTR：不用從頭排查，按已知步驟修復
- 消除人員依賴：最懂系統的那個人休假也不怕
- 減少人為錯誤：壓力下不用做決策，按步驟走
- 知識傳承：老鳥的實戰經驗變成所有人都能用的資產
一份好的 Runbook 長什麼樣？
結構要清楚，讓半夢半醒的工程師也能照做：
1. 基本資訊：嚴重等級、影響服務、最後更新日期、維護者
2. 症狀描述：什麼告警會觸發這份 Runbook？使用者會回報什麼現象？Dashboard 上會看到什麼異常？
3. 診斷步驟：按順序做，每一步都有具體的指令可以複製貼上。不要寫「檢查服務狀態」，要寫具體的 kubectl get pods -n production -l app=xxx。
4. 解決步驟：根據診斷結果分情境處理。情境 A 是重啟、情境 B 是擴展、情境 C 是回滾——每個情境都有完整的指令。
5. 驗證步驟：修完之後怎麼確認真的好了？health check 通過、錯誤率回到正常、告警自動解除、抽查使用者功能正常。
6. 升級條件：30 分鐘搞不定就通知 Team Lead，1 小時搞不定就找 Engineering Manager，涉及資料遺失就直接找 CTO 加法務。
四個最常見的場景
每個團隊都應該預先準備好這四份 Runbook：
場景一：服務掛了（Service Down）
症狀：健康檢查失敗、5xx 錯誤率飆升、使用者回報連不上。
診斷方向：
- Pod 是 OOMKilled 還是 CrashLoopBackOff？
- 最近有沒有部署變更？
- 上游依賴（DB、Redis、第三方 API）正不正常？
- 應用程式 log 裡有什麼 error/fatal？
修復：重啟 → 不行就回滾 → 還不行就擴展 Pod 數量。
場景二：磁碟滿了（Disk Full）
症狀：磁碟使用率 > 90% 告警、I/O 錯誤、資料庫無法寫入。
這個問題的根因幾乎都是日誌沒有做 logrotate。du -sh /var/log/* 一查就知道誰佔了最多空間。
修復：清理過期日誌 → 修 logrotate 設定 → 擴展磁碟容量。
場景三：資料庫連線耗盡（Connection Exhausted）
症狀：「too many connections」錯誤、新請求被拒、連線池等待超時。
用 SELECT count(*) FROM pg_stat_activity; 看當前連線數，再用 SELECT * FROM pg_stat_activity WHERE state = 'idle in transaction'; 找有沒有佔著茅坑不拉屎的連線。
修復：終止 idle 連線 → 調整連線池設定 → 抓慢查詢 → 加大最大連線數。
場景四：SSL 憑證過期
症狀：瀏覽器安全警告、HTTPS 連線失敗。
用 openssl s_client -connect example.com:443 檢查憑證有效期。如果用 Let’s Encrypt 或 cert-manager 的自動續約，查一下為什麼沒有自動續。
修復：手動更新憑證 → 修復自動續約 → 設定到期前 30 天的提醒告警（下次不要再被嚇到了）。
Runbook 最大的敵人：過時
Runbook 最常見的死法不是寫得不好，是沒有人維護。服務遷移了，hostname 換了，工具替換了，Runbook 還是舊的。半夜打開一看，第一條指令就跑不動。
怎麼防止？
- 每個 Runbook 指定一個維護者
- 每次事故處理後，如果 Runbook 有錯就當場更新
- 季度審查：標記最後驗證日期，超過三個月沒驗證的標為「需要審查」
- 更好的做法：把 Runbook 的驗證當成 DR Drill 的一部分
告警疲勞：狼來了效應
另一個相關的問題是告警太多。告警太多、太頻繁、太多誤報，工程師開始無視告警。然後真正的問題來了，沒人注意到。
解法：
- 定期審查告警規則，刪掉不適用的
- 區分「需要立即處理」跟「僅供觀察」，用不同通知管道
- 追蹤告警的信噪比，目標是可行動的告警 > 80%
- 一個告警連續一個月都不需要處理？考慮降級或刪掉
這篇的重點回顧
Runbook 是讓任何人都能在壓力下處理事故的操作手冊。結構化、步驟具體、指令可複製貼上。最大的敵人是過時，所以維護跟撰寫一樣重要。
下一篇聊 Post-mortem——怎麼從每次事故裡學到東西、讓同樣的錯不犯第二次。
系列文章：
- 事故管理（一）：事故生命週期與分級
- 你在這裡 → 事故管理（二）：Runbook
- 事故管理（三）：Post-mortem 與災難復原演練
延伸閱讀：
「好的 Runbook 不是寫給專家看的，是寫給凌晨三點腦子只剩三成運轉能力的你看的。」