故障排除與偵錯策略

雲端故障排除簡介

對於 Professional Cloud Architect 而言，故障排除 (Troubleshooting) 並非憑空「猜測」。這是一個利用雲端平台可觀測性套件所提供的數據進行推導的系統化過程。在分散式的微服務環境中，確定問題「在哪裡」往往與確定問題「是什麼」一樣困難。

本指南概述了識別、隔離和解決 GCP 堆疊問題的結構化方法。

系統化故障排除工作流

1. 定義問題： 預期行為與實際行為有何差異？誰受影響？問題何時開始？
2. 收集證據： 使用 Cloud Logging 和 Cloud Monitoring 查看是否存在錯誤、延遲或資源耗盡的激增。
3. 隔離根本原因 (Root Cause)： 是網路 (VPC)？身分識別 (IAM)？運算資源 (VM/Pod)？還是應用程式碼？
4. 制定並測試假設： 「如果我更改 IAM 角色，403 錯誤會消失嗎？」
5. 實施修復並驗證： 應用更改並監控記錄，確保錯誤率降至零。
6. 事後檢討 (Post-Mortem)： 記錄發生的原因以及如何預防（例如，添加警示或更改架構）。

白話文解釋（Plain English Explanation）

類比 1 — 急診室分流（Severity 與資源路由）

走進急診室，分流護理師會根據病情嚴重程度排序：胸痛優先於扭傷的腳踝。GCP 故障排除完全一樣。Error Reporting 就是分流護理師，依據根本原因將傳入的例外分組，並優先呈現量最大、最新、或成長最快的議題。Cloud Monitoring SLO burn-rate alert 是把待命工程師立刻拉進來的「code blue」廣播，而 log-based metric（搭配 severity>=ERROR 過濾條件）則是病床尾的圖表。沒有這層分流，每個小擦傷與每次心肌梗塞都會落在同一條佇列裡，待命的 SRE 會被最吵但不一定最嚴重的訊號燒乾。

類比 2 — 汽車儀表板（Metrics vs Logs vs Traces）

汽車儀表板一眼能看到 速度、轉速、油量、引擎溫度——這就是 Cloud Monitoring：數值化、即時、以閾值為基礎。當警示燈閃爍（「油壓過低」）時，你會靠邊停車翻 使用手冊與保養紀錄——這就是 Cloud Logging：引擎做了什麼事的文字敘述。如果車子有間歇性抖動，你會插上 OBD-II 診斷儀，記錄試駕期間每一個感測器讀值——這就是 Cloud Trace + Cloud Profiler：每個請求與每個函式級別的粒度。架構師最常犯的錯是只用其中一種儀器：盯著儀表板卻不查手冊，或讀完一萬行 log 卻沒檢查 CPU 是不是已經頂到 100%。

類比 3 — 偵探的案件檔案（根本原因調查）

偵探不會靠看完整座城市的 CCTV 來破案。他們先從 犯罪現場（失敗的端點）出發，訪談 目擊者（kubectl describe pod、gcloud logging read），檢查 鑑識證據（VPC Flow Logs、稽核日誌），並建立 時間軸（依 start time 排序的 Trace span）。嫌疑人名單 是最近一次的變更集——12 分鐘前的部署、一條防火牆規則編輯、一次 IAM 授權。偵探的金科玉律是「跟著證據走，不要跟著直覺走」；架構師的對應版本是「跟著 trace ID 走，不要跟著最吵的儀表板走」。每一次升級到 L3 support 都應該攜帶完整案件檔案：時間戳、request ID、預期與實際行為、以及已經排除的假設。

故障排除的白話類比

類比 1 — 醫生與醫學實驗室（可觀測性工具）

當你感到不舒服時，你會去看 醫生（架構師）。醫生不會只憑直覺猜測。他們會查看你的 生命徵象 (Vitals) (Cloud Monitoring) 以確認是否發燒。他們會查看你的 病史 (Cloud Logging) 以查看你昨天吃了什麼。如果他們需要確切了解血液在血管中的流動情況，他們會開出 X 光或核磁共振 (MRI) 指令 (Cloud Trace)。

