Google PCNE: 網路可觀測性、可靠性與疑難排解 — 學習指南

By Laurynas Brazys · 23 August 2026 · #google #PCNE #certification #exam-prep #study-guide

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

總覽

Google Cloud 上的網路可觀測性，是指有系統地收集、關聯與分析網路訊號，用以描述跨 VPC、負載平衡器、混合式連線及服務的連通性、效能與正確性。可靠性源於為故障偵測與安全修復而設計：首先要部署一流的遙測機制、在接觸資料層前先驗證控制層、僅在必要時才用封包證據深入追查，並將回滾自動化。本節將說明如何使用 Google Cloud 的工具與模式來偵測、診斷及預防問題，同時在變更期間將風險降至最低。

Flow Logs、Logging、Monitoring、指標與 SLO

VPC Flow Logs 在 VPC 防火牆評估後，於 VM 網路卡層級提供取樣、彙總的遙測資料。它們並非完整的封包擷取，也無法取代防火牆規則記錄來作為明確的允許/拒絕證據。主要控制項：

• 取樣率：0.0–1.0。較高的取樣率能提升逼真度，但會增加記錄量與潛在成本。
• 彙總間隔：5 秒–30 分鐘。較短的間隔能縮短偵測時間，但會增加項目數量。
• 中繼資料：包含或排除執行個體與 VPC 的中繼資料。包含可進行更豐富的分析，排除則可限制敏感屬性。

在子網路上啟用的一般作法：

undefined

使用記錄匯出功能，以便進行持久性分析與跨專案共用：

• BigQuery 用於 SQL 分析與長期趨勢分析。
• Pub/Sub 用於傳送至 SIEM/IDS 的近乎即時的管道。
• Cloud Storage 用於封存。

• 匯出至 BigQuery 的範例：

undefined

防火牆規則記錄透過記錄允許/拒絕的決策及匹配的規則，來輔助 flow logs。若要觀測被封鎖的流量，請在您的規則集底部附近新增一條啟用記錄功能的「全部拒絕」規則：

undefined

Cloud Logging 允許結構化查詢，並能與請求記錄、健康狀態檢查記錄、NAT 記錄及負載平衡器記錄進行關聯。為以下這類訊號建立基於記錄的指標：

• 連到後端標籤的被拒絕連線突然增加（可能是允許清單設定錯誤）。
• 到某個通訊埠的大量 SYN 重傳（可能是飽和或黑洞）。
• NAT「無可用通訊埠」事件（Cloud NAT 資源耗盡）。

Cloud Monitoring 會彙總指標，並提供資訊主頁、快訊及 SLO：

• 需關注的指標：負載平衡器 5xx 錯誤率、後端延遲、執行個體網路卡的位元組/封包數、Cloud NAT 已分配/已使用/溢位的通訊埠、Cloud Router BGP 會話狀態、VPN 通道封包捨棄、Interconnect 線路使用率、封包遺失與延遲。
• 資訊主頁：為每個服務與每種連線建立資訊主頁，並在各專案間共用範本以維持操作一致性。
• 快訊：優先採用具有快速回饋的症狀快訊（錯誤率、延遲、捨棄計數器），並在可能影響使用者時，採用會觸發呼叫通知的原因快訊（BGP 波動、線路中斷）。
• SLO：定義以使用者為中心的 SLO（例如，全球 HTTP 成功率與延遲），並使用耗用率快訊來識別快速與緩慢耗用。透過基於記錄的指標，將請求記錄作為分子/分母，以進行精確的 SLO 評估。

權衡取捨與故障模式：

• 低取樣率或長彙總間隔會隱藏微叢發與短暫的故障。
• Flow logs 無法看到防火牆前的封包捨棄；需依賴防火牆規則記錄來取得拒絕的證據。
• 未經篩選的過度記錄會增加成本並可能拖慢調查速度；應聰明地匯出與分割資料。

Network Intelligence Center 與進階診斷

Network Intelligence Center (NIC) 提供主動式與結構化的診斷功能：

Connectivity Tests：

