本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 部署後活動
<a name="post-deployment"></a>

彈性是持續進行的程序，在部署應用程式之後，必須繼續評估應用程式的彈性。部署後活動的結果，例如持續的恢復能力評估，可能需要您重新評估和更新稍早在恢復能力生命週期中執行的一些恢復能力活動。

## 執行彈性評估
<a name="conducting-resilience-assessments"></a>

將應用程式部署到生產環境之後，評估彈性不會停止。即使您有明確定義且自動化的部署管道，變更有時也可能直接發生在生產環境中。此外，您可能還未在部署前彈性驗證中考量到一些因素。 [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)提供一個集中位置，可讓您評估部署的架構是否符合您定義的 RPO 和 RTO 需求。您可以使用此服務執行應用程式的彈性隨需評估、自動化評估，甚至將它們整合到您的 CI/CD 工具中，如 AWS 部落格文章所述[使用 AWS Resilience Hub 和 持續評估應用程式彈性 AWS CodePipeline](https://aws.amazon.com/blogs/architecture/continually-assessing-application-resilience-with-aws-resilience-hub-and-aws-codepipeline/)。自動化這些評估是最佳實務，因為它有助於確保您持續評估生產環境中的彈性狀態。

## DR 測試
<a name="dr-testing"></a>

在[階段 2：設計和實作](stage-2.md)中，您開發了災難復原 (DR) 策略作為系統的一部分。在第 4 階段期間，您應該測試您的 DR 程序，以確保您的團隊為事件做好充分準備，並且您的程序可如預期般運作。您應該定期測試所有 DR 程序，包括容錯移轉和容錯回復，並檢閱每個練習的結果，以判斷是否應該以及如何更新系統的程序，以獲得最佳可能的結果。當您最初開發 DR 測試時，請提前安排測試，並確保整個團隊了解預期的內容、如何衡量結果，以及根據結果使用哪些意見回饋機制來更新程序。在您熟練執行排定的 DR 測試之後，請考慮執行無預警的 DR 測試。實際災難不會按排程發生，因此您需要隨時準備執行您的計劃。不過，未宣布並不表示未計劃。主要利益相關者仍需要規劃事件，以確保有適當的監控，並且客戶和關鍵應用程式不會受到負面影響。

## 漂移偵測
<a name="drift-detection"></a>

即使有自動化和明確定義的程序，生產應用程式中組態仍可能發生非預期的變更。若要偵測應用程式組態的變更，您應該有偵測*偏離*的機制，這是指與基準組態的偏差。若要了解如何偵測 AWS CloudFormation 堆疊中的偏離，請參閱 AWS CloudFormation 文件中的[偵測堆疊和資源的未受管組態變更](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)。若要偵測應用程式 AWS 環境中的偏離，請參閱 AWS Control Tower 文件[中的偵測和解決偏離 AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/drift.html)。

## 合成測試
<a name="synthetic-testing"></a>

[合成測試](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)是建立可在生產環境中依排程執行的可設定軟體的程序，以模擬最終使用者體驗的方式測試應用程式的 APIs。這些測試有時稱為 *Canary*，參考該術語在煤礦中的原始用途。合成測試通常可在應用程式遭受中斷時提供早期警告，即使損害是部分或間歇性，灰色[故障](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html)的情況也是如此。

## 混沌工程
<a name="chaos-engineering"></a>

混沌工程是一種系統化程序，涉及刻意以風險緩解的方式讓應用程式遭受破壞性事件、密切監控其回應，以及實作必要的改進。其目的是驗證或挑戰有關應用程式處理此類中斷能力的假設。混沌工程不會讓這些事件變成可能，而是讓工程師能夠在受控環境中協調實驗，通常是在低流量期間，並提供隨時可用的工程支援來有效緩解。

混沌工程從了解正在考慮的應用程式的正常操作條件開始，稱為*穩定狀態*。從那裡，您將制定一個假設，詳細說明應用程式在發生中斷時的成功行為。 您執行實驗，涉及刻意注入中斷，包括但不限於網路延遲、伺服器故障、硬碟錯誤和外部相依性損害。然後，您可以分析實驗的結果，並根據經驗增強應用程式的彈性。此實驗是改善應用程式各種層面的寶貴工具，包括其效能，並發現可能一直隱藏的潛在問題。此外，混沌工程有助於顯示可觀測性和警示工具的缺陷，並協助您精簡它們。它也有助於縮短復原時間並增強操作技能。Chaos 工程可加速採用最佳實務，並培養持續改進的思維。最終，它可讓團隊透過定期練習和重複來建立和磨練他們的營運技能。

AWS 建議您在非生產環境中啟動混沌工程工作。您可以使用 [AWS Fault Injection Service (AWS FIS)](https://aws.amazon.com/fis/) 執行混沌工程實驗，其中包含一般用途的故障以及獨有的故障 AWS。此全受管服務包含停止條件警示和完整許可控制，因此您可以輕鬆採用具有安全性和可信度的混沌工程。