Cloudflare on Tarragonhttps://tarrragon.github.io/blog/backend/08-incident-response/cases/cloudflare/Recent content in Cloudflare on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Fri, 01 May 2026 00:00:00 +0000Cloudflare 2019 Regex CPU Outagehttps://tarrragon.github.io/blog/backend/08-incident-response/cases/cloudflare/2019-regex-cpu-outage/Thu, 07 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/08-incident-response/cases/cloudflare/2019-regex-cpu-outage/<p>2019 年 Cloudflare regex 事故的核心教訓是：控制面配置錯誤可以在秒級擴散成全球可用性事故。這類事故的第一責任不是「加機器」，而是迅速切斷擴散路徑，讓錯誤停止被新流量放大。</p> <h2 id="事故摘要">事故摘要</h2> <p>Cloudflare 在 2019-07-02 發布新的 WAF Managed Rule 後，規則中的 regex 觸發 catastrophic backtracking，導致 edge CPU 快速打滿。事故影響約 27 分鐘，症狀是大量 502/503 與延遲激增。</p> <p>這起事件屬於典型「控制面配置推送 → data plane 全網受影響」模式。錯誤並非單點節點故障，而是由一致推送機制把同一錯誤同步擴散到整個 edge 網路。</p> <h2 id="判讀訊號">判讀訊號</h2> <table> <thead> <tr> <th>訊號</th> <th>事故中代表什麼</th> <th>第一波決策價值</th> </tr> </thead> <tbody> <tr> <td>全球 CPU 同步飆升</td> <td>問題來自共用規則或共用執行路徑</td> <td>優先檢查最新全域配置變更</td> </tr> <tr> <td>5xx 與延遲同時惡化</td> <td>非單純容量尖峰，更像執行成本突增</td> <td>優先撤回新規則，避免持續放大</td> </tr> <tr> <td>多區域同時報警</td> <td>事故已跨區域，屬全網級控制面風險</td> <td>啟動全域指揮節奏與高頻通訊</td> </tr> <tr> <td>回滾後指標快速回穩</td> <td>根因與近期變更高度相關</td> <td>立即凍結同批規則推送，改走分區驗證</td> </tr> <tr> <td>事件期間 rule path 命中異常增</td> <td>單一規則造成 CPU 熱點</td> <td>補 rule-level profiling 與上線前成本檢查</td> </tr> </tbody> </table> <h2 id="事故路徑">事故路徑</h2> <ol> <li>控制面推送新 WAF 規則到全球 edge。</li> <li>規則 regex 在特定輸入下產生高計算成本。</li> <li>edge CPU 被規則執行成本吃滿，請求處理能力下降。</li> <li>5xx 與延遲擴散成全球可見症狀。</li> <li>回滾規則後，CPU 與可用性逐步恢復。</li> </ol> <p>這條路徑顯示：事故擴散速度主要由「推送覆蓋範圍」決定，而不是由「單機故障率」決定。</p> <h2 id="可回寫控制面">可回寫控制面</h2> <table> <thead> <tr> <th>控制面</th> <th>這次事故暴露的缺口</th> <th>回寫方向</th> </tr> </thead> <tbody> <tr> <td>規則上線前靜態檢查</td> <td>regex 風險模式未被擋下</td> <td>補 regex 風險 lint 與拒絕規則（高 backtracking 風險直接阻擋）</td> </tr> <tr> <td>上線前效能測試</td> <td>缺少 rule-level CPU 成本基線</td> <td>補 rule replay 測試，用代表性 payload 驗證執行成本</td> </tr> <tr> <td>推送策略</td> <td>全域一次推送讓 blast radius 過大</td> <td>改成分區/分群 staged rollout，設回滾閘門</td> </tr> <tr> <td>事故啟動門檻</td> <td>全網症狀出現後才完整升級</td> <td>以「跨區 CPU 同步異常 + 5xx 上升」作為自動升級條件</td> </tr> <tr> <td>Decision log</td> <td>事中決策若缺時間線，復盤成本高</td> <td>在事故期間即時記錄假設、回滾條件、責任人與驗證結果</td> </tr> <tr> <td>Evidence write-back</td> <td>事故教訓易停在 PIR 文本</td> <td>回寫到 <code>04</code> 觀測規則與 <code>06</code> 實驗安全邊界，形成下次推送前硬性 gate</td> </tr> </tbody> </table> <h2 id="下一步路由">下一步路由</h2> <ul> <li>回寫訊號治理： <a href="https://tarrragon.github.io/blog/backend/04-observability/telemetry-data-quality/" data-link-title="4.17 Telemetry Data Quality" data-link-desc="把 missing signal、schema drift、sampling bias 與 timestamp skew 變成資料品質問題">4.17 Telemetry Data Quality</a></li> <li>回寫規則成本訊號： <a href="https://tarrragon.github.io/blog/backend/04-observability/rule-level-cpu-signal-governance/" data-link-title="4.21 Rule-level CPU Signal Governance" data-link-desc="把規則與策略執行成本變成可觀測訊號，避免控制面小變更在資料面形成 CPU 熱點。">4.21 Rule-level CPU Signal Governance</a></li> <li>回寫規則推送閘門： <a href="https://tarrragon.github.io/blog/backend/06-reliability/rule-rollout-safety-gate/" data-link-title="6.24 規則推送安全閘門" data-link-desc="把規則、策略與控制面配置推送從部署步驟升級為可靠性 gate，避免小變更在秒級擴散成全網事故。">6.24 Rule Rollout Safety Gate</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> <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> </ul> <h2 id="引用源">引用源</h2> <ul> <li><a href="https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019">Details of the Cloudflare outage on July 2, 2019</a></li> </ul>2019 年 Cloudflare regex 事故的核心教訓是：控制面配置錯誤可以在秒級擴散成全球可用性事故。這類事故的第一責任不是「加機器」，而是迅速切斷擴散路徑，讓錯誤停止被新流量放大。

