# 設計工作負載以承受元件失敗
須架構具高可用性和低平均復原時間 (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-BP07 建立您的產品架構以符合可用性目標和運行時間服務水準協議 (SLA)](rel_withstand_component_failures_service_level_agreements.md)
# REL11-BP01 監控工作負載的所有元件以偵測故障
持續監控工作負載的運作狀態，讓您和自動化系統在發生故障或效能降低時能夠察覺。根據商業價值監控關鍵績效指標 (KPI)。
所有復原和修復機制首先都必須能夠快速偵測問題。應該先偵測技術故障，以便解決問題。不過，可用性取決於工作負載提供商業價值的能力，因此測量此需求的關鍵績效指標 (KPI) 必須成為偵測和修復策略的一部分。
**預期成果：**工作負載的基本元件會單獨監控，以偵測故障發生的時機和位置並發出警示。
**常見的反模式：**
+ 未設定任何警報，因此會在未發出通知的情況下發生中斷。
+ 警示存在，但在此閾值下無法提供足夠的回應時間。
+ 收集的指標經常不足以符合復原時間點目標 (RTO)。
+ 只主動監控面對客戶的工作負載介面。
+ 只收集技術指標，未收集業務功能指標。
+ 無測量工作負載使用者體驗的指標。
+ 建立了太多監控。
**建立此最佳實務的優勢：**在各層級內進行適當的監控，可讓您減少偵測時間，進而減少復原時間。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
確定將要審核以進行監控的所有工作負載。確定需要監控的所有工作負載元件之後，您現在需要確定監控間隔。根據偵測故障所需的時間而定，監控間隔會直接影響復原的速度。平均偵測時間 (MTTD) 是指從發生故障到開始修復作業經過的時間。服務清單應盡可能廣泛且完整。
監控必須涵蓋應用程式堆疊的所有層級，包括應用程式、平台、基礎設施和網路。
您的監控策略應考慮*微小故障*的影響。如需微小故障的詳細資訊，請參閱《進階多可用區域彈性模式》白皮書中的 [Gray failures](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html)。
### 實作步驟
+ 您的監控間隔取決於復原必須多快完成。您的復原時間取決於所需的復原時間，因此您必須考量此時間和復原時間點目標 (RTO)，藉以決定收集頻率。
+ 設定元件和受管服務的詳細監控。
+ 判斷 [EC2 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)和 [Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) 是否需要詳細監控。詳細監控提供 1 分鐘的間隔指標，預設監控則提供 5 分鐘的間隔指標。
+ 判斷 RDS 是否需要[增強型監控](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html)。增強型監控使用 RDS 執行個體上的代理程式，以取得不同處理程序或執行緒的實用資訊。
+ 判斷 [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-metrics.html)、[API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/monitoring_automated_manual.html)、[Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html)、[Amazon ECS](https://catalog.workshops.aws/observability/en-US/aws-managed-oss/amp/ecs) 和所有類型的[負載平衡器](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-monitoring.html)的關鍵無伺服器元件的監控需求。
+ 確定 [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/monitoring-overview.html)、[Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring_overview.html)、[Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/monitoring_overview.html) 和 [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html) 的儲存元件的監控需求。
+ 建立[自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)以測量業務關鍵績效指標 (KPI)。工作負載會實作重要的業務功能，這些功能應做為 KPI，以利確定間接問題發生的時間。
+ 以使用者 Canary 監控使用者的故障體驗。可執行和模擬客戶行為的[綜合交易測試](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (也稱為 Canary 測試，但請別與 Canary 部署混淆)，是最重要的測試程序之一。針對來自不同遠端位置的工作負載端點持續執行這些測試。
+ 建立追蹤使用者體驗的[自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)。如果您可以檢測客戶的體驗，則可以判斷消費者體驗何時變差。
+ [設定警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)以偵測工作負載的任何部分何時未正常運作，並指示何時自動擴展資源。警示會在儀表板上以視覺化方式顯示、透過 Amazon SNS 或電子郵件傳送提醒，以及搭配使用 Auto Scaling 來擴展或縮減工作負載資源。
+ 建立[儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)以視覺化指標。儀表板可以讓您以視覺化方式查看趨勢、極端值和其他潛在問題的指標，或指出您可能想要調查的問題。
+ 為您的服務建立[分散式追蹤監控](https://aws.amazon.com/xray/faqs/)。透過分散式監控，您可以了解應用程式及其基礎服務的執行方式，以確定和疑難排解效能問題與錯誤的根本原因。
+ 在單獨的區域和帳戶中建立監控系統 (使用 [CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html) 或 [X-Ray](https://aws.amazon.com/xray/faqs/)) 儀表板和資料收集。
+ 透過 [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) 隨時掌握服務降級的相關資訊。[透過 [AWS 使用者通知](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) 建立符合用途的 AWS Health 事件通知](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html)，以利用電子郵件和聊天管道傳送，並透過 [Amazon EventBridge 以程式設計方式與您的監控和警示工具](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)整合。
## 資源
**相關的最佳實務：**
+ [可用性定義](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP06 當事件影響可用性時傳送通知](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.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)
+ [Enhanced Monitoring (增強型監控](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)
+ [使用跨區域跨帳戶 CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html)
+ [使用跨區域跨帳戶 X-Ray 追蹤](https://aws.amazon.com/xray/faqs/)
+ [了解可用性](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/understanding-availability.html)
**相關影片：**
+ [減少微小故障](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html)
**相關範例：**
+ [一個可觀測性研討會：探索 X-Ray](https://catalog.workshops.aws/observability/en-US/aws-native/xray/explore-xray)
**相關工具：**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)：
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP02 容錯移轉至運作良好的資源
如果發生資源失敗，運作良好的資源應繼續處理請求。對於位置受損 (例如可用區域或 AWS 區域)，請確保您的系統已就位，可容錯移轉至未受影響位置中運作良好的資源。
設計服務時，請將負載分散到各個資源、可用區域或區域。因此，可以透過將流量轉移到剩餘運作狀態良好的資源來減輕個別資源故障或損害的影響。請考慮發生故障時，如何找到服務及其路由。
設計服務時，務必考慮故障復原。在 AWS，我們設計服務以盡可能減少從故障復原的時間並減輕對資料的影響。我們的服務主要使用的資料存放區，會在請求持久儲存於區域內的多個複本中之後，才確認請求。經過建構後，它們會使用以儲存格為基礎的隔離，以及使用可用區域提供的故障隔離。我們在營運程序中廣泛使用自動化。我們還將取代-重啟功能最佳化，以期從中斷快速復原。
允許容錯移轉的模式和設計會隨著各 AWS 平台服務而有所不同。許多 AWS 原生受管服務本身就是多個可用區域 (例如 Lambda 或 API Gateway)。其他 AWS 服務 (例如 EC2 和 EKS) 需要特定的最佳實務設計，以支援在 AZ 的各資源或資料儲存容錯移轉。
監控應設定為確認容錯移轉資源是否正常運作、追蹤資源容錯移轉的進度，以及監控業務程序復原。
**預期成果：**系統能夠自動或手動使用新資源，以從降級恢復。
**常見的反模式：**
+ 故障計畫不是規劃和設計階段的一部分。
+ 未建立 RTO 和 RPO。
+ 監控不足，無法偵測出失敗的資源。
+ 正確隔離故障網域。
+ 未考慮多區域容錯移轉。
+ 決定進行容錯移轉時，失敗偵測太過敏感或積極。
+ 未測試或驗證容錯移轉設計。
+ 進行自動修復自動化，但未通知需要修復。
+ 缺少緩衝期，以避免過早容錯恢復。
**建立此最佳實務的優勢：**您可以建置更具彈性的系統，在發生故障時透過適當降級並快速復原來維持可靠性。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
諸如 [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html) 和 [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) 等 AWS 服務可協助跨資源和可用區域分配負載。因此，可以透過將流量轉移到剩餘運作狀態良好的資源來緩解個別資源 (例如 EC2 執行個體) 的失敗或可用區域的損害。
對於多區域工作負載，設計會更複雜。例如，跨區域僅供讀取複本可讓您將資料部署到多個 AWS 區域。不過仍需要容錯移轉，才能將僅供讀取複本提升為主要複本，然後將流量指向新端點。Amazon Route 53、[Amazon 應用程式復原控制器 (ARC)](https://aws.amazon.com/application-recovery-controller/)、Amazon CloudFront 和 AWS Global Accelerator 可協助在 AWS 區域 之間路由流量。
諸如 Amazon S3、Lambda、API Gateway、Amazon SQS、Amazon SNS、Amazon SES、Amazon Pinpoint、Amazon ECR、AWS Certificate Manager、EventBridge 或 Amazon DynamoDB 等 AWS 服務由 AWS 自動部署到多個可用區域。如果發生故障，這些 AWS 服務會自動將流量路由到運作良好的位置。資料以冗餘方式存放在多個可用區域中，並且仍然可用。
對於 Amazon RDS、Amazon Aurora、Amazon Redshift、Amazon EKS 或 Amazon ECS 而言，多可用區域是一種組態選項。如果啟動容錯移轉，則 AWS 可將流量導向運作良好的執行個體。此容錯移轉動作可由 AWS 執行，或依客戶要求執行
對於 Amazon EC2 執行個體、Amazon Redshift 或 Amazon ECS 任務或 Amazon EKS Pod，您可以選擇要部署到哪個可用區域。對於某些設計，Elastic Load Balancing 會提供解決方案，以偵測運作狀態不佳區域中的執行個體，並將流量路由至運作良好的區域。Elastic Load Balancing 也可將流量路由至內部部署資料中心內的元件。
對於多區域流量容錯移轉，重新路由可利用 Amazon Route 53、Amazon 應用程式復原控制器、AWS Global Accelerator、適用於 VPC 的 Route 53 私有 DNS 或 CloudFront 來提供定義網際網路網域和指派路由政策 (包括運作狀態檢查) 的方法，以便將流量路由到運作狀態良好的區域。AWS Global Accelerator 提供靜態 IP 位址，做為應用程式端點的固定進入點，然後使用 AWS 全球網路 (而不是網際網路) 路由至您所選 AWS 區域 中的端點，以獲得更好的效能和可靠性。
### 實作步驟
+ 為所有適當的應用程式和服務建立容錯移轉設計。隔離每個架構元件，並為每個元件建立符合 RTO 和 RPO 的容錯移轉設計。
+ 設定較低的環境 (例如開發或測試)，且其中所有服務都需要有容錯移轉計畫。使用基礎設施即程式碼 (IaC) 來部署解決方案，以確保可重複性。
+ 設定復原站台 (例如第二個區域)，以實作和測試容錯移轉設計。如有必要，可以臨時設定測試的資源，以限制額外的成本。
+ 判斷哪些容錯移轉計畫是由 AWS 自動執行、哪些可由 DevOps 程序自動執行，以及哪些可能要手動執行。記錄並測量每一項服務的 RTO 和 RPO。
+ 建立容錯移轉程序手冊，並包括容錯移轉每個資源、應用程式和服務的所有步驟。
+ 建立容錯恢復程序手冊，並包括容錯恢復 (含時程) 每個資源、應用程式和服務的所有步驟
+ 制定計畫來啟動和演練程序手冊。使用模擬和混亂測試來測試程序手冊的步驟和自動化。
+ 對於位置受損 (例如可用區域或 AWS 區域)，請確保您的系統已就位，可容錯移轉至未受影響位置中運作良好的資源。在容錯移轉測試之前，檢查配額、自動擴展層級和執行的資源。
## 資源
**相關 Well-Architected 的最佳實務：**
+ [REL13 - 災難復原 (DR) 計畫](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html)
+ [REL10 - 使用故障隔離來保護您的工作負載](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)
**相關文件：**
+ [設定 RTO 和 RPO 目標](https://aws.amazon.com/blogs/mt/establishing-rpo-and-rto-targets-for-cloud-applications/)
+ [使用 Route 53 加權路由進行容錯移轉](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 應用程式復原控制器進行災難復原](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/)
+ [具有自動擴展的 EC2](https://github.com/adriaanbd/aws-asg-ecs-starter)
+ [EC2 部署 - 多可用區域](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [ECS 部署 - 多可用區域](https://github.com/aws-samples/ecs-refarch-cloudformation)
+ [使用 Amazon 應用程式復原控制器切換流量](https://docs.aws.amazon.com/r53recovery/latest/dg/routing-control.failover-different-accounts.html)
+ [具有 Application Load Balancer 和容錯移轉的 Lambda](https://docs.aws.amazon.com/lambda/latest/dg/services-alb.html)
+ [ACM 複寫和容錯移轉](https://github.com/aws-samples/amazon-ecr-cross-region-replication)
+ [參數存放區複寫和容錯移轉](https://medium.com/devops-techable/how-to-design-an-ssm-parameter-store-for-multi-region-replication-support-aws-infrastructure-db7388be454d)
+ [ECR 跨區域複寫和容錯移轉](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry-settings-configure.html)
+ [Secrets Manager 跨區域複寫組態](https://disaster-recovery.workshop.aws/en/labs/basics/secrets-manager.html)
+ [針對 EFS 和容錯移轉啟用跨區域複寫](https://aws.amazon.com/blogs/aws/new-replication-for-amazon-elastic-file-system-efs/)
+ [EFS 跨區域複寫和容錯移轉](https://aws.amazon.com/blogs/storage/transferring-file-data-across-aws-regions-and-accounts-using-aws-datasync/)
+ [聯網容錯移轉](https://docs.aws.amazon.com/whitepapers/latest/hybrid-connectivity/aws-dx-dxgw-with-vgw-multi-regions-and-aws-public-peering.html)
+ [使用 MRAP 的 S3 端點容錯移轉](https://catalog.workshops.aws/s3multiregionaccesspoints/en-US/0-setup/1-review-mrap)
+ [為 S3 建立跨區域複寫](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [AWS 上的跨區域容錯移轉和寬限容錯恢復指南](https://d1.awsstatic.com/solutions/guidance/architecture-diagrams/cross-region-failover-and-graceful-failback-on-aws.pdf)
+ [使用多區域 Global Accelerator 進行容錯移轉](https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-multi-region-applications-in-aws-using-aws-global-accelerator/)
+ [透過 DRS 進行容錯移轉](https://docs.aws.amazon.com/drs/latest/userguide/failback-overview.html)
**相關範例：**
+ [ 上的災難復原AWS](https://disaster-recovery.workshop.aws/en/)
+ [ 上的彈性災難復原AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/080af3a5-623d-4147-934d-c8d17daba346/en-US)
# REL11-BP03 將所有分層的修復自動化
偵測到失敗時，使用自動化功能執行動作來進行修復。降級可能透過內部服務機制自動修復，或需要透過矯正動作重新啟動或移除資源。
對於自我管理的應用程式和跨區域修復，復原設計和自動修復程序可從[現有最佳實務](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/)中提取。
重新啟動或移除資源是修復故障的重要工具。最佳實務是盡可能讓服務無狀態。這可防止資源重新啟動時遺失資料或可用性。在雲端，您可以 (且通常應該) 在重新啟動時取代整個資源 (例如，運算執行個體或無伺服器函數)。重新啟動本身是從故障中復原的一個簡單、可靠方法。工作負載中會發生許多不同類型的故障。硬體、軟體、通訊和營運可能會發生故障。
重新啟動或重試也適用於網路請求。對網路逾時和相依系統故障 (其中相依系統會返回錯誤) 套用相同的復原方法。這兩個事件對系統具有類似的影響，因此，不要嘗試讓任何一個事件成為特殊情況，而是藉由指數退避和抖動來採用類似的限制重試策略。重新啟動的能力是復原導向運算和高可用性叢集架構中的一種復原機制。
**預期成果：**執行自動化動作來矯正錯誤偵測。
**常見的反模式：**
+ 佈建資源，但無自動擴展。
+ 個別部署執行個體或容器中的應用程式。
+ 部署不透過自動復原就無法部署到多個位置的應用程式。
+ 手動復原自動擴展和自動復原無法修復的應用程式。
+ 未自動化資料庫容錯移轉。
+ 缺乏自動化方法可將流量重新路由至新端點。
+ 沒有儲存複寫。
**建立此最佳實務的優勢：**自動修復可減少您的平均復原時間，並提高可用性。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
Amazon EKS 或其他 Kubernetes 服務的設計應包括最小和最大複本或有狀態的集合，以及最小叢集和節點群組規模調整。這些機制提供了最少量的連續可用處理資源，同時會使用 Kubernetes 控制平面自動修復任何失敗。
透過使用運算叢集的負載平衡器存取的設計模式應利用 Auto Scaling 群組。Elastic Load Balancing (ELB) 會自動將傳入的應用程式流量分配到一或多個可用區域 (AZ) 中的多個目標和虛擬設備。
未使用負載平衡的叢集式運算設計，其大小設計應考量至少遺失一個節點。這可讓服務在復原新節點的同時，維持在可能減少的容量中自行執行。範例服務包括 Mongo、DynamoDB Accelerator、Amazon Redshift、Amazon EMR、Cassandra、Kafka、MSK-EC2、Couchbase、ELK 和 Amazon OpenSearch Service。其中許多服務都可以設計為納入額外的自動修復功能。某些叢集技術必須在節點遺失時產生警示，才能觸發自動或手動工作流程來重新建立新節點。此工作流程可以使用 AWS Systems Manager 自動化，以快速修復問題。
Amazon EventBridge 可用來監控及篩選事件，例如 CloudWatch 警示，或其他 AWS 服務的狀態變更。根據事件資訊，它接著可以調用 AWS Lambda、Systems Manager Automation 或其他目標，在您的工作負載上執行自訂修復邏輯。Amazon EC2 Auto Scaling 可設定為檢查 EC2 執行個體的運作狀態。如果執行個體處於執行中以外的任何狀態，或系統狀態為受損，Amazon EC2 Auto Scaling 會將執行個體視為運作狀態不佳，並啟動替代執行個體。對於大規模替換 (例如遺失整個可用區域)，靜態穩定性是高可用性的首選。
### 實作步驟
+ 使用 Auto Scaling 群組在工作負載中部署分層。[Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 可以對無狀態應用程式進行自我修復，並新增或移除容量。
+ 對於先前提及的運算執行個體，請使用[負載平衡](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)並選擇適當的負載平衡器類型。
+ 考慮修復 Amazon RDS。對於待命執行個體，請設定待命執行個體的[自動容錯移轉](https://repost.aws/questions/QU4DYhqh2yQGGmjE_x0ylBYg/what-happens-after-failover-in-rds)。對於 Amazon RDS 僅供讀取複本，須有自動化工作流程才能將僅供讀取複本設為主要。
+ 對已部署無法在多個位置中部署之應用程式且可以容忍失敗後重新開機的 EC2 執行個體，實作[自動復原](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)。無法將應用程式部署到多個位置時，自動復原可以用來取代失敗的硬體並重新啟動執行個體。執行個體中繼資料和相關聯的 IP 位址，以及 [EBS 磁碟區](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)和 [Amazon Elastic File System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) 或 [File Systems for Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) 以及 [Windows](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) 的掛載點皆會保留。使用 [AWS OpsWorks](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)，可在層級中設定 EC2 執行個體的自動修復功能。
+ 當您無法使用自動擴展或自動復原，或自動復原失敗時，則使用 [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) 實作自動復原。當您無法使用自動擴展，且無法使用自動復原或自動復原失敗時，則可以使用 AWS Step Functions 和 AWS Lambda 將修復作業自動化。
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 可用來監控及篩選事件，例如 [CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)或其他 AWS 服務的狀態變更。根據事件資訊，它接著可以調用 AWS Lambda (或其他目標)，在您的工作負載上執行自訂修復邏輯。
## 資源
**相關的最佳實務：**
+ [可用性定義](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 監控工作負載的所有元件以偵測故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**相關文件：**
+ [AWS Auto Scaling 的運作方式](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.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)
+ [什麼是 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：使用自動修復來替換出現故障的執行個體](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [什麼是 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？](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)
+ [Amazon RDS 容錯移轉](https://d1.awsstatic.com/rdsImages/IG1_RDS1_AvailabilityDurability_Final.pdf)
+ [SSM - Systems Manager Automation](https://docs.aws.amazon.com/resilience-hub/latest/userguide/integrate-ssm.html)
+ [彈性架構最佳實務](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/)
**相關影片：**
+ [自動佈建及擴展 OpenSearch Service](https://www.youtube.com/watch?v=GPQKetORzmE)
+ [Amazon RDS 自動容錯移轉](https://www.youtube.com/watch?v=Mu7fgHOzOn0)
**相關範例：**
+ [Amazon RDS 容錯移轉研討會](https://catalog.workshops.aws/resilient-apps/en-US/rds-multi-availability-zone/failover-db-instance)
**相關工具：**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)：
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP04 復原期間需使用資料平面，而非控制平面
控制平面提供的管理 API 適用於建立、讀取和描述、更新、刪除和列出 (CRUDL) 資源，而資料平面則處理日常服務流量。對可能影響彈性的事件實作復原或緩解回應時，請盡量使用最少數量的控制平面操作來復原、重新擴展、還原、修復或容錯移轉服務。資料平面動作應取代這些降級事件期間的任何活動。
例如，以下全都是控制平面動作：啟動新的運算執行個體、建立區塊儲存，以及說明佇列服務。啟動運算執行個體時，控制平面必須執行多項工作，例如尋找具有容量的實體主機、配置網路介面、準備本機區塊儲存磁碟區、產生憑證，以及新增安全規則。控制平面往往是複雜的協同運作。
**預期成果：**當資源進入受損狀態時，系統能夠將流量從受損資源轉移到健康狀況良好的資源，來自動或手動復原。
**常見的反模式：**
+ 依賴變更 DNS 記錄來重新路由流量。
+ 依賴控制平面擴展操作來取代因佈建資源不足而受損的元件。
+ 依靠大量、多服務、多 API 的控制平面動作來修復任何類別的損害。
**建立此最佳實務的優勢：**提高自動化修復的成功率可減少平均復原時間，並改善工作負載的可用性。
**未建立此最佳實務時的風險暴露等級：**中。對於某些類型的服務降級，則會影響控制平面。若倚賴大量使用控制平面來進行修復，可能會增加復原時間 (RTO) 和平均復原時間 (MTTR)。
## 實作指引
若要限制資料平面動作，請評估每一項服務還原時所需的動作。
利用 Amazon 應用程式復原控制器來轉移 DNS 流量。這些功能會持續監控應用程式從失敗中復原的功能，讓您在多個 AWS 區域、可用區域和內部部署上控管應用程式復原。
Route 53 路由政策使用控制平面，因此不要依賴它進行復原。Route 53 資料平面會答覆 DNS 查詢，以及執行並評估運作狀態檢查。它們遍佈全球，專為 [100% 可用性服務水準協議 (SLA)](https://aws.amazon.com/route53/sla/) 而設計。
您在其中建立、更新和刪除 Route 53 資源的 Route 53 管理 API 和主控台在控制平面上執行，這些控制平面的設計旨在優先考慮您在管理 DNS 時所需的強大一致性和耐久性。為了實現此目標，控制平面位於單一區域中：美國東部 (維吉尼亞北部)。儘管這兩個系統都建置得非常可靠，但控制平面未包含在 SLA 中。在極少數情況下，資料平面的彈性設計允許它保持可用性，而控制平面則不允許。對於災難復原和容錯移轉機制，使用資料平面功能提供可能最好的可靠性。
將您的運算基礎設施設計為靜態穩定，以避免在發生事件期間使用控制平面。例如，若您使用的是 Amazon EC2 執行個體，請避免手動佈建新執行個體，或避免指示 Auto Scaling 群組在回應中新增執行個體。為獲得最高層級的彈性，請在用於容錯移轉的叢集中佈建足夠的容量。如果必須限制此容量閾值，請對整體端對端系統設定節流，以安全地限制總流量達到所限制的資源集。
對於像是 Amazon DynamoDB、Amazon API Gateway、負載平衡器和 AWS Lambda 無伺服器等服務，使用這些服務會利用資料平面。不過，建立新功能、負載平衡器、API 閘道或 DynamoDB 資料表是控制平面動作，應在降級前完成，以準備進行事件和容錯移轉動作的演練。對於 Amazon RDS，資料平面動作允許存取資料。
如需關於資料平面、控制平面以及 AWS 如何建置服務以滿足高可用性目標的資訊，請參閱[使用可用區域的靜態穩定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)。
了解哪些作業位於資料平面，哪些位於控制平面。
### 實作步驟
針對需要在降級事件之後還原的每個工作負載，評估容錯移轉執行手冊、高可用性設計、自動修復設計，或 HA 資源還原計畫。找出可能視為控制平面動作的每個動作。
考慮將控制動作變更為資料平面動作：
+ Auto Scaling (控制平面) 至預先擴展的 Amazon EC2 資源 (資料平面)
+ Amazon EC2 執行個體擴展 (控制平面) 到 AWS Lambda 擴展 (資料平面)
+ 使用 Kubernetes 評估任何設計，以及控制平面動作的性質。新增 Pod 是 Kubernetes 中的資料平面動作。動作應限於新增 Pod 而不是新增節點。使用[過度佈建的節點](https://www.eksworkshop.com/docs/autoscaling/compute/cluster-autoscaler/overprovisioning/)是限制控制平面動作的慣用方法
請考慮可讓資料平面動作影響相同修復措施的替代方法。
+ Route 53 記錄變更 (控制平面) 或 Amazon 應用程式復原控制器 (資料平面)
+ [Route 53 運作狀態檢查以進行更多自動化更新](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
如果服務具任務關鍵性，請考慮次要區域中的某些服務，以便在未受影響的區域中執行更多控制平面和資料平面動作。
+ 將主要區域中的 Amazon EC2 Auto Scaling 或 Amazon EKS 與次要區域中的 Amazon EC2 Auto Scaling 或 Amazon EKS 相比較，並將流量路由到次要區域 (控制平面動作)
+ 將僅供讀取複本設為主要，或在主要區域中嘗試相同的動作 (控制平面動作)
## 資源
**相關的最佳實務：**
+ [可用性定義](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 監控工作負載的所有元件以偵測故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**相關文件：**
+ [APN 合作夥伴：可以幫助您實現容錯自動化的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace：可用於容錯的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [Amazon 建置者資料中心：控管較小服務，避免分散式系統過載](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 Elemental MediaStore 資料平面](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html)
+ [使用 Amazon 應用程式復原控制器建置高彈性應用程式，第 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 應用程式復原控制器建置高彈性應用程式，第 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/)
+ [什麼是 Amazon 應用程式復原控制器](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)？
+ [Kubernetes 控制平面和資料平面](https://aws.amazon.com/blogs/containers/managing-kubernetes-control-plane-events-in-amazon-eks/)
**相關影片：**
+ [回歸基礎 - 使用靜態穩定性](https://www.youtube.com/watch?v=gy1RITZ7N7s)
+ [使用 AWS 全球服務建置彈性的多站點工作負載](https://www.youtube.com/watch?v=62ZQHTruBnk)
**相關範例：**
+ [Amazon 應用程式復原控制器簡介](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
+ [Amazon 建置者資料中心：控管較小服務，避免分散式系統過載](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [使用 Amazon 應用程式復原控制器建置高彈性應用程式，第 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 應用程式復原控制器建置高彈性應用程式，第 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/)
+ [使用可用區域實現靜態穩定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
**相關工具：**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP05 使用靜態穩定性來防止雙模態行為
工作負載應該是靜態穩定的，且只在單一正常模式下運作。雙模態行為是指工作負載在正常和故障模式下呈現不同行為的情況。
例如，您可能在不同的可用區域中啟動新的執行個體，嘗試回復可用區域故障。這可能會導致在故障模式期間產生雙模態回應。您應改為建置靜態穩定且僅以一種模式操作的工作負載。在此範例中，這些執行個體應該在發生故障之前已佈建在第二個可用區域。此靜態穩定設計可以確保工作負載僅在單一模式下運作。
**預期成果：**工作負載不會在正常和故障模式出現雙模態行為。
**常見的反模式：**
+ 假設無論故障範圍，一律可以佈建資源。
+ 嘗試在故障期間動態取得資源。
+ 在發生故障之前，請勿在多個區域佈建適度的資源。
+ 僅考慮運算資源的靜態穩定設計。
**建立此最佳實務的優勢：**使用靜態穩定設計執行的工作負載，能夠在正常和故障事件發生時產生可預測的結果。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
雙模態行為是指您的工作負載在正常和故障模式下展現出不同的行為，例如，當可用區域故障時，仰賴啟動新的執行個體。其中一個雙模態行為範例是，如果移除一個可用區域，則穩定的 Amazon EC2 設計會在每個可用區域佈建足夠的執行個體來處理工作負載負載。Elastic Load Balancing 或 Amazon Route 53 運作狀態會進行檢查，將負載從受損的執行個體中移出。流量轉移後，使用 AWS Auto Scaling 以非同步方式取代故障區域的執行個體，並在運作良好的區域中啟動這些執行個體。運算部署 (例如 EC2 執行個體或容器) 的靜態穩定性可提供最高的可靠性。
![\[顯示跨可用區域 EC2 執行個體靜態穩定性的圖表\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/static-stability.png)
這必須在所有彈性情況下，與此模型的成本以及維護工作負載的商業價值互相衡量。佈建較少運算容量並在故障時啟動新執行個體的成本較低，但是對於大規模故障 (例如可用區域損壞)，這種方法的效率較低，因為它同時仰賴作業平面，以及未受影響區域中的足夠資源。
您的解決方案也應該權衡可靠性與工作負載的成本需求。靜態穩定架構適用於多種架構，包括在多個可用區域的運算執行個體、資料庫僅供讀取複本設計、Kubernetes (Amazon EKS) 叢集設計，以及多區域容錯移轉架構。
若在每個區域使用更多資源，也可以實施更靜態的穩定設計。透過新增更多區域，您可以降低靜態穩定性所需的額外運算量。
雙模態行為範例之一是網路逾時，網路逾時可能導致系統嘗試重新整理整個系統的組態狀態。這樣一來，即會給另一個元件新增意外負載，且可能導致其發生故障，從而引發其他意外後果。這種負面意見回饋迴圈會影響工作負載的可用性。反之，您可以建置靜態穩定且僅以一種模式操作的系統。靜態穩定的設計是執行持續工作，並始終以固定的規律重新整理組態狀態。叫用失敗時，工作負載會使用先前的快取數值，並啟動警示。
另一個雙模態行為範例是允許用戶端在發生失敗時繞過您的工作負載快取。這看起來可能是滿足用戶端需求的解決方案，但會大幅變更工作負載的需求，且可能導致故障。
評估關鍵工作負載，決定哪些工作負載需要此類彈性設計。針對關鍵工作負載，必須檢視每個應用程式元件。需要靜態穩定性評估的服務類型範例如下：
+ **運算**：Amazon EC2、EKS-EC2、ECS-EC2、EMR-EC2
+ **資料庫**：Amazon Redshift、Amazon RDS、Amazon Aurora
+ **儲存**：Amazon S3 (單一區域)、Amazon EFS (掛載)、Amazon FSx (掛載)
+ **負載平衡器：**在某些設計下
### 實作步驟
+ 建置靜態穩定且僅以一種模式操作的系統。在此情況下，請在每個可用區域佈建足夠的執行個體，以處理移除一個可用區域時的工作負載容量。許多服務皆可用於路由到運作狀態良好的資源，例如：
+ [跨區域 DNS 路由](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html)
+ [MRAP Amazon S3 多區域路由](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html)
+ [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)
+ [Amazon 應用程式復原控制器說明](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ 設定[資料庫讀取複本](https://aws.amazon.com/rds/features/multi-az/)以考慮單一主要執行個體或讀取複本的遺失情況。若僅供讀取複本為流量提供服務，則每個可用區域中的數量應等同於區域故障時的整體需求。
+ 在 Amazon S3 儲存中設定重要資料，以便可用區域故障時，能針對所儲存的資料保持靜態穩定。如果使用 [Amazon S3 One Zone-IA](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/) 儲存類別，則不應將其視為靜態穩定，因為該區域的遺失會最小化此儲存資料的存取權。
+ [Load balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html) 有時會設定錯誤，或本來就設定為供特定可用區域使用。在這種情況下，靜態穩定設計可能是在更複雜的設計中將工作負載分散到多個可用區域。出於安全性、延遲或成本考量，可以使用原始設計來減少區域間流量。
## 資源
**相關 Well-Architected 的最佳實務：**
+ [可用性定義](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 監控工作負載的所有元件以偵測故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
+ [REL11-BP04 復原期間需使用資料平面，而非控制平面](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_avoid_control_plane.html)
**相關文件：**
+ [在災難復原計畫中盡可能減少相依關係](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Amazon 建置者資料中心：使用可用區域實現靜態穩定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [故障隔離界限](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/appendix-a---partitional-service-guidance.html)
+ [使用可用區域實現靜態穩定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [多區域 RDS](https://aws.amazon.com/rds/features/multi-az/)
+ [在災難復原計畫中盡可能減少相依關係](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [跨區域 DNS 路由](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html)
+ [MRAP Amazon S3 多區域路由](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html)
+ [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)
+ [Amazon 應用程式復原控制器說明](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [單區域 Amazon S3](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/)
+ [跨區域負載平衡](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html)
**相關影片：**
+ [AWS 中的靜態穩定性：AWS re:Invent 2019：Amazon 建置者資料中心簡介 (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
# REL11-BP06 當事件影響可用性時傳送通知
當偵測到閥值超標時傳送通知，即使問題造成的事件已自動解決。
自動修復功能可讓您的工作負載變得可靠。不過，也可能會遮蔽需要解決的潛在問題。實作適當的監控和事件，讓您能夠偵測到問題模式 (包括自動修復功能處理的問題模式)，以解決根本原因問題。
具有韌性的系統可將降級事件立即傳達給權責團隊。這些通知應該透過一個或多個通訊管道傳送。
**預期成果：**當超過閾值 (例如錯誤率、延遲或其他關鍵績效指標 (KPI)) 時，營運團隊會立即收到警示，以盡快解決問題，避免或將使用者負面影響降至最低。
**常見的反模式：**
+ 傳送太多警示。
+ 傳送不可採取行動的警示。
+ 警示閾值設置太高 (太敏感) 或太低 (太遲鈍)。
+ 不傳送外部相依性的警示。
+ 在設計監控和警示時，不考慮[微小故障](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html)。
+ 進行修復自動化，但不通知權責團隊需要修復。
**建立此最佳實務的優勢：**回復通知可讓營運和業務團隊注意到服務降級，讓他們可以立即反應，將平均偵測時間 (MTTD) 和平均復原時間 (MTTR) 降至最低。回復事件的通知也會確認您不會忽略不常發生的問題。
**未建立此最佳實務時的風險暴露等級：**中。若無法實作適當的監控和事件通知機制，您可能就無法偵測到問題模式 (包括自動修復功能處理的問題模式)。只有當使用者聯絡客服或偶然情況下，團隊才會注意到系統降級。
## 實作指引
定義監控策略時，觸發警示是常見的事件。此事件可能包含警示的識別碼、警示狀態 (例如 `IN ALARM` 或 `OK`) 以及觸發原因詳情。在許多情況下，系統應檢測到警示事件並傳送電子郵件通知。這是警示動作範例。警示通知對於可觀測性至關重要，因為它會通知權責人員有問題發生。然而，當可觀測性解決方案對事件的回應措施夠熟練後，便可以自動修復問題，無須人為介入。
建立 KPI 監控警示後，閾值超過時就應會向權責團隊傳送警示。這些警示也可用於觸發嘗試修復降級的自動化程序。
針對更複雜的閾值監控，則應考慮使用複合警示。複合警示會使用數個 KPI 監控警示，根據作業商務邏輯建立警示。CloudWatch 警示可設定為傳送電子郵件，或使用 Amazon SNS 整合或 Amazon EventBridge 在第三方事件追蹤系統中記錄事件。
### 實作步驟
根據監控工作負載的方式建立各種警示類型，例如：
+ 應用程式警示可用來偵測工作負載任何無法正常運作的部分。
+ [基礎設施警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)會指出何時擴展資源。警示會在儀表板上以視覺化方式顯示、透過 Amazon SNS 或電子郵件傳送提醒，以及搭配使用 Auto Scaling 來擴展或縮減工作負載資源。
+ 可建立簡單的[靜態指示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)，以監控指標在指定評估期間內超過靜態閾值的時間。
+ [複合警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)可以涵蓋來自多個來源的複雜警示。
+ 建立警示後，請建立適當的通知事件。可以直接調用 [Amazon SNS API](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 來傳送通知，並連結任何自動化以進行修復或通訊。
+ 透過 [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) 隨時掌握服務降級的相關資訊。[透過 [AWS 使用者通知](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) 建立符合用途的 AWS Health 事件通知](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html)，以利用電子郵件和聊天管道傳送，並透過 [Amazon EventBridge 以程式設計方式與您的監控和警示工具](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)整合。
## 資源
**相關 Well-Architected 的最佳實務：**
+ [可用性定義](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.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)
+ [發佈自訂指標](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/Create_Composite_Alarm.html)
+ [re:Invent 2022 中 AWS Observability 的最新消息](https://aws.amazon.com/blogs/mt/whats-new-in-aws-observability-at-reinvent-2022/)
**相關工具：**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)：
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP07 建立您的產品架構以符合可用性目標和運行時間服務水準協議 (SLA)
建立您的產品架構以符合可用性目標和運行時間服務水準協議 (SLA)。如果您發佈或私下同意可用性目標或運行時間 SLA，請確認您的架構和操作程序的設計可以支援。
**預期成果：**每個應用程式都有一個已定義的可用性目標和效能指標的 SLA，可以進行監控和維護，以達到業務成果。
**常見的反模式：**
+ 設計和部署工作負載，而未設定任何 SLA。
+ SLA 指標設定為高，而沒有合理或業務要求。
+ 設定 SLA 但未考慮相依性及其基礎 SLA。
+ 建立應用程式設計而未考慮彈性的共同責任模型。
**建立此最佳實務的優勢：**根據關鍵彈性目標設計應用程式，可協助您達成業務目標和客戶期望。這些目標可協助推動應用程式設計程序，評估不同的技術和考慮各種權衡。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
應用程式設計必須將多元的要求納入考慮，這些要求是從業務、營運和財務目標衍生而來。在營運要求內，工作負載必須有特定彈性指標目標，才能適當地監控和支援。彈性指標不應該在部署工作負載之後設定或衍生。它們應該在設計階段期間定義，協助引導各種決策和權衡。
+ 每個工作負載都應該有自己的一組彈性指標。這些指標可能與其他業務應用程式不同。
+ 降低相依性對可用性有正面影響。每個工作負載都應該考慮其相依性及其 SLA。一般而言，選取可用性目標等於或大於工作負載目標的相依性。
+ 請考慮鬆散耦合設計，讓您的工作負載在可行時不論是否有相依性受損，都可以正確操作。
+ 減少控制平面相依性，特別是復原或降級期間。評估針對任務關鍵性工作負載靜態穩定的設計。使用資源節省來增加工作負載中這些相依性的可用性。
+ 可觀測性和檢測對於透過降低平均偵測時間 (MTTD) 和平均修復時間 (MTTR) 來達成 SLA 相當關鍵。
+ 低頻率失敗 (MTBF 較長)、較短的失敗偵測時間 (較短 MTTD) 和較短的修復時間 (較短 MTTR)，是用來在分散式系統中改善可用性的三個因素。
+ 建立和符合工作負載的彈性指標，是任何有效設計的基礎。這些設計必須考慮到設計複雜性、服務相依性、效能、擴展和成本的權衡。
**實作步驟**
+ 請考慮下列問題，審核和記載工作負載設計：
+ 控制平面用於工作負載的哪個地方？
+ 工作負載如何實作容錯能力？
+ 擴展、自動擴展、備援和高可用性元件的設計模式是什麼？
+ 資料一致性和可用性的要求是什麼？
+ 資源節省或資源靜態穩定性是否有任何考慮？
+ 服務相依性是什麼？
+ 與利益相關者合作時根據工作負載架構定義 SLA 指標。請考慮工作負載所使用所有相依性的 SLA。
+ 一旦設定 SLA 目標，最佳化架構以符合 SLA。
+ 一旦設定可符合 SLA 的設計，實作營運變更、處理自動化以及也會著重在降低 MTTD 和 MTTR 的執行手冊。
+ 部署之後，監控和報告 SLA。
## 資源
**相關的最佳實務：**
+ [REL03-BP01 選擇如何分割工作負載](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 將工作負載部署至多個位置](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 監控工作負載的所有元件以偵測故障](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 將所有分層的修復自動化](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP04 使用混沌工程測試彈性](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL13-BP01 定義停機和資料遺失的復原目標](rel_planning_for_recovery_objective_defined_recovery.md)
+ [了解工作負載運作狀態](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-workload-health.html)
**相關文件：**
+ [備援的可用性](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [可靠性支柱 - 可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [測量可用性](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/measuring-availability.html)
+ [AWS 故障隔離界限](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [彈性的共同責任模型](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/shared-responsibility-model-for-resiliency.html)
+ [使用可用區域實現靜態穩定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
+ [AWS 服務水準協議 (SLA)](https://aws.amazon.com/legal/service-level-agreements/)
+ [AWS 上小組型架構指南](https://aws.amazon.com/solutions/guidance/cell-based-architecture-on-aws/)
+ [AWS 基礎設施](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-infrastructure.html)
+ [《進階多可用區域彈性模式》白皮書](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html)
**相關服務：**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)