Google PCA: 維運、可觀測性與平台自動化 — 學習指南

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

總覽

Google Cloud 上的維運、可觀測性與平台自動化，旨在確保服務具備可診斷性、可維護性，並能持續改進，同時控管安全與成本。一個具凝聚力的設計涵蓋了記錄、指標、追蹤、可稽核性、Runbook、事件應變、配額與容量治理，以及自動化。其目標是提供與服務水準目標 (service-level objectives) 掛鉤、可據以行動且低雜訊的信號，並結合可確定性的自動化來減少瑣務 (toil) 與組態漂移 (configuration drift)。

記錄與可稽核性

Cloud Logging 集中管理來自 Google Cloud 服務、GKE 和 VM 的記錄。建議優先採用結構化記錄 (JSON)，並為 request_id、user_id、service、version、latency_ms 和 severity 等欄位使用一致的鍵值；結構化資料有助於精確查詢、建立基於記錄的指標，以及進行政策評估。在 VM 和 GKE 節點上，安裝 Ops Agent (建議選項) 或舊版 logging agent 來收集系統和應用程式記錄；請確保剖析器 (parser) 能為您的框架產出 JSON 格式。

• 記錄儲存桶與保留期：使用區域級的記錄儲存桶 (log buckets) 以符合資料落地 (data residency) 需求及使用 CMEK。預設的儲存桶包含 _Default 和 _Required；後者用於儲存管理員活動 (Admin Activity)、系統事件 (System Event) 和政策遭拒 (Policy Denied) 的稽核記錄，並具有固定的長期保留期。為不同資料類別 (例如：應用程式、安全性、分析) 建立專屬的儲存桶，並設定客製化的保留期和 CMEK。較長的保留期有助於鑑識分析，但會增加成本；當不需要在 Logging 中保留時，可匯出以進行長期封存。

• 記錄接收器與匯出：使用 Log Router 透過接收器 (sinks) 將記錄路由至 BigQuery (用於分析)、Pub/Sub (用於 SIEM 或 pipeline)，以及 Cloud Storage (用於封存)。使用 BigQuery 的分區資料表 (partitioned tables) 來管理資料量和成本。務必授予接收器服務帳號對目標位置的最小權限寫入存取權，以避免發生無聲的失敗。避免將已匯出的記錄重新擷取回 Logging，以免造成路由迴圈。

• 查詢與基於記錄的指標：使用 Logs Explorer，並透過 logName、resource.type、severity、labels 和 jsonPayload 欄位進行篩選。為錯誤率 SLI 和延遲直方圖衍生出基於記錄的指標 (計數器或分佈)，以支援快訊功能。透過將高變異性欄位正規化，來控制基數 (cardinality)。

• Cloud Audit Logs：管理員活動 (Admin Activity，控制層面的寫入)、資料存取 (Data Access，使用者資料的讀寫)、系統事件 (System Event) 和政策遭拒 (Policy Denied) 等記錄提供了管理上的可觀測性。資料存取記錄的量非常大，因此在許多服務中預設為停用；僅在需要時啟用，並將其路由至具有適當保留期和 CMEK 的儲存桶。政策遭拒記錄有助於及早偵測權限和機構政策 (org policy) 的違規行為。確保保管職責分離：通常由安全團隊擁有並存取稽核記錄，其他團隊則僅有受限的檢視權限。

• 故障模式與取捨：

  • 過於寬鬆的接收器會導致 BigQuery 成本暴增；請精確篩選並設定分區的到期時間。
  • 高基數的 JSON 欄位 (例如：完整的 URL) 會降低查詢效能；應進行清理並提取正規化的標籤。
  • 保留期不足會影響調查；可透過匯出至 GCS 或 BigQuery 來緩解此問題。
  • Agent 遺失或剖析器設定錯誤會導致記錄無聲地遺失；應針對 Agent 的心跳和擷取錯誤設定快訊。

範例：建立一個具備自訂保留期的區域級記錄儲存桶，並匯出一個經過篩選的稽核接收器。

undefined

undefined

監控、追蹤與應用程式診斷

Cloud Monitoring 收集系統和應用程式指標，並支援儀表板、快訊、可用性檢查、通知管道和服務水準目標。

