# 故障排查與應急響應導論

::: tip 前言
**凌晨三點，手機瘋狂震動，線上服務全面癱瘓——你該怎麼辦？** 對於任何網際網路團隊來說，故障不是「會不會發生」的問題，而是「什麼時候發生」的問題。優秀的團隊不是不出故障，而是出了故障能快速響應、高效恢復，並從中學習避免重蹈覆轍。
:::

**這篇文章會帶你學什麼？**

學完這章後，你將獲得：

- **分級意識**：掌握 P0~P4 事故嚴重程度分級標準
- **響應流程**：理解從發現到恢復的完整事故響應時間線
- **組織協作**：了解事故指揮體系中的角色分工和協作機制
- **告警體系**：掌握告警升級策略，確保關鍵問題不被遺漏
- **複盤方法**：學會用「五個為什麼」挖掘根因，寫出有價值的複盤報告

| 章節 | 內容 | 核心概念 |
|-----|------|---------|
| **第 1 章** | 嚴重程度分級 | P0~P4、影響範圍評估 |
| **第 2 章** | 響應時間線 | 發現→響應→恢復→複盤 |
| **第 3 章** | 指揮體系 | IC、通訊官、技術負責人 |
| **第 4 章** | 告警升級 | 分級告警、逐級升級 |
| **第 5 章** | 事後複盤 | 五個為什麼、無責文化 |

---

## 0. 全景圖：故障是最好的老師

Netflix 有一個著名的工具叫 Chaos Monkey——它會隨機殺掉正式環境的伺服器。聽起來瘋狂，但背後的邏輯很清晰：**與其等故障找上門，不如主動製造故障來鍛鍊團隊的應急能力**。

應急響應不是靠臨場發揮，而是靠**流程、角色、工具**三位一體的體系化建設。就像消防隊不是火災發生時才組建的——他們平時就在訓練、演練、維護裝備。

::: tip 應急響應的四個核心要素
- **快速發現**：完善的監控和告警體系，確保問題在使用者感知之前被發現
- **高效協作**：清晰的角色分工和溝通機制，避免混亂中的重複勞動
- **快速恢復**：優先恢復服務，而不是優先找根因。先止血，再治病
- **持續改進**：每次故障都是學習機會，透過複盤不斷完善系統和流程
:::

---

## 1. 嚴重程度分級：不是所有故障都要「全員出動」

一個按鈕顏色顯示錯誤和整個支付系統癱瘓，顯然不是同一個級別的問題。**事故分級**的目的是讓團隊用合適的力度響應合適級別的問題——既不過度反應浪費資源，也不輕視問題導致損失擴大。

<SeverityLevelDemo />

| 級別 | 名稱 | 影響範圍 | 響應要求 | 範例 |
|------|------|---------|---------|------|
| P0 | 致命 | 核心業務完全不可用 | 立即響應，全員待命 | 支付系統癱瘓、資料外洩 |
| P1 | 嚴重 | 核心功能嚴重受損 | 15 分鐘內響應 | 登入失敗率 > 50%、API 大面積逾時 |
| P2 | 重要 | 部分功能異常 | 1 小時內響應 | 搜尋結果不準確、部分頁面 500 |
| P3 | 一般 | 非核心功能異常 | 工作時間處理 | 頭像載入失敗、非關鍵通知延遲 |
| P4 | 輕微 | 體驗問題 | 排入迭代計畫 | UI 錯位、文案錯誤 |

::: tip 分級的關鍵原則
- **影響使用者數**：影響 100% 使用者的 P2 可能比影響 1% 使用者的 P1 更緊急
- **業務損失**：直接影響收入的問題（支付、下單）優先級更高
- **可降級處理**：如果有臨時方案可以緩解影響，可以適當降級處理
- **動態調整**：隨著排查深入，級別可能上調或下調
:::

---

## 2. 響應時間線：從發現到複盤的完整流程

一次事故響應就像一場接力賽，每個階段都有明確的目標和交接點。清晰的時間線能讓團隊在混亂中保持有序。

<IncidentTimelineDemo />

::: tip 事故響應的五個階段
1. **偵測（Detection）**：透過監控告警、使用者回饋或內部巡檢發現異常。目標：儘早發現，縮短 MTTD（平均偵測時間）。
2. **響應（Response）**：確認事故、評估嚴重程度、召集響應團隊、建立溝通頻道。目標：快速組織起有效的響應力量。
3. **緩解（Mitigation）**：採取臨時措施恢復服務，如回滾部署、切換備用節點、限流降級。目標：先止血，恢復使用者體驗。
4. **修復（Resolution）**：找到根本原因並徹底修復。目標：消除隱患，防止復發。
5. **複盤（Postmortem）**：回顧整個過程，分析根因，制定改進措施。目標：從故障中學習，讓系統更健壯。
:::