事故摘要

Cloudflare 在 2019-07-02 發布新的 WAF Managed Rule 後，規則中的 regex 觸發 catastrophic backtracking，導致 edge CPU 快速打滿。事故影響約 27 分鐘，症狀是大量 502/503 與延遲激增。

這起事件屬於典型「控制面配置推送 → data plane 全網受影響」模式。錯誤並非單點節點故障，而是由一致推送機制把同一錯誤同步擴散到整個 edge 網路。

判讀訊號

訊號 事故中代表什麼 第一波決策價值
全球 CPU 同步飆升 問題來自共用規則或共用執行路徑 優先檢查最新全域配置變更
5xx 與延遲同時惡化 非單純容量尖峰，更像執行成本突增 優先撤回新規則，避免持續放大
多區域同時報警 事故已跨區域，屬全網級控制面風險 啟動全域指揮節奏與高頻通訊
回滾後指標快速回穩 根因與近期變更高度相關 立即凍結同批規則推送，改走分區驗證
事件期間 rule path 命中異常增 單一規則造成 CPU 熱點 補 rule-level profiling 與上線前成本檢查

事故路徑

  1. 控制面推送新 WAF 規則到全球 edge。
  2. 規則 regex 在特定輸入下產生高計算成本。
  3. edge CPU 被規則執行成本吃滿，請求處理能力下降。
  4. 5xx 與延遲擴散成全球可見症狀。
  5. 回滾規則後，CPU 與可用性逐步恢復。

這條路徑顯示：事故擴散速度主要由「推送覆蓋範圍」決定，而不是由「單機故障率」決定。

可回寫控制面

控制面 這次事故暴露的缺口 回寫方向
規則上線前靜態檢查 regex 風險模式未被擋下 補 regex 風險 lint 與拒絕規則（高 backtracking 風險直接阻擋）
上線前效能測試 缺少 rule-level CPU 成本基線 補 rule replay 測試，用代表性 payload 驗證執行成本
推送策略 全域一次推送讓 blast radius 過大 改成分區/分群 staged rollout，設回滾閘門
事故啟動門檻 全網症狀出現後才完整升級 以「跨區 CPU 同步異常 + 5xx 上升」作為自動升級條件
Decision log 事中決策若缺時間線，復盤成本高 在事故期間即時記錄假設、回滾條件、責任人與驗證結果
Evidence write-back 事故教訓易停在 PIR 文本 回寫到 04 觀測規則與 06 實驗安全邊界，形成下次推送前硬性 gate

