Google PCD: 可觀測性、偵錯與網站可靠性維運 — 學習指南

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

屬於 Google Professional Cloud Developer — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

Google Cloud 中的可觀測性 (Observability)、偵錯與網站可靠性維運 (SRE)，其核心在於讓系統變得可衡量、可診斷且具備韌性。強大的可觀測性需要一致的日誌與指標、分散式追蹤、可採取行動的快訊，以及嚴謹的事件應變機制。可靠性則要求明確的服務水準指標 (SLI) 與目標 (SLO)、嚴格的健康狀態信號，以及一個能將線上環境的洞見轉化為工程改進的回饋循環。本節將概述如何在 Google Cloud 中端到端地建構這些能力，並探討如何權衡取捨與分析常見的故障模式。

日誌與監控基礎

Cloud Logging

發送結構化日誌。優先使用 JSON 格式並搭配穩定的欄位名稱，這樣查詢與基於日誌的指標在版本更新後仍能保持穩健。日誌應包含嚴重性、服務名稱、版本、位置，以及用於關聯的請求 ID 或追蹤脈絡 (trace context)。
透過設定以下欄位將日誌與追蹤關聯起來：
- logging.googleapis.com/trace: projects/PROJECT_ID/traces/TRACE_ID
- logging.googleapis.com/spanId: SPAN_ID
- logging.googleapis.com/trace_sampled: true
儲存桶與保留天數。_Default 儲存桶通常有 30 天的保留期 (可設定)。_Required 儲存桶包含特定的稽核日誌，其保留期較長且固定。建立區域性儲存桶以控制資料存放位置，並為每個儲存桶設定自訂的保留天數。
匯出槽 (Sinks)。將日誌路由到 BigQuery 進行分析、到 Pub/Sub 供串流消費者使用，或到 Storage 進行封存。在資料夾或機構層級使用匯總匯出槽，以擷取底下所有專案的日誌。
查詢。使用 Logging 查詢語言，依 resource.type、labels、jsonPayload、httpRequest 或 textPayload 進行篩選。

範例：

結構化日誌項目 (簡化版)：

undefined

更新保留天數：

undefined

為錯誤日誌建立一個 BigQuery 匯出槽：

undefined

讀取 Cloud Run 最近的 5xx 錯誤：

undefined

Cloud Monitoring

指標。使用 Google Cloud 指標、自訂指標與基於日誌的指標。偏好使用低基數 (low-cardinality) 的標籤；標籤基數爆炸會導致成本與查詢延遲問題。
資訊主頁。為每個服務及其依賴項目 (資料庫、快取、佇列) 精心設計資訊主頁。將 RED (請求、錯誤、延遲) 與 USE (使用率、飽和度、錯誤) 信號視覺化。
快訊政策。可依據門檻值、指標不存在、比率、SLO 燃盡率或可用性檢查失敗來觸發。設定通知管道 (電子郵件、簡訊、PagerDuty、Pub/Sub、webhooks)。透過時間窗口 (windowing) 與對齊器 (aligners) 來抑制快訊頻繁觸發 (flapping)。
可用性檢查。從多個地區進行探測；對內部端點使用私有可用性檢查，或在 VPC 內執行綜合監控 (synthetics)。

基於日誌的指標