• 驗證跨越路由、防火牆規則（包含階層式政策）、服務帳戶/標籤、負載平衡器、Cloud NAT 及混合式連線的控制層連通性。
• 路由診斷會計算所選的下一個躍點，並回報設定錯誤，例如遺失路由或非對稱路徑。
• 在任何網路變更前後使用，以偵測非預期的影響範圍。它模擬控制層，但不保證資料層的品質；需與封包/指標證據搭配使用。

Performance Dashboard：

• 一個由 Google 管理的視圖，顯示跨區域及到網際網路觀測點的封包遺失與延遲。有助於偵測宏觀事件（區域性或路徑範圍的壅塞）與服務本地問題的區別。

Network Topology：

• 將跨專案、跨 VPC 及混合式連線與流量（利用記錄）視覺化，以識別熱點、非預期的對等互連路徑，以及您可能不樂見的傳遞性行為。

Firewall Insights：

• 偵測被遮蔽的規則、未使用的允許規則、過於寬鬆的來源，以及缺少目標標籤/服務帳戶的規則。它會建議更嚴格的規則以減少攻擊面，且不中斷已知的流量。

Network Analyzer：

• 跨專案的靜態與動態組態檢查，以揭露如下情況：
  • 健康狀態檢查被防火牆封鎖（記得允許 Google 健康狀態檢查的來源 IP 範圍）。
  • 負載平衡器的後端位於錯誤的區域或缺少指定的通訊埠。
  • 停用 Private Google Access 的子網路，導致沒有外部 IP 的執行個體無法存取 API。
  • 將重要前綴黑洞化的路由，或跨 VPN/Interconnect 的非對稱路由。

操作指引：

• 將 NIC 檢查整合到網路變更的 CI/CD 流程中，並排程定期執行。將發現的問題視為可靠性債務，並根據其降低風險的影響力來排定修復的優先順序。

Packet Mirroring、負載平衡器與混合式遙測

Packet Mirroring：

• 將 VM 流量鏡像到收集器 (設備或託管式 IDS) 以進行深度檢測。依子網路、網路標籤或服務帳戶來界定範圍；限制必要的協定以控制成本。
• 額外負擔與權衡取捨：鏡像流量的輸出會產生費用；過度的鏡像會對收集器造成壓力；請勿在生產環境中無差別地進行鏡像。針對突發事件，應使用有時間限制且範圍狹窄的工作階段。
• IDS 整合：
  • Cloud IDS 利用 Packet Mirroring 提供託管式、頻外 (out-of-band) 的威脅偵測。為了快速啟用並減少維護，建議優先選用。
  • 在需要特定簽章或廠商生態系的情況下，第三方 IDS 設備仍然是可行的選擇。

負載平衡器日誌與健康檢查證據：

• HTTP(S) 負載平衡器的請求日誌包含方法、URL、後端、回應碼、延遲以及透過 X-Forwarded-For 取得的用戶端 IP。由於 traceroute 會在 Google Front Ends (GFEs) 停止，因此請使用這些日誌進行用戶端路徑分析。
• 在後端服務上啟用日誌記錄，並設定取樣以在成本與可見性之間取得平衡。開啟健康檢查日誌記錄，以查看探測結果和失敗原因。
• 限制用戶端存取：透過為執行個體加上標籤並建立防火牆規則，只允許經核准的用戶端範圍和 Google 健康檢查 IP，在後端強制執行。對於 L7 威脅緩解和逐步推出，請在強制執行前，先以預覽模式使用 Cloud Armor 規則。

VPN 與 Interconnect 遙測：

• Cloud VPN (HA VPN) 指標：位元組、丟棄封包、加密錯誤、通道正常運作時間以及 BGP 工作階段狀態。針對封包丟棄、頻繁的 DPD 事件和 BGP 抖動 (flaps) 設定警示。
• 擴展吞吐量：新增通道至不同的對等 IP 並分散流量；監控可用空間 (headroom)。如果您需要在 Cloud Routers 之間實現 active/standby，建議優先使用地端的 MED 屬性來影響路徑選擇。
• Interconnect 指標：每個連結的使用率、CRC 錯誤和可用性；注意持續使用率是否超過 60–70% 以及錯誤是否突然飆升。維持備用容量和多樣化的線路。透過重傳和佇列指標來調查延遲增加的原因。
• 跨邊緣的飽和訊號：TCP 重傳次數上升、在沒有程式碼變更的情況下 99 百分位延遲增加、NAT 連接埠溢位事件以及佇列佔用警示，這些都是即將發生影響的早期警訊。