下一步路由

引用源

]]>Cloudflare 2023 Control Plane Token Incidenthttps://tarrragon.github.io/blog/backend/08-incident-response/cases/cloudflare/2023-control-plane-token-incident/Thu, 07 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/08-incident-response/cases/cloudflare/2023-control-plane-token-incident/<p>2023 年 Cloudflare control-plane 事故的核心教訓是：身份與憑證類變更一旦跨產品共用，單點錯誤會變成系統級連鎖故障。這類事故要先切的是信任邊界，不是先做流量微調。</p> <h2 id="事故摘要">事故摘要</h2> <p>Cloudflare 在 2023-01-24 經歷 service token 相關變更問題，造成內外部控制面能力受影響，連帶影響多個產品面向。事件本質是控制面身份機制失效，並透過共用依賴擴散。</p> <p>這類事故的危險在於症狀看起來像多個服務同時不穩，但根因其實是同一個共享身份控制點。若沒有先識別 shared dependency，排障會被切成很多局部問題，恢復速度會顯著下降。</p> <h2 id="判讀訊號">判讀訊號</h2> <table> <thead> <tr> <th>訊號</th> <th>事故中代表什麼</th> <th>第一波決策價值</th> </tr> </thead> <tbody> <tr> <td>多產品同時出現驗證/授權異常</td> <td>共享身份或憑證控制點可能失效</td> <td>優先檢查 token / policy 最新變更</td> </tr> <tr> <td>失敗集中在控制面 API</td> <td>問題偏向控制面，不是資料面容量瓶頸</td> <td>啟動控制面優先處理，不先做業務層調參</td> </tr> <tr> <td>局部回復但整體仍不穩</td> <td>依賴鏈條有殘留錯誤狀態</td> <td>補 dependency-by-dependency 驗證清單</td> </tr> <tr> <td>回退後錯誤快速下降</td> <td>變更與故障關聯度高</td> <td>立即凍結同批身份變更與關聯部署</td> </tr> <tr> <td>事故中責任邊界模糊</td> <td>ownership 與交接規則不足</td> <td>指派 single incident owner 與決策記錄</td> </tr> </tbody> </table> <h2 id="事故路徑">事故路徑</h2> <ol> <li>控制面 token/身份相關變更進入生產環境。</li> <li>共享身份依賴開始出現授權或驗證失效。</li> <li>多個產品面的控制操作受阻，形成連鎖症狀。</li> <li>團隊透過回退與修正策略逐步收斂。</li> <li>事件後需回寫身份變更治理與事故交接流程。</li> </ol> <p>這條路徑顯示：擴散關鍵在 shared identity dependency，不在單一產品流量高低。</p> <h2 id="可回寫控制面">可回寫控制面</h2> <table> <thead> <tr> <th>控制面</th> <th>這次事故暴露的缺口</th> <th>回寫方向</th> </tr> </thead> <tbody> <tr> <td>身份變更審核</td> <td>token/policy 變更前缺少跨產品影響分析</td> <td>補 shared dependency impact checklist</td> </tr> <tr> <td>發布策略</td> <td>身份控制面變更缺少逐層 rollout</td> <td>先低風險範圍啟用，再逐步擴大</td> </tr> <tr> <td>事故啟動條件</td> <td>多產品異常時未即時指向 shared root</td> <td>新增「多產品授權異常」的快速升級條件</td> </tr> <tr> <td>Decision log</td> <td>假設、回退條件與責任分工不夠明確</td> <td>事中強制記錄假設、證據、回退門檻與 owner</td> </tr> <tr> <td>Evidence write-back</td> <td>教訓停在事件敘述</td> <td>回寫 <code>07</code> 身分邊界治理、<code>08</code> decision log、<code>04</code> 控制面健康訊號</td> </tr> <tr> <td>Handoff protocol</td> <td>長事故交接易遺失上下文</td> <td>使用固定 handoff 模板，包含當前假設、已驗證路徑、未完成風險與下一步責任</td> </tr> </tbody> </table> <h2 id="下一步路由">下一步路由</h2> <ul> <li>身分邊界與權限治理： <a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/identity-access-boundary/" data-link-title="7.2 身分與授權邊界" data-link-desc="以問題驅動方式整理身分、授權、會話與供應商身分鏈">7.2 Identity Access Boundary</a></li> <li>規則推送安全閘門： <a href="https://tarrragon.github.io/blog/backend/06-reliability/rule-rollout-safety-gate/" data-link-title="6.24 規則推送安全閘門" data-link-desc="把規則、策略與控制面配置推送從部署步驟升級為可靠性 gate，避免小變更在秒級擴散成全網事故。">6.24 Rule Rollout Safety Gate</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/04-observability/observability-operating-model/" data-link-title="4.18 Observability Operating Model" data-link-desc="定義 platform / service team / on-call 對訊號、dashboard、alert 與成本的 ownership">4.18 Observability Operating Model</a></li> </ul> <h2 id="引用源">引用源</h2> <ul> <li><a href="https://blog.cloudflare.com/cloudflare-incident-on-january-24th-2023/">Cloudflare incident on January 24, 2023</a></li> </ul>2023 年 Cloudflare control-plane 事故的核心教訓是：身份與憑證類變更一旦跨產品共用，單點錯誤會變成系統級連鎖故障。這類事故要先切的是信任邊界，不是先做流量微調。

