# REL 12. 如何測試可靠性？
<a name="rel-12"></a>

在將工作負載設計為可彈性應對生產壓力之後，進行測試是確認其依設計運作並提供預期之彈性的唯一方法。

**Topics**
+ [

# REL12-BP01 使用程序手冊調查失敗
](rel_testing_resiliency_playbook_resiliency.md)
+ [

# REL12-BP02 執行事件後分析
](rel_testing_resiliency_rca_resiliency.md)
+ [

# REL12-BP03 測試可擴展性和效能需求
](rel_testing_resiliency_test_non_functional.md)
+ [

# REL12-BP04 使用混沌工程測試彈性
](rel_testing_resiliency_failure_injection_resiliency.md)
+ [

# REL12-BP05 定期進行演練日
](rel_testing_resiliency_game_days_resiliency.md)

# REL12-BP01 使用程序手冊調查失敗
<a name="rel_testing_resiliency_playbook_resiliency"></a>

 藉由在程序手冊中記錄調查程序，對無法充分理解的失敗情境進行快速一致的回應。程序手冊是為識別造成失敗情境的因素所執行的預先定義步驟。在識別或呈報問題之前，任何程序步驟的結果都會用來決定要採取的後續步驟。

 程序手冊是您必須進行的主動規劃，以便能夠有效地採取回應動作。在生產環境中遇到程序手冊未涵蓋的故障情境時，請先解決問題 (解決燃眉之急)。然後返回並查看您為解決問題所採取的步驟，並使用這些步驟在程序手冊中新增新的項目。

 請注意，程序手冊用於回應特定事件，而執行手冊則用於實現特定成果。執行手冊通常用於例行活動，而程序手冊則用於回應非例行事件。

 **常見的反模式：**
+  在不知道診斷問題或回應事件的程序之情況下，規劃部署工作負載。
+  調查事件時，未規劃即決定要向哪些系統收集日誌和指標。
+  指標和事件的保留時間過短，無法用以擷取資料。

 **建立此最佳實務的優勢：**擷取程序手冊可確保流程得到一致遵循。有系統地編纂您的程序手冊可限制手動活動引入錯誤。程序手冊自動化可免除團隊成員介入的需要，或在介入開始時提供其他資訊，從而縮短事件回應時間。

 **未建立此最佳實務時的曝險等級：**高 