計數器 (Counters) 用於匯總事件發生次數 (例如，計算 /api/alpha/* 請求的數量)。
分佈 (Distributions) 用於擷取延遲或酬載大小。
範例：

undefined

維運分析

若需進行臨時性分析，可透過匯出槽將資料路由到 BigQuery；設計好結構描述 (schema) 並依時間戳記進行資料分割，以控制成本。
在適用情況下，直接使用 Logging 儲存桶中的 Log Analytics 進行匯總，無需匯出資料。
從 CPU、記憶體、佇列深度、Cloud SQL 連線數、Spanner 高優先級 CPU、Pub/Sub 未確認訊息數，以及 Cloud Storage 429/5xx 錯誤率等指標來建構容量信號。

常見陷阱與權衡

過度記錄日誌會增加擷取成本並掩蓋重要信號；應優先考慮取樣與嚴謹的嚴重性分級。
缺少關聯 ID 會阻礙事件分類處理；應確保追蹤 ID 在整個系統中端到端地傳遞。
在經常存取的儲存桶中設定過長的保留期會增加成本；若有長期需求，應將資料匯出至封存或 BigQuery。

追蹤、錯誤與深度診斷

分散式追蹤

追蹤情境。優先使用 W3C trace-context (traceparent, tracestate)。為了與 Cloud Trace 的互通性，請繼續支援 x-cloud-trace-context： x-cloud-trace-context: TRACE_ID/SPAN_ID;o=1
傳播。在服務、訊息佇列和非同步邊界之間轉發追蹤標頭；在進行 RPC 或 SQL 呼叫時，擷取新的子 span。情境遺失會破壞服務拓樸圖，並增加「未知服務」節點。
取樣。在成本和精確度之間取得平衡；在傳入流量上進行動態前端取樣 (head-based sampling)，並對罕見的慢速請求進行後端取樣 (tail-based sampling)，可以提高實用性。

Cloud Trace

提供延遲直方圖、span 瀑布圖和服務拓樸圖。對關鍵的子操作 (如 RPC、資料庫查詢) 使用註解。
使用 p95/p99 追蹤來診斷異常值；注意扇出 (fan-out)、N+1 查詢或鎖競爭 (lock contention) 等問題。
啟用追蹤與日誌的關聯，以便點擊追蹤即可顯示其相關日誌。

Error Reporting

根據每個服務/版本的堆疊簽章自動匯總例外。設定服務情境以避免跨服務的錯誤混淆。抑制吵雜的已知錯誤，或將其導向較低優先級的通知。
從例外訊息中編輯移除個人可識別資訊 (PII)；改為記錄穩定的錯誤碼和關聯 ID。

Cloud Profiler

為支援的執行環境提供低負擔的持續性 CPU/堆疊剖析。比較不同版本和流量水準下的剖析資料，以捕捉效能退化。避免將取樣假象解讀為精確計數。

Cloud Debugger

快照 (Snapshots) 可在不暫停程序的情況下，擷取特定程式碼位置的變數。日誌點 (Logpoints) 可注入暫時性的日誌記錄陳述。限制存取權限、編輯移除敏感變數，並將範圍限定在不含 PII 的表達式。

簡短範例：新增 W3C traceparent 並關聯一筆日誌

HTTP 傳播： traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
用以連結到 Cloud Trace 的日誌欄位： “logging.googleapis.com/trace”: “projects/myproj/traces/4bf92f3577b34da6a3ce929d0e0e4736”

可靠性工程、警報與健康訊號

SLI、SLO、SLA 與錯誤預算

SLI (服務等級指標) 衡量使用者滿意度：可用性、延遲、正確性。應為每個關鍵端點和使用者旅程定義 SLI。
SLO (服務等級目標) 設定目標值，例如：在 30 天內，99.9% 的請求延遲低於 300 毫秒。
錯誤預算 (Error budgets) 量化了可容許的不可靠性。將預算用於發布、實驗或遷移；如果消耗率過高，則凍結變更。
SLA (服務等級協議) 是對外的承諾；應保持 SLO 比 SLA 更嚴格，以保留緩衝空間。

高品質警報設計

盡可能優先採用基於 SLO 和症狀的警報，而非基於原因的警報。
使用多重時間視窗、多重消耗率的警報 (例如，5 分鐘內消耗 14 倍，1 小時內消耗 2 倍)，以捕捉快速和緩慢的預算消耗，同時減少雜訊。
為看門狗 (watchdog) 機制 (例如，長時間執行任務的心跳) 增加指標缺席的警報。
根據嚴重性路由警報；對通知進行速率限制；提供指向操作手冊 (runbook) 和儀表板的連結。

健康檢查與探測 (probe)

就緒探測 (Readiness check) 會在依賴項準備就緒前阻擋流量；存活探測 (liveness check) 會在程序卡死時觸發重啟；啟動探測 (startup probe) 保護啟動緩慢的應用免於過早被重啟。
對於負載平衡的 VM，需允許健康檢查程式的來源 IP 範圍，否則流量將無法到達後端：

undefined

Kubernetes 範例：

undefined

綜合測試。透過 Cloud Scheduler + Cloud Run/Functions 使用正常運行時間檢查和客製化的端到端流程，來驗證登入、付款或其他關鍵路徑。
依賴項監控。追蹤資料庫連線飽和度、RPC 錯誤率、佇列積壓、出口 (egress) 錯誤和第三方 SLI。對於暫時性的 429/5xx 錯誤，應設定帶有截斷式指數退避 (truncated exponential backoff) 的重試機制，並使用冪等性金鑰 (idempotency keys) 以確保安全。

事件應變、具備安全意識的偵錯與根本原因分析

事件應變生命週期

Triage (分類)：依據定義好的管道，對事件進行嚴重性分類、指派事件指揮官，並呼叫 on-call 人員。
圍堵：應用已知的緩解措施與流量控制（例如：回滾、canary、斷路器、速率限制器）。
溝通：維持內部戰情室運作、定期向利害關係人更新進度，並在必要時發布面向使用者的狀態更新。
解決與恢復：透過 SLI 驗證系統健康狀況；避免過早宣布「狀況解除」。
Postmortem (事後檢討)：以無指責的方式分析事件時間軸、偵測缺口、促成因素，並列出包含負責人與截止日期的行動項目。追蹤這些項目直到完成。

Runbook (執行手冊)

包含觸發條件、必要的上下文資訊、診斷指令、安全的緩解措施、回滾步驟以及上報路徑。連結到儀表板、日誌以及針對特定故障模式的劇本 (playbook)。

配額與容量監控

透過 Cloud Monitoring 指標監控服務配額。在用量達到 70–80% 時自動發出警報，並為計畫中的負載測試或產品上線預先申請提高配額。
需追蹤的容量指標：CPU、記憶體、檔案描述符 (file descriptors)、執行緒池 (thread pools)、資料庫連線數、自動擴展器限制以及請求佇列深度。

在不洩漏敏感資訊的情況下進行偵錯

在來源端就對密鑰和 PII (個人可識別資訊) 進行遮蔽；將密鑰集中存放在 Secret Manager 中。對使用者識別碼使用雜湊或權杖化 (tokenization)。在日誌中介軟體中啟用欄位級別的資料遮蔽。
透過 IAM 限制對日誌、追蹤和偵錯工具的存取；在適用情況下使用 CMEK 和 VPC Service Controls。
在 Debugger 中，停用大型物件圖的收集，並新增條件以避免擷取到敏感的堆疊幀 (frames)。

跨層的根本原因分析

執行環境 (Runtime)：透過 Profiler 將 GC、執行緒池或 CPU 的突增，與 Trace 中的 p99 延遲進行關聯分析。
網路：檢查負載平衡器日誌、VPC Flow Logs、防火牆日誌和 Connectivity Tests 來驗證路徑。健康檢查失敗通常是因防火牆規則遺失或連接埠錯誤所致。
IAM：檢閱 Cloud Audit Logs 以查找權限拒絕或策略變更；確認服務帳號的角色與權杖範圍。
資料：使用 Cloud SQL Insights、Spanner 查詢統計、Bigtable CPU 與熱點 tablet，以及 Storage 錯誤率來找出熱點。對於暫時性故障，應採用帶有退避機制的重試，並減少會放大尾部延遲的扇出 (fan-out)。
使用相互關聯的追蹤 ID 和基於日誌的指標將所有資訊串連起來；匯出到 BigQuery 以便在事後分析期間執行多來源的 join 操作。

實務問題情境

Fjord Retail 將其多服務結帳系統遷移至 Google Cloud，使用了 Cloud Run、Cloud SQL、Pub/Sub 以及一個外部的稅務 API。在快閃銷售期間，使用者回報間歇性的逾時和突增的錯誤率，而 on-call 人員收到了充滿雜訊、低信號的警報。

解決方法：

實作帶有追蹤關聯性的結構化日誌

在所有服務間實作 W3C traceparent 傳播，並在所有日誌中包含 logging.googleapis.com/trace。理由：端到端的關聯性讓工程師能從一個緩慢的使用者請求，直接切換到確切緩慢的 RPC 或查詢及其相關日誌。

建立 Logging 儲存桶、保留政策與匯出

將 _Default 儲存桶的保留天數增加到 90 天，並為歐盟的工作負載建立一個區域性儲存桶。為 ERROR 和 WARNING 等級的日誌新增一個匯總接收器到 BigQuery： gcloud logging sinks create bq-prod
bigquery.googleapis.com/projects/fjord/datasets/ops_logs
–log-filter=‘severity>=WARNING’ –include-children 理由：足夠的熱儲存保留時間有助於偵錯；BigQuery 則能在不增加熱儲存成本的情況下，實現快速的事件分析。

定義 SLI/SLO 及基於 SLO 的警報

可用性 SLI：成功請求數 / 總請求數。延遲 SLI：POST /checkout 的 p95 處理時間。
SLO：每月 99.9% 可用性；95% 的結帳請求在 300 毫秒內完成。
設定多視窗的錯誤預算消耗率 (burn-rate) 警報，以及針對結帳心跳指標的指標缺席警報。理由：基於症狀的警報能減少雜訊，並只在真正影響使用者時才發出通知。

設定健康探測與綜合檢查

Cloud Run 服務提供 /ready 和 /healthz 端點。為 /checkout 新增一個全球性的執行時間檢查 (uptime check)，並在 VPC 中新增一個私有的綜合檢查任務，使用測試憑證執行完整的結帳流程。理由：就緒探測 (readiness) 可防止冷後端接收流量；綜合檢查 (synthetics) 能捕捉到端到端的問題和第三方服務的回歸問題。

啟用 Cloud Trace 與 Profiler，並採用帶有退避機制的重試

在適用的地方安裝 Trace/Profiler 代理程式；啟用自動 HTTP 客戶端檢測 (instrumentation) 和 SQL span 註解。為稅務 API 的呼叫實作帶有冪等性金鑰 (idempotency keys) 的截斷指數退避 (truncated exponential backoff)。理由：追蹤功能可以隔離造成延遲的因素；退避機制可以減少 429/5xx 錯誤的放大效應並保護錯誤預算。

監控容量與配額

為 Cloud SQL 連線數、CPU、InnoDB 緩衝池、Pub/Sub 未確認訊息數、Cloud Run 並行處理量以及服務配額使用率，新增儀表板和警報。理由：容量飽和是尾部延遲常見的隱藏原因；及早發出警報可以預防服務中斷。

強化偵錯的隱私保護

使用雜湊處理的使用者 ID，並從錯誤訊息中排除 PII。限制 Debugger 在生產環境中只能使用帶有資料遮蔽規則的日誌點 (logpoints)。理由：在遵循資料最小化原則的同時，維持系統的可觀測性。

建立依賴項監控與斷路器

透過自訂指標追蹤外部稅務 API 的成功率和延遲；當失敗次數超過閾值時，觸發斷路器，改用快取的稅率。理由：隔離第三方依賴項的故障，並維持核心結帳功能的可用性。

準備 Runbook 與上報路徑

文件化步驟：驗證 SLO 儀表板、檢查 Trace 服務地圖中的熱點邊緣 (hot edges)、檢視 Cloud SQL Insights 中的慢查詢、驗證防火牆和健康檢查，以及評估配額餘裕。包含回滾和 canary 程序。理由：一致且快速的回應能降低 MTTR (平均解決時間)，並避免臨時的高風險變更。