AWS 中斷暴露了 DevOps 韌性的弱點

2021年12月7日的 Amazon Web Services (AWS) 中斷事件嚴重干擾了來自廣泛商業範圍的服務超過五個小時，並凸顯了企業對互聯網交付服務的依賴程度。這次中斷主要影響了美國東部的網絡服務，但其含義是普遍的：這提醒了許多企業盲目忽視了不要把所有的蛋放在一個籃子里的古老格言，反而依賴於一個具有單點故障的提供商。

從航空訂票系統到流媒體視頻再到電子商務的服務在這次中斷期間被干擾，造成了數百萬美元的收入損失和無數的生產力損失小時。這次中斷更有趣的方面之一是它對來自協作供應商如 Slack、Trello、Asana 和 Smartsheet 等服務的影響——許多開發和 DevOps 團隊已經依賴的工具。

此外，AWS 的核心服務，如公司的 Elastic Compute 和 DynamoDB 雲工具也受到影響，嚴重阻礙了使用這些服務的許多第三方服務和業務流程。雖然中斷的明顯受害者如亞馬遜自己的電子商務運營是眾所周知的，但有一個令人不安的底流：對 DevOps 框架及其用戶的干擾。

到目前為止，AWS 對於中斷的根本原因相當閉口不談；然而，對於 DevOps 社區仍有許多教訓要學，必須提出的問題，例如“在 IaaS/SaaS 中斷期間 DevOps 過程能否存活？”以及“可以將多雲故障轉移解決方案烘焙進 DevOps 構建的應用中嗎？”

對於這些問題沒有簡單的答案，但這次中斷強調了需要理解部署的 DevOps 系統的底層架構和框架。例如，許多 DevOps 社區的開發者如何接受 SaaS 工具來加速開發過程並餵養 CI/CD 管道。SaaS 應用程序如代碼掃描器、管道編排甚至 IDE 在 DevOps 世界中已變得普遍。但是否有人問過如果這些工具中的任何一個失敗會發生什麼？

此外，對於開發過程中 SaaS 工具的依賴導致 DevOps 開發者創建的應用程序中創造了潛在的責任。DevOps 應用程序已經依賴於 API，經常由微服務驅動，並且經常部署到在 SaaS 上運行的容器中。如果這些元素中的任何一個變得非功能性，許多應用程序可能會失敗，最終讓開發者解釋為什麼他們創建了具有單點故障的應用程序。

展望未來，DevOps 社區需要認真審視他們框架的組件並確定是否有任何單點故障，包括他們的 IaaS/SaaS 提供商。雖然可能無法解決每一個問題，但這次中斷教會了我們關於如果沒有人費心建立使用工具的清單並考慮到任何一個工具的故障如何影響工作流程，開發過程可能變得多麼脆弱的教訓。有無數例子顯示外部單一組件的故障如何影響應用的功能，而根本原因的發現過程則花了幾天甚至幾週的時間。這主要是歸咎於不僅缺乏知識，還缺乏對使用的組件的可見性。

這些教訓可以擴展到開發過程本身，在那裡最佳實踐的挖掘單點故障可以擴展到應用程序本身。利用這種智慧從理解軟件物料清單（SBoM）的概念開始，這是一份支持文件，對應用程序的提供者越來越重要。一個正確定義的 SBoM 揭示了烘焙進應用中的所有組件（庫、API 等），可以用作定義弱點可能存在的地圖。

對於 DevOps 社群而言，最近的 AWS 中斷已經成為一個警鐘，呼籲他們內省，發現他們正在建設的應用程序可能如何成為問題的一部分。隨著連續性和韌性成為 IT 和商業領域的主要話題，DevOps 從業者開始探索如何支持這兩個業務關鍵需求的時機已經到來。將責任歸咎於他人的日子必須結束，如果依賴軟件的企業想要成長，就需要有人在發生中斷時提供解答，並從這些中斷中學習，以創建更具韌性的應用程序。