類比 2 — 遺失的包裹（追蹤與記錄）

如果你訂購的包裹沒有寄達，你不會只打電話給郵局說「包裹丟了」。你會使用 追蹤號碼 (Tracking Number) (Trace ID)。你會看到它離開了倉庫（服務 A），抵達了分揀中心（服務 B），但從未離開送貨卡車（服務 C）。Cloud Trace 會告訴你微服務鏈中的哪輛「卡車」弄丟了包裹。

類比 3 — 安靜的圖書館 (Error Reporting)

想像一個人們不斷細語的圖書館，但突然有人尖叫。Error Reporting 就像一位圖書管理員，他會忽略那些細語，但會立即記錄下那個人尖叫的內容、他們拿著哪本書以及在哪一頁。它會將類似的「尖叫」分組在一起，以便你知道哪個書架（程式碼）需要先修復。

GCP 可觀測性套件 (Operations Suite)

1. Cloud Logging (歷史學家)

所有記錄的中央儲存庫。

• Log Explorer (記錄總管)： 使用強大的查詢功能，按 resource.type、severity 或特定的 textPayload 進行過濾。
• 記錄型指標 (Log-Based Metrics)： 將重複出現的文字字串（例如 "Out of Memory"）轉換為數字圖表，並據此設置警示。

2. Cloud Monitoring (崗哨)

專注於指標 (CPU、記憶體、延遲、吞吐量)。

• 儀表板 (Dashboards)： 系統健康狀況的視覺化呈現。
• 警示政策 (Alerting Policies)： 當超出閾值時（例如 CPU > 80% 持續 5 分鐘），透過 PagerDuty、電子郵件或 Slack 通知 SRE。

3. Cloud Trace (偵探)

追蹤單個請求在多個服務中移動的路徑。

• 最適合尋找 延遲瓶頸 (Latency Bottlenecks)。如果網頁加載需要 10 秒，Trace 會顯示服務 D 佔用了其中的 9 秒。

4. Cloud Profiler (效能調校師)

在 程式碼層級 分析 CPU 和記憶體消耗。它會告訴你確切的哪個函式或哪行程式碼正在耗盡資源。

常見 GCP 問題與查找位置

架構師工具： 使用 Network Intelligence Center (Connectivity Tests) 來排除 VPC 問題。它可以在你 不 發送實際流量的情況下，告訴你數據包是否被防火牆規則或缺失的路由攔截。 ::

Cloud Logging 過濾語法：快速分流

Logs Explorer 的 Logging Query Language (LQL) 是架構師的第一把手術刀。熟記五種過濾模式，可大幅縮短 MTTD（mean-time-to-detect）：

核心分流過濾條件

• 依名稱鎖定單一資源： resource.type="gce_instance" AND resource.labels.instance_id="1234567890"——只看某台 VM。
• 嚴重性下限： severity>=ERROR——濾掉 INFO/DEBUG 噪音；搭配 timestamp>="2026-05-12T00:00:00Z" 限定時間窗。
• HTTP 錯誤類別： httpRequest.status>=500 AND httpRequest.requestUrl=~"/checkout/.*"——用 regex 鎖定失敗的路徑。
• 稽核日誌鑑識： protoPayload.methodName="storage.objects.delete" AND protoPayload.authenticationInfo.principalEmail="*@external.com"——找出外部身分的刪除操作。
• 以 trace 串聯關聯： trace="projects/my-proj/traces/abc123"——把單一請求在所有服務中的每一行 log 拉出來。

操作模式

• 在 Logs Explorer 釘選查詢，讓待命團隊一進來就看到正確視圖；saved query 勝過 Slack 上的口耳相傳片段。
• 把反覆出現的過濾條件升級為 log-based metric（counter 或 distribution），並在 Cloud Monitoring 上繪圖。OOMKilled 文字爆量？現在它是可設警示的訊號，而非大海撈針。
• 使用 logName="projects/PROJECT/logs/cloudaudit.googleapis.com%2Factivity" 來只看 Admin Activity 稽核日誌——這類日誌免費且永遠開啟；Data Access 日誌要付費，且必須逐服務啟用。
• 為了控制擷取成本，在 _Default sink 設定 exclusion filter：resource.type="k8s_container" AND severity<WARNING——但 絕不要 排除 cloudaudit.googleapis.com，否則會失去鑑識證據。