事故摘要

Cloudflare 在 2023-01-24 經歷 service token 相關變更問題，造成內外部控制面能力受影響，連帶影響多個產品面向。事件本質是控制面身份機制失效，並透過共用依賴擴散。

這類事故的危險在於症狀看起來像多個服務同時不穩，但根因其實是同一個共享身份控制點。若沒有先識別 shared dependency，排障會被切成很多局部問題，恢復速度會顯著下降。

判讀訊號

訊號 事故中代表什麼 第一波決策價值
多產品同時出現驗證/授權異常 共享身份或憑證控制點可能失效 優先檢查 token / policy 最新變更
失敗集中在控制面 API 問題偏向控制面，不是資料面容量瓶頸 啟動控制面優先處理，不先做業務層調參
局部回復但整體仍不穩 依賴鏈條有殘留錯誤狀態 補 dependency-by-dependency 驗證清單
回退後錯誤快速下降 變更與故障關聯度高 立即凍結同批身份變更與關聯部署
事故中責任邊界模糊 ownership 與交接規則不足 指派 single incident owner 與決策記錄

事故路徑

  1. 控制面 token/身份相關變更進入生產環境。
  2. 共享身份依賴開始出現授權或驗證失效。
  3. 多個產品面的控制操作受阻，形成連鎖症狀。
  4. 團隊透過回退與修正策略逐步收斂。
  5. 事件後需回寫身份變更治理與事故交接流程。

這條路徑顯示：擴散關鍵在 shared identity dependency，不在單一產品流量高低。

可回寫控制面

控制面 這次事故暴露的缺口 回寫方向
身份變更審核 token/policy 變更前缺少跨產品影響分析 補 shared dependency impact checklist
發布策略 身份控制面變更缺少逐層 rollout 先低風險範圍啟用，再逐步擴大
事故啟動條件 多產品異常時未即時指向 shared root 新增「多產品授權異常」的快速升級條件
Decision log 假設、回退條件與責任分工不夠明確 事中強制記錄假設、證據、回退門檻與 owner
Evidence write-back 教訓停在事件敘述 回寫 07 身分邊界治理、08 decision log、04 控制面健康訊號
Handoff protocol 長事故交接易遺失上下文 使用固定 handoff 模板，包含當前假設、已驗證路徑、未完成風險與下一步責任

下一步路由

