多年來，每當 Cloudflare 發生了影響客戶的服務中斷情況，我們很快就會撰寫部落格，詳細地說明發生了什麼事情、原因是什麼以及我們正在採取什麼措施來解決服務中斷。而今天的文章稍微有點另類。它描述了單個客戶的網站因 Cloudflare 採取錯誤措施而無法正常工作的事情。
儘管客戶並未以任何方式被禁止使用 Cloudflare，也未失去帳戶存取權，但他們的網站卻無法正常工作了。而網站之所以無法正常工作，是因為 Cloudflare 在我們和他們的原始伺服器之間對頻寬進行了節流處理。結果就是網站無法使用了。
由於這種節流處理並不常見，客戶支援團隊內部有點搞不清狀況。他們錯誤地以為，客戶受到限制是因為違反了我們的自助服務訂閱協議第 2.8 條，該協議禁止使用我們的自助 CDN 來提供過多的非 HTML 內容（如影像和視訊），而不使用包含這些服務的付費方案（例如，這是為了防止有人在 Cloudflare 上構建影像託管服務並耗用大量頻寬；對於這種使用案例，我們提供了付費的影像和視訊方案）。
但是，這位客戶並沒有違反第 2.8 條，而且他們既是付費客戶，也是節流流量正在通過的 Cloudflare Workers 的付費客戶。這種節流本不應該發生。此外，客戶也不需要升級至其他方案層級。
此事件引發了 Cloudflare 內部的多個工作流，以確保團隊之間的溝通更順暢，防止此類事件發生，並確保 Cloudflare 與客戶之間的溝通更加清晰。
在解釋我們自己的錯誤以及原因之前，我們想先向客戶道歉。我們意識到了這件事情所產生的嚴重影響，也瞭解了我們未能達到客戶期望的原因。在這篇部落格文章中，我們想要解釋一下發生了什麼事情，而更重要的是，我們將要做出哪些改變以確保這種情況再也不會發生。
背景
2 月 2 日，我們在阿什本資料中心的一位待命網路工程師收到警報，稱與 Equinix IX 聯繫的介面出現壅塞。雖然這並不是一個異常警報，但有兩個原因讓它引起了我們的注意。首先，這是連續第二天發生這種情況，其次，壅塞的原因是突然出現了極度的流量暴增。
負責此事的工程師發現，客戶的網域 tardis.dev 導致了 Cloudflare 與他們的原始網路（一個儲存產品提供商）之間的流量突然暴增。由於此壅塞發生在連線到外部對等節點的實體介面上，因此對我們的許多客戶和同儕產生了直接影響。像這樣的連接埠壅塞通常會導致封包遺失、輸送量緩慢，而且延遲會比平常更久。雖然我們已經針對介面壅塞問題部署了自動緩解措施，但在這種情況下，緩解措施並不能夠徹底消除這種影響。
來自此客戶的流量從平均每秒 1,500 個要求和每個要求 0.5 MB 的承載，突然增加到每秒 3,000 個要求（2 倍）和每個要求超過 12 MB 的承載（25 倍）。
Cloudflare 和原始網路之間發生了壅塞。快取並未發生，因為要求都是流向原始網路的不重複 URL，因此我們無法從緩存提供服務。
Cloudflare 工程師決定應用節流機制，以防止該區域從其原始網路提取如此多的流量。我們對這項措施的態度非常明確：Cloudflare 沒有既定的流程來對耗用大量頻寬的客戶進行節流處理，也不打算建立這樣的流程。這個補救措施是個錯誤，並未獲得批准，我們對此深感遺憾。
我們在啟動節流 12 小時 53 分鐘後，透過內部向上呈報取消了節流。
下一步行動
為了確保不再發生類似事件，我們正在制定清晰的規則以緩解類似的問題。針對客戶網域（無論是否付費）採取的任何措施都需要經過多個層級的核准，並與客戶溝通清楚。我們將改進工具來反映這一點。針對流量暴增影響連結的情況，我們有很多方式來定型流量，而在這種情況下，我們本可以應用另一種緩解措施的。
我們正在修改服務條款，以更好地反映客戶目前在我們的平台上提供的服務類型。我們還致力於以簡單的語言向使用者解釋自助方案所允許的行為。作為一間以開發人員為先且將透明度作為核心原則之一的公司，我們知道我們可以在這一點上做得更好。稍後，我們會再撰寫一篇部落格文章，專門闡述這些變更。
我們對這項措施以及它對其他 Cloudflare 客戶造成的困惑，再次向客戶致以歉意。