這是一次極其罕見且荒謬的事件：許多 AWS 用戶在登入控制台後，發現本月預估帳單竟然達到了數百萬、數十億，甚至高達數兆美元。其中一個每月支出不到 5 美元的帳戶，預估金額竟跳到了 17 億美元。雖然最終確認這只是顯示錯誤，實際扣款並未受影響，但這次事件揭露了大型雲端平台在計費系統、監控機制以及端到端測試上的嚴重漏洞。
對於工程師而言，比起那些天文數字，更值得關注的是這次故障的技術成因以及 AWS 在應對過程中的失效鏈條。
計費系統的單位錯誤：為什麼會出現兆級帳單
這次問題的核心在於計費管線（Billing Pipeline）中的單位定價錯誤。在雲端計費邏輯中，服務端會發送計量數據（Metering Data，例如傳輸了多少 GB 數據），而計費系統則會將這些數據與定價計畫（Pricing Plan）進行關聯計算。
根據技術社群的分析，這類 Bug 通常發生在單位轉換失效時。舉例來說，如果原本的定價是每 GB 5 美分，但系統在設定時遺漏了 GB 這個單位，導致計費系統將其視為每 Byte 5 美分。由於 1 GB 等於 10 億個 Byte，原本微小的費用會瞬間被放大 10 億倍，導致帳單金額在短短幾小時內飆升至天文數字。
監控失效：當警報響了卻沒有人收到通知
這次事件最令工程實務者不安的是 AWS 內部監控的失效。根據 AWS Health Dashboard 的說明，系統在問題發生後不久就偵測到了成本異常（Cost Anomalies），但這些警報並沒有觸發後續的自動化攔截程序，也沒有通知到負責的工程團隊。
結果是，AWS 內部系統知道出錯了，但工程師卻在四個多小時後，直到收到大量客戶投訴才意識到問題。這形成了一個諷刺的對比：大多數公司在 AWS 上發生成本失控時，都是靠客戶端的警報來發現，而這次輪到 AWS 自己的計費系統失控，同樣得靠客戶告知才發現。
端到端測試的缺失
為什麼這種明顯的單位錯誤能進入生產環境？這涉及到軟體工程中常見的測試盲區：缺乏端到端測試（End-to-End Testing）。
在大型組織中，開發計量數據的團隊與開發計費系統的團隊通常分屬不同部門，管理鏈條不同。團隊 A 可能測試了計量數據輸出正確，團隊 B 測試了計費邏輯在接收正確數據時運作正常，但兩者之間缺乏一個完整的整合測試來驗證：當新的定價配置套用後，最終產出的帳單金額是否在合理範圍內。
應對措施的二次傷害
在嘗試修復過程中，AWS 的處理方式也帶來了額外的風險。當初步的配置回滾（Rollback）失效後，AWS 選擇暫停所有預估帳單的生成，並暫時關閉了全平台的預算（Budgets）與成本異常警報。
這對許多採取 FinOps（雲端財務管理）實務的企業造成了衝擊。許多公司會將 AWS 的成本警報與自動化腳本掛鉤，例如當費用異常時自動發送 Slack 通知，甚至觸發 SCP（服務控制策略）來強制關閉部分工作負載以止損。當 AWS 全域關閉這些警報時，企業的成本安全網被強制拆除，導致他們在故障期間處於完全盲視的狀態。
給工程師的實務啟示
這次事件提醒我們，任何監控系統本身也是一個具有失效模式的依賴項。
首先，不要過度依賴單一平台的自動化警報。如果你的業務對成本極其敏感，除了平台內建的 Budget 警報，應考慮建立獨立的第三方監控或基於實際 API 抽樣的驗證機制。
其次，在設計涉及金錢或資源配額的系統時，必須建立合理的邊界檢查（Boundary Check）。例如，如果單一帳戶的預估費用突然增長 10 億倍，系統應觸發硬性熔斷（Circuit Breaker）而非僅僅發送通知。
最後，這再次強調了整合測試的重要性。單元測試能保證邏輯正確，但只有端到端測試能保證不同模組在協作時不會因為一個單位的定義差異而導致災難性的結果。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。