引用源

]]>Cloudflare 2026 BYOIP BGP Withdrawalhttps://tarrragon.github.io/blog/backend/08-incident-response/cases/cloudflare/2026-byoip-bgp-withdrawal/Thu, 07 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/08-incident-response/cases/cloudflare/2026-byoip-bgp-withdrawal/<p>2026 年 Cloudflare BYOIP / BGP 事故的核心教訓是：控制面資料一旦同時承擔 customer configuration 與 operational state，錯誤清理流程會直接變成全網路由變更。這類事故的第一責任是停止錯誤狀態傳播，再把 desired state 與 actual state 拆開恢復。</p> <h2 id="事故摘要">事故摘要</h2> <p>Cloudflare 在 2026-02-20 17:48 UTC 發生 BYOIP 相關 outage。部分使用 Bring Your Own IP（BYOIP）的客戶，其 IP prefixes 被 Cloudflare 經由 BGP 非預期撤告，導致相關服務從 Internet 無法到達。官方回顧指出，事故總時長為 6 小時 7 分鐘；在 4,306 個 BYOIP prefixes 中，約 1,100 個 prefixes 曾被撤告，約佔 BYOIP prefixes 的 25%。</p> <p>事故起因是 Cloudflare 在 Addressing API / BYOIP pipeline 中引入的自動化清理流程，與外部攻擊無關。該流程原本要移除 pending deletion 的 prefixes，但 API query 的 <code>pending_delete</code> 參數沒有值，server 端將它解讀成一般查詢，回傳所有 BYOIP prefixes。下游流程接著把回傳結果當成待刪除集合，開始撤告 prefixes 與移除相關 service bindings。</p> <h2 id="判讀訊號">判讀訊號</h2> <table> <thead> <tr> <th>訊號</th> <th>事故中代表什麼</th> <th>第一波決策價值</th> </tr> </thead> <tbody> <tr> <td>BYOIP prefixes 數量快速下降</td> <td>BGP advertisement 正在被控制面錯誤改寫</td> <td>立即停止最新 Addressing API / cleanup 任務</td> </tr> <tr> <td>客戶服務從 Internet 無法連線</td> <td>prefix withdrawal 已影響資料面可達性</td> <td>優先恢復 prefix advertisement，而非只查應用層錯誤</td> </tr> <tr> <td>部分客戶可自行 re-advertise</td> <td>部分狀態只被撤告，binding 尚未被刪除</td> <td>對外提供 dashboard workaround，降低待處理影響面</td> </tr> <tr> <td>部分客戶無法自助恢復</td> <td>service bindings 或 edge 設定也被移除</td> <td>需要工程團隊做資料恢復與 global configuration rollout</td> </tr> <tr> <td>恢復分成多批完成</td> <td>受影響 prefixes 處於不同損壞狀態</td> <td>decision log 要分別記錄「可自助」「需手動」「需全域 rollout」</td> </tr> </tbody> </table> <h2 id="事故路徑">事故路徑</h2> <ol> <li>Addressing API 相關程式碼在 2026-02-05 合併，並於 2026-02-20 部署。</li> <li>cleanup sub-task 查詢 <code>/v1/prefixes?pending_delete</code>，但 <code>pending_delete</code> 沒有值。</li> <li>API server 沒有進入 pending deletion 分支，而是回傳所有 BYOIP prefixes。</li> <li>cleanup sub-task 將回傳的 prefixes 解讀成待移除集合，開始撤告 prefixes 與刪除 dependent objects。</li> <li>Cloudflare 在觀察到 1.1.1.1 相關失敗後回退變更並終止 broken sub-process。</li> <li>多數 prefixes 透過 re-advertise 或 restore 流程恢復，剩餘約 300 個 prefixes 需要工程師手動恢復 service bindings 與 edge 設定。</li> </ol> <p>這條路徑顯示：BGP withdrawal 是結果，真正的事故起點是控制面資料查詢語意不明確，以及 operational workflow 對查詢結果缺少大範圍變更 circuit breaker。</p> <h2 id="可回寫控制面">可回寫控制面</h2> <table> <thead> <tr> <th>控制面</th> <th>這次事故暴露的缺口</th> <th>回寫方向</th> </tr> </thead> <tbody> <tr> <td>API schema</td> <td>boolean-like query 參數語意不明確</td> <td>將狀態查詢參數標準化，錯誤或空值直接拒絕，不進入危險預設路徑</td> </tr> <tr> <td>Desired / actual state 分離</td> <td>customer configuration 與 operational action 混在同一資料面</td> <td>引入 snapshot / staged deployment，讓壞資料可快速回到 known-good state</td> </tr> <tr> <td>大範圍 withdrawal circuit breaker</td> <td>cleanup 任務可一次影響大量 prefixes</td> <td>對 prefix withdrawal / deletion 設速率、數量與健康訊號閘門</td> </tr> <tr> <td>Staging 與 mock data</td> <td>測試資料未覆蓋 task-runner 自主操作情境</td> <td>補 production-like state mutation 測試，而不只測 customer journey</td> </tr> <tr> <td>Incident intake</td> <td>1.1.1.1 異常成為早期觀察點</td> <td>將共享基礎服務異常納入控制面事故快速升級條件</td> </tr> <tr> <td>Evidence write-back</td> <td>恢復分成 dashboard 自助、資料修復、global rollout 多條路</td> <td>回寫 decision log 與 evidence package，保留每種狀態的恢復判準</td> </tr> </tbody> </table> <h2 id="下一步路由">下一步路由</h2> <ul> <li>控制面資料品質： <a href="https://tarrragon.github.io/blog/backend/04-observability/telemetry-data-quality/" data-link-title="4.17 Telemetry Data Quality" data-link-desc="把 missing signal、schema drift、sampling bias 與 timestamp skew 變成資料品質問題">4.17 Telemetry Data Quality</a></li> <li>規則推送安全閘門： <a href="https://tarrragon.github.io/blog/backend/06-reliability/rule-rollout-safety-gate/" data-link-title="6.24 規則推送安全閘門" data-link-desc="把規則、策略與控制面配置推送從部署步驟升級為可靠性 gate，避免小變更在秒級擴散成全網事故。">6.24 Rule Rollout Safety Gate</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> <li>驗證證據交接： <a href="https://tarrragon.github.io/blog/backend/06-reliability/verification-evidence-handoff/" data-link-title="6.23 Verification Evidence Handoff" data-link-desc="把 SLO、load、chaos、DR 與 readiness 結果包成 release / incident 可用證據">6.23 Verification Evidence Handoff</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> </ul> <h2 id="引用源">引用源</h2> <ul> <li><a href="https://blog.cloudflare.com/cloudflare-outage-february-20-2026/">Cloudflare outage on February 20, 2026</a></li> </ul>2026 年 Cloudflare BYOIP / BGP 事故的核心教訓是：控制面資料一旦同時承擔 customer configuration 與 operational state，錯誤清理流程會直接變成全網路由變更。這類事故的第一責任是停止錯誤狀態傳播，再把 desired state 與 actual state 拆開恢復。

