事件回應與管理

事件回應簡介

事件 (Incident) 指的是對服務品質計劃外的中斷或降低。無論你的系統架構設計得有多好，事件總會發生。事件回應管理 (Incident Response Management) 是處理這些事件的過程，旨在盡快恢復服務，同時將對業務的影響降至最低。

對於 GCP Professional Cloud Architect 來說，重點在於建立一個可重複的流程，該流程依賴於角色、溝通和學習，而不是個人英雄主義。

白話文解釋 Incident Response

比喻 1 — 消防隊

當火災發生時，消防隊不會隨機跑進建築物。他們有一位事件指揮官 (Incident Commander)（隊長）留在外面進行協調。他們有專門的角色（水龍頭、梯子、醫護）。火撲滅後，他們會調查原因（事後檢討）以防止未來的火災，而不是僅僅指責那個忘了關爐火的人。

比喻 2 — 急診室創傷小組

在醫院急診室，當呼叫「紅色代碼 (Code Red)」時，一個特定的團隊會集結。一個人領導復甦工作（主任醫師），而其他人處理特定任務（生命體徵、藥物）。他們使用「閉環溝通 (Closed-loop communication)」進行清晰的溝通（例如：「給予 5 毫克腎上腺素」->「已給予 5 毫克腎上腺素」）。這可以防止在混亂的事件中出錯。

比喻 3 — 航空公司飛行員的緊急清單

當引擎失效時，飛行員不會驚慌。他們拿出快速參考手冊 (Quick Reference Handbook, QRH)。這就像是一個事件操作手冊 (Incident Playbook)。它包含針對已知問題的分步說明，讓他們保持冷靜並遵循一條經過驗證的安全路徑。

事件回應生命週期

1. 偵測 (Detection): 透過告警 (Cloud Monitoring) 或使用者報告識別事件。
2. 分類 (Triage): 確定嚴重性 (Severity)（影響）和優先級 (Priority)（緊急程度）。
3. 封鎖/緩解 (Containment/Mitigation): 立即採取行動以「止血」（例如：回滾部署、增加容量）。這不是進行永久修復的時候。
4. 解決 (Resolution): 實施永久修復。
5. 事後檢討/回顧 (Post-mortem/Retrospective): 分析根本原因並確定防止再次發生的行動。

事件回應中的關鍵角色

• 事件指揮官 (Incident Commander, IC): 負責回應的人。他們協調團隊，做出高層級決策，並確保每個人都擁有其所需的資源。IC 不編寫程式碼或修復 Bug。
• 運維負責人 (Operations Lead): 負責動手緩解和解決問題的技術專家。
• 溝通負責人 (Communications Lead): 負責更新利益相關者（內部主管和外部客戶）的人。

無責備事後檢討 (Blameless Post-mortems)

事後檢討的目標是學習，而不是懲罰。

• 無責備 (Blameless): 我們假設每個人在當時都以最好的意圖和可用的資訊行事。
• 根本原因分析 (Root Cause Analysis, RCA): 我們尋找系統性故障（例如：「自動化測試套件沒有捕捉到這種情況」），而不是人為錯誤（例如：「小明輸入了錯誤的指令」）。
• 行動項目: 每次事後檢討都必須產生具體的任務，以改進系統或流程。

架構師洞察： 在 PCA 考試中，如果問題詢問如何改善公司的「可靠性文化 (Culture of Reliability)」，答案幾乎總是實施無責備事後檢討。這鼓勵誠實和持續改進，而不是恐懼和隱藏錯誤。 ::

嚴重程度分級 (SEV1–SEV4)

一致的嚴重程度量表能去除分類時的模糊性，並告訴 PagerDuty / Cloud Monitoring 路由引擎該叫醒誰。Google SRE 團隊通常標準化為四個等級：

SEV1 — 嚴重影響客戶

面向使用者的 GCP 工作負載全面或大部分中斷（例如：Cloud Run 修訂版本對 >50% 請求回傳 5xx、GKE Ingress 無法連線、Cloud SQL 主庫故障但備庫未升主）。立即呼叫值班人員，開戰情室（Google Meet 橋接），並於 5 分鐘內通知溝通負責人 (Communications Lead)。每 15 分鐘更新狀態頁直到緩解。