• 指標與儀表板：使用 Google 服務的內建指標，或透過 Cloud Monitoring API 或 OpenTelemetry 建立自訂指標。著重於四大黃金信號：延遲 (latency)、流量 (traffic)、錯誤 (errors)、飽和度 (saturation)。審慎地使用標籤；避免使用無邊界值的標籤。使用 Metrics Scope 來匯總多專案的視圖。在需要時，使用 MQL 進行更具表達力的查詢。

• 快訊與通知管道：為 SLO 實作多時間窗、多燃燒率 (multi-burn-rate) 的快訊，以在快速偵測和降低雜訊之間取得平衡。定義通知管道 (電子郵件、簡訊、Pub/Sub、webhook、第三方事件工具)，並在快訊文件中包含 Runbook 連結和相關情境說明。使用通知速率限制和事件自動關閉功能，以防止快訊風暴。

• 可用性檢查：從多個地區對關鍵端點進行探測，並包含 TLS 驗證、DNS 和內容比對。將可用性檢查與快訊和服務 SLO 掛鉤。請記住，可用性檢查無法驗證內部依賴項；需透過綜合交易 (synthetic transactions) 和內部健康檢查來補足。

• SLO 與 SLI：為可用性、延遲和正確性定義 SLI。在 Cloud Monitoring 的 Service Monitoring 中設定 SLO 並追蹤錯誤預算 (error budget)。應針對預算消耗而非原始錯誤數發出快訊，以使其與客戶影響保持一致。使用發布閘門 (release gates) 或漸進式交付 (progressive delivery) 來確保不超出剩餘的錯誤預算。

• Cloud Trace、Error Reporting、Profiler：使用 OpenTelemetry 進行跨服務的分散式追蹤，並用請求和依賴項的中繼資料來註釋 span。根據不同服務和路徑動態調整取樣率，以確保涵蓋關鍵流程，同時控制成本。Error Reporting 會自動匯總來自記錄的例外錯誤，根據堆疊追蹤 (stack trace) 進行去重，並觸發通知。Profiler 以低額外負擔的方式，在生產環境中提供持續的 CPU、堆積 (heap) 和牆上時間 (wall-time) 的剖析；可用它來消除熱點路徑 (hot paths) 並降低成本。

• 故障模式與取捨：

  • 過高的指標基數會增加成本並拖慢查詢速度；應在發送前進行匯總。
  • 過低的追蹤取樣率會隱藏長尾延遲 (tail latency) 問題；應對慢速路徑採用更高的取樣率。
  • 不恰當的 SLO (例如：過於嚴格) 會導致快訊疲勞；應根據真實流量數據進行迭代調整。
  • 可用性檢查可能通過，但內部依賴項卻已失敗；應使用能感知依賴關係的 SLO。

平台維運、Runbook 與事件管理

嚴謹的維運紀律能縮短偵測、緩解與學習的平均時間。

• Runbook 與上報機制：每個警報都必須連結到一個確定性的 runbook，其中包含先決條件、診斷步驟、回滾程序與溝通範本。定義清楚的 on-call 輪值與上報政策。將 runbook 儲存在版本控制中並進行測試。

• 事件管理與事後檢討 (postmortem)：使用標準化的嚴重性等級、角色（事件指揮官、溝通、維運、主題專家 SME）與溝通管道。偏好使用 ChatOps 與狀態頁面進行廣播。撰寫無指責文化的事後檢討，記錄時間軸、促成因素、偵測缺口、客戶影響，以及與負責人和日期綁定的具體後續行動。

• 配額管理與容量信號：透過對使用率設定警報來監控 Service Usage 與 serviceruntime 配額指標。主動申請提高配額，並將自動擴展的限制與配額對齊。使用容量信號，例如 CPU、記憶體、檔案描述符、連線池與佇列深度。對於 GKE，調整 HPA/VPA 與叢集自動擴展器 (cluster autoscaler)；對於 GCE MIGs，在適當情況下設定冷卻時間 (cool-down) 與預測性自動擴展。

