# REL 11  如何設計工作負載以承受元件失敗？ 需要高可用性和低平均復原時間 (MTTR) 的工作負載必須建立彈性架構。 **Topics** + [REL11-BP01 監控工作負載的所有元件以偵測失敗](rel_withstand_component_failures_monitoring_health.md) + [REL11-BP02 容錯移轉至運作良好的資源](rel_withstand_component_failures_failover2good.md) + [REL11-BP03 將所有分層的修復自動化](rel_withstand_component_failures_auto_healing_system.md) + [REL11-BP04 復原期間需使用資料平面，而非控制平面](rel_withstand_component_failures_avoid_control_plane.md) + [REL11-BP05 使用靜態穩定性來防止雙模態行為](rel_withstand_component_failures_static_stability.md) + [REL11-BP06 當事件影響可用性時傳送通知](rel_withstand_component_failures_notifications_sent_system.md) # REL11-BP01 監控工作負載的所有元件以偵測失敗 持續監控工作負載的運作狀態，讓您和自動化系統在發生效能降低或失敗時能夠察覺。根據商業價值監控關鍵績效指標 (KPI)。 所有復原和修復機制首先都必須能夠快速偵測問題。應該先偵測技術故障，以便解決問題。不過，可用性取決於工作負載提供商業價值的能力，因此測量此需求的關鍵績效指標 (KPI) 必須成為偵測和修復策略的一部分。 **常用的反模式：** + 未設定任何警示，因此會在未發出通知的情況下發生停機。 + 警示存在，但在此臨界值下無法提供足夠的回應時間。 + 收集的指標經常不足以符合復原時間目標 (RTO)。 + 只會主動監控面對客戶的工作負載層。 + 只會收集技術指標，不收集業務功能指標。 + 無測量工作負載的使用者體驗的指標。 **建立此最佳實務的優勢：** 在各層級內進行適當的監控，可讓您減少偵測時間，進而減少復原時間。 **若未建立此最佳實務，暴露的風險等級為：** 高 ## 實作指引 + 根據您的復原目標決定元件的收集間隔。 + 您的監控間隔取決於復原必須多快完成。您的復原時間取決於所需的復原時間，因此您必須考量此時間和復原時間目標 (RTO)，藉以決定收集頻率。 + 設定元件的詳細監控。 + 判斷 EC2 執行個體和 Auto Scaling 是否需要詳細監控。詳細監控提供 1 分鐘的間隔指標，預設監控則提供 5 分鐘的間隔指標。 + [為執行個體啟用或停用詳細監控](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) + [使用 Amazon CloudWatch 監控 Auto Scaling 群組和執行個體](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) + 判斷 RDS 是否需要增強型監控。增強型監控使用 RDS 執行個體上的代理程式，以取得 RDS 執行個體上不同處理程序或執行緒的實用資訊。 + [增強監控](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) + 建立自訂指標來測量業務關鍵績效指標 (KPI)。工作負載會實作關鍵業務功能。這些功能應做為 KPI，以協助確定何時發生間接問題。 + [發布自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) + 以使用者 Canary 監控使用者的故障體驗。可執行和模擬客戶行為的綜合交易測試 (也稱為 Canary 測試，但請別與 Canary 部署混淆)，是最重要的測試程序之一。針對來自不同遠端位置的工作負載端點持續執行這些測試。 + [Amazon CloudWatch Synthetics 可讓您建立使用者 Canary](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) + 建立追蹤使用者體驗的自訂指標。如果您可以檢測客戶的體驗，則可以判斷消費者體驗何時變差。 + [發布自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) + 設定警示以偵測工作負載的任何部分何時未正常運作，並指示何時自動擴展資源。警示會在儀表板上以視覺化方式顯示、透過 Amazon SNS 或電子郵件傳送提醒，以及使用 Auto Scaling 向上或向下擴展工作負載的資源。 + [使用 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) + 建立儀表板以視覺化指標。儀表板可以讓您以視覺化方式查看趨勢、極端值和其他潛在問題的指標，或提供您可能想要調查之問題的指示。 + [使用 CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) ## 資源 **相關文件：** + [Amazon CloudWatch Synthetics 可讓您建立使用者 Canary](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) + [為執行個體啟用或停用詳細監控](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) + [增強監控](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) + [使用 Amazon CloudWatch 監控 Auto Scaling 群組和執行個體](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) + [發布自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) + [使用 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) + [使用 CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) **相關範例：** + [Well-Architected 實驗室：第 300 級：實作運作狀態檢查和管理相依性以提升可靠性](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html) # REL11-BP02 容錯移轉至運作良好的資源 可確保如果發生資源故障，運作良好的資源可以繼續為請求提供服務。對於位置故障 (例如可用區域或 AWS 區域)，請確保您的系統已就位，可容錯移轉至未受影響位置中運作良好的資源。 AWS 服務 (例如 Elastic Load Balancing 和 AWS Auto Scaling) 會協助跨資源和可用區域分配負載。因此，可以透過將流量轉移到剩餘運作狀態良好的資源來緩解個別資源 (例如 EC2 執行個體) 的失敗或可用區域的損害。對於多區域工作負載，這會更複雜。例如，跨區域僅供讀取複本讓您可以將資料部署至多個 AWS 區域，但您仍須將僅供讀取複本升階為主節點，並在發生容錯移轉時將流量指向其中。Amazon Route 53 和 AWS Global Accelerator 可以協助跨 AWS 區域 路由流量。 如果您的工作負載使用 Amazon S3 或 Amazon DynamoDB 等 AWS 服務，則它們會自動部署至多個可用區域。如果發生失敗，AWS 控制平面會自動為您路由流量至運作良好的位置。資料以冗餘方式存放在多個可用區域中，並且仍然可用。對於 Amazon RDS，您必須選擇異地同步備份做為組態選項，然後在發生失敗時，AWS 會自動將流量導向至運作良好的執行個體。對於 Amazon EC2 執行個體、Amazon ECS 任務或 Amazon EKS Pod，您可以選擇要部署的可用區域。然後，Elastic Load Balancing 會提供解決方案，以偵測運作狀態不佳區域中的執行個體，並將流量路由至運作良好的區域。Elastic Load Balancing 甚至可將流量路由至內部部署資料中心內的元件。 對於多區域方法 (可能也包含內部部署資料中心)，Amazon Route 53 提供一種定義網際網路網域的方法，並指派包含運作狀態檢查的路由政策，以確保流量路由至運作良好的區域。或者，AWS Global Accelerator 提供靜態 IP 地址，做為應用程式的固定進入點，然後使用 AWS 全球網路 (而不是網際網路) 路由至您所選 AWS 區域中的端點，以獲得更好的效能和可靠性。 AWS 在設計服務時會考慮到故障復原。我們設計服務以最大程度地減少從故障復原的時間以及對資料的影響。我們的服務主要使用僅在將請求持久儲存於區域內的多個複本中之後才確認請求的資料存放區。這些資源和服務包括 Amazon Aurora、Amazon Relational Database Service (Amazon RDS) 異地同步備份資料庫執行個體、Amazon S3、Amazon DynamoDB、Amazon Simple Queue Service (Amazon SQS) 和 Amazon Elastic File System (Amazon EFS)。它們經建構為使用基於儲存格的隔離以及可用區域提供的故障隔離。我們在營運程序中廣泛使用自動化。我們還對我們的取代-重啟功能進行優化，以期從中斷中快速復原。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 容錯移轉至運作良好的資源。可確保如果發生資源故障，運作良好的資源可以繼續為請求提供服務。對於位置故障 (例如可用區域或 AWS 區域)，請確保您的系統已就位，可容錯移轉至未受影響位置中運作良好的資源。 + 如果您的工作負載使用 Amazon S3 或 Amazon DynamoDB 等 AWS 服務，則它們會自動部署至多個可用區域。如果發生失敗，AWS 控制平面會自動為您路由流量至運作良好的位置。 + 對於 Amazon RDS，您必須選擇異地同步備份做為組態選項，然後在發生失敗時，AWS 會自動將流量導向至運作良好的執行個體。 + [Amazon RDS 的高可用性 (多可用區域)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) + 對於 Amazon EC2 執行個體或 Amazon ECS 任務，您可以選擇要部署的可用區域。然後，Elastic Load Balancing 會提供解決方案，以偵測運作狀態不佳區域中的執行個體，並將流量路由至運作良好的區域。Elastic Load Balancing 甚至可將流量路由至內部部署資料中心內的元件。 + 如果採用多區域方法 (可能也包含內部部署資料中心)，確保來自運作狀態良好之位置的資料和資源可以繼續為請求提供服務 + 例如，跨區域僅供讀取複本讓您可以將資料部署至多個 AWS 區域，但您仍須將僅供讀取複本升階為主節點，並在主要位置發生失敗時將流量指向該主節點。 + [Amazon RDS 讀取複本的概觀](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) + Amazon Route 53 提供一種方法，可定義網際網路網域和指派路由政策 (可能包含運作狀態檢查)，以確保流量路由到運作狀態良好的區域。或者，AWSGlobal Accelerator 提供靜態 IP 地址，做為應用程式的固定進入點，然後使用 AWS 全球網路 (而不是公用網際網路) 路由至您所選 AWS 區域中的端點，以獲得更好的效能和可靠性。 + [Amazon Route 53：選擇路由政策](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) + [什麼是 AWS Global Accelerator？](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) ## 資源 **相關文件：** + [APN 合作夥伴：可以幫助您實現容錯自動化的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=automation) + [AWS Marketplace：可用於容錯的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance) + [AWS OpsWorks：使用自動修復來替換故障的執行個體](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html) + [Amazon Route 53：選擇路由政策](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) + [Amazon RDS 的高可用性 (多可用區域)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) + [Amazon RDS 讀取複本的概觀](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) + [Amazon ECS 任務置放策略](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html) + [為多個可用區域建立 Kubernetes Auto Scaling 群組](https://aws.amazon.com/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-groups/) + [什麼是 AWS Global Accelerator？](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) **相關範例：** + [Well-Architected 實驗室：第 300 級：實作運作狀態檢查和管理相依性以提升可靠性](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html) # REL11-BP03 將所有分層的修復自動化 偵測到失敗時，使用自動化功能執行動作來進行修復。 *重新啟動的能力* 是修復故障的重要工具。如同先前針對分散式系統的討論一樣，最佳實務是盡可能讓服務無狀態。這可防止重新啟動時遺失資料或可用性。在雲端，您可以在重新啟動時 (且通常應該) 取代整個資源 (例如，EC2 執行個體或 Lambda 函數)。重新啟動本身是從故障中復原的一個簡單、可靠方法。工作負載中會發生許多不同類型的故障。硬體、軟體、通訊和營運可能會發生故障。與其建構新穎的機制來捕獲、識別並修正每個不同類型的故障，不如將許多不同類型的故障映射至相同的復原策略。執行個體可能因為硬體故障、作業系統錯誤、記憶體洩漏或其他原因而發生故障。不要為每個情況建置自訂修復，而是將任何情況都視為執行個體故障。終止執行個體，並允許 AWS Auto Scaling 取代之。之後，請對故障的頻外資源執行分析。 另一個範例是能夠重新啟動網路請求。對網路逾時和相依系統故障 (其中相依系統會返回錯誤) 套用相同的復原方法。這兩個事件對系統具有類似的影響，因此，不要嘗試讓任何一個事件成為「特殊情況」，而是藉由指數退避和抖動來採用類似的限制重試策略。 *重新啟動的能力* 是復原導向運算和高可用性叢集架構中的一種復原機制。 Amazon EventBridge 可用來監控並篩選事件，例如 CloudWatch 警示或其他 AWS 服務的狀態變更。根據事件資訊，它可以觸發 AWS Lambda、AWS Systems Manager Automation 或其他目標，在您的工作負載上執行自訂修復邏輯。 Amazon EC2 Auto Scaling 可設定為檢查 EC2 執行個體的運作狀態。如果執行個體處於執行中以外的任何狀態，或系統狀態為受損，Amazon EC2 Auto Scaling 會將執行個體視為運作狀態不佳，並啟動替代執行個體。如果使用 AWS OpsWorks，您可以在 OpsWorks 層級中設定 EC2 執行個體的自動修復功能。 對於大規模替換 (例如遺失整個可用區域)，靜態穩定性是高可用性的首選，而不是一次嘗試取得多個新資源。 **常用的反模式：** + 個別部署執行個體或容器中的應用程式。 + 部署不透過自動復原就無法部署到多個位置的應用程式。 + 手動復原自動擴展和自動復原無法修復的應用程式。 **建立此最佳實務的優勢：** 即使工作負載一次只能部署到一個位置，自動修復也會減少平均復原時間，並確保工作負載的可用性。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 使用 Auto Scaling 群組在工作負載中部署分層。Auto Scaling 可以對無狀態應用程式進行自我修復，並新增和移除容量。 + [AWS Auto Scaling 的運作方式](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) + 對已部署無法在多個位置中部署之應用程式，且可以容忍失敗後重新開機的 EC2 執行個體，實作自動復原。在應用程式無法部署於多個位置時，自動復原可以用來取代失敗硬體並重新啟動執行個體。執行個體中繼資料和相關聯的 IP 地址，以及 Amazon EBS 磁碟區和 Lustre 及 Windows 的彈性檔案系統或檔案系統的掛載點皆會保留。 + [Amazon EC2 自動復原](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) + [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) + [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) + [什麼是 Amazon FSx for Lustre？](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) + [什麼是 Amazon FSx for Windows File Server？](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) + 您可以使用 AWS OpsWorks，在層級中設定 EC2 執行個體的自動修復功能。 + [AWS OpsWorks：使用自動修復來替換故障的執行個體](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html) + 當您無法使用自動擴展或自動復原，或自動復原失敗時，則使用 AWS Step Functions 和 AWS Lambda 實作自動復原。當您無法使用自動擴展，且無法使用自動復原或自動復原失敗時，則可以使用 AWS Step Functions 和 AWS Lambda 將修復作業自動化。 + [什麼是 AWS Step Functions？](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) + [什麼是 AWS Lambda？](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) + Amazon EventBridge 可用來監控並篩選事件，例如 CloudWatch 警示或其他 AWS 服務的狀態變更。根據事件資訊，它接著可以觸發 AWS Lambda (或其他目標)，在您的工作負載上執行自訂修復邏輯。 + [什麼是 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) ## 資源 **相關文件：** + [APN 合作夥伴：可以幫助您實現容錯自動化的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=automation) + [AWS Marketplace：可用於容錯的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance) + [AWS OpsWorks：使用自動修復來替換故障的執行個體](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html) + [Amazon EC2 自動復原](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) + [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) + [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) + [AWS Auto Scaling 的運作方式](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) + [使用 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.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) + [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) + [什麼是 AWS Step Functions？](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) + [什麼是 Amazon FSx for Lustre？](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) + [什麼是 Amazon FSx for Windows File Server？](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) **相關影片：** + [AWS 中的靜態穩定性：AWS re:Invent 2019：The Amazon Builders’ Library 簡介 (DOP328)](https://youtu.be/sKRdemSirDM?t=704) **相關範例：** + [Well-Architected 實驗室：第 300 級：實作運作狀態檢查和管理相依性以提升可靠性](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html) # REL11-BP04 復原期間需使用資料平面，而非控制平面 控制平面是用來配置資源，資料平面用來提供服務。一般而言，資料平面的可用性設計目標會高於控制平面，且較為簡單。針對有可能影響彈性的事件實作復原或緩解回應時，使用控制平面作業可能會降低架構的整體彈性。例如，您可以使用 Amazon Route 53 資料平面，根據運作狀態檢查可靠地路由 DNS 查詢，但更新 Route 53 路由政策需使用控制平面，所以不要將控制平面用於復原。 Route 53 資料平面回答 DNS 佇列，以及執行並評估運作狀態檢查。它們遍布全球，而且針對 [100% 可用性服務水準協議 (SLA) 設計的。](https://aws.amazon.com/route53/sla/) 您可在其中建立、更新和刪除 Route 53 資源的 Route 53 管理 API 和主控台，在控制平面上執行，這些控制平面的設計旨在優先考慮您在管理 DNS 時所需的強式一致性和耐久性。為了實現此目標，控制平面位於單一區域 US East (N. Virginia) 中。儘管將這兩個系統建置為非常可靠，但控制平面未包含在 SLA 中。在極少數情況下，資料平面的彈性設計允許它保持可用性，而控制平面則不允許。對於災難復原和容錯移轉機制，使用資料平面功能提供可能最好的可靠性。 如需資料平面、控制平面，以及 AWS 如何建置服務以符合高可用性目標的詳細資計，請參閱 [使用可用區域實現靜態穩定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) 文件和 [Amazon 建置者資料中心。](https://aws.amazon.com/builders-library/) **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 將 Amazon Route 53 用於災難復原時，請使用資料平面，而非控制平面。Route 53 應用程式復原控制器可協助您使用準備度檢查和路由控制，來管理和協調容錯移轉。這些功能會持續監控應用程式從失敗中復原的功能，可讓您在多個 AWS 區域、可用區域和內部部署上控管應用程式復原。 + [什麼是 Route 53 應用程式復原控制器？](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) + [使用 Amazon Route 53 建立災難復原機制](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/) + [使用 Amazon Route 53 應用程式復原控制器建置高彈性應用程式 (第 1 部分)：單一區域堆疊](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/) + [使用 Amazon Route 53 應用程式復原控制器建置高彈性應用程式，第 2 部分：單一區域堆疊](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/) + 了解哪些作業位於資料平面，哪些位於控制平面。 + [Amazon Builders' Library：控管較小服務，避免分散式系統過載](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/) + [Amazon DynamoDB API (控制平面和資料平面)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html) + [AWS Lambda 執行](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (分割成控制平面和資料平面) + [AWS Lambda 執行](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (分割成控制平面和資料平面) ## 資源 **相關文件：** + [APN 合作夥伴：可以幫助您實現容錯自動化的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=automation) + [AWS Marketplace：可用於容錯的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance) + [Amazon Builders' Library：控管較小服務，避免分散式系統過載](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/) + [Amazon DynamoDB API (控制平面和資料平面)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html) + [AWS Lambda 執行](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (分割成控制平面和資料平面) + [AWS 資料平面](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html) + [使用 Amazon Route 53 應用程式復原控制器建置高彈性應用程式 (第 1 部分)：單一區域堆疊](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/) + [使用 Amazon Route 53 應用程式復原控制器建置高彈性應用程式，第 2 部分：單一區域堆疊](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/) + [使用 Amazon Route 53 建立災難復原機制](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/) + [什麼是 Route 53 應用程式復原控制器？](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) **相關範例：** + [簡介 Amazon Route 53 應用程式復原控制器](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/) # REL11-BP05 使用靜態穩定性來防止雙模態行為 雙模態行為是您的工作負載在正常和失敗模式下展現出不同的行為，例如，當可用區域失敗時，仰賴啟動新的執行個體。您應改為建置靜態穩定且僅以一種模式操作的工作負載。在這種情況下，如果移除一個可用區域，則在每個可用區域佈建足夠的執行個體來處理工作負載負載，然後使用 Elastic Load Balancing 或 Amazon Route 53 運作狀態檢查，將負載從受損的執行個體移出。 運算部署 (例如 EC2 執行個體或容器) 的靜態穩定性可提供最高的可靠性。這必須與成本考量進行權衡。佈建較少的運算容量，而且在發生故障時仰賴啟動新的執行個體，所需的成本會更低。但對於大規模故障 (例如可用區域故障)，此方法效率較低，因為它仰賴在發生故障時對受損情況做出回應，而不是在發生之前為這些受損情況做好準備。您的解決方案應該權衡可靠性與工作負載的成本需求。透過使用更多可用區域，靜態穩定性所需的額外運算量會減少。 ![\[圖表：顯示跨可用區域之 EC2 執行個體的靜態穩定性\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/static-stability.png) 流量轉移後，使用 AWS Auto Scaling 以非同步方式取代故障區域的執行個體，並在運作良好的區域中啟動這些執行個體。 另一個雙模態行為範例是網路逾時，網路逾時可能導致系統嘗試重新整理整個系統的組態狀態。這樣一來，即會給另一個元件新增意外負載，且可能導致其發生故障，從而引發其他意外後果。這種負面意見回饋迴圈會影響工作負載的可用性。反之，您應該建置靜態穩定且僅以一種模式操作的系統。靜態穩定的設計是執行持續工作，並始終以固定的規律重新整理組態狀態。叫用失敗時，工作負載會使用先前的快取數值，並觸發警示。 另一個雙模態行為範例是允許用戶端在發生失敗時繞過您的工作負載快取。這看起來可能是滿足用戶端需求的解決方案，但不應得到允許，因為這會大幅變更工作負載的需求，且可能導致故障。 **若未建立此最佳實務，暴露的風險等級為：** 中 ## 實作指引 + 使用靜態穩定性來防止雙模態行為。雙模態行為是您的工作負載在正常和失敗模式下展現出不同的行為，例如，當可用區域失敗時，仰賴啟動新的執行個體。 + [在災難復原計畫中盡可能減少相依關係](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/) + [Amazon Builders' Library：使用可用區域實現靜態穩定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) + [AWS 中的靜態穩定性：AWS re:Invent 2019：The Amazon Builders’ Library 簡介 (DOP328)](https://youtu.be/sKRdemSirDM?t=704) + 您應改為建置靜態穩定且僅以一種模式操作的系統。在這種情況下，如果移除一個 AZ，則在每個區域佈建足夠的執行個體來處理工作負載負載，然後使用 Elastic Load Balancing 或 Amazon Route 53 運作狀態檢查，將負載從受損的執行個體移出。 + 另一個雙模態行為範例是允許用戶端在發生失敗時繞過您的工作負載快取。這看起來可滿足用戶端需求的解決方案，但不應允許，因為這會大幅變更工作負載的需求，且可能導致失敗。 ## 資源 **相關文件：** + [在災難復原計畫中盡可能減少相依關係](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/) + [Amazon Builders' Library：使用可用區域實現靜態穩定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) **相關影片：** + [AWS 中的靜態穩定性：AWS re:Invent 2019：The Amazon Builders’ Library 簡介 (DOP328)](https://youtu.be/sKRdemSirDM?t=704) # REL11-BP06 當事件影響可用性時傳送通知 當偵測到重大事件時傳送通知，即使事件造成的問題已自動解決。 自動修復功能可讓您的工作負載變得可靠。不過，它也可能會遮蔽需要解決的潛在問題。實作適當的監控和事件，讓您能夠偵測到問題模式 (包括自動修復功能處理的問題模式)，以便解決根本原因問題。Amazon CloudWatch 警示可根據發生的故障來觸發，也可以根據執行的自動修復動作來觸發。CloudWatch 警示可設定為傳送電子郵件，或使用 Amazon SNS 整合在第三方事件追蹤系統中記錄事件。 **常用的反模式：** + 傳送無人對其採取行動的警示。 + 進行自動修復自動化，但不通知需要修復。 **建立此最佳實務的優勢：** 復原事件的通知可確保您不會忽略不常發生的問題。 **若未建立此最佳實務，暴露的風險等級：** 中 ## 實作指引 + 當業務關鍵績效指標超過臨界值下限時，發出該指標的警示：對業務 KPI 制定臨界值下限警示，有助於您知道何時無法使用工作負載或工作負載無法運作。 + [根據靜態臨界值建立 CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) + 叫用修復自動化的事件警示：您可以直接叫用 SNS API，以透過您建立的任何自動化來傳送通知。 + [什麼是 Amazon Simple Notification Service？](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) ## 資源 **相關文件：** + [根據靜態臨界值建立 CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) + [什麼是 Amazon EventBridge？](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) + [什麼是 Amazon Simple Notification Service？](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)