SEV2 — 顯著降級

延遲或錯誤率突破 fast burn-rate 告警（例如：HTTP(S) Load Balancer P95 延遲超出 SLO 目標 >10 分鐘），但服務仍部分可用。單一區域降級而其他健康也屬此類。呼叫值班，不需召集全員戰情室。

SEV3 — 次要 / 部分問題

非面向客戶的故障：Cloud Scheduler 工作失敗、Dataflow 批次管線卡住、BigQuery 排程查詢失敗。開單，上班時間內修。非工作時間不呼叫。

SEV4 — 表面 / 資訊性

儀表板上的錯字、棄用的 log 訊息、缺少標籤。記錄到 backlog。

# Example severity → notification channel mapping
sev1:
  channels: [pagerduty-page, slack-incident-room, status-page-update]
  ack_sla_minutes: 5
sev2:
  channels: [pagerduty-page, slack-incident-room]
  ack_sla_minutes: 15
sev3:
  channels: [slack-alerts]
  ack_sla_minutes: 240

將嚴重程度矩陣記錄在 runbook 儲存庫中，任何工程師在凌晨 3 點都能自行正確分級。

值班輪替設計

健康的值班排程能防止 burnout，同時保證 24/7 覆蓋。GCP 團隊常見的模式：

• Follow-the-sun（追日制）: APAC / EMEA / AMER 三個區域團隊各負責約 8 小時的當地工作日。需要三個區域團隊；任何人都不必凌晨 3 點接呼叫。
• 主 + 副 (Primary + Secondary): 一位工程師先收到呼叫；若 5 分鐘內未確認，PagerDuty 升級到副手。兩者每週輪替。
• 分層升級: Tier 1（值班 SRE）→ Tier 2（服務負責人）→ Tier 3（工程經理 / VP）。每層都有自己的確認 SLA。

排程衛生

• 值班佔工作時間不超過 25%，依照 Google SRE 指南。
• 補償: 補休或值班津貼；絕不要視為「額外義務」。
• 交接儀式: 卸任值班在 Slack 發布開放中事件、被靜音的告警、已知不穩定服務的摘要給接班人。
• 練習輪替: 新進工程師擔任主值班前先跟班 2-3 週。

Runbook 設計與操作手冊

Runbook（或 playbook）是你服務的 QRH — 已知故障模式的逐步緩解步驟。好的 runbook 能把 SEV1 從 90 分鐘的兵荒馬亂變成 10 分鐘的檢查表。

每份 Runbook 必須包含

1. 告警特徵 — 哪個 Cloud Monitoring 告警觸發，其 labels 的含義。
2. 可能原因 — 此告警的前 3 大根本原因，按頻率排序。
3. 診斷指令 — 可直接複製貼上的 gcloud / kubectl / bq 指令。範例：

   # Check GKE pod status
   kubectl get pods -n prod -l app=checkout --field-selector=status.phase!=Running
   # Inspect Cloud SQL replication lag
   gcloud sql operations list --instance=prod-db --filter="status=RUNNING"
   

4. 緩解步驟 — 明確的 rollback、scale-out、failover 指令。每步註明「預期輸出」。
5. 升級條件 — 何時呼叫服務負責人或宣告 SEV1。
6. 負責人與最後審閱日期 — runbook 會腐朽；每季審閱。

儲存與發現

• 將 runbook 與服務程式碼一起放在 Git（單一真實來源，變更經過 code review）。
• 在 Cloud Monitoring 告警政策的 documentation.content 欄位直接附上 runbook 連結，這樣呼叫訊息就包含連結，不必到處找。
• 透過靜態網站（Hugo、MkDocs）部署到 Firebase Hosting 渲染 runbook，這樣即使內部 wiki 掛了也能存取。

事件指揮架構 (IC、SME、Comms)

Google 的 Incident Management at Google (IMAG) 框架明確定義三個核心角色。對於 SEV1，三個角色都要由不同的人擔任：

事件指揮官 (Incident Commander, IC)

• 負責回應，而非修復。設定優先順序、分派任務、宣告嚴重程度變更。
• 主持 Meet 橋接：「目前的假設是什麼？下一步是什麼？誰來執行？」
• 決定何時宣告解決、何時將 IC 角色交接給下一人（長時間事件中，每 4 小時輪替一次）。

