雲集中化的隱性成本
當 AWS 的 US-East-1 區域在 10 月底陷入癱瘓，一周後 Microsoft Azure 也出現故障時，這再次鮮明地提醒我們，即使是世界上最大的雲供應商也無法倖免。 AWS Route 53 中的一個簡單的 DNS 故障會向外蔓延，導致應用程序癱瘓、數據庫服務中斷，並提醒我們我們的技術基礎設施對少數雲區域的依賴程度。由於“無意的租戶配置更改”，Azure 中斷進一步凸顯了其中一些系統的不穩定性，再次證明了微小的變化可以產生相當大的影響。 CyberCube 估計 AWS 中斷的成本可能在 38 至 5.81 億美元之間，因此該中斷造成的經濟和運營損失怎麼強調都不為過。對於缺乏資源來吸收數小時或多天停機時間的中小型組織來說尤其如此。對於許多企業來說，這一最新的顛覆暴露了雲集中化的隱性成本：當一個區域出現問題時，一切都可能陷入停滯。停電是不可避免的。甚至 AWS 自己的 CTO 也說過同樣的話：系統會失敗，因此它們的架構必須能夠預期並承受失敗。然而，太多組織的設計仍然認為雲本身是萬無一失的。他們假設冗餘、備份和恢復是自動內置的，但發現事實並非如此時為時已晚。好消息是，可以在下一次故障發生之前建立彈性。 停電前多樣化：不要等待下一次停電 第一道防線的概念很簡單，但執行起來卻很困難。在災難來臨之前，您必須實現多元化。將其視為投資組合。你不會把所有的錢都存入一個賬戶；它涵蓋多種選擇，為您的投資提供最大的成功機會。這意味著針對多個可用區或區域的故障進行設計。 AWS 甚至在其“AWS Well-Architected”指南中建議這樣做。 一個架構良好的系統應該能夠在幾秒鐘內將流量從一個區域轉移到另一個區域（例如，US-East-1 到 US-West-1）。停機很少會同時導致多個區域癱瘓，因此多區域架構仍然是防止停機的最有效防禦措施之一。轉向多雲並消除浪費的支出一些組織甚至更進一步，將工作負載分配給多個雲提供商。多雲設計提供了額外的彈性，但它們需要很高的複雜性和技術技能，並且可能會產生更高的成本。這裡的關鍵是從小處開始，僅將最關鍵的工作負載或控制平面移至冗餘位置。然後，一旦您評估了所涉及的複雜性和成本，就可以進行擴展。 大多數公司會發現單一云中的多區域多元化更實用，但無論他們選擇哪條路線，心態都必須相同：假設某些事情會發生故障，並做出相應的計劃。同樣重要的是識別並消除浪費的技術支出。並非每個工作負載都需要在最昂貴的高可用性配置中運行。通過適當的業務影響分析，組織可以將投資與風險結合起來，在失敗會真正損害業務的地方進行支出，並在力所能及的地方進行節約。對於較小的公司來說，了解什麼是關鍵任務以及什麼可以等待恢復上線是實現經濟高效的彈性的關鍵。 用於管理數據中心和網絡彈性的 BCDR 如果您的組織已經在不同的地理區域甚至不同的雲提供商之間實現多元化，那麼認識到彈性並不因這些基礎設施選擇而結束，這一點至關重要。這就是業務連續性和災難恢復 (BCDR) 計劃發揮作用的地方。多元化有助於減少風險敞口。但是，如果沒有經過測試的計劃來應對出現問題的情況，即使是架構最完善的環境也會出現問題。當你為任何事情做好準備時，沒有什麼可以阻止你。 無論您的組織的 BCDR 計劃是什麼，建立彈性的一個簡單方法是定期測試這些計劃。 Netflix 著名地使用了一種被他們稱為 Chaos Monkey 的工具，該工具可以隨機禁用生產實例，以確保系統能夠承受意外故障。目前還不清楚混沌猴子會如何或何時發動襲擊。通過故意注入混亂，團隊必須構建能夠快速恢復並在壓力下繼續運行的容錯架構。這是一個極端的例子。較小的組織可以從每年一次或兩次的測試開始，隨著組織的發展完善計劃。較大的組織可能希望在追隨 Netflix 的腳步之前更頻繁地運行此類測試，例如每季度一次。不管怎樣，撣掉活頁夾上的灰塵，並對該計劃進行升級，以適應任何情況。 具有前瞻性的韌性心態 正如我們不會在一座橋樑上建設城市一樣，我們也不應該將數字經濟錨定在少數超大規模區域上。最近的 AWS 和 Microsoft 服務中斷並不是第一次，也肯定不會是最後一次。這些與下一個之間的區別將在於組織的準備程度。 集中化的隱性成本不僅僅是停機時間，還有停機時間。這是現代數字系統中固有的脆弱性。如果您不預先花錢來針對故障和中斷進行架構設計，從長遠來看，您會損失更多。但通過智能架構和嚴格的投資，我們可以將過去的脆弱性轉化為未來的彈性，並從長遠來看節省成本。 下一次停電不是是否會發生的問題，而是何時發生的問題。問題是，你準備好還是措手不及？ Juan Orlandini 是 Insight Enterprises 的首席技術官。 Fast Company 改變世界創意獎的最終截止日期是太平洋時間 12 月 12 日星期五晚上 11:59。今天申請。
已发布: 2025-12-01 21:50:00