| 指標 | 含義 | 最佳化方向 |
|------|------|---------|
| MTTD | 平均偵測時間 | 完善監控覆蓋、降低告警閾值 |
| MTTR | 平均恢復時間 | 自動化恢復、預案演練 |
| MTBF | 平均故障間隔 | 提升系統可靠性、消除單點故障 |

---

## 3. 指揮體系：的可見性範圍界定

大型事故中最怕的不是技術難題，而是**混亂**——十幾個人同時在排查，沒人知道別人在做什麼，關鍵資訊在各個群裡碎片化傳播。事故指揮體系（Incident Command System）就是為了解決這個問題。

<IncidentCommandDemo />

::: tip 三個核心角色
1. **事故指揮官（Incident Commander, IC）**：整個事故響應的總負責人。負責決策、協調資源、把控節奏。IC 不一定是技術最強的人，但必須是最冷靜、最有全域觀的人。
2. **通訊官（Communication Lead）**：負責對外溝通——更新狀態頁、通知客戶、同步管理層。讓 IC 和技術人員專注於解決問題，不被溝通事務打斷。
3. **技術負責人（Tech Lead）**：負責技術層面的排查和修復。組織技術人員分工協作，向 IC 彙報進展和方案。
:::

---

## 4. 告警升級：確保關鍵問題不被遺漏

告警系統是事故響應的「眼睛」。但告警太少會漏報，告警太多會導致「告警疲勞」——當每天收到幾百條告警時，真正重要的那條很容易被淹沒。**告警升級策略**就是解決這個問題的關鍵。

<AlertEscalationDemo />

::: tip 告警升級的三層機制
1. **一線響應（L1）**：告警觸發後，先通知值班工程師。如果 15 分鐘內未確認，自動升級。
2. **二線升級（L2）**：通知團隊負責人和相關領域專家。如果 30 分鐘內未緩解，繼續升級。
3. **三線升級（L3）**：通知技術總監和管理層，啟動全面應急響應。
:::

| 告警級別 | 通知方式 | 響應時限 | 升級條件 |
|---------|---------|---------|---------|
| Warning | IM 訊息 | 工作時間處理 | 持續 30 分鐘未恢復 |
| Critical | 電話 + IM | 15 分鐘內確認 | 未確認或未緩解 |
| Fatal | 電話轟炸 + 簡訊 | 5 分鐘內響應 | 自動升級至管理層 |

---

## 5. 事後複盤：從故障中學習

事故恢復後，最重要的一步是**複盤（Postmortem）**。複盤不是為了追責，而是為了找到系統性的改進機會。Google、Meta 等公司都奉行「無責複盤」文化——關注「系統為什麼允許這個錯誤發生」，而不是「誰犯了這個錯誤」。

<PostmortemDemo />

::: tip 「五個為什麼」分析法
從表面現象出發，連續追問「為什麼」，直到找到根本原因：
1. **為什麼服務掛了？** → 資料庫連線池耗盡
2. **為什麼連線池耗盡？** → 慢查詢佔用連線不釋放
3. **為什麼有慢查詢？** → 缺少索引，全表掃描
4. **為什麼缺少索引？** → 新表上線時沒有 DBA 審核
5. **為什麼沒有審核？** → 沒有強制的 SQL 審核流程

根因不是「某個人忘了加索引」，而是「缺少 SQL 審核流程」。修復根因才能防止復發。
:::

---

## 總結

故障排查與應急響應是每個技術團隊的必備能力。它不是靠英雄主義的個人發揮，而是靠體系化的流程、清晰的角色分工和持續的複盤改進。

回顧本章的關鍵要點：

1. **分級響應**：P0~P4 分級確保用合適的力度應對合適級別的問題
2. **時間線清晰**：偵測→響應→緩解→修復→複盤，每個階段目標明確
3. **指揮體系**：IC + 通訊官 + 技術負責人，分工協作避免混亂
4. **告警升級**：分級告警 + 自動升級，確保關鍵問題不被遺漏
5. **無責複盤**：用「五個為什麼」挖掘根因，關注系統改進而非個人追責

## 延伸閱讀

- [Google SRE Book - Incident Response](https://sre.google/sre-book/managing-incidents/) - Google 的事故管理實踐
- [PagerDuty Incident Response Guide](https://response.pagerduty.com/) - PagerDuty 開源的應急響應指南
- [Atlassian Incident Management](https://www.atlassian.com/incident-management) - Atlassian 的事故管理最佳實踐
- [Learning from Incidents](https://www.learningfromincidents.io/) - 從事故中學習的社群資源
- [Chaos Engineering (O'Reilly)](https://www.oreilly.com/library/view/chaos-engineering/9781492043850/) - 混沌工程原理與實踐