領域專家 (SME) / 運維負責人

• 真正動手操作鍵盤的人。執行 gcloud、讀 Cloud Logging、推動緩解。
• 向 IC 回報發現；不做範圍決策（「我們應該切換到 us-east1 嗎？」→ IC 決定）。
• 可以有多位 SME 平行工作（每個受影響服務一位：GKE SME、Spanner SME、網路 SME）。

溝通負責人 (Communications Lead, Comms)

• 草擬並發布狀態頁更新、內部 Slack 公告、主管郵件。
• 把 SME 的術語（「Spanner 領導者選舉超時」）翻譯成客戶能懂的話（「europe-west4 區域的 API 請求可能比平常慢」）。
• 負責事件後客戶郵件與任何法規通知。

為何要分開角色

單一工程師無法同時 debug Spanner 查詢、更新狀態頁、向 VP 簡報。分開角色減少 context switching，並由 IC 在開始時宣告角色：「我是 IC，Alice 是 checkout 的 SME，Bob 是 Comms。」

Cloud Logging 事件時間線

可重建的時間線是每次事後檢討的骨幹。Cloud Logging 是你的權威來源，但前提是事件發生前就已設定好。

擷取策略

• 在 Organization 層級的彙總 log sink 路由到專用的 BigQuery 資料集（logs_incidents），保留 400 天 — 足夠調查慢燃事件並滿足多數稽核窗口。
• 必要 log buckets: Cloud Audit Logs（敏感服務的 Admin Activity + Data Access）、VPC Flow Logs（取樣）、結構化 jsonPayload 的應用程式 log。
• 標準化 correlation ID: 每個請求帶一個 trace_id，貫穿 GKE、Cloud Run、Pub/Sub、Cloud SQL proxy 的 log，這樣能重建單一使用者的旅程。

事件發生時建立時間線

1. 在事件頻道釘選 Log Analytics 已存查詢，依服務 + severity≥ERROR 過濾。
2. 用 Logs Explorer 時間範圍滑桿找出第一個異常 log 條目 — 那就是 t0。
3. 與 Cloud Monitoring 儀表板（MQL 或 PromQL）交叉比對確認 SLI 何時破壞。
4. 用 gcloud 把時間線匯出到 Google Doc：

   gcloud logging read 'resource.type="k8s_container" severity>=ERROR
     timestamp>="2026-05-12T10:00:00Z" timestamp<="2026-05-12T11:30:00Z"' \
     --format="csv(timestamp,resource.labels.pod_name,jsonPayload.message)" \
     --limit=500 > incident-timeline.csv
   

常見陷阱

• 事件前忘了啟用 Cloud SQL / BigQuery 的 Data Access audit logs — 事後無法追溯開啟。
• VPC Flow Logs 取樣太激進（0.1%） — 網路事件變得無法重現。
• 高負載下 Ops Agent buffer 溢位導致 log 在 agent 端被丟棄；在 tier-1 instance 預先配置較大的 buffer。

PagerDuty + GCP 整合

PagerDuty 是 GCP 團隊最常見的呼叫器；透過 Pub/Sub 與 webhook 雙向整合。

連接 Cloud Monitoring → PagerDuty

1. 在 Cloud Monitoring 建立類型為「Webhook」的 Notification Channel，指向 PagerDuty 的 Events API v2 端點，或使用預設的 PagerDuty channel 只需 integration key。
2. 將 channel 附加到告警政策。PagerDuty 事件帶有 incident_id + condition_name，值班看到告警標題就在呼叫內。
3. 把告警 severity labels（severity=sev1）對應到 PagerDuty Urgency，這樣 SEV1 即使值班關了「低急迫性通知」也會呼叫。

連接 PagerDuty → GCP 做自動化

• 使用 PagerDuty webhooks → Cloud Functions 自動執行安全的緩解動作（例如：service=payment 的 SEV1 自動把 GKE node pool 擴容 +50%，並把動作 po 到事件頻道）。
• 使用 PagerDuty Event Orchestration 對來自同一 resource.labels.instance_id 的雜訊告警做去重，避免一台抖動的 VM 產生 50 個呼叫。