## 實作指引
<a name="implementation-guidance"></a>
+  使用程序手冊識別出問題。程序手冊是調查問題的書面程序。透過在程序手冊中記錄程序，對失敗情境做出一致且迅速的回應。程序手冊包含的資訊和指南必須能夠讓技能嫻熟的人員得以收集適用資訊、識別潛在的失敗來源、隔離故障，以及判斷成因 (執行事件後分析)。
  +  將程序手冊實做為程式碼。透過撰寫程序手冊指令碼，以程式碼形式執行操作，確保一致性並限制和減少手動程序引起的錯誤。程序手冊可由多個指令碼組成，這些指令碼代表識別成因時可能需要的不同步驟。執行手冊活動可以做為程序手冊活動的一部分被調用或執行，或者可能提示執行程序手冊，以回應已識別的事件。
    +  [透過 AWS Systems Manager 自動化您的操作程序手冊](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/) 
    +  [AWS Systems Manager 執行命令](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) 
    +  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
    +  [什麼是 AWS Lambda？](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 
    +  [什麼是 Amazon EventBridge？](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
    +  [使用 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 

## 資源
<a name="resources"></a>

 **相關文件：**
+  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
+  [AWS Systems Manager 執行命令](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) 
+  [透過 AWS Systems Manager 自動化您的操作程序手冊](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/) 
+  [使用 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [使用 Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 
+  [什麼是 Amazon EventBridge？](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
+  [什麼是 AWS Lambda？](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 

 **相關範例：**
+  [使用程序手冊和執行手冊將操作自動化](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/) 

# REL12-BP02 執行事件後分析
<a name="rel_testing_resiliency_rca_resiliency"></a>

 審查影響客戶的事件，並識別成因和預防性行動項目。使用此資訊來開發緩解措施，以限制或防止事件再次發生。制定可快速有效回應的程序。適當地傳達成因和為目標受眾量身打造的糾正措施。建立一種可以根據需要將這些原因傳達給其他人的方法。

 評估現有測試找不到問題的原因。如果測試尚未存在，請為此案例新增測試。

 **預期成果：**您的團隊擁有一致且商定的方法來處理事件後分析。一種機制是[錯誤糾正 (COE) 流程](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)。COE 程序可幫助您的團隊識別、了解和解決事件的根本原因，同時還能建置機制和防護機制，以限制相同事件再次發生的可能性。

 **常見的反模式：**
+  尋找成因，但未繼續深入尋找其他潛在問題和減輕方法。
+  僅確定人為錯誤原因，不未嘗試可防止人為錯誤發生的任何培訓或或自動化。
+  專注於追究責任，而不是了解根本原因，造成恐懼文化並阻礙開放的溝通 
+  無法分享見解，只讓一小群人知道事件分析調查結果，讓其他人無法從學到的教訓中受益 
+  沒有機制可擷取機構知識而失去寶貴的見解，因為組織不會以更新過的最佳實務形式保存所學到的教訓，並導致重複發生相同或類似根本原因的事件 

 **建立此最佳實務的優勢：**進行事件後分析並分享結果，以讓其他實作了相同成因的工作負載減輕風險，並讓工作負載能夠在事件發生前實作減輕措施或自動復原。

 **未建立此最佳實務時的曝險等級：**高 

## 實作指引
<a name="implementation-guidance"></a>

 良好的事件後分析提供了機會，為系統中其他地方使用的架構模式問題提出通用解決方案。

 COE 程序的基石是記錄和解決問題。建議您定義標準化方式來記錄關鍵的根本原因，並確保加以檢視和解決。為事件後分析程序指派明確的擁有權。指定負責監督事件調查和後續跟進的團隊或個人。

 鼓勵專注於學習和改進的文化，而不是追究責任的文化。強調目標是預防未來的事件，而不是懲罰個人。

 開發用於進行事件後分析的明確定義程序。這些程序應概述要採取的步驟、要收集的資訊，以及要在分析期間解決的關鍵問題。徹底調查事件，跳脫出直接原因以找出根本原因和成因。使用諸如*[五個為什麼](https://en.wikipedia.org/wiki/Five_whys)*等技巧深入研究潛在問題。

 維護事件分析所學教訓的儲存庫。此機構知識可以做為未來事件和預防工作的參考。分享事件後分析的調查結果和見解，並考慮舉行公開邀請的事件後檢討會議，以討論學到的教訓。

### 實作步驟
<a name="implementation-steps"></a>
+  在進行事件後分析時，請確保事件後分析不會讓相關人員受到責備。這可讓事件中的相關人員平心靜氣看待建議的糾正措施，並促進誠實地自我評估與跨團隊合作。
+  定義標準化方式來記錄重要問題。這類文件的範例結構如下：
  +  發生了什麼？ 
  +  對客戶和您的業務有什麼影響？ 
  +  根本原因是什麼？ 
  +  您擁有什麼可以提供支援的資料？ 
    +  例如，指標和圖表 
  +  對關鍵支柱的影響有哪些 (尤其是安全性)？ 
    +  建立工作負載的架構時，您可依照業務環境，在各支柱之間作出權衡。這些業務決策可以讓您了解工程設計的優先順序。您可以選擇在開發環境中以可靠性做為代價最佳化成本，或者針對關鍵任務解決方案，以較高成本達到可靠性的最佳化。安全始終是首要工作，因為您必須保護客戶。
  +  您獲得了什麼教訓？ 
  +  您正在採取什麼糾正措施？ 
    +  動作項目 
    +  相關項目 
+  建立用於進行事件後分析的明確定義標準作業程序。
+  設定標準化的事件報告程序。全面記錄所有事件，包括初始事件報告、日誌、通訊，以及事件期間採取的行動。
+  請記住，發生事件時不見得會有中斷情形。事件也可能是幾乎錯過的情況，或是系統雖以意想不到的方式執行，卻仍可履行其業務功能。
+  請根據意見回饋和學到的教訓，持續改善事件後分析程序。
+  擷取知識管理系統中的關鍵調查結果，並考慮任何應新增至開發人員指南或部署前檢查清單的模式。

## 資源
<a name="resources"></a>

 **相關文件：**
+  [為什麼您應該制定錯誤糾正 (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/) 

 **相關影片：**
+ [Amazon 成功失敗的方法](https://aws.amazon.com/builders-library/amazon-approach-to-failing-successfully/)
+ [AWS re:Invent 2021 - Amazon 建置者資料中心：Amazon 的卓越營運](https://www.youtube.com/watch?v=7MrD4VSLC_w)

# REL12-BP03 測試可擴展性和效能需求
<a name="rel_testing_resiliency_test_non_functional"></a>

 使用諸如負載測試等技術來驗證工作負載符合擴展和效能需求。

 在雲端，您可以隨需為工作負載建立正式作業規模的測試環境。您不必依賴縮減規模的測試環境，這可能會導致正式作業行為的預測不準確，而是可以使用雲端來佈建測試環境，以確切反映您預期的正式作業環境。此環境可協助您以更準確模擬您的應用程式面臨的真實狀況來進行測試。

 除了效能測試之外，務必確認您的基本資源、擴展設定、服務配額和彈性設計能夠在負載下如預期運作。這種整體方法可確認您的應用程式即使在最嚴苛的條件下，仍能可靠地擴展和執行。

 **預期成果：**您的工作負載即使在承受尖峰負載的情況下，仍維持其預期行為。您主動解決可能隨應用程式發展和演進而出現的任何效能相關問題。

 **常見的反模式：**
+  您使用的測試環境與正式作業環境相似程度不高。
+  您將負載測試視為單獨的一次性活動，而不是部署持續整合 (CI) 管道整體的一部分。
+  您未定義明確且可衡量的效能需求，例如回應時間、輸送量和可擴展性目標。
+  您在負載情況不切實際或不足的情況下執行測試，而且未能測試尖峰負載、突發性峰值和持續高負載。
+  您未透過超過預期的負載限制來對工作負載進行壓力測試。
+  您使用不適當或不適合的負載測試和效能分析工具。
+  您缺乏全方位的監控和警示系統可用來追蹤效能指標並偵測異常。

 **建立此最佳實務的優勢：**
+  負載測試可協助您在付諸正式作業之前，找出系統中潛在的效能瓶頸。當您模擬正式作業層級流量和工作負載時，就可找出系統處理負載時可能遇到困難層面，例如，回應時間緩慢、資源限制或系統故障。
+  當您在各種負載條件下測試系統時，您可以更了解支援工作負載所需的資源需求。此資訊可協助您做出有關資源分配的明智決策，並防止資源過度佈建或佈建不足。
+  若要找出潛在的故障點，您可以觀察工作負載在高負載條件下的運作情形。此資訊可協助您透過適時實作容錯機制、容錯移轉策略和備援措施，來改善工作負載的可靠性和彈性。
+  您可及早找出和解決效能問題，這有助於避免系統中斷、回應時間緩慢和使用者不滿意所帶來代價高昂的後果。
+  測試期間收集的詳細效能資料和分析資訊，可協助您解決正式作業時可能出現的效能相關問題。這樣就能加快回應和解決事件，進而降低對使用者和組織營運的影響。
+  在某些產業中，主動效能測試可協助讓工作負載符合合規標準，進而降低遭受懲罰或產生法律問題的風險。

 **未建立此最佳實務時的曝險等級：**高 

## 實作指引
<a name="implementation-guidance"></a>

 第一步是定義全面的測試策略，涵蓋擴展和效能需求的所有層面。首先，請根據您的業務需求，例如輸送量、延遲長條圖和錯誤率，清楚定義工作負載的服務層級目標 (SLO)。接著設計一套測試，可模擬從平均用量到突發尖峰和持續尖峰負載的各種負載案例，並確認工作負載的行為符合您的 SLO。這些測試應該自動化，並整合到您的持續整合和部署管道中，以及早發現開發過程中的效能迴歸。

 為了有效測試擴展和效能，請投資正確的工具和基礎設施。這包括可產生實際使用者流量的負載測試工具、識別瓶頸的效能分析工具，以及追蹤關鍵指標的監控解決方案。重要的是，您應確認您的測試環境在基礎設施和環境條件方面盡量與正式作業環境相符，以使測試結果盡可能準確。為了更容易可靠地複寫和調整類似正式作業的設定，請使用基礎設施即程式碼和容器型應用程式。

 擴展和效能測試是持續進行的程序，而不是一次性的活動。實作全面監控和警示，以追蹤應用程式正式作業時的效能，並使用這些資料持續改進您的測試策略和最佳化工作。定期分析效能資料，以找出新興問題、測試新的擴展策略並實作最佳化，以提高應用程式的效率和可靠性。只要您採用迭代方法並持續從正式作業資料中學習，就可以確認您的應用程式能夠適應不斷變化的使用者需求，並隨著時間維持彈性和最佳效能。

### 實作步驟
<a name="implementation-steps"></a>

1.  確立明確且可衡量的效能需求，例如回應時間、輸送量和可擴展性目標。這些需求應以工作負載的使用模式、使用者期望和業務需求為基礎。

1.  選取並設定負載測試工具，以準確地模擬正式作業環境中的負載模式和使用者行為。

1.  設定盡量與正式作業環境相符的測試環境，包括基礎設施和環境條件，以提高測試結果的準確性。

1.  建立測試套件，涵蓋從平均用量模式到尖峰負載、快速尖峰和持續高負載等各種案例。將這些測試整合到您的持續整合和部署管道中，以及早發現開發過程中的效能迴歸。

1.  執行負載測試以模擬實際使用者流量，並了解應用程式在不同負載條件下的行為。若要對您的應用程式進行壓力測試，請超過預期的負載並觀察其行為，例如回應時間變慢、資源耗盡或系統故障，這樣做有助於識別應用程式的中斷點並納入擴展策略。透過逐步增加負載來評估工作負載的可擴展性，並衡量效能影響以了解擴展限制並規劃未來容量需求。

1.  實作全面的監控和警示，以追蹤效能指標、偵測異常情況，並在超出閾值時初始化擴展動作或通知。

1.  持續監控和分析效能資料，以識別需要改進的層面。對您的測試策略和最佳化工作採取迭代方法。

## 資源
<a name="resources"></a>

 **相關的最佳實務：**
+  [REL01-BP04 監控和管理配額](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_monitor_manage_limits.html) 
+  [REL06-BP01 監控工作負載的所有元件 (產生)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html) 
+  [REL06-BP03 傳送通知 (即時處理和警示)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_monitor.html) 

 **相關文件：**
+  [負載測試應用程式](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html) 
+  [AWS 上的分散式負載測試](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) 
+  [應用程式效能監控](https://aws.amazon.com/what-is/application-performance-monitoring/) 
+  [Amazon EC2 測試政策](https://aws.amazon.com/ec2/testing/) 

 **相關範例：**
+  [AWS 上的分散式負載測試 (GitHub)](https://github.com/aws-solutions/distributed-load-testing-on-aws) 

 **相關工具：**
+  [Amazon CodeGuru Profiler](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html) 
+  [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 
+  [Apache JMeter](https://jmeter.apache.org/) 
+  [K6](https://k6.io/) 
+  [Vegeta](https://github.com/tsenart/vegeta) 
+  [Hey](https://github.com/rakyll/hey) 
+  [ab](https://httpd.apache.org/docs/2.4/programs/ab.html) 
+  [wrk](https://github.com/wg/wrk) 
+ [AWS 上的分散式負載測試](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/)

# REL12-BP04 使用混沌工程測試彈性
<a name="rel_testing_resiliency_failure_injection_resiliency"></a>

 定期在位於或盡可能鄰近生產環境的環境中執行混沌試驗，以了解您的系統因應不良狀況的能力。

 **預期成果：**

 除了以彈性測試驗證您的工作負載在某事件期間的已知預期行為以外，還可以藉由在故障注入試驗中套用混沌工程或注入非預期的負載，來定期驗證工作負載的彈性。結合混沌工程與彈性測試，您將可確信工作負載在經歷元件失敗後仍可存留，並且可在 (幾乎) 不受影響的情況下從非預期的中斷復原。

 **常見的反模式：**
+  針對彈性進行設計，但未確認工作負載在錯誤發生時的整體運作情形。
+  未曾在真實的情況和預期的負載下試驗。
+  未將試驗視為程式碼或透過開發週期加以維護。
+  未在 CI/CD 管道中與部署以外執行混沌試驗。
+  在決定要以哪些錯誤進行試驗時，未使用過去的事故後分析。

 **建立此最佳實務的優勢：**注入錯誤以驗證工作負載的彈性，可讓您確信在發生真正的錯誤時，彈性設計的復原程序將可發揮作用。

 **未建立此最佳實務時的曝險等級：**中 

## 實作指引
<a name="implementation-guidance"></a>

 混沌工程可讓您的團隊有能力以受控的方式，持續在服務供應商、基礎架構、工作負載和元件層級注入真實的中斷 (模擬)，且對客戶 (幾乎) 不會造成影響。它可讓您的團隊從錯誤中學習，並且觀察、測量及改善工作負載的彈性，以及驗證在事件發生時會引發提醒，且團隊會收到通知。

 持續執行時，混沌工程可能會凸顯您工作負載中的缺陷，且若未解決，可能會對可用性與操作產生負面影響。

**注意**  
混沌工程是在系統中進行試驗的專業領域，旨在建立對系統承受生產環境中紊亂情況的能力的信心。– [混沌工程的原則](https://principlesofchaos.org/) 

 如果系統能夠承受這些中斷，則應將混沌試驗視為自動化迴歸測試來維護。此時，您應在系統開發生命週期 (SDLC) 和 CI/CD 管道中執行混沌試驗。

 若要確定您的工作負載可以承受元件失敗，請在試驗中注入真實事件。例如，進行遺失 Amazon EC2 執行個體或容錯移轉主要 Amazon RDS 資料庫執行個體的試驗，並驗證您的工作負載未受影響 (或僅受到些微影響)。使用元件錯誤的組合，模擬可用區域的中斷可能導致的事件。

 對於應用程式層級的錯誤 (例如當機)，您可以從記憶體和 CPU 用盡之類的壓力源開始著手。

 為了驗證由於間歇性網路中斷導致的外部相依性的[備用或容錯移轉機制](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/)，您的元件應在指定的時間內 (可延續數秒到數小時) 阻止對第三方供應商的存取來模擬這類事件。

 其他降級模式可能會導致功能降低和回應速度緩慢，而往往會導致服務中斷。這種降級的常見原因是關鍵服務的延遲增加和不可靠的網路通訊 (丟包)。以這些錯誤 (包括延遲、已捨棄訊息和 DNS 失敗等聯網影響) 進行的試驗，可包含無法解析名稱、無法連線到 DNS 服務，或無法建立相依服務的連線等情境。

 **混沌工程工具：**

 AWS Fault Injection Service (AWS FIS) 是用來執行故障注入試驗的全受管服務，這些試驗可作為 CD 管道的一部分，或未於管道以外。AWS FIS 很適合在混沌工程演練日期間使用。它支援跨不同類型的資源同時引入故障，包括 Amazon EC2、Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS) 和 Amazon RDS。這些錯誤包括終止資源、強制執行容錯移轉、施壓於 CPU 或記憶體、限流，以及封包遺失。由於它與 Amazon CloudWatch 警示整合，因此您可以將停止條件設定為防護機制，以在試驗導致非預期的影響時將其回復。

![\[圖表顯示 AWS Fault Injection Service 與 AWS 資源整合，以允許您對工作負載執行故障注入試驗。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/images/fault-injection-simulator.png)


故障注入試驗也有數個第三方選項。其中包括開放原始碼工具，例如 [Chaos Toolkit](https://chaostoolkit.org/)、[Chaos Mesh](https://chaos-mesh.org/) 和 [Litmus Chaos](https://litmuschaos.io/)，以及諸如 Gemlin 之類的商業選項。為了擴大可以在 AWS 上注入的故障範圍，AWS FIS 會[與 Chaos Mesh 和 Litmus Chaos 整合](https://aws.amazon.com/about-aws/whats-new/2022/07/aws-fault-injection-simulator-supports-chaosmesh-litmus-experiments/)，使您可以在多種工具之間協調故障注入工作流程。例如，您可以在使用 AWS FIS 錯誤動作終止隨機選定百分比的叢集節點時，使用 Chaos Mesh 或 Litmus 錯誤對 Pod 的 CPU 執行壓力測試。

## 實作步驟
<a name="implementation-steps"></a>

1.  決定要將哪些錯誤用於試驗。

    評估您的工作負載設計是否有彈性。這類設計 (使用 [Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html) 的最佳實務建立) 會根據關鍵相依性、過去的事件、已知問題和合規性要求來考量風險。列出要用來維護彈性的每個設計元素，及其依設計要減輕的錯誤。如需有關建立此類清單的詳細資訊，請參閱 [Operational Readiness Review 白皮書](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)，指導您如何建立程序以防止先前事件再次發生。Failure Modes and Effects Analysis (FMEA) 程序提供了相關架構，讓您執行失敗的元件層級分析，並說明失敗對於工作負載有何影響。Adrian Cockcroft 在 [Failure Modes and Continuous Resilience](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5) 中詳盡地闡述了 FMEA。

1.  指派每個錯誤的優先順序。

    請從粗略的分類開始著手，例如高、中或低。若要評估優先順序，請考量錯誤的頻率，以及失敗對整體工作負載的影響。

    考量特定錯誤的頻率時，請分析此工作負載過去的資料 (如果可用)。如果無法使用，請使用在類似環境中執行的其他工作負載所包含的資料。

    考量特定錯誤的影響時，錯誤的範圍愈大，通常影響就愈大。另請考量工作負載的設計和用途。例如，對執行資料轉換和分析的工作負載而言，存取來源資料存放區的能力至關重要。在此情況下，您應優先執行存取錯誤以及限流存取和延遲注入的試驗。

    事故後分析是您了解失敗模式的頻率與影響的理想資料來源。

    請使用指派的優先順序，決定要先以哪些錯誤進行試驗，以及要以何種順序開發新的故障注入試驗。

1.  對於您所執行的每個試驗，均應依循下圖中的混沌工程和連續彈性飛輪操作。  
![\[混沌工程和連續彈性飛輪的圖表，顯示「改善」、「穩定狀態」、「假設」、「執行試驗」和「驗證」等階段。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/images/chaos-engineering-flywheel.png)

    

   1.  將穩定狀態定義為顯示出正常行為之工作負載的某種可測量輸出。

       工作負載的運作若可靠且符合預期，就會呈現穩定狀態。因此，在定義穩定狀態前，請先驗證工作負載的運作狀態良好。穩定狀態不一定表示在錯誤發生時完全不會影響到工作負載，因為有特定百分比的錯誤可能會在可接受的限制內。穩定狀態是您在試驗期間將觀察到的基準，如果您在下一步定義的假設未符合預期，就會凸顯異常。

       例如，支付系統的穩定狀態可定義為 300 TPS、成功率 99%、且來回時間為 500 毫秒的處理。

   1.  形成關於工作負載將如何回應錯誤的假設。

       良好的假設奠基於工作負載應如何減輕錯誤以維護穩定狀態。假設指出，在發生特定類型的錯誤時，系統或工作負載將持續保有穩定狀態，因為工作負載設有特定緩解機制。特定類型的錯誤和緩解機制應指定於假設中。

       以下是可用於假設的範本 (但也接受其他措辭)：
**注意**  
 如果發生*特定錯誤*，*工作負載名稱*工作負載將*描述緩解控制措施*，以維持*業務或技術指標的影響*。

       例如：
      +  若 Amazon EKS 節點群組中有 20% 的節點遭到關閉，Transaction Create API 會在 100 毫秒以內繼續提供第 99 個百分位數的請求 (穩定狀態)。Amazon EKS 節點將在五分鐘內復原，而 Pod 將在試驗起始後的八分鐘內進入排程並處理流量。提醒將在三分鐘內引發。
      +  單一 Amazon EC2 執行個體失敗發生時，訂單系統的 Elastic Load Balancing 運作狀態檢查將使 Elastic Load Balancing 僅將請求傳送至其餘運作狀態良好的執行個體，而 Amazon EC2 Auto Scaling 會取代失敗的執行個體，將伺服器端 (5xx) 錯誤的增量維持在 0.01% 以內 (穩定狀態)。
      +  主要 Amazon RDS 資料庫執行個體失敗時，供應鏈資料收集工作負載將進行容錯移轉並連線至待命 Amazon RDS 資料庫執行個體，以維持不到 1 分鐘的資料庫讀取或寫入錯誤 (穩定狀態)。

   1.  藉由注入錯誤來執行試驗。

       試驗依預設應處於安全模式，並獲得工作負載的容許。如果您確知工作負載將失敗，請不要執行試驗。混沌工程應該用來尋找已知的未知或未知的未知。*已知的未知*是您知道但不完全理解的事情，*未知的未知*是您不知道也不完全理解的事情。對您確知已失效的工作負載執行試驗，將不會為您帶來新的見解。試驗應經過審慎規劃、具有明確的影響範圍，並且提供在非預期的錯亂發生時可供套用的回復機制。如果您的盡職調查顯示工作負載應可承受試驗，請繼續執行試驗。有數種選項可用來注入錯誤。對於 AWS 上的工作負載，[AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) 提供許多預先定義的錯誤模擬，稱為[動作](https://docs.aws.amazon.com/fis/latest/userguide/actions.html)。您也可以定義在 AWS FIS 中執行的自訂動作 (使用 [AWS Systems Manager 文件](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html))。

       我們不鼓勵使用自訂指令碼來執行混沌試驗，除非指令碼有能力理解工作負載目前的狀態、能夠發出日誌，並且提供回復機制和停止條件 (若情況允許)。

       支援混沌工程的有效架構或工具集，應追蹤試驗目前的狀態、發出日誌，並提供回復機制以支援受控制的試驗執行。請先從 AWS FIS 這類已建立的服務著手，以便能以明確定義的範圍執行試驗，並且有安全機制可在試驗導入非預期的錯亂時回復試驗。要了解更多有關使用 AWS FIS 的實驗，請參閱 [Resilient and Well-Architected Apps with Chaos Engineering lab](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US)。此外，[AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) 會分析您的工作負載，並建立可供您選擇在 AWS FIS 中實作並執行的試驗。
**注意**  
 對於每一項試驗，您都應明確了解其範圍與影響。我們建議，錯誤應先在非生產環境中模擬，再於生產環境中執行。

       在可行的情況下，實驗應該使用 [Canary 部署](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db)在實際負載下在生產環境中執行，這可加速控制和實驗系統部署。在非尖峰時段執行試驗是很好的做法，可以減少首次在生產環境中試驗時的潛在影響。此外，如果使用實際的客戶流量會伴隨太高的風險，您可以對控制和試驗部署使用生產基礎架構上的綜合流量，來執行試驗。無法使用生產環境時，請在盡可能接近生產環境的生產前環境中執行試驗。

       您必須建立防護機制並加以監控，以確定試驗不會超出可接受的限制而影響到生產流量或其他系統。請建立停止條件，以在試驗達到您定義的防護機制指標閾值時，將試驗停止。其中應包括工作負載的穩定狀態指標，以及您對其注入錯誤的元件所適用的指標。[綜合監測](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (也稱為使用者 Canary)，是您在一般情況下應納入作為使用者代理的指標之一。[AWS FIS 的停止條件](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html)被視為試驗範本的一部分受到支援，每個範本最多可啟用五個停止條件。

       混沌的準則之一，是盡可能縮小試驗的範圍與影響：

       儘管容許某些短期負面影響是必要的，但混沌工程師有責任和義務將試驗的副作用控制在最低限度。

       驗證範圍和潛在影響的方法之一，是先在非生產環境中執行試驗，驗證停止條件的閾值在試驗期間會依預期啟動，且有可觀測性會捕捉例外狀況，而不是直接在生產環境中試驗。

       執行故障注入試驗時，請驗證所有的責任方都會及時獲得通知。請與營運團隊、服務可靠性團隊和客戶支援等適當的團隊通訊，讓他們知道試驗將於何時執行，且預期會有何情況。請為這些團隊提供通訊工具，以便他們在試驗執行期間發現任何不利影響時發出通知。

       您必須將工作負載及其基礎系統還原為原始的已知良好狀態。工作負載的彈性設計通常具有自癒能力。但某些錯誤設計或失敗的試驗可能會使您的工作負載處於非預期的失敗狀態。試驗結束時，您必須察覺到這一點，並還原工作負載和系統。透過 AWS FIS，您可以在動作參數內設定回復組態 (也稱為後置動作)。後置動作會將目標回復為動作執行前原有的狀態。無論是自動 (例如使用 AWS FIS) 還是手動，這些後續動作皆應為程序手冊的一部分，以說明如何偵測及處理失敗。

   1.  驗證假設。

      [混沌工程的原則](https://principlesofchaos.org/)提供了下列關於如何驗證工作負載穩定狀態的指引：

      著重於可測量的系統輸出，而不是系統的內部屬性。這類輸出在一段時間內的測量，會構成系統穩定狀態的代理。整體系統的輸送量、錯誤率和延遲百分位數，全都可能成為呈現穩定狀態行為的相關指標。著重於試驗期間的系統行為模式，混沌工程會驗證系統是否可運作，而非試著驗證其運作情形。

       在先前的兩個範例中，我們納入了伺服器端 (5xx) 錯誤的增量低於 0.01% 的穩定狀態指標，以及資料庫讀取和寫入錯誤不到一分鐘的穩定狀態指標。

       5xx 錯誤是工作負載的用戶端在失敗模式下將直接經歷的結果，因此可說是良好的指標。資料庫錯誤測量是錯誤的直接產物，因此有其效用，但應同時輔以用戶端影響測量，例如失敗的客戶請求或用戶端遇到的錯誤。此外，請在工作負載的用戶端直接存取的任何 API 或 URI 納入綜合監控 (也稱為使用者 Canary)。

   1.  改善工作負載設計的彈性。

       如果未維持穩定狀態，請採用 [AWS Well-Architected 可靠性支柱](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)的最佳實務，調查如何改進工作負載設計來緩解故障。可以在 [AWS 建置者資料中心](https://aws.amazon.com/builders-library/)中找到其他指引和資源，其中包含有關如何[改善運作狀態檢查](https://aws.amazon.com/builders-library/implementing-health-checks/)或[在應用程式碼中透過輪詢進行重試](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)等文章。

       這些變更實作完成後，請再次執行試驗 (在混沌工程飛輪中以虛線表示) 以判斷其有效性。若驗證步驟指出假設成立，則工作負載將處於穩定狀態，且週期會繼續。

1.  請定期執行試驗。

    混沌試驗是一個週期，而試驗應被視為混沌工程的一部分定期執行。當工作負載符合試驗的假設後，即應將試驗自動化，以將其視為 CI/CD 管道的迴歸部分持續執行。要了解如何執行此操作，請參閱有關[如何使用 AWS CodePipeline 執行 AWS FIS 實驗](https://aws.amazon.com/blogs/architecture/chaos-testing-with-aws-fault-injection-simulator-and-aws-codepipeline/)的部落格。這個關於 [CI/CD 管道中的經常性 AWS FIS 實驗](https://chaos-engineering.workshop.aws/en/030_basic_content/080_cicd.html)的實驗室可讓您親手操作。

    故障注入試驗也是演練日的一部分 (請參閱 [REL12-BP05 定期進行演練日](rel_testing_resiliency_game_days_resiliency.md))。演練日會模擬失敗或事件，以驗證系統、程序和團隊的應變。目的是實際執行在異常事件發生時團隊將要執行的動作。

1.  擷取並儲存試驗結果。

   故障注入試驗的結果必須擷取並保存。請納入所有必要資料 (例如時間、工作負載和條件)，以便後續能分析試驗結果和趨勢。舉例來說，結果可包括儀表板的螢幕擷取畫面、指標的資料庫產生的 CSV 傾印，或是試驗中的事件與觀察的手寫記錄。[使用 AWS FIS 試驗日誌記錄](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html)可以是此資料擷取的一部分。

## 資源
<a name="resources"></a>

 **相關的最佳實務：**
+  [REL08-BP03 將彈性測試整合為部署的一部分](rel_tracking_change_management_resiliency_testing.md) 
+  [REL13-BP03 測試災難復原實作以驗證實作](rel_planning_for_recovery_dr_tested.md) 

 **相關文件：**
+  [什麼是 AWS Fault Injection Service？](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) 
+  [什麼是 AWS Resilience Hub？](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) 
+  [混沌工程的原則](https://principlesofchaos.org/) 
+  [混沌工程：規劃您的第一個試驗](https://medium.com/the-cloud-architect/chaos-engineering-part-2-b9c78a9f3dde) 
+  [彈性工程：學習接受故障](https://queue.acm.org/detail.cfm?id=2371297) 
+  [混沌工程案例](https://github.com/ldomb/ChaosEngineeringPublicStories) 
+  [避免分散式系統的備用](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) 
+  [混沌試驗的 Canary 部署](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) 

 **相關影片：**
+ [AWS re:Invent 2020：使用混沌工程測試彈性 (ARC316)](https://www.youtube.com/watch?v=OlobVYPkxgg) 
+  [AWS re:Invent 2019：透過混沌工程提升彈性 (DOP309-R1)](https://youtu.be/ztiPjey2rfY) 
+  [AWS re:Invent 2019：在無伺服器環境中執行混沌工程 (CMY301)](https://www.youtube.com/watch?v=vbyjpMeYitA) 

 **相關工具：**
+  [AWS Fault Injection Service](https://aws.amazon.com/fis/) 
+ AWS Marketplace：[Gremlin 混沌工程平台](https://aws.amazon.com/marketplace/pp/prodview-tosyg6v5cyney) 
+  [Chaos Toolkit](https://chaostoolkit.org/) 
+  [Chaos Mesh](https://chaos-mesh.org/) 
+  [Litmus](https://litmuschaos.io/) 

# REL12-BP05 定期進行演練日
<a name="rel_testing_resiliency_game_days_resiliency"></a>

 舉辦演練日，以定期執行程序來回應影響工作負載的事件和損害。讓可能負責處理正式作業案例的相同團隊參與。這些練習有助於強制執行措施，以防止使用者因正式作業事件而受到影響。若您在實際情況下練習回應程序，就可以在實際事件發生之前識別和解決任何差距或弱點。

 演練日會在類似正式作業環境中模擬事件，以測試系統、程序和團隊回應。目的是實際執行在異常事件發生時，團隊會執行的動作。這些練習可幫助您了解何處有改善空間，並能協助發展組織處理事件和損害的經驗。這些練習應該定期進行，讓您的團隊能夠培養應對的肌肉記憶。

 演練日可讓團隊更有信心地處理實際發生的事件。熟悉演練的團隊更能夠快速偵測和回應各種案例。這可大幅改善整備度和彈性狀態。

 **預期成果：**您定期一致地進行彈性演練日。這些演練日會做為預期的正常業務營運。您的組織袍養出整備文化，當正式作業問題發生時，您的團隊已準備好有效地回應、有效率地解決問題，並減輕對客戶的影響。

 **常見的反模式：**
+  您記載您的程序，但未曾進行演練。
+  您未讓業務決策者參與測試練習。
+  您進行演練日，但未通知所有相關利害關係人。
+  您只專注於技術失敗，但未納入業務利害關係人。
+  您未將演練日所學到的經驗納入復原程序中。
+  您在發生失敗或錯誤時責怪團隊。

 **建立此最佳實務的優勢：**
+  增強回應技能：在演練日，團隊會在模擬事件的過程中練習其職責並測試其溝通機制，從而在實際情境中建立更協調且更有效率的回應。
+  識別和解決相依性：複雜的環境通常涉及各種系統、服務和元件之間繁複的相依性。演練日可協助您識別並解決這些相依性，以及確認您的關鍵系統和服務確實涵蓋在您的執行手冊程序內，並且能夠及時向上擴展或復原。
+  培養彈性的文化：演練日有助於培養組織內的彈性思維。當您納入跨職能團隊和利害關係人時，這些練習就能提升整個組織對彈性重要性的意識、協作和同理。
+  持續改進和適應：定期演練日可協助您持續評估和調整彈性策略，以便在面對不斷變化的情況時，保持關聯性和有效性。
+  提高對系統的信心：成功的演練日可協助您建立對系統承受中斷並從中復原能力的信心。

 **未建立此最佳實務時的曝險等級：**中 

## 實作指引
<a name="implementation-guidance"></a>

 設計並實作必要的彈性措施後，請舉行演練日來確認正式作業時，一切是否如規畫運作。特別是第一次的演練日，應納入所有團隊成員，且所有利害關係人和參與者都應事先收到有關日期、時間和模擬案例的通知。

 在演練日，參與的團隊會根據既定程序模擬各種事件和可能的案例。參與者會密切監控和評估這些模擬事件的影響。如果系統依設計運作，則自動偵測、擴展和自我修復機制應會啟動，而且對使用者的影響極少或無影響。如果團隊觀察到任何負面影響，則會透過自動化的方式或適用的執行手冊中記錄的手動介入方式，來復原測試並補救找到的問題。

 為了持續改善彈性，記錄並納入學到的經驗至關重要。此程序是一種*回饋循環*，採取系統化的方式從演練日獲得洞察，並利用它們來增強系統、程序和團隊功能。

 為了協助您重現系統元件或服務可能意外失敗的真實案例，請將模擬錯誤植入演練日練習中。團隊可以測試其系統的彈性和容錯能力，並在受控的環境中模擬其事件回應和復原程序。

 在 AWS 中，您的演練日可以使用基礎設施即程式碼，透過正式作業環境的複本來執行。透過此程序，您可以在類似正式作業環境的安全環境中進行測試。考慮使用 [AWS Fault Injection Service](https://aws.amazon.com/fis/) 來建立不同的失敗案例。使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 和 [AWS X-Ray](https://aws.amazon.com/xray/) 等服務來監控演練日的系統行為。使用 [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 來管理和執行程序手冊，並使用 [AWS Step Functions](https://aws.amazon.com/step-functions/) 來協調週期性演練日工作流程。

### 實作步驟
<a name="implementation-steps"></a>
+  **擬訂演練日計畫：**擬訂結構化的計畫，以定義演練日的頻率、範圍和目標。規畫和執行這些練習時，讓主要利害關係人和主題專家參與。
+  **準備演練日：**

  1.  指定做為演練日重點的重要關鍵業務服務。將支援這些服務的人員、程序和技術造冊並對應。

  1.  設定演練日的流程，並讓參與的團隊準備好參與活動。備妥自動化服務，以模擬規劃的案例並執行適當的復原程序。[AWS Fault Injection Service](https://aws.amazon.com/fis/)、[AWS Step Functions](https://aws.amazon.com/step-functions/) 和 [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 等 AWS 服務可協助您自動進行演練日的各個層面，例如植入錯誤和啟動復原動作。
+  **執行模擬：**在演練日當天，執行規劃的案例。觀察並記錄人員、程序和技術對模擬事件的反應。
+  **進行練習後檢討：**在演練日結束後，舉行回顧會議來檢討學到的經驗。識別需要改進的層面，以及改善營運彈性所需的任何動作。記錄您的調查結果，並追蹤任何必要的變更，以增強彈性策略並完成準備。

## 資源
<a name="resources"></a>

 **相關的最佳實務：**
+  [REL12-BP01 使用程序手冊調查失敗](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency.html) 
+  [REL12-BP04 使用混沌工程測試彈性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_failure_injection_resiliency.html) 
+  [OPS04-BP01 識別關鍵績效指標](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_identify_kpis.html) 
+  [OPS07-BP03 使用執行手冊執行程序](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html) 
+  [OPS10-BP01 使用程序進行事件、事故和問題管理](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html) 

 **相關文件：**
+  [什麼是 AWS GameDay？](https://aws.amazon.com/gameday/) 

 **相關影片：**
+  [AWS re：Invent 2023 - 寓教於樂：Amazon 如何將彈性擴展到新境界](https://www.youtube.com/watch?v=r3J0fEgNCLQ&t=1734s) 

 **相關範例：**
+  [AWS 研討會 - 駕馭風暴：充分利用彈性系統的受控混沌](https://catalog.us-east-1.prod.workshops.aws/workshops/eb89c4d5-7c9a-40e0-b0bc-1cde2df1cb97) 
+  [打造自己的演練日以支援營運彈性](https://aws.amazon.com/blogs/architecture/build-your-own-game-day-to-support-operational-resilience/)