• 服務健康狀況與故障排除：結合 Logs Explorer 的即時追蹤 (live tail)、基於日誌的指標、儀表板與 Trace 來縮短 MTTD。啟用 VPC Flow Logs 與 Firewall Rules Logging 進行網路分類 triage；使用 VM 序列控制台 (serial console) 來處理啟動失敗。將封包擷取 (packet capture) 與核心追蹤 (kernel tracing) 作為 runbook 中的緊急應變程序 (break-glass procedures)。

• 故障模式：

  • 配額耗盡看起來就像服務中斷；在用量達到 80% 時發出警報，並對上游進行速率限制。
  • 沒有預熱 (prewarming) 的自動擴展會導致冷啟動；為關鍵路徑使用最小副本數。
  • 缺乏綜合性檢查 (synthetic checks) 會掩蓋客戶可見的故障；應實作金絲雀交易 (canary transactions)。

自動化、資源盤點、政策與偏移

以最低權限和冪等性 (idempotency) 自動化可重複的任務。

• 工具：使用 Cloud Shell 進行安全、短暫的管理工作，其 $HOME 目錄具備持續性；將輔助的二進位檔放在 ~/bin 中，以維持 PATH 的持續性。使用 gcloud、REST API 和用戶端函式庫進行自動化。使用服務帳號和 Workload Identity 來消除長期存在的金鑰。

• 排程器與協調器：使用 Cloud Scheduler 根據 cron 排程觸發 HTTP 和 Pub/Sub 工作。使用 Workflows 來協調多服務的自動化，並包含重試、退避 (backoff)、補償和逾時機制。確保冪等性，並在日誌中加入關聯 ID。

• 日常自動化範例：

  • 每日將資產匯出至 GCS 和 BigQuery，以進行盤點和偏移報告。
  • 自動計算 SLO 燃盡率 (burn-rate) 並發布到儀表板。
  • 定期評估組織政策和 IAM 異常情況。

• 資源盤點與政策評估：Cloud Asset Inventory 提供資源、IAM 繫結和組織政策的時間點快照及即時變更摘要 (feed)。匯出到 BigQuery 進行歷史分析和偏移偵測；訂閱 Pub/Sub 以近乎即時地分類處理政策違規事件。使用 Policy Analyzer 和 Recommender 偵測過於寬鬆的 IAM 和未使用的權限。使用 Organization Policy 強制執行約束，並在部署前透過 policy-as-code 驗證組態。

• 組態偏移：透過宣告式 IaC 和持續驗證來防止偏移。偵測到偏移時，可自動協調或隔離資源。為資源加上來源標籤 (例如 deployment_id)，以區分受管理和臨時建立的資源。

• 安全性、可靠性與成本的可觀測性架構：

  • 安全性：將稽核日誌路由到受 CMEK 保護且存取受限的儲存桶；匯出到專用的安全專案。透過 Pub/Sub 整合 SIEM。
  • 可靠性：根據 SLI 和追蹤資料來驅動儀表板和警示；使用 Workflows 演練事件自動化處理流程。
  • 成本：控制指標的基數 (cardinality)，調整各儲存桶的日誌保留時間，對 BigQuery 匯出資料進行分割，並使用 Profiler 優化熱門路徑 (hot path)。

範例：排程每日資產匯出並執行一個 workflow。

undefined

undefined

實際問題情境

Contoso Commerce 正在推出一個基於 GKE 的多區域結帳平台。需求包括：可稽核的管理、由 SLO 驅動且雜訊最少的警示、端到端的請求追蹤、自動化的夜間合規盤點，以及嚴格的成本控制。

方法：

1. 建立日誌記錄與稽核基礎

• 為應用程式、安全性和分析日誌建立具備 CMEK 的區域性日誌儲存桶；依需求設定應用程式日誌保留 30 天，安全性日誌保留 400 天以上。將 Admin Activity、System Event 和 Policy Denied 日誌路由到安全性儲存桶；僅為支付服務啟用 Data Access 日誌。
• 理由：按敏感度隔離可縮小爆炸半徑並降低成本；CMEK 符合合規要求；限定 Data Access 的範圍可避免流量遽增。

2. 實作結構化的應用程式日誌記錄與收集

