實現云彈性的一種方法—系統和混沌測試
譯文【51CTO.com快譯】
在當今數字技術時代,停工就意味著停機,構建彈性云結構勢在必行。例如,在新冠疫情期間,IT 維護團隊不能再在本地重新啟動數據中心的任何服務器。如果本地硬件出現故障,這可能會導致訪問所有數據或軟件的巨大障礙,使得生產率下降,并造成整體業務損失。然而,針對上述問題的解決方案,是將所有 IT 操作傳輸到云基礎架構,通過遠程成員提供 24/7 全天候技術支持來確保安全。云在這里本質上是神一樣的存在。
最近,一些公司已經充分利用云的潛力,因此,云操作的可觀察性 和彈性變得勢在必行,因為停機現在等同于斷開連接和業務損失。
在當今技術驅動的商業經濟中,想象云失敗將是災難性的。任何故障和中斷都會導致多米諾骨牌效應,影響公司的系統性能。因此,對于組織和公司來說,通過混亂和系統化的測試將云彈性構建到云結構中變得十分重要。在這篇文章中,我將帶您了解彈性和可觀察性的含義,以及為什么彈性和混沌測試對于避免停機至關重要。
為避免云故障,企業必須通過連續和混亂的方式對其云架構進行測試,從而在其云架構中構建彈性。
1.) 可觀察性
可觀察性可以通過兩個方面來理解。一個是通過控制理論, 它將可觀察性解釋為通過推斷系統的外部輸出來理解系統狀態的過程。另一個方面解釋了可觀察性的學科和方法,即用來測量不確定性和未知數的學科和方法。
云計算的可觀察性是利用跨領域、規模和服務的端到端監控的先決條件。可觀察性不應與監控相混淆,因為監控用于了解應用程序中問題和異常的根本原因。 監控會告訴你什么時候出現了問題,而可觀察性可幫助你了解出現問題的原因。它們各自服務于不同的目的,但肯定是相輔相成的。
云系統需要具備可觀察性和彈性,以確保更少的停機時間、 更快的應用程序速度等。
2.) 彈性
穩定 |
是否開啟/可訪問? |
可靠性 |
它會以應有的方式始終如一地工作,并且在我們需要的時候工作嗎? |
可用性 |
它是否可以隨時隨地可靠地訪問? |
彈力 |
系統如何應對挑戰以使其可靠可用? |
每個遷移到云基礎設施的企業都應確保并測試其系統的穩定性、可靠性、可用性和彈性,其中彈性位于層次結構的頂部。穩定性是保證系統和服務器不會經常崩潰;可用性通過將應用程序分布在不同的位置以減輕工作量,從而確保系統正常運行時間;可靠性確保云系統的高效運行和可用性。但是,如果企業想要解決不可預見的問題,那么不斷測試彈性就變得必不可少。
彈性是指預期會出現的問題,并且系統會以某種方式進行測試,以解決和調整該問題。 系統的彈性不是自動實現的。彈性的系統承認復雜的系統和問題,并努力逐步采取措施應對錯誤。它需要不斷測試,以減少問題或故障的影響。持續測試可避免云故障,確保更高的性能和效率。
可通過現場彈性設計和利用混沌測試等系統測試方法實現彈性。
常規測試及其不足
傳統測試 確保應用程序直接安裝和遷移到云系統中,并監控它們的性能和工作效率。足以確保云系統不會根據設計改變應用程序的性能和功能。
常規測試是不夠的,因為它在發現潛在的隱藏架構問題和異常方面效率低下,一些故障僅在觸發特定條件時才可見。
云的高可用承諾
Scott Guthrie 在談到云的未來和前景時說,“我們看到數字空間的發展速度逐漸加快。云讓我們能夠按照摩爾定律的速度進行擴展,也可以使用更少的基礎設施快速擴展”。由于疫情人們被迫在家工作,云投資并沒有激增。但是,由于這種前所未有的需求,所有超大規模企業都必須引入節流和優先級控制,這違背了公共云的按需彈性原則。
在中斷和停機方面,公共云并非不可挑戰。例如,谷歌最近的宕機時間導致 Gmail 和 Youtube 等多項谷歌服務停止,這表明公共云也不一定沒有系統宕機。因此,我想說,大流行為彈性云系統增加了幾個額外的視角:
1. 即使在線流量意外激增,系統也必須平穩運行且保持不變
2. 系統必須尋找替代方法來管理功能和資源池,以防云提供商拒絕或限制額外的資源分配請求。
3. 該系統應該是可訪問且安全的,以處理未知位置并轉移到混合工作環境(可能是網絡防火墻之外的許多端點)。
疫情突出了對彈性云系統進行連續測試和混亂測試的價值。一個有彈性且經過全面測試的系統將能夠以安全、無縫和穩定的方式管理額外擁塞的流量。 為了檢測未知數,需要彈性測試 和彈性工程 。
單獨的云原生應用程序設計無法實現彈性
在公共云世界中,由于云提供商提供的基礎能力、多層/多種技術基礎架構以及云系統的分布式特性存在差距,因此 應用程序彈性 架構的構建更為關鍵。 即使云提供商提供了底層基礎架構的可用性和彈性,這也可能導致云應用程序以不可預測的方式失敗。
為建立良好的應用彈性基礎, 在設計過程中,云工程師應采用以下策略來測試、評估和描述應用程序層彈性:
1. 利用架構良好的框架實現總體解決方案架構,并采用云本機功能實現可用性和災難恢復。
2. 與云架構師和技術架構師協作,定義可用性目標,并派生應用程序和數據庫層彈性屬性。
A. 與威脅建模一起,根據預期或觀察到的使用模式定義假設的故障模型,并根據業務影響為這些故障模式建立測試計劃。
通過采用架構驅動的測試方法,組織可以在上線之前深入了解云應用程序彈性的基本級別, 并為性能修復活動分配足夠的時間。但是仍然需要測試應用程序是否存在未知故障以及 云原生應用程序設計中多個故障點。
混亂測試與工程
混亂測試是一種有意將壓力和異常引入云結構的方法,以系統地測試系統的彈性。
首先,混亂測試不能替代實際的測試系統。 這只是衡量錯誤的另一種方式。通過向系統引入降級,IT 團隊可以看到發生了什么以及它是如何反應的。重要的是,測試可以幫助測試人員衡量系統的可觀察性和彈性方面的差距,這些是最初被忽略的事情。
Netflix 在 2011 年遷移到云系統期間首先效仿了這種測試方法,此后,它有效地建立了這種方法。混亂測試揭示了低效率,并引導開發團隊改變、衡量和提高彈性,并幫助云架構師更好地理解和改變他們的設計。
持續、系統和混亂的測試增加了云基礎設施的彈性,從而有效地增強了系統的彈性,并最終增強了管理和運營團隊對他們正在構建的系統的信心。
彈性企業必須部分或全部在云 基礎架構上創建彈性 IT 系統。
使用混沌和站點可靠性工程可幫助企業在以下方面保持彈性:
• 云和基礎架構彈性
• 通過持續監控實現數據彈性。
• 通過確保用戶界面在高壓力條件下保持穩定,實現用戶和客戶體驗彈性
• 通過將安全性與治理和控制機制相結合來增強網絡安全性
• 對基礎架構、應用程序和數據的彈性支持
為了建立完整的應用程序彈性,除了前面提到的云應用程序設計方面,解決方案架構師還需要采用架構模式,允許注入特定故障以觸發內部錯誤,從而在開發和測試階段模擬故障。
故障觸發器的一些常見示例包括響應延遲、資源占用、網絡中斷、瞬態條件、用戶的極端行為等等。
1. 針對常見的已識別場景,制定持續監控、管理和自動化事件響應計劃
2. 建立混沌測試框架和環境
3. 注入具有不同嚴重性和組合的故障,并監控應用層行為
4. 識別異常行為并重復上述步驟以確認關鍵性
如何進行混沌測試
混沌測試可以通過在云結構的任何七層中引入異常來完成,這有助于評估對恢復力的影響。
當 Netflix 在 2011 年成功宣布其彈性工具 Chaos Monkey 時,許多開發團隊將其用于混沌工程測試系統。還有另一個由軟件工程師開發的工具測試系統 Gremlin, 基本上也在做同樣的事情。但是,如果在 COVID-19 的環境中執行混沌測試,可以使用 GameDay 來實現。這會引發異常情況,其中流量突然增加;例如,客戶同時訪問移動應用程序。GameDay 的目標不僅是測試彈性,還要提高系統的可靠性。
確保成功進行混沌測試所需采取的步驟如下:
1. 識別: 識別系統中的關鍵弱點,并創建一個假設和預期結果。工程師需要識別和評估在假設框架內注入什么樣的故障。
2. 模擬: 根據真實事件在生產過程中注入異常。這樣可以確保將系統中可能發生的情況包括在內。這可能導致應用程序或網絡中斷或節點故障。
3. 自動化:自動化這些實驗,可能是每小時/每周等。這確保了連續性,這是混沌工程中的一個不利因素。
4. 持續反饋和改進: 實驗有兩種結果。可以確保彈性或發現需要解決的問題。這兩種方法都是很好的結果,你可以從中獲取反饋來完善您的系統。
在系統上引發錯誤攻擊和序列的其他具體方法可能是:
1. 增加網絡延遲
2. 切斷計劃任務
3. 切斷微服務
4. 斷開系統與數據中心的連接
總結
在當今的數字時代,增強云彈性以提高應用程序的有效性能變得勢在必行。在項目的生命周期中,持續和系統的測試是必不可少的,但同時也要確保在公共云負擔過重的時候云彈性。 通過防止長時間的中斷和未來的中斷,企業可以節省大量成本,此外還可以確保為客戶提供服務的持久性。因此,混沌工程成為大規模分布式系統的一種必然。
【51CTO譯稿,合作站點轉載請注明原文譯者和出處為51CTO.com】