本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
部署後活動
彈性是持續進行的程序，在部署應用程式之後，必須繼續評估應用程式的彈性。部署後活動的結果，例如持續彈性評估，可能需要您重新評估和更新您在彈性生命週期中稍早執行的一些彈性活動。
執行彈性評估
將應用程式部署到生產環境之後，評估彈性不會停止。即使您有明確定義且自動化的部署管道，變更有時也可能直接發生在生產環境中。此外，您可能還未在部署前彈性驗證中考慮一些因素。 AWS Resilience Hub提供一個集中位置，可讓您評估部署的架構是否符合您定義的 RPO 和 RTO 需求。您可以使用此服務執行應用程式的彈性隨需評估、自動化評估，甚至將它們整合到您的 CI/CD 工具中，如 AWS 部落格文章中所述使用 AWS Resilience Hub 和 持續評估應用程式彈性 AWS CodePipeline
DR 測試
在階段 2：設計和實作中，您開發了災難復原 (DR) 策略做為系統的一部分。在第 4 階段期間，您應該測試您的 DR 程序，以確保您的團隊為事件做好充分準備，並且您的程序可如預期般運作。您應該定期測試所有 DR 程序，包括容錯移轉和容錯回復，並檢閱每個練習的結果，以判斷系統的程序是否應該以及如何更新，以獲得最佳結果。當您最初開發 DR 測試時，請事先安排測試，並確保整個團隊了解預期的內容、如何衡量結果，以及根據結果使用哪些意見回饋機制來更新程序。在您熟練執行排定的 DR 測試之後，請考慮執行未宣布的 DR 測試。實際災難不會按排程發生，因此您需要隨時準備執行您的計劃。不過，無預警並不表示未計劃。主要利益相關者仍需要規劃事件，以確保有適當的監控，並且客戶和關鍵應用程式不會受到負面影響。
漂移偵測
即使有自動化和明確定義的程序，生產應用程式中組態仍可能發生非預期的變更。若要偵測應用程式組態的變更，您應該有偵測偏離的機制，這是指與基準組態的偏差。若要了解如何偵測 AWS CloudFormation 堆疊中的偏離，請參閱 AWS CloudFormation 文件中的偵測堆疊和資源的未受管組態變更。若要偵測應用程式 AWS 環境中的偏離，請參閱 AWS Control Tower 文件中的偵測和解決偏離 AWS Control Tower。
合成測試
合成測試是建立可設定的軟體的程序，這些軟體會依排程在生產環境中執行，以模擬最終使用者體驗的方式測試應用程式的 APIs。這些測試有時稱為 Canary，參考 一詞在煤礦探勘中的原始用途。合成測試通常可在應用程式遭受中斷時提供早期警告，即使損害是部分或間歇性，灰色故障的情況也是如此。
混沌工程
混沌工程是一種系統化程序，涉及刻意以風險緩解的方式讓應用程式遭受破壞性事件、密切監控其回應，以及實作必要的改進。其目的是驗證或挑戰有關應用程式處理此類中斷能力的假設。混沌工程不讓這些事件變成可能，而是讓工程師能夠在受控環境中協調實驗，通常是在低流量期間，並提供隨時可用的工程支援來有效緩解。
混沌工程從了解正在考慮的應用程式的正常操作條件開始，稱為穩定狀態。從那裡，您制定了一個假設，詳細說明了應用程式在發生中斷時的成功行為。您執行實驗，涉及刻意注入中斷，包括但不限於網路延遲、伺服器故障、硬碟錯誤和外部相依性損害。然後，您可以分析實驗的結果，並根據您的學習增強應用程式的彈性。此實驗是改善應用程式各種層面的寶貴工具，包括其效能，並發現可能一直隱藏的潛在問題。此外，混沌工程有助於顯示可觀測性和警示工具的不足，並協助您進行精簡。它也有助於縮短復原時間並增強操作技能。Chaos 工程可加速最佳實務的採用，並培養持續改進的思維。最後，它可讓團隊透過定期練習和重複來建立和磨練他們的營運技能。
AWS 建議您在非生產環境中啟動混沌工程工作。您可以使用 AWS Fault Injection Service (AWS FIS)