事故摘要

Cloudflare 在 2026-02-20 17:48 UTC 發生 BYOIP 相關 outage。部分使用 Bring Your Own IP（BYOIP）的客戶，其 IP prefixes 被 Cloudflare 經由 BGP 非預期撤告，導致相關服務從 Internet 無法到達。官方回顧指出，事故總時長為 6 小時 7 分鐘；在 4,306 個 BYOIP prefixes 中，約 1,100 個 prefixes 曾被撤告，約佔 BYOIP prefixes 的 25%。

事故起因是 Cloudflare 在 Addressing API / BYOIP pipeline 中引入的自動化清理流程，與外部攻擊無關。該流程原本要移除 pending deletion 的 prefixes，但 API query 的 pending_delete 參數沒有值，server 端將它解讀成一般查詢，回傳所有 BYOIP prefixes。下游流程接著把回傳結果當成待刪除集合，開始撤告 prefixes 與移除相關 service bindings。

判讀訊號

訊號 事故中代表什麼 第一波決策價值
BYOIP prefixes 數量快速下降 BGP advertisement 正在被控制面錯誤改寫 立即停止最新 Addressing API / cleanup 任務
客戶服務從 Internet 無法連線 prefix withdrawal 已影響資料面可達性 優先恢復 prefix advertisement，而非只查應用層錯誤
部分客戶可自行 re-advertise 部分狀態只被撤告，binding 尚未被刪除 對外提供 dashboard workaround，降低待處理影響面
部分客戶無法自助恢復 service bindings 或 edge 設定也被移除 需要工程團隊做資料恢復與 global configuration rollout
恢復分成多批完成 受影響 prefixes 處於不同損壞狀態 decision log 要分別記錄「可自助」「需手動」「需全域 rollout」