設定陷阱

• 每個服務一個 routing key，而非每個團隊 — 讓 PagerDuty 即使團隊邊界變動也能正確對應到排程。
• 自動解決 Cloud Monitoring 告警在條件清除時關閉，這樣 PagerDuty incident 自動關閉而不會懸掛數天。
• 維護視窗: 計畫性 Cloud SQL 維護或 GKE 升級期間用 PagerDuty maintenance windows 靜音呼叫，而不是停用告警（你會忘記重新啟用）。

事後檢討範本

一致的範本讓事後檢討可搜尋、可比較。Google SRE 規範結構：

1. 標頭

• 事件 ID: INC-2026-0512-001
• 嚴重程度: SEV1
• 日期 / 持續時間: 2026-05-12, 10:00–11:42 UTC（1h 42m）
• 作者 / IC / SMEs: 列名
• 狀態: Draft / In Review / Published

2. 摘要 (2-3 句，主管可讀)

什麼壞了、誰受影響、如何緩解。不用術語。

3. 影響

• 客戶影響：例如「12% 的 checkout API 請求在 1h 42m 內回傳 503」。
• SLO 影響：「checkout-api 月度錯誤預算消耗 38%」。
• 營收 / 合約：「估計 $X 失敗交易；對 4 個企業帳戶積欠 SLA 補償」。

4. 時間線

依時間順序，時間戳用 UTC。每列：時間、誰、做了什麼或觀察到什麼。從 Cloud Logging 匯出資料拉。

5. 根本原因（「5 個為什麼」）

鑽研系統性原因。範例：壞的部署 → 為何通過審查？→ 為何測試沒抓到？→ 為何跳過 canary 階段？

6. 哪些做得好 / 哪些不好

肯定省時的部分（好的 runbook、快速 rollback），也檢討花時間的部分（過時儀表板、缺少告警）。

7. 行動項目（最重要的一節）

每個行動項目都有負責人、期限、JIRA 連結 — 否則永遠不會出貨。

8. 學到的教訓

簡短反思，回饋到全團隊技術分享與新人訓練教材。

事件期間的錯誤預算燃燒

錯誤預算 (Error Budget) = 1 - SLO 把事件回應與產品速度連結起來。事件期間你正在主動花預算 — 追蹤它。

Fast Burn vs Slow Burn 告警

Google SRE 建議每個 tier-1 SLO 都設定多視窗、多燃燒率告警政策：

• Fast burn (14.4x, 1h 視窗): 每小時花 2% 的月預算 → 立即呼叫（SEV1/SEV2 候選）。
• Slow burn (3x, 6h 視窗): 6 小時內每小時花 1% → 開單，上班時間調查。

在 Cloud Monitoring 為服務建立 SLO，然後附加 SloBurnRateCondition 告警政策：

conditions:
  - displayName: "Fast burn — checkout availability"
    conditionThreshold:
      filter: 'select_slo_burn_rate("projects/PROJECT/services/checkout/serviceLevelObjectives/availability-99-9", "3600s")'
      comparison: COMPARISON_GT
      thresholdValue: 14.4

決策框架

• 單一事件消耗 >50% 的月預算 → 凍結該服務的非關鍵功能上線，直到預算恢復。
• 一季內預算耗盡兩次 → 強制可靠性 sprint；產品團隊透過 SLO 合約事前同意。
• 預算長期未動用 (<10% 使用) → SLO 太鬆；緊縮它讓工程精力轉移到其他地方。

工具

• Cloud Monitoring SLO 儀表板顯示即時剩餘預算，在事件戰情室醒目顯示，讓 IC 看見事件每延長一分鐘的成本。
• 透過 Cloud Monitoring → Pub/Sub → Dataflow 把 SLO 指標匯出到 BigQuery，做長期趨勢分析與季度可靠性審查。

Cloud Monitoring 故障處理

當故障發生在 Cloud Monitoring 本身（或上游 Google 基礎設施），你正常的可觀測性堆疊本身可能也受影響。

防禦模式