故障排除方法論、事件處理與主動式可靠性

從 DNS 到應用程式的結構化故障排除：

1. 識別出問題的使用者歷程與時間範圍；鎖定區域與路徑（公有路徑經由 LB、私有路徑經由 VPC，或混合式路徑）。
2. DNS：

• 使用 Cloud DNS 日誌、dig 輸出和政策行為來驗證名稱解析。檢查分割區域名稱解析 (split-horizon) 的衝突，並確保轉送政策已生效。
• 確認 TTL 和近期的變更；過期的快取可能模擬出服務中斷的假象。

3. 負載平衡器與邊緣：

• 檢視請求與健康狀態檢查日誌。將 5xx 錯誤高峰與後端健康狀況及部署事件建立關聯。對於 L7，應信任請求日誌，而非 traceroute。
• 當存取受限時，請驗證防火牆規則中的用戶端允許清單與 Google 健康狀態檢查 IP。

4. 路由與防火牆：

• 使用 Connectivity Tests 進行確定性的控制層評估。檢查有效路由與階層式防火牆政策。尋找非對稱路由與被遮蔽的規則。
• 對於被拒絕的封包，應依賴防火牆規則日誌；在調查期間，可考慮在優先級堆疊的底部附近新增一條有記錄的「全部拒絕」規則。

5. 對 Google API 的輸出流量 (Egress)：

• 如果執行個體沒有外部 IP，請確認 Private Google Access 及/或 Cloud NAT 是否已設定。缺少任一項都會導致間歇性故障與令人困惑的逾時。

6. 混合式網路：

• 檢查 Cloud Router 與 VPN/Interconnect 的指標。BGP 狀態為 up 但路由未安裝，可能反映了屬性偏好設定；請驗證 MED/local-pref 與 ASN。注意封包丟失與路徑 MTU 問題。

7. 封包證據：

• 如果控制層看起來正確但症狀持續存在，可小範圍地使用 Packet Mirroring 在受影響的 VM 或服務層附近收集 PCAP；檢查 SYN/SYN-ACK 時間、重傳次數，以及 MSS/DF 位元以找出 MTU 黑洞。

事件處理：

• 變更安全性：透過將範圍限定在標籤/服務帳戶、較低的優先順序，以及停用的規則來分階段進行變更；啟用日誌記錄並使用 Canary 進行測試。對於 L7 政策變更，可使用 Cloud Armor 預覽模式。
• 復原 (Rollback)：預先定義反向變更，將先前的設定保存在版本控制中，並在適用的情況下於應用程式邊緣使用短生命週期的功能旗標。
• 事件後分析：從日誌和指標建構時間軸，對促成因素進行分類（例如：寬鬆的允許規則被拒絕規則遮蔽、NAT 耗盡），記錄偵測缺口，並增加防護措施：警報、NIC 檢查與政策強化。

容量規劃與主動式可靠性：

• 追蹤預留空間目標：VPN/Interconnect 鏈路維持 30–50% 的預留空間、NAT 連接埠持續使用率低於 60%、LB 後端 CPU 與 QPS 遠低於自動擴展的觸發條件。
• 針對關鍵風險建立基於日誌的指標：拒絕次數高峰、NAT 溢位、BGP 中斷次數、5xx 錯誤率，以及 LB 後端連線錯誤。使用多重時間窗的燃燒率警報來捕捉快速與緩慢發生的事件。
• 綜合監控：從多個區域使用 Uptime Checks 來監控公有端點，並從測試 VM 使用私有探測器來監控內部服務。
• 預防性改善：使用 Firewall Insights 優化防火牆規則、解決 Network Analyzer 的發現、在尖峰事件期間縮短 Flow Log 的彙總間隔，並將日誌匯出至 BigQuery 以進行週期性異常偵測。

實際問題情境

Contoso Games 公司在 us-east1 和 europe-west1 營運一個全球性的 HTTP(S) 負載平衡遊戲 API，並透過 HA VPN 連接到一個地端資料中心。歐洲的使用者在最近一次防火牆變更後，回報了間歇性逾時與較高的延遲。執行個體沒有外部 IP，且必須私下存取 Google API。

