告警策略簡介
沒有有效告警策略的觀測系統就像是一個沒有電池的煙霧探測器——它可能會看到火災，但不會喚醒任何人。在 Google Cloud 中，Cloud Monitoring 允許你創建告警策略，當系統指標跨越特定門檻值或運作時間檢查 (uptime checks) 失敗時觸發。
對於 Professional Cloud Architect 來說，目標不僅僅是「對所有內容進行告警」，而是設計一個具有行動指引性 (actionable)、相關性且及時的系統。過度告警會導致告警疲勞 (alert fatigue)，由於不斷湧入的「噪音」，關鍵問題反而會被忽略。
白話文解釋 Alerting Strategies
比喻 1 — 保安員的監視器
想像一個保安員看著 100 個螢幕。如果每次有貓走過鏡頭警報就會響（噪音），保安員最終會把音量調低。一個好的告警策略就像是一個系統，只有當一個人類大小的物體打破窗戶（具行動指引性的事件）時，才會響起巨大的鈴聲。對於貓，它可能只是靜靜地記錄下事件。
比喻 2 — 醫療檢傷分類
告警就像是醫院急診室的檢傷分類 (ER triage)。一個割傷手指的病人（低優先級）不會引起警笛響起；他們需要排隊等待。一個胸痛的病人（高優先級/P0）會觸發「藍色代碼 (Code Blue)」告警，立即召集所有人。你的告警策略應該區分「磁碟已滿 80%」（割傷手指）和「資料庫宕機」（藍色代碼）。
比喻 3 — 汽車的「低油量」燈
「低油量」燈是一個完美的告警。它不會在你剛用掉 10% 的油時就大聲尖叫。它會等到你處於關鍵門檻值時（例如：剩餘 50 英里），給予你足夠的提前時間 (lead time) 在系統失效（車子停止）之前採取行動（找加油站）。
值班工程師因面臨大量頻繁、不具行動指引性的告警而感到的疲憊和麻木狀態。
設計有效的告警策略
1. 針對症狀而非原因進行告警
不要僅僅因為「CPU 很高」就發出告警。要因為「使用者延遲很高」或「錯誤率 > 5%」而發出告警。在批次作業期間，高 CPU 可能是預期之內的；但對於使用者來說，高延遲永遠是個問題。
2. 門檻值與持續時間
- 門檻值 (Threshold): 觸發告警的數值（例如：90% CPU）。
- 持續時間 (Duration): 條件必須持續多久才會發送告警（例如：「持續 5 分鐘」）。這有助於忽略會自行修正的短暫「尖峰」。
3. 通知管道 (Notification Channels)
Google Cloud 支援多種管道：
- 高緊急性: PagerDuty、Opsgenie、簡訊或電話。
- 中/低緊急性: 電子郵件、Slack 或 Microsoft Teams。
- 自動修復 (Automated Remediation): 使用 Pub/Sub 觸發 Cloud Function，它可以自動擴展叢集或重啟服務。
減少告警疲勞
- 靜音與延後 (Muting and Snoozing): 在計劃維護期間使用「靜音窗口」，這樣你就不會因為預期內的停機時間而被呼叫。
- 嚴重性級別: 為告警分配嚴重性（Critical、Error、Warning）。只有「Critical」才應該在凌晨 3 點叫醒某人。
- 告警標籤: 在告警說明中使用文件連結和「操作手冊 (Playbooks)」，以便回應者確切知道該做什麼。
架構師洞察： 對於 PCA 考試，如果場景描述維運團隊「被告警淹沒」或「遺漏關鍵問題」，解決方案通常涉及調整門檻值、增加持續時間，以及針對 SLO 違規進行告警，而不是針對原始資源指標。
進階告警：基於 SLO 的告警
SRE（網站可靠性工程）的「黃金標準」是基於 服務水準目標 (SLOs) 和 錯誤預算 (Error Budgets) 進行告警。
- 消耗率告警 (Burn Rate Alerting): 與其在發生錯誤時發出告警，不如在你的每月錯誤預算「消耗」太快時發出告警。這會告訴你，如果你現在不採取行動，到月底你將會違反 SLA。
多視窗、多消耗率的 SLO 告警
Cloud Monitoring 的 Service Monitoring 功能允許你將告警策略直接附加到 SLO 定義上，這是針對使用者實際感受到的故障進行告警最精準的方式，而不是被基礎設施雜訊干擾。Google SRE workbook 建議採用 multi-window, multi-burn-rate（多視窗、多消耗率）策略，結合一個快速視窗和一個慢速視窗，這樣既能快速捕捉故障，又能對短暫尖峰保持容忍。
典型的 Burn Rate 分層
- Fast burn（立即呼叫）: 1 小時與 5 分鐘視窗、消耗率 14.4×。代表在 1 小時內就會吃掉 30 天錯誤預算的 2%，必須立刻呼叫 on-call。
- Slow burn（開工單）: 24 小時與 1 小時視窗、消耗率 1×。這代表慢性問題，值得在上班時間處理，但不應該在凌晨 3 點叫人起床。
- Trickle burn（提醒）: 6 小時視窗、消耗率 6×。通常路由到 Slack 頻道而非 PagerDuty。
在 Google Cloud 上的設定方式
- 在 Service Monitoring 中定義 SLI（request-based 或 windows-based），對應到 Cloud Run、GKE 或 Istio mesh 上的服務。
- 設定 SLO target（例如：rolling 30 天日曆視窗的 99.9% 可用率）。
- 使用
gcloud alpha monitoring policies create，搭配windowsBasedSli條件並引用select_slo_burn_rate(...)MQL 表達式。 - 把兩個條件（fast + slow）綁在同一個策略上，這樣只有當兩個視窗都同意時告警才會觸發，能大幅降低誤報。
對於 PCA 考試中描述「使用者已經受影響但團隊卻只在 CPU 飆高時被叫」的場景，正確的架構決策是把告警從原始資源指標的門檻值告警，遷移到以 select_slo_burn_rate 為基礎的 multi-window, multi-burn-rate SLO 告警。這樣呼叫頻率才會對齊使用者體驗，並直接連結到管控功能釋出節奏的 Error Budget Policy。參考：https://sre.google/workbook/alerting-on-slos/
告警分組、自動關閉與暫停
一次故障往往會觸發數十個彼此相關的告警（每個 replica 一個、每個 region 一個、每個下游依賴一個）。Cloud Monitoring 內建了多種機制，避免這種情況演變成「呼叫器風暴」。
Auto-Close Duration（自動關閉時間）
每個告警策略都有 auto-close 設定（預設 7 天，最低可設到 30 分鐘）。當底層條件不再成立時，事件 (incident) 會自動轉為「Closed」。設太長會讓陳舊事件一直掛著；設太短則容易造成抖動告警重複觸發。
Notification Rate Limiting（通知頻率限制）
- 多條件策略上的
combiner: OR與combiner: AND控制的是：任一資源（label set）就能觸發策略、還是所有條件都必須同時成立。 notificationRateLimit欄位（例如period: 3600s）會限制同一個未關閉事件的重複通知頻率，對於暫時無法修復的雜訊型基礎設施告警特別有用。
Snoozes 與 Muting Rules
- Snoozes（2023 年推出）會在固定時間視窗內暫時讓某個策略或特定 labels 靜音，非常適合計畫性的部署視窗。
- Muting Rules 是基於 label 的篩選器，會阻擋通知但不會阻止事件紀錄被建立，這對需要稽核紀錄的合規審查很重要。
排定發佈視窗時，建議建立帶 label filter（例如 environment=staging）的 snooze，而不是停用整個告警策略。這樣 production 的呼叫機制依然處於武裝狀態，工程師也不會不小心把 staging 永久靜音——snooze 會自動到期。參考：https://cloud.google.com/monitoring/alerts/manage-snoozes
多管道升級與 On-Call 路由
只用單一通知管道，等於把單點失效寫進架構。能在故障中存活的設計，會跨多種異質管道採用 tiered escalation（分層升級）。
Escalation Tiers（升級分層）
- Primary（P0, 0–5 分鐘）： 透過官方 Cloud Monitoring notification channel 串接 PagerDuty 或 Opsgenie。這些服務本身已經處理 on-call 輪班、推播通知與 acknowledgement。
- Secondary（5–15 分鐘）： Cloud Monitoring 的 SMS + voice call 管道，加上一個 Pub/Sub topic 扇出到位於不同雲端或 region 的次要呼叫系統（防範 PagerDuty 本身故障）。
- Tertiary（15+ 分鐘）： 電子郵件群組，以及 Slack/Teams webhook 管道，用於廣泛的情境感知。
依嚴重性 Label 路由
利用告警策略上的 severity 欄位（CRITICAL、ERROR、WARNING、INFO）結合 notification channel groups，讓只有 CRITICAL 等級的策略會觸發呼叫器，而 WARNING 策略則進入工單佇列。在 Terraform 裡，這對應到每個策略掛上不同的 notification_channels array。
Webhook + Pub/Sub 混合模式
對於正在標準化 Eventarc 的組織，可以把 Cloud Monitoring 告警先送進 Pub/Sub，再交給一個 Cloud Run 服務來補強 payload（補上 runbook 連結、最近一次 deploy 的 SHA、對應的負責團隊），最後再轉發到 PagerDuty Events API v2。這條解耦管線在供應商故障時也能存活，並且讓你能在不動到每一條告警策略的情況下，A/B 測試新的呼叫供應商。
常見的架構錯誤是把每一條告警策略都直接接到 PagerDuty，沒有 Pub/Sub fan-out。2023 年 PagerDuty 發生數小時故障時，沒有第二條路徑的團隊就在那段時間完全看不到 production 事件。PCA 考試期待你認得 Pub/Sub + Cloud Run notification fan-out 這個 resilient 設計模式——千萬不要假設你的事件管理供應商會比它監控的工作負載還可靠。
告警雜訊降低與自動化修復
成熟告警的目標不只是通知人類——而是儘可能把人類從迴圈中移出。GCP 提供了幾個原語，可以打造 SOAR-style（Security Orchestration, Automation, and Response）的工作流，把偵測與修復串成閉迴路。
戰術層級的雜訊降低手段
- Aggregation： 使用 MQL 的
align rate搭配group_by [resource.label.cluster_name]，針對 cluster 而非個別 pod 發出告警。 - 預測式條件 (Forecast-based)： 使用
MetricAbsence與 forecasted threshold 條件型別，在趨勢演變成事件之前就先告警。 - Log-based metrics： 把吵雜的 log-based 告警轉換為帶有萃取 label 的 log-based metrics，再針對變化率告警——這比直接做原始文字比對穩定許多。
自動化修復管線
Cloud Monitoring alert → Pub/Sub topic (alerts-actionable)
→ Cloud Run service (remediation handler)
→ 呼叫 Compute Engine API 擴展 MIG，或
→ 呼叫 GKE API 重啟 Deployment，或
→ 觸發 Cloud Workflows 執行多步驟復原
Cloud Run handler 必須是 idempotent（告警可能會重複觸發），並把帶有原始事件 ID 的 audit log 寫入 Cloud Logging。對於高爆炸半徑的動作（終止 node pool、把 Cloud SQL replica 切換為主節點），要透過 Cloud Workflows 的 callback 步驟加上 人工核可關卡。
用 Eventarc 做跨服務觸發
Eventarc 可以訂閱同一個 Pub/Sub topic，並觸發 Cloud Functions、Cloud Run 或 Workflows。當修復邏輯跨越服務邊界時（例如：Spanner 告警觸發暫停 BigQuery export），這就是建議模式。
PCA 考試的標準 GCP 告警對接修復鏈條是：Cloud Monitoring alert policy → Pub/Sub notification channel → Eventarc / Cloud Run handler → 目標服務 API（GKE、Compute、Cloud SQL）→ 寫回 Cloud Logging 的 audit log。當場景提到「self-healing」、「auto-remediation」或「降低 on-call 負擔」時，這條五段式管線就是答案——絕對不要提議在某台 VM 上寫一支常駐 daemon 去輪詢 Monitoring 的告警。
FAQ — 告警與通知策略
Q1. 「條件 (Condition)」和「策略 (Policy)」有什麼區別？
條件是具體的規則（例如：CPU > 80%）。策略是包含一個或多個條件並指定通知對象和方式的容器。
Q2. 我可以將告警發送到私有的 Slack 頻道嗎？
是的。你需要在 Google Cloud 控制台中配置 Slack 整合，並確保「Google Cloud Monitoring」應用程式具有存取該私有頻道的權限。
Q3. 如何防止告警「抖動 (Flapping)」？
當指標恰好在門檻值附近波動時，會導致告警重複觸發和清除，這稱為「抖動」。為了防止這種情況，請增加持續時間或使用觸發缺失 (Trigger Absense) 條件。
Q4. 我可以針對記錄 (logs) 而非指標發出告警嗎？
是的。基於記錄的告警 (Log-based Alerts) 允許你在記錄中出現特定字串時觸發通知（例如：「FATAL DATABASE ERROR」）。但是，請謹慎使用，因為它們可能會產生很多噪音。
Q5. Pub/Sub 在告警中扮演什麼角色？
Pub/Sub 充當自動修復的橋樑。當告警觸發時，它會向 Pub/Sub 主題發送訊息。訂閱者（如 Cloud Function）隨後可以執行程式碼來自動修復問題。