Cloud Trace span 分析：延遲鑑識

當一個請求耗時 8 秒而非 200ms 時，Cloud Trace 會重建跨服務的瀑布圖。每個請求是一個 trace；每段工作（HTTP 呼叫、RPC、DB query）是一個 span。架構師會從 trace 讀三種訊號：

Span 要看什麼

1. Span 持續時間 vs 父 span 持續時間——若子 span 在 8 秒的父 span 中佔 7.9 秒，瓶頸在父 span 下游。若許多小 child 加總成 8 秒，你遇到的是 N+1 query 症候群。
2. Span attribute——http.status_code、http.method、db.statement、peer.service。同一個 trace 裡 db.statement="SELECT ..." 重複 500 次，就是 ORM lazy-load 的氣味。
3. Span 之間的時間缺口——沒有 instrumented 工作的空檔，通常代表 未取樣的 middleware、GC pause，或 冷啟動（例如 Cloud Run 實例 cold start）。

取樣與 context 傳遞

• Trace 預設取樣率是 0.1 request/sec 每個 instrumented 服務，以控制成本。高 QPS 服務可用 OPENTELEMETRY_TRACES_SAMPLER_ARG=0.05（5%）覆寫。
• Context 傳遞 使用 W3C traceparent header（或舊版 X-Cloud-Trace-Context）。瀑布圖中某個服務消失，幾乎一定是該服務的 HTTP client 沒 轉發 header——這通常是一行程式碼的 bug。
• 對服務執行 Trace Insights（自動產生的延遲分析）：它會自動標記 p99 相對 baseline 的退化，不需你手動設閾值。

何時 Trace 不是對的工具

如果請求根本沒到你的服務（DNS 失敗、GFE 攔阻、防火牆 drop），就不會有 span。改用 VPC Flow Logs + Connectivity Tests。Trace 處理的是程序內與跨服務延遲，不是「封包根本沒抵達」。

Cloud Profiler：CPU 與記憶體熱點

Cloud Profiler 是統計型、持續性、低開銷（約 1% CPU）的工具。Trace 告訴你哪個服務慢，Profiler 則告訴你 哪一行程式碼 在燒 CPU 週期。支援 Go、Java、Node.js、Python、.NET，可用於 GCE、GKE、Cloud Run、App Engine。

Profile 類型

• CPU time——wall-clock 對比 on-CPU。某函式 CPU time 2 秒、wall time 8 秒，代表它在 等 I/O，不是在算數。
• Heap / Heap allocation——找出記憶體洩漏與大量短生命期 allocation（GC 壓力）。
• Contention（Java/Go）——鎖競爭熱點；經典凶手是被當成 global bottleneck 的 synchronized map。
• Threads（Java）——thread pool starvation。

看 flame graph

• 寬度 = sample count = 花在該處的時間／allocation。 頂端寬寬的 leaf 就是熱點。
• 用 diff view 比較兩段時間範圍（部署前後）。部署後新出現的寬 stack 是退化候選。
• 用 deployment label 過濾（version=v123）以在同一張圖中比較 canary 與 stable。

Network Intelligence Center：Connectivity Tests 與 Performance Dashboard

Network Intelligence Center (NIC) 是架構師的網路作戰室。故障排除常用的四個子模組：

Connectivity Tests（殺手級功能）

Connectivity Tests 執行 靜態組態分析——它會走 VPC 圖（路由、防火牆規則、peering、Cloud NAT、混合雲 VPN/Interconnect），告訴你從 source=VM-A 到 destination=10.20.30.40:443 的封包 是否會 被送達。沒有實際送出任何流量。輸出是逐步軌跡：「比對到 route X、評估到 firewall rule Y（allow）、從 Cloud NAT Z 出去」。若封包會被 drop，NIC 會指出確切的規則或缺失的路由。