處理方法：

1. 建立時間範圍與 SLO 影響

• 理由：精確鎖定時間範圍能將查詢限制在相關的日誌內，並將調查與影響使用者的 SLO 對齊。一則燃燒率警報確認了 europe-west1 的 SLO 正在快速消耗。

2. 使用 Connectivity Tests 驗證控制層

• 理由：建立一個從外部 HTTP(S) 負載平衡器前端到 europe-west1 後端服務的測試，以及一個從受影響的 VM 到 Private Google Access VIP 的測試。測試標示出一個階層式防火牆政策正在阻擋對某些後端的健康狀態檢查，且有一個子網路缺少 Private Google Access。

3. 透過日誌確認邊緣與後端的健康狀況

• 理由：篩選 europe-west1 的負載平衡器請求日誌，條件為 response_code >= 500，以隔離後端錯誤。健康狀態檢查日誌顯示，來自已知的 Google 健康狀態檢查來源 IP 的探測失敗。這證明了是防火牆引起的後端服務不穩定 (flapping)，而非應用程式的回歸問題。

4. 透過限定範圍的變更來恢復健康並保障安全

• 理由：新增一條針對後端標籤的允許規則，允許健康狀態檢查的來源範圍。在此規則上啟用日誌記錄。由於存取僅限於已知的用戶端，請驗證允許清單防火牆規則僅包含特定的用戶端 IP 範圍與健康狀態檢查範圍。初期先將新規則保持停用，然後在低流量的 Canary 期間啟用，以限制影響範圍。

5. 重新建立對 Google API 的私有輸出流量

• 理由：在受影響的子網路上啟用 Private Google Access，如此一來，沒有外部 IP 的執行個體便能存取 Google 服務，而無需透過 VPN 或第三方防火牆進行髮夾彎路由 (hairpinning)。這能降低延遲並移除一個瓶頸點。

6. 檢查混合式網路的飽和度與 MTU

• 理由：檢視 HA VPN 的封包丟失與使用率指標。其中一個通道顯示丟包率升高。透過新增第二個通道連接到不同的地端對等 IP 來增加容量並分散流量。驗證有效的 MTU 與 MSS clamp，以防止 VPN 路徑上出現 PMTU 黑洞。

7. 對於可疑的濫用行為用戶端，使用 Cloud Armor 預覽模式

• 理由：從請求日誌中發現，一小群用戶端 IP 在探測失敗前流量暴增。在 Cloud Armor 中新增一條拒絕規則並設定為預覽模式，以便在強制執行前驗證阻擋該流量確實能減少後端負載，避免意外影響正常使用者。

8. 小範圍地使用 Packet Mirroring 來確認資料層的行為

• 理由：將單一不健康後端 VM 的流量鏡像到 Cloud IDS 15 分鐘。PCAP 顯示，在來自濫用行為 IP 的流量突發期間，發生了 SYN 待辦佇列 (backlog) 耗盡的情況，這證實了 Cloud Armor 政策的效用以及實施速率限制的必要性。

9. 結束事件並進行強化

• 理由：在啟用健康狀態檢查的允許規則、確認 Private Google Access、擴展 VPN 容量，並強制執行已驗證的 Cloud Armor 規則後，錯誤率恢復到基準水平。新增儀表板以監控健康狀態檢查成功率、NAT 連接埠使用率、VPN 丟包率，以及各區域的 5xx 錯誤率。建立基於日誌的警報，用於偵測對後端標籤的防火牆拒絕事件，以及 SLO 燃燒率警報。記錄此事件、根本原因（階層式防火牆變更、濫用流量、VPN 飽和），並將 NIC Analyzer 與 Firewall Insights 檢查加入到變更前的檢查清單中。

此順序展示了一個安全、由證據驅動的工作流程：確認控制層、觀察資料層、應用最小且可逆的變更，然後透過警報與自動化檢查將學習到的經驗制度化。

← GKE、容器與應用程式網路 · 所有領域 · 網路自動化、治理與成本營運 →

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

瀏覽 Google →