• 跨區域儀表板: 關鍵儀表板在兩個區域同時託管；若 us-central1 Cloud Monitoring console 變慢，切到 europe-west4。
• 頻外 (out-of-band) 呼叫: 為前 5 大 SLI 保留次要告警路徑（例如 Datadog、Grafana Cloud），這樣 Cloud Monitoring 故障時不至於完全失明。
• GCP 外的合成檢測: 用 PagerDuty synthetic monitoring 或託管在 AWS / Azure 的第三方探針來偵測「GCP 本身掛了」的情況。

Google Cloud Service Health

• 讓值班輪替訂閱 Google Cloud Service Health RSS feed 與 Personalized Service Health 告警（可透過 Cloud Monitoring 通知 channel 設定）。
• 當 Service Health 宣告區域性議題時，先確認再假設是自己的 bug — 省下數小時的錯誤方向除錯。
• 與 status.cloud.google.com 交叉比對全球故障視圖。

雲端供應商故障時的溝通

若根本原因是 Google Cloud 區域故障：

1. 在狀態頁向客戶承認上游議題在 GCP 端，並附上 Google 事件報告連結。
2. 若故障超過 RTO，啟動 DR runbook（例如 Spanner multi-region 從 us-central1 切到 us-east1，或在 Global External HTTP(S) LB 後切換 Cloud Run 的 active region）。
3. 在事後檢討中收錄 Google 最終公布的 RCA；即使你沒造成，客戶仍經歷了影響，你的行動項目應聚焦在防禦性架構（多區域、circuit breaker、優雅降級）。

客戶狀態頁策略

公開狀態頁是事件回應的一部分，不是事後想法。客戶評斷你可靠性的依據，事件期間的溝通與 uptime 數字同樣重要。

平台選擇

• Statuspage (Atlassian)、Better Stack、Instatus、Cachet — 託管型，一小時就能上線。
• 若採 GCP 原生：把靜態頁面託管到 Cloud Storage + Cloud CDN + Cloud Load Balancing，由 PagerDuty webhook 觸發的 Cloud Function 餵資料。關鍵：狀態頁要託管在與主要工作負載不同的雲或至少不同區域，否則同一個故障會把兩邊都拉下來。

更新節奏

寫出建立信任的更新

• 陳述事實，不講理論。 「我們正在調查 checkout API 升高的 5xx 錯誤」— 不要寫「可能是資料庫議題」。
• 具體承認影響。 「約 8% 歐洲客戶無法完成購買」勝過「部分使用者可能遇到議題」。
• 承諾下次更新時間。 「下次更新 14:30 UTC」— 即使沒新進展也要守時（「仍在調查，下次更新 15:00」）。
• 5 個工作日內發布事後檢討並從狀態頁連出。這是建立信任最大的單點動作。

訂閱者頻道

讓客戶透過電子郵件、SMS、RSS、Slack webhook 或 Microsoft Teams connector 訂閱。用 Cloud Tasks 或 Pub/Sub fan-out 派發更新，這樣一個有 10,000 訂閱者的狀態頁更新不會花 20 分鐘才送完。

FAQ — 事件回應管理

Q1. 「緩解 (Mitigation)」與「解決 (Resolution)」有什麼區別？

緩解是恢復服務的臨時修復（例如：重啟 VM）。解決是針對根本原因的永久修復（例如：修復程式碼中的記憶體洩漏）。

Q2. 在事件期間應該多久更新一次利益相關者？

這取決於嚴重程度。對於 P0（緊急）事件，通常每 15-30 分鐘更新一次。對於 P2，每 2-4 小時更新一次可能就足夠了。一致性比頻率更重要。

Q3. 什麼是「閉環溝通 (Closed-loop Communication)」？

這是一種接收者向發送者重複指令以確保理解正確的技術。在壓力巨大的事件期間，這對於防止技術錯誤至關重要。

Q4. 我們是否應該對每次事件都進行事後檢討？

理想情況下，對於任何違反 SLO 或顯著影響客戶的事件都應該進行。對於次要事件，為了節省時間，進行「微型事後檢討 (micro-post-mortem)」或簡單的日誌記錄可能就足夠了。

Q5. 我們如何在不破壞生產環境的情況下模擬事件？

使用混沌工程 (Chaos Engineering)（例如：故障注入 Fault Injection）或進行 Game Days，讓團隊在臨時環境中經歷模擬場景，以練習他們的回應並測試他們的操作手冊。