Google Cloud Platform on Tarragonhttps://tarrragon.github.io/blog/backend/08-incident-response/cases/gcp/Recent content in Google Cloud Platform on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Fri, 01 May 2026 00:00:00 +0000GCP 2019 US Network Congestion Multi-service Incidenthttps://tarrragon.github.io/blog/backend/08-incident-response/cases/gcp/2019-us-network-congestion-multi-service-incident/Thu, 07 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/08-incident-response/cases/gcp/2019-us-network-congestion-multi-service-incident/<p>2019 年 GCP 網路壅塞事故的核心教訓是：當共享網路容量被打滿，影響會跨越產品邊界，同一時間出現在 compute、storage、observability 與管理面。</p> <h2 id="事故摘要">事故摘要</h2> <p>Google Cloud 在 2019-06-02 發生美國多區域 network congestion，官方摘要指出多個 US region 出現 elevated packet loss，影響持續約 3 至 4 小時以上，並牽動多個 GCP 與非 Cloud 服務。</p> <p>這類事故本質是共享網路資源退化造成的跨產品連鎖事件，單一服務壞掉反而好處理。</p> <h2 id="判讀訊號">判讀訊號</h2> <table> <thead> <tr> <th>訊號</th> <th>事故中代表什麼</th> <th>第一波決策價值</th> </tr> </thead> <tbody> <tr> <td>多區域 packet loss 同時上升</td> <td>共享網路層失衡，不是單服務 bug</td> <td>優先走區域隔離與流量調整路徑</td> </tr> <tr> <td>多產品錯誤率一起上升</td> <td>事故已跨產品依賴鏈擴散</td> <td>事故分級以跨產品影響為主，而非單團隊視角</td> </tr> <tr> <td>部分 region 正常、部分 region 退化</td> <td>區域差異可用來做流量重新分配</td> <td>啟動 region-aware mitigation</td> </tr> <tr> <td>status page 更新中提到 varied impact</td> <td>影響面非均勻分布</td> <td>對外更新要分 region / service 粒度</td> </tr> </tbody> </table> <h2 id="事故路徑">事故路徑</h2> <ol> <li>美國多區域網路容量在高壓下出現壅塞與丟包。</li> <li>多個 GCP 產品受同一網路瓶頸影響，出現延遲與錯誤。</li> <li>工程團隊進行流量與容量調整，逐區域回復。</li> <li>狀態頁持續更新受影響範圍與恢復進度。</li> <li>事後回寫區域隔離、容量保留與跨產品協調流程。</li> </ol> <h2 id="可回寫控制面">可回寫控制面</h2> <table> <thead> <tr> <th>控制面</th> <th>這次事故暴露的缺口</th> <th>回寫方向</th> </tr> </thead> <tbody> <tr> <td>Region-aware traffic control</td> <td>區域壅塞時流量轉移策略不夠快</td> <td>建立區域流量切換的預設策略與演練</td> </tr> <tr> <td>Cross-product incident command</td> <td>多產品同時受影響時協調成本高</td> <td>強化跨產品指揮節奏與共享 decision log</td> </tr> <tr> <td>Network dependency mapping</td> <td>服務依賴共享網路層但判讀入口分散</td> <td>補跨產品依賴圖與共同告警面板</td> </tr> <tr> <td>Status communication granularity</td> <td>對外說明若只寫全域狀態會失真</td> <td>更新按 region 與 service 分層揭露</td> </tr> </tbody> </table> <h2 id="下一步路由">下一步路由</h2> <ul> <li>觀測證據包： <a href="https://tarrragon.github.io/blog/backend/04-observability/observability-evidence-package/" data-link-title="4.20 Observability Evidence Package" data-link-desc="把 log、metric、trace、audit 與資料品質限制包成可交接證據">4.20 Observability Evidence Package</a></li> <li>事故通訊： <a href="https://tarrragon.github.io/blog/backend/08-incident-response/incident-communication/" data-link-title="8.4 事故通訊與狀態更新" data-link-desc="建立內外部通報節奏與狀態更新格式">8.4 Incident Communication</a></li> <li>事中決策紀錄： <a href="https://tarrragon.github.io/blog/backend/08-incident-response/incident-decision-log/" data-link-title="8.19 Incident Decision Log" data-link-desc="把事中假設、決策、證據、回退條件與責任人留下可復盤紀錄">8.19 Incident Decision Log</a></li> <li>證據回寫流程： <a href="https://tarrragon.github.io/blog/backend/08-incident-response/incident-evidence-write-back/" data-link-title="8.22 Incident Evidence Write-back" data-link-desc="把事故證據、決策與復盤結論回寫到 observability、reliability 與 runbook">8.22 Incident Evidence Write-back</a></li> <li>實驗安全邊界： <a href="https://tarrragon.github.io/blog/backend/06-reliability/experiment-safety-boundary/" data-link-title="6.20 Experiment Safety Boundary" data-link-desc="定義 chaos、load test、DR drill 的 [blast radius](/backend/knowledge-cards/blast-radius/)、停止條件與權限約束">6.20 Experiment Safety Boundary</a></li> </ul> <h2 id="引用源">引用源</h2> <ul> <li><a href="https://status.cloud.google.com/incident/cloud-networking/19009">Google Cloud Networking Incident #19009</a></li> <li><a href="https://cloud.google.com/blog/topics/inside-google-cloud/an-update-on-sundays-service-disruption">An update on Sunday’s service disruption</a></li> </ul>2019 年 GCP 網路壅塞事故的核心教訓是：當共享網路容量被打滿，影響會跨越產品邊界，同一時間出現在 compute、storage、observability 與管理面。

事故摘要

Google Cloud 在 2019-06-02 發生美國多區域 network congestion，官方摘要指出多個 US region 出現 elevated packet loss，影響持續約 3 至 4 小時以上，並牽動多個 GCP 與非 Cloud 服務。

這類事故本質是共享網路資源退化造成的跨產品連鎖事件，單一服務壞掉反而好處理。

判讀訊號

訊號 事故中代表什麼 第一波決策價值
多區域 packet loss 同時上升 共享網路層失衡，不是單服務 bug 優先走區域隔離與流量調整路徑
多產品錯誤率一起上升 事故已跨產品依賴鏈擴散 事故分級以跨產品影響為主，而非單團隊視角
部分 region 正常、部分 region 退化 區域差異可用來做流量重新分配 啟動 region-aware mitigation
status page 更新中提到 varied impact 影響面非均勻分布 對外更新要分 region / service 粒度

事故路徑

  1. 美國多區域網路容量在高壓下出現壅塞與丟包。
  2. 多個 GCP 產品受同一網路瓶頸影響，出現延遲與錯誤。
  3. 工程團隊進行流量與容量調整，逐區域回復。
  4. 狀態頁持續更新受影響範圍與恢復進度。
  5. 事後回寫區域隔離、容量保留與跨產品協調流程。

可回寫控制面

控制面 這次事故暴露的缺口 回寫方向
Region-aware traffic control 區域壅塞時流量轉移策略不夠快 建立區域流量切換的預設策略與演練
Cross-product incident command 多產品同時受影響時協調成本高 強化跨產品指揮節奏與共享 decision log
Network dependency mapping 服務依賴共享網路層但判讀入口分散 補跨產品依賴圖與共同告警面板
Status communication granularity 對外說明若只寫全域狀態會失真 更新按 region 與 service 分層揭露

下一步路由

引用源

]]>