可觀測性三大支柱
系統上線後，架構師最大的挑戰不是「東西壞了怎麼修」，而是「怎麼在用戶發現之前就知道系統出了問題」。可觀測性（Observability）就是讓你從系統的外部輸出推斷其內部狀態的能力，它建立在三大支柱之上：
| 支柱 | 回答的問題 | GCP 服務 | 典型用途 |
|---|---|---|---|
| Metrics（指標） | 系統現在的狀態如何？ | Cloud Monitoring | CPU 使用率、請求延遲 P99、錯誤率趨勢 |
| Logs（日誌） | 發生了什麼具體事件？ | Cloud Logging | 錯誤訊息、存取記錄、稽核軌跡 |
| Traces（追蹤） | 一個請求經過了哪些服務、花了多少時間？ | Cloud Trace | 跨微服務的延遲分析、瓶頸定位 |
三者缺一不可——Metrics 告訴你「延遲飆高了」，Logs 告訴你「某個 API 回傳 500 錯誤」，Traces 告訴你「是下游的 Cloud SQL 查詢花了 3 秒」。真正的可觀測性在於三者的關聯（Correlation）：從 Monitoring 告警出發，點擊進入相關 Logs，再追蹤到具體的 Trace Span，形成完整的除錯路徑。
💡 考試小提示：PCA 題目常問「如何診斷微服務間的延遲問題」——正確答案通常是 Cloud Trace（分散式追蹤），而非僅靠 Monitoring 指標或 Logging。
Cloud Monitoring
Cloud Monitoring 是 GCP 可觀測性的核心樞紐，負責收集、視覺化和告警所有指標資料。
指標類型
| 指標來源 | 說明 | 範例 |
|---|---|---|
| 系統指標（System Metrics） | GCP 服務自動產生，零設定 | compute.googleapis.com/instance/cpu/utilization |
| 自訂指標（Custom Metrics） | 應用透過 API 或 OpenTelemetry SDK 回報 | 業務 KPI（訂單數、轉換率） |
| 外部指標（External Metrics） | 從 AWS、Azure 或第三方服務匯入 | 跨雲監控場景 |
Dashboard 與 MQL
Dashboard 支援拖拉式編輯和程式碼模式。對於複雜查詢，MQL（Monitoring Query Language） 提供類似 SQL 的語法：可在單一查詢中做 join、ratio 運算和 group_by 聚合，比 GUI 篩選器靈活得多。
Uptime Checks 與 SLO Monitoring
- Uptime Checks — 從全球多個區域定期探測 HTTP(S)、TCP 或自訂協定端點，偵測服務是否可達。支援 SSL 憑證到期檢查
- SLO Monitoring — 直接在 Monitoring 中定義 SLO（如「99.9% 的請求在 200ms 內回應」），系統自動計算 Error Budget 剩餘量並在燒盡速率異常時告警
💡 考試小提示：題目描述「需要從外部監控服務可用性」時，答案指向 Uptime Checks；「需要追蹤 SLO 達成率和 Error Budget」則是 SLO Monitoring。
Cloud Logging
Cloud Logging 處理 GCP 上所有日誌的收集、路由、儲存與分析，是稽核合規和故障排除的關鍵基礎設施。
Log Router 與路由架構
所有日誌進入 Cloud Logging 後，會通過 Log Router 進行路由決策。Log Router 使用 inclusion/exclusion filters 決定日誌的去向：
| Sink 目標 | 適用場景 |
|---|---|
| Cloud Logging Storage | 預設目標，支援即時查詢（Log Explorer） |
| BigQuery | 長期分析、跨日誌關聯查詢、合規報表 |
| Cloud Storage | 低成本歸檔，滿足長期保留需求 |
| Pub/Sub | 即時串流至第三方 SIEM（如 Splunk、Datadog） |
Log-based Metrics 與保留策略
- Log-based Metrics — 從日誌內容自動產生 Monitoring 指標（如「每分鐘 HTTP 500 錯誤次數」），無需修改應用程式碼就能建立業務指標
- 保留期限 —
_Requiredbucket 400 天（不可修改）、_Defaultbucket 30 天（可延長至 3,650 天）。Exclusion filters 可在入口處丟棄高量低價值日誌（如 debug 等級），大幅降低儲存成本
💡 考試小提示：「需要將日誌匯出至第三方 SIEM 做即時分析」選 Pub/Sub sink；「需要長期日誌分析和 SQL 查詢」選 BigQuery sink。
Cloud Trace
Cloud Trace 提供分散式追蹤能力，讓你看見一個請求在微服務架構中的完整旅程。
核心能力
- 延遲分析 — 自動產生延遲分布圖（P50、P95、P99），快速發現效能退化
- Trace-Log Correlation — 每個 Trace 自動關聯相關日誌條目，點擊 span 即可查看該階段的詳細日誌
- OpenTelemetry 整合 — 透過 OpenTelemetry SDK 自動注入 trace context，支援跨語言、跨服務的 context propagation。App Engine、Cloud Run、Cloud Run functions 等服務已內建自動追蹤
採樣策略
生產環境不需要追蹤每一個請求。Cloud Trace 支援多種採樣策略——固定比例（如 1%）、自適應採樣（流量高時降低比例）、以及強制追蹤（對特定高價值請求）。正確的採樣策略在成本和診斷能力之間取得平衡。
Cloud Profiler
Cloud Profiler 是持續性的生產環境效能剖析工具，以極低的效能開銷（通常 < 0.5% CPU）收集 CPU 時間、記憶體分配和 Wall-time 資料。
與傳統 profiler 的關鍵差異在於它設計給生產環境使用——不需要重啟服務、不會顯著影響效能，讓你在真實流量下找到程式碼層級的熱點。支援 Go、Java、Node.js 和 Python，直接在 Console 中以火焰圖（Flame Graph）呈現，快速定位哪個函式消耗最多資源。
Error Reporting
Error Reporting 自動從 Cloud Logging 中識別和聚合應用錯誤：
- 自動錯誤分組 — 相同的 stack trace 自動歸為同一錯誤群組，避免被重複錯誤淹沒
- Stack Trace 分析 — 直接在 Console 中查看完整的呼叫堆疊，支援原始碼對應（Source Mapping）
- 通知管道 — 新錯誤或錯誤重現時透過 Email、Pub/Sub、PagerDuty、Slack 等管道即時通知
搭配 Cloud Trace，Error Reporting 可以告訴你「這個錯誤發生時，請求的完整路徑長什麼樣」，大幅縮短除錯時間。
SRE 方法論
Google 的 Site Reliability Engineering（SRE） 方法論是 PCA 考試的重要考點。SRE 的核心信念：100% 的可用性是錯誤的目標——追求完美可用性會拖慢創新速度，正確做法是用 Error Budget 在可靠性和迭代速度之間找到平衡。
SLI / SLO / SLA
| 概念 | 定義 | 範例 |
|---|---|---|
| SLI（服務等級指標） | 量化服務品質的具體指標 | 請求延遲 < 200ms 的比例、成功回應（非 5xx）的比例 |
| SLO（服務等級目標） | SLI 的目標閾值，內部承諾 | 「99.9% 的請求在 200ms 內回應」（月度計算） |
| SLA（服務等級協議） | SLO 加上違約後果，對外合約 | 「若月可用性低於 99.9%，退還 10% 費用」 |
關鍵原則：SLO 應比 SLA 嚴格——SLA 是 99.9% 時，SLO 設 99.95%，留出緩衝空間在觸發 SLA 違約前採取行動。
Error Budget（錯誤預算）
如果 SLO 是 99.9% 可用性，那麼一個月就有 0.1% 的錯誤預算（約 43 分鐘）。Error Budget 的核心用法：
- 預算充足時 — 加速功能發佈、允許更大膽的實驗
- 預算消耗過快 — 凍結新功能發佈，團隊全力投入可靠性改善
- Error Budget Policy — 預先制定書面政策（如「連續兩週 burn rate > 2x 時自動啟動 feature freeze」），避免臨場爭論
Toil Reduction 與事故管理
- Toil（苦差事） — 手動、重複、可自動化、無持久價值的操作工作。SRE 的目標是將 toil 控制在工作時間的 50% 以下，持續透過自動化消除
- 事故管理 — 明確的 Incident Commander 角色、即時溝通頻道（War Room）、結構化的升級流程
- Blameless Postmortem — 事後檢討聚焦於「系統為什麼讓這件事發生」而非「誰犯了錯」。產出具體的 action items 並追蹤到完成
💡 考試小提示：題目問「如何決定是否繼續發佈新功能」時，答案指向 Error Budget Policy——根據剩餘 Error Budget 決定是加速迭代還是凍結發佈。
告警策略設計
告警是可觀測性的最後一哩路，但設計不良的告警比沒有告警更糟糕——告警疲勞（Alert Fatigue） 會讓團隊忽略真正重要的訊號。
告警分級與設計原則
| 嚴重等級 | 回應方式 | 範例 |
|---|---|---|
| P1 Critical | 立即呼叫 On-call，15 分鐘內回應 | 核心服務完全不可用、Error Budget 快速燒盡 |
| P2 High | 通知 On-call，1 小時內回應 | 錯誤率顯著上升但服務仍可用 |
| P3 Medium | 建立工單，下一個工作日處理 | 非核心功能異常、效能輕微退化 |
| P4 Low | 記錄觀察，趨勢追蹤 | 資源使用率接近閾值 |
設計原則
- Symptom-based Alerting — 告警基於用戶可感知的症狀（延遲高、錯誤率上升），而非底層原因（CPU 使用率高）。CPU 80% 不一定是問題，延遲 P99 飆升才是
- Multi-window / Multi-burn-rate — Cloud Monitoring SLO Alerting 支援多時間窗口的 burn rate 告警（如「1 小時 burn rate > 14x」觸發 P1，「6 小時 burn rate > 6x」觸發 P2），兼顧靈敏度和誤報率
- Escalation Policy — 告警未在指定時間內回應時自動升級至下一層（工程師 → Tech Lead → VP），整合 PagerDuty 或 Opsgenie 管理 on-call 排班
實戰情境
情境一：電商平台的 SLO 監控體系
背景：Cymbal Shops 的核心 API 需要建立完整的 SLO 監控，目標是「99.9% 的請求在 300ms 內成功回應」，並在 Error Budget 異常消耗時自動採取行動。
架構決策：
- 定義兩個 SLI：可用性（非 5xx 回應比例）和延遲（回應時間 < 300ms 的比例），在 Cloud Monitoring 建立對應 SLO
- 設定 Multi-burn-rate Alerting：1 小時 burn rate > 14x 觸發 P1（PagerDuty 呼叫 On-call），6 小時 burn rate > 6x 觸發 P2（Slack 通知頻道）
- Error Budget Policy：月度 Error Budget 消耗超過 50% 時，自動凍結非關鍵功能發佈，團隊轉向可靠性改善
- 所有日誌透過 Log Router 同時導向 Cloud Logging（即時查詢）和 BigQuery（月度 SLO 報告和趨勢分析）
- Uptime Checks 從 6 個全球區域每分鐘探測關鍵端點，偵測區域性故障
情境二：用 Trace + Profiler 診斷生產延遲
背景：部署新版本後，訂單 API 的 P95 延遲從 150ms 上升至 800ms，但 CPU 和記憶體使用率都正常。
診斷路徑：
- Cloud Monitoring 告警觸發：P95 延遲超過 SLO 閾值，burn rate 異常
- 進入 Cloud Trace 分析延遲分布，發現高延遲 trace 集中在呼叫 Inventory 微服務的 span 上
- 點擊 span 查看關聯的 Cloud Logging 日誌，發現 Inventory 服務大量的 slow query warning
- 開啟 Cloud Profiler 查看 Inventory 服務的火焰圖，發現新版本引入的一個 ORM 查詢產生了 N+1 問題，每筆訂單觸發 50 次 DB 查詢
- 修復方式：將 N+1 查詢改為批次查詢（batch query），延遲恢復至 120ms
- 撰寫 Blameless Postmortem，action item 包含：新增查詢數量的 log-based metric 並設定告警閾值，CI 流水線加入慢查詢偵測測試
重點整理
- 可觀測性三大支柱：Metrics（Cloud Monitoring）、Logs（Cloud Logging）、Traces（Cloud Trace）——三者關聯才能形成完整的診斷路徑
- Cloud Logging 的 Log Router 控制日誌路由，BigQuery sink 用於長期分析，Pub/Sub sink 用於串流至第三方 SIEM
- Cloud Trace 搭配 OpenTelemetry 實現跨服務分散式追蹤，Cloud Profiler 以極低開銷持續剖析生產環境效能
- SRE 核心：SLI 量化品質、SLO 設定目標、Error Budget 平衡速度與可靠性、Blameless Postmortem 持續改進
- Error Budget Policy 是決定「繼續發佈功能」還是「修復可靠性」的關鍵機制
- 告警設計：基於症狀而非原因、Multi-burn-rate 避免誤報、明確的 escalation policy 防止告警疲勞
- Error Reporting 自動聚合錯誤、關聯 stack trace，搭配通知管道即時回報
下一步
在下一課中，我們將探討災難復原與業務持續性策略，包括 RTO/RPO 定義、備份與復原架構設計，以及如何在 GCP 上實現跨區域的高可用與容錯架構——確保系統在最糟糕的情況下也能持續運行。