使用時機：

• 每次防火牆變更後執行（可作 Terraform 部署後檢查）。
• 透過 Cloud VPN／Interconnect 偵錯 on-prem 到 GCP 流量——NIC 理解 BGP 路由與 Cloud Router 交換。
• Private Google Access／Private Service Connect 偵錯——它知道哪些子網開啟了 PGA。

Performance Dashboard

顯示 GCP zone／region 之間、以及你的專案到 internet 的 packet loss 與 median RTT——免去自行部署 iperf VM。

Firewall Insights

依過去 60 天的命中數，標記 shadowed rule（高優先序規則遮住低優先序規則）、過度寬鬆規則（22 port 開放 0.0.0.0/0）、與 未使用的規則。

Network Topology

VM 之間流量的視覺化圖——適合用來偵測某個服務意外地在和外部 IP 互傳（資料外洩線索）。

Error Reporting：以根本原因為先的分組

Error Reporting 會自動依 stack trace 指紋去重（具語言感知能力：忽略行號、依函式呼叫鏈分組）。一次真實的客戶情境就算被 50,000 名使用者觸發，也只會產生一個 Error Reporting group。

分流工作流

1. 依 「最近一小時發生次數」 排序，找出正在延燒的火。
2. 依 「First seen」 排序，找出今天部署引入的退化。
3. 依 「受影響使用者數」 排序，把對客戶的衝擊優先於吵雜的 bot。
4. 點進 group →查看 resolved 狀態（open／acknowledged／resolved／muted）、指派工程師、以及連結的 Cloud Logging 條目。

與待命系統整合

• 對 log-based metric error_reporting.googleapis.com/error_count 設 Cloud Monitoring 警示（依服務過濾）。新 error group 爆量 → PagerDuty 通知。
• resolved 後再復發 是自動偵測：若你把 group 標為 resolved 後再次發生，Error Reporting 會自動 reopen，並可再次通知待命。可抓出未徹底修復的問題。
• 對已知第三方噪音（例如爬蟲觸發 404）使用 mute，而非 resolve。

GKE Pod 偵錯：kubectl 作戰手冊

Pod 故障時，依下列順序執行命令。每一步回答一個特定問題：

Step 1 — Pod 健康嗎？

kubectl get pod <pod> -n <ns> -o wide
# READY 0/1, STATUS CrashLoopBackOff, RESTARTS 17 → 應用程式 crash loop
# STATUS Pending → 排程不到節點；看 events
# STATUS ImagePullBackOff → registry／認證問題

Step 2 — 為什麼會這樣？

kubectl describe pod <pod> -n <ns>

讀最底下的 Events 區。重點看：

• FailedScheduling: 0/3 nodes are available: insufficient cpu → 擴增 node pool、降低 request、或啟用 autoscaling。
• Liveness probe failed: HTTP probe failed with statuscode: 503 → probe 路徑錯誤或應用程式啟動太慢。
• OOMKilled（exit code 137）→ 提高 memory limit 或修記憶體洩漏（用 Cloud Profiler heap 模式）。

Step 3 — 應用程式實際印了什麼？

kubectl logs <pod> -c <container> --previous   # 上一次崩潰的 container 日誌
kubectl logs -f <pod> --tail=200               # 即時串流

多容器 Pod 一定要加 -c。--previous 對 CrashLoopBackOff 至關重要——不加的話你只看到下一次啟動的開頭，看不到上一次失敗的尾巴。

Step 4 — 進入跑著但行為異常的 container

kubectl exec -it <pod> -- /bin/sh

若映像檔是 distroless（沒有 shell），用 ephemeral debug container：

kubectl debug -it <pod> --image=busybox:1.36 --target=<container>

它會附掛一個 sidecar，擁有完整 network/PID namespace 存取權，不必重新建構映像檔。GKE 1.23+ 原生支援。

Step 5 — 切到 Cloud Logging