事故路徑

  1. Addressing API 相關程式碼在 2026-02-05 合併，並於 2026-02-20 部署。
  2. cleanup sub-task 查詢 /v1/prefixes?pending_delete，但 pending_delete 沒有值。
  3. API server 沒有進入 pending deletion 分支，而是回傳所有 BYOIP prefixes。
  4. cleanup sub-task 將回傳的 prefixes 解讀成待移除集合，開始撤告 prefixes 與刪除 dependent objects。
  5. Cloudflare 在觀察到 1.1.1.1 相關失敗後回退變更並終止 broken sub-process。
  6. 多數 prefixes 透過 re-advertise 或 restore 流程恢復，剩餘約 300 個 prefixes 需要工程師手動恢復 service bindings 與 edge 設定。

這條路徑顯示：BGP withdrawal 是結果，真正的事故起點是控制面資料查詢語意不明確，以及 operational workflow 對查詢結果缺少大範圍變更 circuit breaker。

可回寫控制面

控制面 這次事故暴露的缺口 回寫方向
API schema boolean-like query 參數語意不明確 將狀態查詢參數標準化，錯誤或空值直接拒絕，不進入危險預設路徑
Desired / actual state 分離 customer configuration 與 operational action 混在同一資料面 引入 snapshot / staged deployment，讓壞資料可快速回到 known-good state
大範圍 withdrawal circuit breaker cleanup 任務可一次影響大量 prefixes 對 prefix withdrawal / deletion 設速率、數量與健康訊號閘門
Staging 與 mock data 測試資料未覆蓋 task-runner 自主操作情境 補 production-like state mutation 測試，而不只測 customer journey
Incident intake 1.1.1.1 異常成為早期觀察點 將共享基礎服務異常納入控制面事故快速升級條件
Evidence write-back 恢復分成 dashboard 自助、資料修復、global rollout 多條路 回寫 decision log 與 evidence package，保留每種狀態的恢復判準

下一步路由