• 在 GKE 節點上部署 Ops Agent，並使用 sidecar/daemonset 收集器，將應用程式日誌以結構化 JSON 格式傳送，其中包含關聯 ID (trace_id, span_id) 以及已針對 PII 進行清理的使用者/工作階段標籤。
• 理由：結構化日誌能實現精確查詢、基於日誌的指標，並與追蹤資料進行關聯；關聯 ID 則支援分散式診斷。

3. 部署分散式追蹤、錯誤匯總與效能剖析

• 使用 OpenTelemetry SDK 來檢測微服務，並將資料匯出到 Cloud Trace；為結帳和支付路徑設定較高的取樣率。為所有執行環境啟用 Error Reporting，並為 CPU/記憶體關鍵服務啟用 Profiler。
• 理由：追蹤能按服務躍點定位延遲；Error Reporting 將堆疊追蹤分組以加速分類處理；Profiler 可降低運算成本和尾部延遲 (tail latency)。

4. 定義 SLI/SLO 並設定警示與儀表板

• 定義 SLI：p90 和 p99 的結帳延遲、結帳 API 的可用性，以及支付成功率。設定 SLO (例如：99.9% 的可用性，p99 延遲低於 800 毫秒)。設定燃盡率警示 (1 小時內 2% 和 6 小時內 1%)，並附上應變手冊連結和 PagerDuty 通道；建立儀表板以顯示黃金指標和錯誤預算趨勢。
• 理由：錯誤預算警示與客戶影響掛鉤，可減少雜訊；儀表板則提供營運的態勢感知。

5. 新增外部與內部健康狀態檢查

• 為結帳端點設定多區域的正常執行時間檢查，並包含內容驗證；為購物車到支付的流程新增綜合交易檢查。整合 GCLB 和 GKE 的整備度探測 (readiness probe)。
• 理由：正常執行時間檢查可驗證面向客戶的可用性；綜合流程可偵測依賴項的故障。

6. 自動化盤點、政策監控與偏移偵測

• 建立一個安全性專案，以接收匯出至 GCS 和 BigQuery 的 Cloud Asset Inventory 資料；為 IAM 和組織政策變更啟用即時的 Pub/Sub 摘要。每晚執行 Workflows，將期望狀態的清單檔與當前資產進行比較；針對低風險的偏移建立工單或自動協調。
• 理由：集中式盤點支援稽核；持續的政策評估可防止權限蠕變 (privilege creep)；自動化則能抑制偏移。

7. 治理配額與容量

• 監控運算、負載平衡器和 API 的配額，並在使用率達到 70% 和 85% 時發出警示。針對目標負載預先申請更高的配額；將 GKE 叢集自動擴展器和 HPA 的限制與配額對齊。對於啟動緩慢、基於 MIG 的服務，啟用預測性自動擴展。
• 理由：配額上限可能偽裝成服務中斷；主動調整和對齊的自動擴展可防止在尖峰時段發生節流。

8. 優化可觀測性的成本

• 按儲存桶限制日誌保留時間，透過 Log Router 過濾器在生產環境中排除詳細的偵錯日誌，並僅將必要欄位匯出到 BigQuery，同時設定分割區到期時間。限制指標標籤的基數；利用 Profiler 的發現來縮減熱門服務的規模。
• 理由：可觀測性應具成本效益；針對性的保留和匯出可防止支出失控。

9. 準備應變手冊與事件演練

• 為每個警示政策編寫版本化的應變手冊，內容包括診斷查詢、追蹤過濾器、回滾指令和通訊方式。執行 Game Day 來驗證升級流程和自動化機制。
• 理由：確定性且經過演練的回應可降低 MTTR 並提高可靠性。

10. 驗證與迭代

• 根據實際流量持續檢視警示雜訊、調整閾值並優化 SLO。追蹤事後檢討的行動項目，確保有負責人和截止日期並完成。
• 理由：透過可衡量的回饋來改善可觀測性和營運，從而減少瑣碎工作 (toil) 並隨著時間提高服務品質。

← 遷移、現代化與混合雲策略 · 所有領域 · DevOps、交付工程與基礎設施即程式碼 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Google →