Logs Explorer 查詢：resource.type="k8s_container" AND resource.labels.pod_name="<pod>" AND severity>=WARNING。Pod 消失後日誌仍然保留——kubectl logs 不會。

VPC Flow Logs 分析：網路鑑識

VPC Flow Logs 會以取樣方式記錄子網流量 metadata（5-tuple + bytes + RTT + action）。這是被嚴重低估、最有用的安全與連線事後檢討工具。

聰明地啟用

• 按子網啟用，不要整個 VPC；flow log 成本與流量成正比。
• 調整 彙整間隔（預設 5 秒）與 取樣率（預設 0.5 = 50%）。低流量子網拉到 1.0；話多的子網降到 0.1。
• 啟用 metadata field（src_instance、dest_instance、geo_country），不必再做 IP-to-resource 對照就能分析。

鑑識查詢（BigQuery sink）

透過 Log Router 把 flow log 匯出到 BigQuery，做 SQL 分析：

-- 過去一小時對外流量排名
SELECT jsonPayload.connection.dest_ip, SUM(CAST(jsonPayload.bytes_sent AS INT64)) AS bytes
FROM `proj.flow_logs.compute_googleapis_com_vpc_flows_*`
WHERE jsonPayload.reporter = "SRC"
  AND jsonPayload.dest_location.country NOT IN ("us", "tw")
  AND timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR)
GROUP BY 1 ORDER BY bytes DESC LIMIT 20;

數分鐘內就能浮出 資料外洩候選。搭配 Firewall Rules Logging（獨立功能）可確認每條 flow 被哪條規則 allow／deny。

Flow Logs 做不到的事

它會取樣。單一被 drop 的封包不一定會出現。要確定性答案，請改用 Connectivity Tests（組態分析）或 Packet Mirroring（完整 PCAP 鏡像到分析 VM）。

稽核日誌鑑識：Admin Activity、Data Access、System Event

GCP Cloud Audit Logs 回答「誰在何時從何處做了什麼」。四個資料流：

• Admin Activity——永遠開啟、免費、保存 400 天。捕捉 setIamPolicy、create、delete、update 等資源操作。「誰刪了 bucket」第一個看這。
• Data Access——預設關閉（BigQuery DATA_READ 例外）。記錄 get、list、read 操作。對含 PII 的服務啟用；預期日誌量會大幅成長。
• System Event——Google 發起的動作（live migration、自動實例恢復）。用來解釋「為什麼 VM 自己重開」。
• Policy Denied——只在組織政策拒絕 API 呼叫時記錄。診斷「為什麼 Terraform 建不出這個資源」。

調查模式

protoPayload.authenticationInfo.principalEmail 回答 誰。protoPayload.methodName 回答 做了什麼。protoPayload.requestMetadata.callerIp 回答 從何處。protoPayload.authorizationInfo[].granted 回答 是否獲得授權。

懷疑安全事件時，第一時間把關鍵稽核日誌透過 Logging sink 匯出到 另一個權限隔離的專案，避免擁有專案層管理權的攻擊者刪掉證據。

Recommender API：主動暴露隱藏議題

Recommender API 是雲端版的季度健檢——它分析使用模式，並在安全、成本、效能、可管理性、可靠性五個維度發出 insight + recommendation。只在事件中才查 Recommender 的架構師，錯過了它真正的價值。

高訊號的 recommender

• google.iam.policy.Recommender——IAM 角色精簡：依過去 90 天實際 API 使用紀錄，把過於寬鬆的角色替換成最小權限的自訂角色。
• google.compute.instance.IdleResourceRecommender——標記 CPU 連續數週 <3% 的 VM；經典的成本回收。
• google.compute.disk.IdleResourceRecommender——靜悄悄被計費的未掛載 persistent disk。
• google.compute.firewall.Recommender——shadowed 與過度寬鬆的防火牆規則（與 Firewall Insights 重疊）。
• google.cloudsql.instance.OutOfDiskRecommender——在資料庫 hang 之前預測 Cloud SQL disk 即將耗盡。
• google.gke.cluster.Recommender——GKE 升級、版本錯位警示、叢集內已棄用的 API。