引用源

]]>Cloudflare 2023 Workers KV Deployment Tool Misconfigurationhttps://tarrragon.github.io/blog/backend/08-incident-response/cases/cloudflare/2023-workers-kv-deployment-tool-misconfiguration/Thu, 07 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/08-incident-response/cases/cloudflare/2023-workers-kv-deployment-tool-misconfiguration/<p>這起事件的核心責任判讀是：控制面工具設定錯誤會跨越產品邊界擴散，事故第一步要先切斷擴散路徑，再做功能修復。若先把症狀拆成多個產品問題，恢復速度會被 shared dependency 拖慢。</p> <h2 id="事故摘要">事故摘要</h2> <p>Cloudflare 在 2023-10-30 發生控制面相關事故，根因涉及 deployment tool 的設定錯誤，影響 Workers KV 與相關服務操作路徑。表面症狀可出現在多個產品面向，但本質是共享控制面變更帶來的連鎖失效。</p> <p>這類事故和單點 runtime bug 不同。關鍵不是「哪個服務先報錯」，而是「哪個共用控制點先失真」。</p> <h2 id="判讀訊號">判讀訊號</h2> <table> <thead> <tr> <th>訊號</th> <th>代表意義</th> <th>第一波決策價值</th> </tr> </thead> <tbody> <tr> <td>多產品控制操作同時不穩</td> <td>shared control dependency 可能失效</td> <td>先盤點同批變更與共用工具</td> </tr> <tr> <td>功能異常分布不均</td> <td>擴散沿著控制面依賴鏈條走</td> <td>用 dependency map 排定恢復優先順序</td> </tr> <tr> <td>回退後錯誤率快速下降</td> <td>變更關聯度高</td> <td>凍結同類變更、啟動增量復原</td> </tr> <tr> <td>事故中角色交接反覆切換</td> <td>ownership 與指揮節奏不足</td> <td>固定 single incident commander 與節點交接</td> </tr> </tbody> </table> <h2 id="事故路徑">事故路徑</h2> <ol> <li>控制面 deployment tool 變更進入生產。</li> <li>設定錯誤導致共享控制路徑失真。</li> <li>Workers KV 與關聯產品出現控制操作異常。</li> <li>團隊透過回退與修正逐步收斂錯誤。</li> <li>事故後回寫 deployment guardrail、decision log 與 evidence 管線。</li> </ol> <h2 id="可回寫控制面">可回寫控制面</h2> <table> <thead> <tr> <th>控制面</th> <th>暴露缺口</th> <th>回寫方向</th> </tr> </thead> <tbody> <tr> <td>變更範圍治理</td> <td>控制面變更可快速全域擴散</td> <td>強制 staged rollout + canary gate</td> </tr> <tr> <td>決策紀錄</td> <td>假設與回退條件在事中容易遺失</td> <td>強制使用 [8.19] 決策欄位模板</td> </tr> <tr> <td>證據回寫</td> <td>教訓停留在事件敘事</td> <td>連到 [8.22]，把證據回寫到 observability/reliability 控制面</td> </tr> <tr> <td>規則推送安全閘門</td> <td>變更工具缺少風險分級</td> <td>回寫 [6.24] 的 rule rollout gate</td> </tr> </tbody> </table> <h2 id="下一步路由">下一步路由</h2> <ul> <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/rule-rollout-safety-gate/" data-link-title="6.24 規則推送安全閘門" data-link-desc="把規則、策略與控制面配置推送從部署步驟升級為可靠性 gate，避免小變更在秒級擴散成全網事故。">6.24 Rule Rollout Safety Gate</a></li> <li>觀測治理模型： <a href="https://tarrragon.github.io/blog/backend/04-observability/observability-operating-model/" data-link-title="4.18 Observability Operating Model" data-link-desc="定義 platform / service team / on-call 對訊號、dashboard、alert 與成本的 ownership">4.18 Observability Operating Model</a></li> </ul> <h2 id="引用源">引用源</h2> <ul> <li><a href="https://blog.cloudflare.com/cloudflare-incident-on-october-30-2023/">Cloudflare incident on October 30, 2023</a></li> </ul>這起事件的核心責任判讀是：控制面工具設定錯誤會跨越產品邊界擴散，事故第一步要先切斷擴散路徑，再做功能修復。若先把症狀拆成多個產品問題，恢復速度會被 shared dependency 拖慢。

事故摘要

Cloudflare 在 2023-10-30 發生控制面相關事故，根因涉及 deployment tool 的設定錯誤，影響 Workers KV 與相關服務操作路徑。表面症狀可出現在多個產品面向，但本質是共享控制面變更帶來的連鎖失效。

這類事故和單點 runtime bug 不同。關鍵不是「哪個服務先報錯」，而是「哪個共用控制點先失真」。

判讀訊號

訊號 代表意義 第一波決策價值
多產品控制操作同時不穩 shared control dependency 可能失效 先盤點同批變更與共用工具
功能異常分布不均 擴散沿著控制面依賴鏈條走 用 dependency map 排定恢復優先順序
回退後錯誤率快速下降 變更關聯度高 凍結同類變更、啟動增量復原
事故中角色交接反覆切換 ownership 與指揮節奏不足 固定 single incident commander 與節點交接

事故路徑

  1. 控制面 deployment tool 變更進入生產。
  2. 設定錯誤導致共享控制路徑失真。
  3. Workers KV 與關聯產品出現控制操作異常。
  4. 團隊透過回退與修正逐步收斂錯誤。
  5. 事故後回寫 deployment guardrail、decision log 與 evidence 管線。

可回寫控制面

控制面 暴露缺口 回寫方向
變更範圍治理 控制面變更可快速全域擴散 強制 staged rollout + canary gate
決策紀錄 假設與回退條件在事中容易遺失 強制使用 [8.19] 決策欄位模板
證據回寫 教訓停留在事件敘事 連到 [8.22]，把證據回寫到 observability/reliability 控制面
規則推送安全閘門 變更工具缺少風險分級 回寫 [6.24] 的 rule rollout gate

下一步路由

引用源

]]>