> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh-hant/2025/w43-lessons-learned-from-the-aws-incident.md).

# W43-從 AWS 事故學習到的教訓

上週 AWS 出現持續 15 小時的重大故障，全球超過 1000 家企業服務中斷，造成數十億美元經濟損失。學習到一個深刻的教訓：再精妙的工程設計，也敵不過一個單點依賴。

這次事故發生在 AWS 最關鍵的 us-east-1 區域。根因是 DynamoDB 的 DNS 管理自動化出現競態缺陷，誤清空了區域端點的 IP 記錄，導致解析失敗。us-east-1 並不是一個普通的數據中心，它是 AWS 全球基礎設施的“中樞神經系統”，幾乎所有區域的公共控制平面都依賴於此，包括 EC2 調度、NLB、Lambda 等關鍵服務，因此引發了級聯崩潰。

更諷刺的是，事故發生 75 分鐘後，AWS 狀態頁仍顯示 “一切正常”——因為 CloudWatch 本身也依賴 DynamoDB，監控系統跟著失明。

恢復過程也並不輕鬆。DNS 記錄雖能快速修復，但 DynamoDB 是核心控制節點，EC2 調度器需要為數萬臺服務器重建租約，網絡管理器要清理擁塞並分發延遲狀態，負載均衡器因誤判實例健康狀況反覆將其剔除。最終 AWS 只能關閉自動健康檢查與故障轉移，人工干預才讓系統避免不斷雪崩。

看完熱鬧後，回顧一下我們自己的服務。最可能埋下系統性單點隱患的，反而是業務迭代關注度不高的基礎服務。例如信息化入口、驗證類服務，其中信息化入口業務邏輯簡單，但爆破面巨大，掌握著 80% 的流量。這類服務的工程設計，應遵循最小依賴、最大熵原則，保持極致的清晰與簡單。

信息化入口這種小組件，對有野心的工程師有一定誘惑性，因為有突出工程挑戰：維護面向多個技術棧的多版本，發版週期長依賴業務宿主頁面。回看今年我們在信息化入口做的事情，我覺得有必要復盤一下是不是選擇了一個正確的方向。為了實現動態更新，縮短業務迭代的發佈週期，提升發佈靈活性。在工程上做了很多工作，引入了更多的依賴、設計了更複雜的架構，同時也降低了回滾生效效率。按照這個方向，動態化解決完了可能下一步就要搞一個動態組件跑在各個容器裡，收斂信息化入口的實現版本，做到高動態高複用。只是當信息化入口過了迭代高峰後， feature 就有了債務的影子。

我反思今年的注意力還是在訓練工程能力上，給大家創造些鍛鍊花拳繡腿的機會，沒有足夠左移到提升技術決策質量上。在決策時缺乏清晰的框架、事實依據和邏輯推演。唯一做對的一件事，我認為是引入了民主、集體決策。

每個工程師的成長過程都會經歷這樣的認知習慣，厭惡冗餘、抽象一切、強調複雜，以此判斷技術含量。要勇於拋棄這些中段水平的認知，追求經過權衡後的清晰與簡單，就像 Unix 設計哲學，要品味高級貨。