與營運整合

• 用 gcloud recommender recommendations list --recommender=google.iam.policy.Recommender --location=global 抓取建議，餵進每週工程審查。
• 設定 Active Assist alert，讓高優先級的新建議透過電子郵件或 Pub/Sub 發布出去。
• 把 Security Command Center 的 Security Health Analytics 視為平行的資料流——SCC 加 Recommender 兩條線同跑，多數隱藏的組態錯誤不必人工稽核就會浮現。

Support Case 升級：選對等級

GCP support 等級（Basic、Standard、Enhanced、Premium）差別在回應 SLO、溝通管道、與 TAM（Technical Account Manager）的可用性。架構師必須知道何時、如何升級，才能拉對等級的支援進來。

Case 優先級與回應目標（Premium）

• P1——關鍵衝擊、服務不可用：15 分鐘回應、24/7。只保留給沒有 workaround 的正式環境停機。
• P2——高度衝擊、降級：1 小時回應、24/7。
• P3——中度衝擊：4 個工作小時。
• P4——低度衝擊／一般問題：8 個工作小時。

寫一份好 case

在 case 內文（不是後續留言）就提供：

1. Project ID、region/zone、resource 名稱。
2. 以 UTC 表示的精確時間戳，並標明時區。
3. Request ID／Trace ID／Operation ID——Google support 只能用這些 ID 拉內部日誌。
4. 你已經排除哪些可能——IAM、quota、最近變更。讓 L1 不必重做你做過的事。
5. 業務衝擊——「checkout 對 100% 的歐洲使用者失效」才證成 P1 升級。

升級路徑

• 在 case 內升級：明確要求把 P 等級往上調，若衝擊已擴大。
• TAM（僅 Premium）：故障時直接通知 TAM——他們會 fast-track 到產品團隊並負責內部協調。
• Customer Care Manager 處理計費／合約議題。
• Google Cloud status dashboard（status.cloud.google.com）——花幾小時偵錯自己程式之前，先確認區域性事件是否已公告。

FAQ — 故障排除策略

Q1. 記錄 (Log) 和指標 (Metric) 有什麼區別？

記錄 (Log) 是特定事件的紀錄（「使用者 X 已登錄」）。指標 (Metric) 是隨時間變化的數值測量（「現在有 500 名使用者登錄」）。記錄用於分析「為什麼」，指標用於分析「是什麼」。

Q2. 如何排除不斷重啟的 GKE Pod (CrashLoopBackOff)？

1. 檢查 kubectl describe pod 以查看退出代碼。
2. 使用針對該特定 Pod 名稱的過濾器檢查 Cloud Logging，查看應用程式在崩潰前的 stderr/stdout 記錄。
3. 檢查 Error Reporting 以查看是否拋出了特定的異常。

Q3. 為什麼我在記錄總管中看不到任何記錄？

檢查三件事：

1. 服務是否具有 logging.logWriter 角色？
2. 你查看的時間範圍是否正確？
3. Log Router 中是否有 排除過濾器 (Exclusion Filter) 為了節省費用而丟棄了記錄？

Q4. 什麼時候應該使用 Cloud Trace 而不是 Cloud Logging？

當你在多個微服務之間遇到效能問題時，請使用 Cloud Trace。當你在單個服務中遇到特定的錯誤或崩潰時，請使用 Cloud Logging。

Q5. 什麼是 "VPC Flow Logs"？

它們記錄流經 VPC 的所有網路流量樣本（IP、連接埠、位元組）。它們對於排除「誰在與誰通訊」以及識別未經授權的網路嘗試至關重要。

架構師最終提示

在 PCA 考試中，如果問題與「延遲」有關，答案通常是 Cloud Trace。如果與「資源使用/警示」有關，請尋找 Cloud Monitoring。對於「稽核/安全/錯誤詳情」，請使用 Cloud Logging。始終優先選擇最 精確的工具（例如，使用 Connectivity Tests 處理網路問題），而不是僅僅「查看所有記錄」。