本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
REL08-BP03 整合彈性測試作為部署的一部分
通過有意識地在系統中引入故障來整合彈性測試，以在破壞性情況下衡量其能力。彈性測試與通常整合在部署週期中的單元和功能測試不同，因為它們專注於識別系統中的意外故障。雖然從生產前的彈性測試整合開始是安全的，但應設定一個目標，在生產環境中實作這些測試，作為演練日的一部分。
預期成果：彈性測試有助於建立系統承受生產降級能力的信心。實驗可識別會導致故障的弱點，這有助於您改善系統，以自動且有效地緩解故障和降級。
常見的反模式：
-
在部署過程中缺乏可觀測性和監控
-
依賴人類解決系統故障
-
品質不佳的分析機制
-
專注於系統中的已知問題，缺乏識別任何未知因素的實驗
-
可識別故障，但沒有解決方案
-
沒有調查結果和執行手冊文件
建立最佳實務的優勢：在部署中整合的彈性測試有助於識別系統中未知的問題，否則這些問題會被忽視，從而導致生產中停機。在系統中識別這些未知因素可協助您記錄調查結果、將測試整合到您的 CI/CD 程序中以及建置執行手冊，透過高效率、可重複的機制簡化緩解作業。
未建立此最佳實務時的曝險等級：中
實作指引
可以整合到系統部署中的最常見彈性測試表單是災難復原和混沌工程。
-
在任何重大部署中，包含災難復原計劃和標準操作程序 （SOPs） 的更新。
-
將可靠性測試整合至您的自動化部署管道。諸如 AWS Resilience Hub
的服務可整合到您的 CI/CD 管道 中，以建立持續的彈性評估，並在每次部署中自動進行評估。 -
在 中定義您的應用程式 AWS Resilience Hub。復原能力評估會產生程式碼片段，協助您將復原程序建立為應用程式的 AWS Systems Manager 文件，並提供建議的 Amazon CloudWatch 監控器和警示清單。
-
您的 DR 計劃和SOPs更新後，請完成災難復原測試，以確認它們是否有效。災難復原可協助您判斷是否可以在事件發生後還原系統並恢復正常操作。您可以模擬各種災難復原策略，並確定您的規劃是否足以滿足您的正常運行時間需求。常見的災難復原策略包括備份與還原、指示燈、冷待命、暖待命、熱待命和主動-主動式，而且成本和複雜性都有所不同。在災難復原測試之前，建議您定義復原時間目標 （RTO） 和復原點目標 （RPO），以簡化要模擬的策略選擇。 AWS 提供災難復原工具AWS Elastic Disaster Recovery
，例如協助您開始規劃和測試。 -
混沌工程實驗引入了系統中斷，例如網路中斷和服務故障。透過模擬受控故障，您可以發現系統的漏洞，同時控制注入故障的影響。就像其他策略一樣，在非生產環境中使用諸如 AWS Fault Injection Service
等服務執行受控故障模擬，以在部署到生產環境之前獲得信心。
資源
相關文件：
相關影片：
