概觀

比較彈性測試與混沌工程

彈性測試是確定性的。也就是說，它會驗證已在應用程式中實作的復原機制的已知特性，例如斷路器、重試、容錯移轉或備用。它確認了這些應用程式元件如何吸收受控中斷，並且對使用者的影響最小或沒有影響。因此，彈性測試著重於驗證注入應用程式元件的已知失敗模式，以產生通過/失敗結果。您應該在管道中持續執行彈性測試，以確保不會將迴歸引入彈性狀態。在彈性測試中，您通常不會對實際元件執行測試，但模擬特定元件APIs。此方法允許在受控環境中對故障案例進行一致且可重現的測試，使其適用於自動化管道整合和迴歸測試。

相反地，混沌工程是非確定性的。也就是說，它以假設為基礎，並驗證您的心理模型，了解應用程式及其相依性 （人員、程序和技術） 如何吸收、適應意外故障模式，最終從中復原。因此，混沌工程著重於未知失敗模式的end-to-end驗證，目標是及早發現瑕疵，並在這些瑕疵變成大規模事件之前進行修復。混沌工程促進持續學習，應該透過單獨的混沌管道或臨機操作實驗進行練習，讓您能夠隨時執行多個實驗，而不會阻礙開發人員部署程式碼的生產力。

混沌工程程序通常從混沌的遊戲日開始，這是一個專用事件，讓團隊刻意將受控的故障或故障注入其應用程式。遊戲日是漸進的：它從較低層級的環境 （例如開發或測試） 開始，隨著可信度建置逐漸進展到更高層級的環境 （例如預備和生產前）。透過有系統地在這些環境中移動，團隊可以在到達生產環境之前，驗證其系統是否可正確容忍注入的故障。這種有條不紊的進展可確保在生產環境中執行混沌實驗時，團隊對其系統的恢復能力建立了很大的信心。遊戲日程序是一種主動方法，用於識別應用程式架構和操作實務中的弱點和漏洞，同時消除意外生產中斷期間的學習壓力。

混沌工程的值

複雜系統在現今的世界中是無處不在的。從金融市場到醫療保健，它們在我們生活的許多層面都扮演重要角色。我們預期這些系統永遠可以運作。不過，複雜系統通常容易受到可能造成重大後果的意外事件和行為所影響。組織需要規劃中斷，而不是想知道是否會發生。他們可以將案例測試套用至其關鍵或關鍵任務商業服務，藉此達成此目的。這是混沌工程發揮作用的地方。

Chaos 工程提供一種方法來管理複雜的系統，以協助降低風險並改善彈性。準備混沌實驗的過程需要團隊制定有關其系統行為的假設，這加深他們對系統如何建置及其操作方式的了解。此準備通常會顯示可能未發現的心理差距、架構洞見和操作知識。透過進一步了解複雜的系統如何對故障做出反應，混沌工程可提高系統設計和管理的透明度和責任。組織執行混沌工程的頻率越高，操作的準備就越好。混沌工程可協助您建立最佳實務，以設計可承受元件故障的彈性應用程式，而不會影響使用者。這可確保關鍵應用程式在預期的服務水準和影響容錯範圍內運作，同時持續增強團隊對其系統的知識。

為不利條件做好準備

當您建置時 AWS，會使用不同類型的服務，包括區域服務，例如 Amazon Elastic Compute Cloud (Amazon EC2)、區域服務，例如 Amazon Simple Storage Service (Amazon S3)、全域服務，例如 AWS Identity and Access Management (IAM)、第三方軟體即服務 (SaaS) 服務，以及內部部署服務。每種類型的服務都會公開您需要考慮的不同失敗網域。如何準備自我引發的事件，或組織無法控制的第三方所造成的事件？

為了協助了解應用程式可能如何回應不良情況，您可以使用 AWS Fault Injection Service (AWS FIS)。 AWS FIS 是一種全受管服務，以受控方式執行故障注入實驗。您可以使用此服務注入 AWS提供的案例，例如可用區域電源中斷和跨區域連線問題，或透過將服務提供的各種故障動作鏈結在一起來建置您自己的實驗。 AWS FIS 可讓您的團隊持續練習並了解其應用程式如何在偵測到常見故障時做出反應並修復缺陷。

練習受控制的混沌工程

受控混沌實驗的主要原則如下：

若要成功擴展混沌工程，您必須以控制的方式實作混沌實驗。使用 時 AWS FIS，您可以使用 Amazon CloudWatch 警示建立停止條件。您可以將這些條件合併到實驗範本中，以確保實驗在超出界限時停止，並復原回其最後已知狀態。 AWS FIS 也提供安全控制桿。當您使用這些控制桿時， 會 AWS FIS 停止並復原 帳戶中所有執行中的實驗 AWS 區域，包括多帳戶實驗，並防止新的實驗啟動。這可防止在特定期間發生故障注入，例如交易時間、銷售事件或產品啟動，或回應應用程式運作狀態警示。安全控制桿會保持接合狀態，直到手動分離為止。

當您進行混沌實驗時，您應該定義保護措施，以防止環境中的不良副作用，特別是如果實驗可能會影響生產中的應用程式時。當您規劃實驗時，請預測它可能對環境中其他應用程式造成的任何負面影響。例如，其他應用程式可能會從屬於實驗一部分的應用程式接收錯誤的訊息、遇到高請求量，或遇到資源爭用，如果他們共用基礎設施。在執行實驗之前，請記錄這些風險並解決任何已知或不可接受的問題。