# 可靠性
**Topics**
+ [基礎](a-foundations.md)
+ [工作負載架構](a-workload-architecture.md)
+ [變更管理](a-change-management.md)
+ [失敗管理](a-failure-management.md)
# 基礎
**Topics**
+ [REL 1 您如何管理服務配額和限制？](w2aac19b9b5b5.md)
+ [REL 2 如何規劃您的網路拓撲？](w2aac19b9b5b7.md)
# REL 1 您如何管理服務配額和限制？
雲端型工作負載架構會有服務配額 (也稱為服務限制)。這些配額旨在用於防止不慎佈建超過您所需的資源，並限制 API 操作上的請求率，以防止服務遭到濫用。此外也會有資源限制，例如，您可將位元壓入光纖電纜的速率或實體磁碟上的儲存量會受到限制。
**Topics**
+ [REL01-BP01 了解服務配額和限制](rel_manage_service_limits_aware_quotas_and_constraints.md)
+ [REL01-BP02 管理跨帳戶和區域的服務配額](rel_manage_service_limits_limits_considered.md)
+ [REL01-BP03 透過架構適應固定服務配額和限制](rel_manage_service_limits_aware_fixed_limits.md)
+ [REL01-BP04 監控和管理配額](rel_manage_service_limits_monitor_manage_limits.md)
+ [REL01-BP05 自動配額管理](rel_manage_service_limits_automated_monitor_limits.md)
+ [REL01-BP06 確保目前配額與最大使用量之間存在足夠差距以適應容錯移轉](rel_manage_service_limits_suff_buffer_limits.md)
# REL01-BP01 了解服務配額和限制
您需了解工作負載架構的預設配額和配額增加要求。您也需知道哪些資源限制 (例如，磁碟或網路) 具有潛在影響。
Service Quotas 是一項 AWS 服務，有助於您從單一位置管理 100 多種 AWS 服務的配額。除了查閱配額值外，您也可以從 Service Quotas 主控台或透過 AWS 開發套件請求和追蹤配額增長。AWS Trusted Advisor 提供服務配額檢查功能，會顯示部分服務某些層面的用量和配額。每項服務的預設服務配額也根據各自服務列於 AWS 文件中，例如，請參閱 [Amazon VPC 配額](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html)。若要在 API Gateway 中設定用於調節 API 的速率限制，請設定用量計畫。在其各自服務上設為組態的其他限制包括佈建 IOPS、分配的 RDS 儲存體，以及 EBS 磁碟區分配。Amazon Elastic Compute Cloud (Amazon EC2) 具有專門的 Service Limits 儀表板，有助於您管理執行個體、Amazon Elastic Block Store (Amazon EBS) 和彈性 IP 地址限制。如果在您的使用案例中，服務配額會影響您的應用程式效能且無法根據您的需求調整，請聯絡 AWS 支援 以查看是否有緩解措施。
**常用的反模式：**
+ 部署工作負載，但不考慮所使用 AWS 服務上的服務配額。
+ 設計工作負載，但不調查和適應 AWS 服務的設計限制。
+ 部署具有重要用途的工作負載取代已知的現有工作負載，但事先未設定必要的配額或聯絡 AWS 支援。
+ 規劃事件以將流量導引至您的工作負載，但事先未設定必要的配額或聯絡 AWS 支援。
**建立此最佳實務的優勢：** 了解服務配額、API 調節限制和設計限制，可讓您在設計、實作和操作工作負載的過程中納入這些考量。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 在發佈的文件和 Service Quotas 中審查 AWS 服務配額。
+ [AWS Service Quotas (先前稱為 Limits)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ 透過查看部署程式碼來確定工作負載所需的所有服務。
+ 使用 AWS Config 尋找在 AWS 帳戶 中使用的所有 AWS 資源。
+ [AWS Config 支援的 AWS 資源類型和資源關係](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html)
+ 您也可以使用 AWS CloudFormation 來確定所使用的 AWS 資源。查看在 AWS 管理主控台或透過 list-stack-resources CLI 命令建立的資源。您也可以查看設為自行在範本中部署的資源。
+ [在 AWS 管理主控台 上檢視 AWS CloudFormation 堆疊資源和資料](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html)
+ [AWS CLI for CloudFormation：list-stack-resources](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html)
+ 決定適用的服務配額。透過 Trusted Advisor 和 Service Quotas 使用可以程式設計方式存取的資訊。
## 資源
**相關文件：**
+ [AWS Marketplace：可追蹤限制的 CMDB 產品](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWSService Quotas (先前稱為 Service Limits)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor 最佳實務檢查 (請參閱 Service Limits 一節)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS Answers 上的 AWS Limit Monitor](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [什麼是 Service Quotas？](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**相關影片：**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP02 管理跨帳戶和區域的服務配額
如果您使用多個 AWS 帳戶或 AWS 區域，確保在生產工作負載執行的所有環境中都要求合適的配額。
系統會針對每個帳戶追蹤服務配額。除非另有說明，否則每個配額都是 AWS 區域特有。除生產環境之外，也會在所有適用的非生產環境中管理配額，因此不會阻礙測試和開發。
**常用的反模式：**
+ 允許一個隔離區域內的資源利用率增長，但無維持其他隔離區域中容量的機制。
+ 獨自手動設定隔離區域中的所有配額。
+ 未確保隔離區域的部署在部署遺失時調整規模，以適應來自其他區域的流量增加。
**建立此最佳實務的優勢：** 確保您可以在隔離區域無法使用時可以處理目前的負載，這可協助減少在容錯移轉期間發生的錯誤，而不會對客戶造成阻斷服務狀況。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 根據您的服務要求、延遲、法規和災難復原 (DR) 要求，選擇相關的帳戶和區域。
+ 確定所有相關帳戶、區域和可用區域中的服務配額。限制範圍受限於帳戶和區域。
+ [什麼是 Service Quotas？](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
## 資源
**相關文件：**
+ [AWS Marketplace：可追蹤限制的 CMDB 產品](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWSService Quotas (先前稱為 Service Limits)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor 最佳實務檢查 (請參閱 Service Limits 一節)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS Answers 上的 AWS Limit Monitor](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [什麼是 Service Quotas？](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**相關影片：**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP03 透過架構適應固定服務配額和限制
瞭解不可變更的服務配額和實體資源及架構，以防止這些因素影響可靠性。
範例包括網路頻寬、AWS Lambda 承載大小、API Gateway 調節爆量速率，以及 Amazon Redshift 叢集的使用者同時連線數目。
**常用的反模式：**
+ 執行基準化分析的時間過短，利用高載限制，但預期服務會以該容量持續執行一段期間。
+ 選擇每位使用者或客戶使用一項服務的一項資源的設計，但未注意到擴展時會導致此項設計失效的設計限制。
**建立此最佳實務的優勢：** 追蹤 AWS 服務中的固定配額和工作負載其他部分中的限制 (例如連線能力限制、IP 地址限制和第三方服務的限制)，能夠讓您察覺何時趨向於配額限制，並有能力在超過配額前處理配額。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
+ 注意固定服務配額：請注意固定的服務配額和限制，並根據這些因素建立架構。
+ [AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
## 資源
**相關文件：**
+ [AWS Marketplace：可追蹤限制的 CMDB 產品](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWSService Quotas (先前稱為 Service Limits)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor 最佳實務檢查 (請參閱 Service Limits 一節)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS Answers 上的 AWS Limit Monitor](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [什麼是 Service Quotas？](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**相關影片：**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP04 監控和管理配額
評估潛在用量並適當地增加配額，以允許使用量按計劃增長。
對於支援的服務，您可以設定 CloudWatch 警示來監控用量並提醒您已接近配額限制，從而管理配額。這些警示可以從 Service Quotas 或 Trusted Advisor 觸發。您也可以使用 CloudWatch Logs 上的指標篩選條件，搜尋與擷取日誌中的模式，以判斷用量是否正在接近配額閾值。
**常用的反模式：**
+ 設定了正在接近 Service Quotas 的警示，但無如何回應提醒的程序。
+ 只設定 Service Quotas 支援的服務警示，但未監控其他服務。
**建立此最佳實務的優勢：** 自動追蹤 AWS 服務配額並根據這些配額監控您的使用量，可讓您查看何時會接近配額限制。您也可以使用此監控資料來評估何時可能降低配額以節省成本。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
+ 監控和管理您的配額：評估您在 AWS 上的潛在使用量，適當提高區域服務配額，並允許使用量按計劃增長。
+ 擷取當前資源消耗 (例如，儲存貯體、執行個體)。使用服務 API 操作 (例如 Amazon EC2 DescribeInstances API) 來收集當前資源消耗。
+ 擷取您的目前配額：使用 AWS Service Quotas、AWS Trusted Advisor 和 AWS 文件。
+ 使用 AWS Service Quotas，這是一項 AWS 服務，有助於您從單一位置管理 100 多種 AWS 服務的配額。
+ 使用 Trusted Advisor 服務限制來確定您當前的服務限制。
+ 使用服務 API 操作來確定支援的當前服務配額。
+ 記錄請求增加的配額及其狀態：核准配額增加後，請確保您更新記錄，以反映配額的變更。
## 資源
**相關文件：**
+ [AWS Marketplace：可追蹤限制的 CMDB 產品](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWSService Quotas (先前稱為 Service Limits)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor 最佳實務檢查，適用於 Service Limits](https://docs.aws.amazon.com/awssupport/latest/user/service-limits.html)
+ [AWS Answers 上的 AWS Limit Monitor](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [什麼是 Service Quotas？](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [使用 Amazon CloudWatch 警示監控 Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/configure-cloudwatch.html)
**相關影片：**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP05 自動配額管理
實作工具以在接近閾值時獲得提醒。您可以使用 AWS Service Quotas API，自動化配額增加請求。您可以自動化配額增加請求。
如果您將組態管理資料庫 (CMDB) 或票務系統與 Service Quotas 整合，則可以自動追蹤配額增加請求和目前的配額。除了 AWS 開發套件外，Service Quotas 也會使用 AWS Command Line Interface (AWS CLI) 提供自動化。
**常用的反模式：**
+ 以試算表追蹤配額和使用量。
+ 每日、每週或每月執行使用量報告，然後比較使用量與配額。
**建立此最佳實務的優勢：** 自動追蹤 AWS 服務配額並根據該配額監控您的使用量，可讓您查看何時會接近配額限制。您可以設定自動化，協助您在需要時請求增加配額。當您的使用量與實現風險降低 (登入資料遭危害時) 和成本節省的優勢背道而馳時，您可能會考慮降低部分配額。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
+ 設定自動監控：使用開發套件實作工具，以在接近閾值時獲得提醒。
+ 使用 Service Quotas，並以如 AWS Limit Monitor 或 AWS Marketplace 中的產品等自動配額監控解決方案擴大此項服務。
+ [什麼是 Service Quotas？](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [AWS 上的配額監視器 - AWS 解決方案](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ 使用 Amazon SNS 和 AWS Service Quotas API 設定由配額閾值觸發的回應。
+ 測試自動化。
+ 設定限制閾值。
+ 與來自 AWS Config、部署管道、Amazon EventBridge 或第三方的變更事件整合。
+ 人工設定較低配額閾值以測試回應。
+ 設定觸發程序以在收到通知時採取適當的措施，以及在必要時讓人員聯絡 AWS 支援。
+ 手動觸發變更事件。
+ 執行演練日以測試配額增長變更程序。
## 資源
**相關文件：**
+ [APN 合作夥伴：可以幫助進行組態管理的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=Configuration+Management)
+ [AWS Marketplace：可追蹤限制的 CMDB 產品](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWSService Quotas (先前稱為 Service Limits)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor 最佳實務檢查 (請參閱 Service Limits 一節)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS 上的配額監視器 - AWS 解決方案](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [什麼是 Service Quotas？](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**相關影片：**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP06 確保目前配額與最大使用量之間存在足夠差距以適應容錯移轉
當資源失敗時，在成功終止之前，其可能仍會被計入限額。在終止失敗的資源之前，確保您的配額涵蓋所有失敗的資源與替換資源的重疊部分。計算此差距時，應考慮可用區域失敗。
**常用的反模式：**
+ 根據目前的需求設定服務配額，而不考量容錯移轉案例。
**建立此最佳實務的優勢：** 當事件可能影響可用性時，雲端可讓您實作策略來減輕影響或從這些事件中復原。這類策略通常包括建立額外資源以取代失敗的資源。您的配額策略必須容納這些額外的資源。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 確保您的服務配額和最大用量之間存在足夠的差距以適應容錯移轉。
+ 確定服務限制，並在此過程中考慮您的部署模式、可用性要求和使用量增長。
+ 視需要請求增加配額。規劃必要的時間來滿足增加配額的請求。
+ 確定您的可靠性方案 (也稱為「幾個 9」)。
+ 建立故障案例 (例如，元件、可用區域或區域遺失)。
+ 建立您的部署方法 (例如，Canary、藍/綠、紅/黑或滾動)。
+ 為當前限制新增適當的緩衝 (例如 15%)。
+ 為使用量增長制定計畫 (例如，監控使用量趨勢)。
## 資源
**相關文件：**
+ [AWS Marketplace：可追蹤限制的 CMDB 產品](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWSService Quotas (先前稱為 Service Limits)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [AWS Trusted Advisor 最佳實務檢查 (請參閱 Service Limits 一節)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [什麼是 Service Quotas？](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**相關影片：**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL 2 如何規劃您的網路拓撲？
工作負載經常存在於多個環境中。這些環境包括多個 (可公開存取和私有的) 雲端環境，且可能包含您現有的資料中心基礎設施。計畫必須包括系統內和系統間連線、公有 IP 地址管理、私有 IP 地址管理和網域名稱解析等網路考量因素。
**Topics**
+ [REL02-BP01 針對工作負載公有端點使用高可用性網路連線](rel_planning_network_topology_ha_conn_users.md)
+ [REL02-BP02 在雲端中的私有網路與內部部署環境之間佈建冗餘連線能力](rel_planning_network_topology_ha_conn_private_networks.md)
+ [REL02-BP03 確保 IP 子網路分配帳戶具有擴展性和可用性](rel_planning_network_topology_ip_subnet_allocation.md)
+ [REL02-BP04 偏好軸幅式拓撲而非多對多網狀拓撲](rel_planning_network_topology_prefer_hub_and_spoke.md)
+ [REL02-BP05 在連線的所有私有地址空間中強制使用不重疊的私有 IP 地址範圍](rel_planning_network_topology_non_overlap_ip.md)
# REL02-BP01 針對工作負載公有端點使用高可用性網路連線
這些端點及其路由必須具備高可用性。為達成此目的，請使用高度可用的 DNS、內容交付網路 (CDN)、API Gateway、負載平衡或反向代理。
Amazon Route 53、AWS Global Accelerator、Amazon CloudFront、Amazon API Gateway 和 Elastic Load Balancing (ELB) 全都提供高可用性的公開端點。您也可以選擇評估用於負載平衡和代理的 AWS Marketplace 軟體設備。
您的工作負載提供的服務取用者 (無論是最終使用者還是其他服務) 會請求這些服務端點。有多種 AWS 資源可供您提供高可用性端點。
Elastic Load Balancing 提供跨可用區域的負載平衡，執行 Layer 4 (TCP) 或 Layer 7 (http/https) 路由，與 AWS WAF 整合，以及與 AWS Auto Scaling 整合，以便協助建立自我修復基礎設施並吸收增加的流量，同時在流量減少時釋放資源。
Amazon Route 53 是可擴展的高可用性網域名稱系統 (DNS) 服務，能將使用者請求連接到 AWS 中執行的基礎設施，例如 Amazon EC2 執行個體、Elastic Load Balancing 負載平衡器或 Amazon S3 儲存貯體，還可用於將使用者路由到 AWS 外部的基礎設施。
AWS Global Accelerator 是網路層服務，可供您透過 AWS 全球網路將流量引導至最佳端點。
分散式阻斷服務 (DDoS) 攻擊所存在的風險會將合法流量阻擋在外，並減少使用者的可用性。AWS Shield 為您工作負載上的 AWS 服務端點，提供抵擋這些攻擊的自動防護，無需額外費用。您可以使用 APN 合作夥伴和 AWS Marketplace 提供的虛擬設備來增強這些功能，以滿足您的需求。
**常用的反模式：**
+ 在執行個體或容器上使用公有網際網路地址，並透過 DNS 管理其連線。
+ 使用網際網路通訊協定地址，而非網域名稱來定位服務。
+ 提供內容 (網頁、靜態資產、媒體檔案) 到大型地理區域，而不使用內容交付網路。
**建立此最佳實務的優勢：** 透過在工作負載中實作高可用性服務，即可知道負載可供使用者使用。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
確保為工作負載使用者提供高可用性連線：Amazon Route 53、AWS Global Accelerator、Amazon CloudFront、Amazon API Gateway 和 Elastic Load Balancing (ELB) 全都提供高可用性的公開端點。您也可能選擇評估用於負載平衡和代理的 AWS Marketplace 軟體設備。
+ 確保您與使用者的連線高度可用。
+ 確保您使用的是高度可用的 DNS 來管理應用程式端點的網域名稱。
+ 如果使用者透過網際網路存取您的應用程式，請使用服務 API 操作來確認正確使用網際網路閘道。同時確認託管應用程式端點之子網路的路由表項目正確。
+ [DescribeInternetGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInternetGateways.html)
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
+ 確保在應用程式前面使用高可用性的反向代理或負載平衡器。
+ 如果使用者透過您的內部部署環境存取您的應用程式，應確保 AWS 與您的內部部署環境之間的連線高度可用。
+ 使用 Route 53 來管理您的網域名稱。
+ [什麼是 Amazon Route 53？](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ 使用符合您要求的第三方 DNS 供應商。
+ 使用 Elastic Load Balancing。
+ [什麼是 Elastic Load Balancing？](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ 使用符合您要求的 AWS Marketplace 設備。
## 資源
**相關文件：**
+ [APN 合作夥伴：可以幫助您規劃聯網的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [AWS Direct Connect 恢復能力建議](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [適用於網路基礎設施的 AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011)
+ [Amazon Virtual Private Cloud 連線能力選項白皮書](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [多個資料中心 HA 網路連線](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [以 Direct Connect 彈性工具組開始使用](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html)
+ [VPC 端點和 VPC 端點服務 (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [什麼是 AWS Global Accelerator？](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [什麼是 Amazon VPC？](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [什麼是 Transit Gateway？](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [什麼是 Amazon CloudFront？](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ [什麼是 Amazon Route 53？](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [什麼是 Elastic Load Balancing？](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [使用 Direct Connect Gateway](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html)
**相關影片：**
+ [AWS re:Invent 2018：進階 VPC 設計及 Amazon VPC 的新功能 (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019：適用於許多 VPC 的 AWS Transit Gateway 參考架構 (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP02 在雲端中的私有網路與內部部署環境之間佈建冗餘連線能力
在單獨部署的私有網路之間使用多個 AWS Direct Connect 連線和多個 VPN 通道。使用多個 Direct Connect 位置以實現高可用性。如果使用多個 AWS 區域，請至少在其中兩個區域中確保冗餘。您可能需要評估終止 VPN 的 AWS Marketplace 設備。如果您使用 AWS Marketplace 設備，可在不同的可用區域中部署冗餘執行個體以實現高可用性。
AWS Direct Connect 是一項雲端服務，可讓您輕鬆地建立一個連接內部部署環境和 AWS 的專用網路連線。您的內部部署資料中心可以使用 Direct Connect Gateway，連線至橫跨多個 AWS 區域的多個 AWS VPC。
此冗餘可以解決會影響連線彈性的可能故障：
+ 您可如何彈性回應拓樸故障？
+ 如果您錯誤設定並刪除連線會怎樣？
+ 您是否能夠處理服務流量或使用方面的意外增加情況？
+ 您是否能夠應對企圖的分散式阻斷服務 (DDoS) 攻擊？
透過 VPN 將 VPC 連線至內部部署資料中心時，您應在選擇需要在其上執行設備的供應商和執行個體大小時，考慮所需的彈性和頻寬要求。如果您使用的 VPN 設備在實作上沒有彈性，則您應透過第二個設備進行冗餘連線。對於所有這些情況，您需要定義可接受的復原時間並進行測試以確保能滿足這些要求。
如果您選擇使用 Direct Connect 連線將 VPC 連線到資料中心，且您需要此連線具有高可用性，請從各資料中心獲取冗餘 Direct Connect 連線。冗餘連線應使用不同於第一個位置的第二個 Direct Connect 連線。如果您擁有多個資料中心，請確保在不同的位置終止連線。使用 [Direct Connect 彈性工具組](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html) 有助於您進行此項設定。
如果您選擇使用 Site-to-Site VPN 透過網際網路容錯移轉到 VPN，請務必了解其支援至多每個 VPN 通道 1.25 Gbps 的輸送量，但是若在同一 VGW 上終止多個 AWS Managed VPN 通道，則不支援等價多路徑 (ECMP) 傳出流量。除非您可以忍受容錯移轉時低於 1 Gbps 的速度，否則我們不建議您將 AWS Managed VPN 做為 Direct Connect 連線的備份。
您也可以使用 VPC 端點，將 VPC 私密連線至支援的 AWS 服務和採用 AWS PrivateLink 技術的 VPC 端點服務，而不需周遊公有網際網路。端點是虛擬裝置。它們是水平擴展、冗餘和高可用性的 VPC 元件。它們允許 VPC 中的執行個體與服務之間進行通訊，而不會對網路流量帶來可用性風險或頻寬限制。
**常用的反模式：**
+ 您的現場網路與 AWS 之間只有一個連線供應商。
+ 使用 AWS Direct Connect 連線的連線功能，但只有一個連線。
+ 您的 VPN 連線只有一個路徑。
**建立此最佳實務的優勢：** 透過在您的雲端環境與您的公司或內部部署環境之間實作冗餘連線，即可確保兩個環境之間的相依服務能夠可靠地進行通訊。
**若未建立此最佳實務，暴露的風險等級為：** 高
## 實作指引
+ 確保 AWS 與內部部署環境之間具有高度可用的連線。在單獨部署的私有網路之間使用多個 AWS Direct Connect 連線和多個 VPN 通道。使用多個 Direct Connect 位置以實現高可用性。如果使用多個 AWS 區域，請至少在其中兩個區域中確保冗餘。您可能需要評估終止 VPN 的 AWS Marketplace 設備。如果您使用 AWS Marketplace 設備，可在不同的可用區域中部署冗餘執行個體以實現高可用性。
+ 確保與內部部署環境之間存在冗餘連線。您可能需要與多個 AWS 區域的冗餘連線才能滿足可用性需求。
+ [AWS Direct Connect 恢復能力建議](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [使用冗餘站點對站點 VPN 連接提供容錯移轉](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html)
+ 使用服務 API 操作來識別對 Direct Connect 線路的正確使用。
+ [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html)
+ [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html)
+ [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html)
+ [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll)
+ [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html)
+ [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html)
+ [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html)
+ 如果僅存在一個 Direct Connect 連線，或者一個都沒有，則設定到虛擬私有閘道的冗餘 VPN 通道。
+ [什麼是 AWS 站點對站點 VPN？](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html)
+ 擷取您當前的連線 (例如，直接連線、虛擬私有閘道、AWS Marketplace 設備)。
+ 使用服務 API 操作來查詢 Direct Connect 連線的組態。
+ [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html)
+ [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html)
+ [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html)
+ [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll)
+ [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html)
+ [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html)
+ [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html)
+ 使用服務 API 操作來收集路由表使用的虛擬私有閘道。
+ [DescribeVpnGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpnGateways.html)
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
+ 使用服務 API 操作收集路由表使用的 AWS Marketplace 應用程式。
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
## 資源
**相關文件：**
+ [APN 合作夥伴：可以幫助您規劃聯網的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [AWS Direct Connect 恢復能力建議](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [適用於網路基礎設施的 AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011)
+ [Amazon Virtual Private Cloud 連線能力選項白皮書](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [多個資料中心 HA 網路連線](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [使用冗餘站點對站點 VPN 連接提供容錯移轉](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html)
+ [以 Direct Connect 彈性工具組開始使用](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html)
+ [VPC 端點和 VPC 端點服務 (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [什麼是 Amazon VPC？](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [什麼是 Transit Gateway？](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [什麼是 AWS 站點對站點 VPN？](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html)
+ [使用 Direct Connect Gateway](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html)
**相關影片：**
+ [AWS re:Invent 2018：進階 VPC 設計及 Amazon VPC 的新功能 (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019：適用於許多 VPC 的 AWS Transit Gateway 參考架構 (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP03 確保 IP 子網路分配帳戶具有擴展性和可用性
Amazon VPC IP 地址範圍必須足夠大，以適應工作負載的要求，包括考慮將來擴展 IP 地址以及跨可用區域將 IP 地址分配給子網路。這包括負載平衡器、EC2 執行個體和容器型應用程式。
規劃您的網路拓樸時，首先要定義 IP 地址空間。私有 IP 地址範圍 (依循 RFC 1918 指導方針) 應分配給各 VPC。在此流程中請滿足下列要求：
+ 允許每個區域為多於一個 VPC 準備 IP 地址空間。
+ 在 VPC 內，允許多個子網路的空間，並可跨越多個可用區域。
+ 經常在 VPC 內留下未用 CIDR 區塊空間，以供未來擴展。
+ 確保有 IP 地址空間可以滿足您可能會用到之 EC2 執行個體的任何臨時機群需求，例如，用於機器學習的 Spot Fleets、Amazon EMR 叢集或 Amazon Redshift 叢集。
+ 請注意，在各子網路 CIDR 區塊中，前四個 IP 地址和最後一個 IP 地址均預留起來，無法供您使用。
+ 您應計劃部署大型 VPC CIDR 區塊。請注意，雖然無法變更或刪除分配給 VPC 的最初 VPC CIDR 區塊，但您可以將不重疊的其他 CIDR 區塊新增至 VPC。無法變更子網路 IPv4 CIDR，但可以變更 IPv6 CIDR。請牢記，部署最大的 VPC 可能 (/16) 會導致超過 65,000 個 IP 地址。單單在基底 10.x.x.x IP 地址空間中，您即可佈建 255 個此類 VPC。因此，您應該選擇過大而非過小，以便更容易管理 VPC。
**常用的反模式：**
+ 建立小型 VPC。
+ 建立小型子網路，然後必須隨著增長將子網路新增至組態。
+ 錯誤預估 Elastic Load Balancer 可以使用的 IP 地址數量。
+ 在相同的子網路中部署許多高流量負載平衡器。
**建立此最佳實務的優勢：** 如此可確保您可以適應工作負載的增長，並在向上擴展時繼續提供可用性。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 規劃網路以適應增長、法規要求以及與其他網路整合。增長可能會被低估，合規要求可能會發生變化，並且如果沒有適當的規劃，採購或私有網路連線可能會難以實作。
+ 根據您的服務要求、延遲、法規和災難復原 (DR) 要求，選擇相關的 AWS 帳戶和區域。
+ 確定您對區域 VPC 部署的需求。
+ 確定 VPC 的大小。
+ 確定是否要部署多 VPC 連線。
+ [什麼是 Transit Gateway？](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [單區域多 VPC 連線](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/)
+ 確定您是否需要區隔聯網以滿足法規要求。
+ 讓 VPC 盡可能保持較大規模。雖然無法變更或刪除分配給 VPC 的最初 VPC CIDR 區塊，但您可以將不重疊的其他 CIDR 區塊新增至 VPC。但這可能會導致地址範圍片段化。
+ 讓 VPC 盡可能保持較大規模。雖然無法變更或刪除分配給 VPC 的最初 VPC CIDR 區塊，但您可以將不重疊的其他 CIDR 區塊新增至 VPC。但這可能會導致地址範圍片段化。
## 資源
**相關文件：**
+ [APN 合作夥伴：可以幫助您規劃聯網的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [適用於網路基礎設施的 AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011)
+ [Amazon Virtual Private Cloud 連線能力選項白皮書](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [多個資料中心 HA 網路連線](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [單區域多 VPC 連線](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/)
+ [什麼是 Amazon VPC？](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
**相關影片：**
+ [AWS re:Invent 2018：進階 VPC 設計及 Amazon VPC 的新功能 (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019：適用於許多 VPC 的 AWS Transit Gateway 參考架構 (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP04 偏好軸幅式拓撲而非多對多網狀拓撲
如果兩個以上的網路地址空間 (例如，VPC 和內部部署網路) 透過 VPC 對等互連 AWS Direct Connect 或 VPN 連線，則使用軸幅式模型，例如 AWS Transit Gateway 提供的此類模型。
如果您只有這兩種網路，僅需相互連線，但隨著網路數成長，此類網狀連線的複雜性將變得難以處理。AWS Transit Gateway 提供容易維護的軸幅式模型，以便跨多條網路路由流量。
![\[顯示未使用 AWS Transit Gateway 的圖表\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/without-transit-gateway.png)
![\[顯示使用 AWS Transit Gateway 的圖表\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/with-transit-gateway.png)
**常用的反模式：**
+ 使用 VPC 對等互連來連接兩個以上的 VPC。
+ 為每個 VPC 建立多個 BGP 工作階段，以建立橫跨多個 AWS 區域間多個 Virtual Private Clouds (VPC) 的連線。
**建立此最佳實務的優勢：** 隨著網路數量增加，此類網狀連線的複雜性將變得難以處理。AWS Transit Gateway 提供容易維護的軸幅式模型，以便在多條網路之間路由流量。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
+ 偏好軸幅式拓撲而非多對多網狀拓撲。如果兩個以上的網路地址空間 (VPC、內部部署網路) 透過 VPC 對等互連、AWS Direct Connect 或 VPN 連線，則使用軸幅式模型，例如 AWS Transit Gateway 提供的此類模型。
+ 如果只有這兩種網路，則僅需將這兩種網路相互連線，但隨著網路數量增加，此類網狀連線的複雜性將變得難以處理。AWS Transit Gateway 提供容易維護的軸幅式模型，以便跨多條網路路由流量。
+ [什麼是 Transit Gateway？](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
## 資源
**相關文件：**
+ [APN 合作夥伴：可以幫助您規劃聯網的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [適用於網路基礎設施的 AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011)
+ [多個資料中心 HA 網路連線](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [VPC 端點和 VPC 端點服務 (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [什麼是 Amazon VPC？](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [什麼是 Transit Gateway？](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
**相關影片：**
+ [AWS re:Invent 2018：進階 VPC 設計及 Amazon VPC 的新功能 (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019：適用於許多 VPC 的 AWS Transit Gateway 參考架構 (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP05 在連線的所有私有地址空間中強制使用不重疊的私有 IP 地址範圍
如果透過 VPN 對等互連或連線，則每個 VPC 的 IP 地址範圍不得重疊。同樣地，您必須避免 VPC 與內部部署環境或您所使用之其他雲端供應商之間出現 IP 地址衝突。您也須有一種在需要時分配私有 IP 地址範圍的方法。
IP 地址管理 (IPAM) 系統可以協助解決此問題。AWS Marketplace 提供多套 IPAM 系統。
**常用的反模式：**
+ 在 VPC 中使用與內部部署或公司網路相同的 IP 範圍。
+ 不追蹤用來部署工作負載之 VPC 的 IP 範圍。
**建立此最佳實務的優勢：** 主動規劃網路可確保在互連網路中不會出現多個相同的 IP 地址。這可防止在使用不同應用程式的工作負載部分中發生路由問題。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
+ 監控和管理您的 CIDR 使用。評估您在 AWS 上的潛在使用情況，將 CIDR 範圍新增到現有 VPC，並建立 VPC 以允許計劃的用量增長。
+ 擷取當前的 CIDR 消耗 (例如，VPC、子網路)
+ 使用服務 API 操作來收集當前的 CIDR 消耗。
+ 記錄您當前的子網路用量。
+ 使用服務 API 操作來收集每個區域中每個 VPC 的子網路。
+ [DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html)
+ 記錄目前用量。
+ 確定是否建立了任何重疊的 IP 範圍。
+ 計算備用容量。
+ 識別重疊的 IP 範圍。如果需要連線重疊範圍，則可以遷移至新的地址範圍，也可以使用 AWS Marketplace 的網路和連接埠轉換 (NAT) 設備。
## 資源
**相關文件：**
+ [APN 合作夥伴：可以幫助您規劃聯網的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [適用於網路基礎設施的 AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011)
+ [Amazon Virtual Private Cloud 連線能力選項白皮書](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [多個資料中心 HA 網路連線](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [什麼是 Amazon VPC？](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [什麼是 IPAM？](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html)
**相關影片：**
+ [AWS re:Invent 2018：進階 VPC 設計及 Amazon VPC 的新功能 (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019：適用於許多 VPC 的 AWS Transit Gateway 參考架構 (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# 工作負載架構
**Topics**
+ [REL 3 如何設計您的工作負載服務架構？](w2aac19b9b7b5.md)
+ [REL 4 如何在分散式系統中設計防止失敗的互動？](w2aac19b9b7b7.md)
+ [REL 5 如何設計分散式系統中的互動以緩解或承受故障？](w2aac19b9b7b9.md)
# REL 3 如何設計您的工作負載服務架構？
使用服務導向架構 (SOA) 或微型服務架構，建置擴展性與可靠性高的工作負載。服務導向架構 (SOA) 是透過服務界面讓軟體元件可重複使用的做法。微型服務架構則進一步讓元件變得更小、更簡單。
**Topics**
+ [REL03-BP01 選擇如何劃分工作負載](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 建置專注於特定業務領域和功能的服務](rel_service_architecture_business_domains.md)
+ [REL03-BP03 每個 API 都提供服務合約](rel_service_architecture_api_contracts.md)
# REL03-BP01 選擇如何劃分工作負載
在確認應用程式的彈性要求時，工作負載劃分是很重要的。應盡可能避免整合型架構。您應審慎考量哪些應用程式元件可分解為微型服務。根據您的應用程式要求，這最終會盡可能由服務導向架構 (SOA) 與微型服務組合而成。可以無狀態的工作負載較有能力部署為微型服務。
**預期成果：** 工作負載應可受支援、可擴展，並且盡可能地鬆散耦合。
在選擇如何劃分工作負載時，請在效益與複雜性之間取得平衡。讓新產品能率先推出的正確做法，不同於打造可從最初需求擴展的工作負載的做法。重構現有的整合型時，您必須考量應用程式如何能支援以無狀態為方向的解構。將服務細分為較小的服務，可讓明確定義的小型團隊加以開發及管理。但較小的服務可能會帶來複雜性，包括延遲可能增加、偵錯更複雜，以及運作負擔增加。
**常見的反模式：**
+ AWS Well-Architected [微型服務 *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) 是一種特定情況：基本元件變得高度互相依賴，以致於只要有其中之一失敗，就會引發更加巨大的失敗，而導致元件像整合型一樣僵固且脆弱。
**建立此實務準則的優勢：**
+ 更明確的劃分可造就更高的靈活性、組織彈性及可擴展性。
+ 降低服務中斷的影響。
+ 應用程式元件可能會有不同的可用性要求，這一點可藉由更細微的劃分來支應。
+ 為支援工作負載的團隊明確定義責任。
**未建立此最佳實務時的曝險等級：** 高
## 實作指引
根據劃分工作負載的方式，選擇您的架構類型。選擇 SOA 或微型服務架構 (或在少數情況下選擇整合型架構)。即使您選擇從整合型架構開始，仍須確保該架構為模組化，且隨著使用者採用，產品擴展時，該架構最終可以演進成 SOA 或微型服務。SOA 和微型服務各自提供較小的劃分，這些劃分同時也是偏好使用的現代可擴展且可靠的架構；但在部署微型服務架構時，特別要考慮做一些取捨。
主要取捨之一，就是您現在擁有一種分散式運算架構，而其可能會增加您滿足使用者延遲要求的難度，並且在偵測和追蹤使用者互動方面還存在額外的複雜性。您可以利用 AWS X-Ray 來解決此問題。要考慮的另一個影響是，隨著您管理的應用程式數量增加，營運複雜性也隨之增加，因而需要部署多個獨立元件。
![\[整合型、服務導向與微型服務架構的比較圖\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## 實作步驟
+ 決定適當的架構以重構或建置您的應用程式。SOA 和微型服務各自提供較小的分隔，而這是偏好使用的現代可擴展和可靠架構。SOA 會是達成較小分隔的良好折衷方案，同時能避免微型服務的部分複雜性。如需詳細資訊，請參閱 [微型服務權衡](https://martinfowler.com/articles/microservice-trade-offs.html)。
+ 如果您的工作負載適用於此類型，且您的組織可以提供支援，則應使用微型服務架構達成最佳的靈活性和可靠性。如需詳細資訊，請參閱 [實作 AWS 上的微型服務。](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ 考慮遵循 [*Strangler Fig* 模式，](https://martinfowler.com/bliki/StranglerFigApplication.html) 將整合型重構為較小的元件。為此，必須逐步將特定的應用程式元件取代為新的應用程式和服務。[AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) 可作為增量重構的起點。如需詳細資訊，請參閱 [「使用扼制模式順暢地遷移內部部署的工作負載」](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/)。
+ 實作微型服務時可能需要服務探索機制，讓這些分散式服務能夠彼此通訊。[AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) 可以搭配服務導向架構使用，以提供可靠的服務探索和存取。 [AWS Cloud Map](https://aws.amazon.com/cloud-map/) 也可用於動態、使用 DNS 的服務探索。
+ 如果您要從整合型遷移至 SOA，[Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) 可在您於雲端重新設計舊版應用程式時，以服務匯流排的形式消弭差距。
+ 對於具有單一共用資料庫的現有整合型，請選擇如何將資料重新組織為較小的區段。此時可以按業務單位、存取模式或資料結構來劃分。在重構程序的這個時間點，您應選擇以關聯式或非關聯式 (NoSQL) 類型的資料庫繼續操作。如需詳細資訊，請參閱 [「從 SQL 到 NoSQL」](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html)。
**實作計劃的工作量：** 高
## 資源
**相關的最佳實務：**
+ [REL03-BP02 建置專注於特定業務領域和功能的服務](rel_service_architecture_business_domains.md)
**相關文件：**
+ [Amazon API Gateway：使用 OpenAPI 設定 REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [什麼是服務導向架構？](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [有界限的環境 (領域驅動設計的集中模式)](https://martinfowler.com/bliki/BoundedContext.html)
+ [實作 AWS 上的微型服務](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [微型服務權衡](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [微型服務 - 此新架構術語的定義](https://www.martinfowler.com/articles/microservices.html)
+ [AWS 上的微型服務](https://aws.amazon.com/microservices/)
+ [什麼是 AWS App Mesh？](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**相關範例：**
+ [迭代應用程式現代化研討會](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**相關影片：**
+ [透過 AWS 上的微型服務提供卓越品質](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 建置專注於特定業務領域和功能的服務
服務導向架構 (SOA) 會建置具有依業務需求定義之明確描述功能的服務。微型服務運用領域模型和有界限的環境來對此項業務進一步限縮，因此各服務僅做一件事。專注於特定功能讓您能夠區別不同服務的可靠性要求，並更集中瞄準投資目標。簡要的業務問題和與各服務相關的小型團隊，也更容易讓組織擴展。
在設計微型服務架構的過程中，運用領域驅動設計 (DDD) 有助於使用實體建立業務問題模型。例如，對於 Amazon.com 網站而言，實體可能包括包裝、交付、時間表、價格、折扣和貨幣。然後運用 [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html)，將此模型進一步劃分成更小的模型，其中具有相似功能和特性的實體歸類成一組。因此，以 Amazon.com 為例，包裝、交付及時間表會是出貨環境的一環，而價格、折扣及貨幣則是定價環境的一環。隨著此模型劃分成多個環境，如何界定微型服務界限的範本便會浮現。
![\[如何界定微型服務的模型範本\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/building-services.png)
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 根據您的業務領域及其各自功能設計工作負載。專注於特定功能讓您能夠區別不同服務的可靠性要求，並更集中瞄準投資目標。簡要的業務問題和與各服務相關的小型團隊，也更容易讓組織擴展。
+ 進行領域分析，以便對應工作負載的領域驅動設計 (DDD)。然後您可以選擇符合工作負載需求的架構類型。
+ [如何整合型服務分成微型服務](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [遭到舊式系統包圍時開始使用 DDD](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Eric Evans「領域驅動設計：解決軟件核心的複雜性」](https://www.amazon.com/gp/product/0321125215)
+ [實作 AWS 上的微型服務](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ 將您的服務分解為最小的元件。您可以使用微型服務架構，將工作負載劃分具有最小的功能的多個元件，以實現組織擴展和敏捷性。
+ 定義工作負載的 API 及其設計目標、限制和其他使用考量。
+ 定義 API。
+ API 定義應考慮增長和其他參數。
+ 定義設計的可用性。
+ 您的 API 可能針對不同功能具有多個設計目標。
+ 建立限制
+ 使用測試來定義工作負載功能的限制。
## 資源
**相關文件：**
+ [Amazon API Gateway：使用 OpenAPI 設定 REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [有界限的環境 (領域驅動設計的集中模式)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Eric Evans「領域驅動設計：解決軟件核心的複雜性」](https://www.amazon.com/gp/product/0321125215)
+ [遭到舊式系統包圍時開始使用 DDD](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [如何整合型服務分成微型服務](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [實作 AWS 上的微型服務](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [微型服務權衡](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [微型服務 - 此新架構術語的定義](https://www.martinfowler.com/articles/microservices.html)
+ [AWS 上的微型服務](https://aws.amazon.com/microservices/)
# REL03-BP03 每個 API 都提供服務合約
服務合約為服務整合團隊間的明訂記載的協議，並包括電腦可讀取的 API 定義、速率限制和效能期望。版本控制策略可讓您的用戶端繼續使用現有 API，並在準備好時將應用程式遷移至更新的 API。只要不違反合約，隨時都可進行部署。服務供應商團隊可以使用自己選擇的技術堆疊，以滿足 API 合約要求。同樣地，服務取用者可以使用自有的技術。
微型服務採用此服務導向架構 (SOA) 的概念，進而建立擁有最少功能組的服務。每個服務均會發佈一個 API 及使用該服務的設計目標、限制和其他考量事項。這可與 *呼叫應用程式* 建立合約。這樣即可實現三個主要優勢：
+ 該服務包含一個待處理的簡明業務問題，以及一個存在業務問題的小團隊。這樣一來，將能更好地進行組織擴展。
+ 只要符合 API 和合約要求，團隊能隨時進行部署。
+ 只要符合 API 和合約要求，團隊能隨時使用任何他們想要的技術堆疊。
Amazon API Gateway 是一項全受管的服務，可讓開發人員輕鬆地建立、發佈、維護、監控和保護任何規模的 API。涉及接受和處理多達數十萬個並行 API 呼叫 (包括流量管理、授權與存取控制、監控和 API 版本管理) 的所有任務均由 API Gateway 處理。您可以使用 OpenAPI Specification (OAS) (先前稱為 Swagger Specification)，定義 API 合約並將其匯入至 API Gateway。您之後可以使用 API Gateway 進行 API 的版本控制和部署作業。
**若未建立此最佳實務，暴露的風險等級：** 低
## 實作指引
+ 每個 API 都提供服務合約：服務合約為服務整合團隊間的明訂記載的協議，並包括電腦可讀取的 API 定義、速率限制和效能期望。
+ [Amazon API Gateway：使用 OpenAPI 設定 REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ 版本控制策略可讓用戶端繼續使用現有 API，並在準備好時將應用程式遷移至更新的 API。
+ Amazon API Gateway 是一種全受管的服務，可讓開發人員輕鬆地建立任何規模的 API。您可以使用 OpenAPI Specification (OAS) (先前稱為 Swagger Specification)，定義 API 合約並將其匯入至 API Gateway。您之後可以使用 API Gateway 進行 API 的版本控制和部署作業。
## 資源
**相關文件：**
+ [Amazon API Gateway：使用 OpenAPI 設定 REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [有界限的環境 (領域驅動設計的集中模式)](https://martinfowler.com/bliki/BoundedContext.html)
+ [實作 AWS 上的微型服務](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [微型服務權衡](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [微型服務 - 此新架構術語的定義](https://www.martinfowler.com/articles/microservices.html)
+ [AWS 上的微型服務](https://aws.amazon.com/microservices/)
# REL 4 如何在分散式系統中設計防止失敗的互動？
分散式系統倚賴通訊網路來互連元件，例如伺服器或服務。即使這些網路上的資料遺失或延遲，您的工作負載仍必須可靠運作。分散式系統的元件必須以不會對其他元件或工作負載造成負面影響的方式運作。這些最佳實務可防止失敗，並延長平均失敗間隔時間 (MTBF)。
**Topics**
+ [REL04-BP01 確定需要哪種分散式系統](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 實作鬆散耦合相依性](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 持續執行工作](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 將所有回應設為等冪](rel_prevent_interaction_failure_idempotent.md)
# REL04-BP01 確定需要哪種分散式系統
硬式即時分散式系統需要同步、快速給予回應，而軟式即時系統則可以在更長的時段 (分鐘) 內來回應。離線系統會透過批次或非同步處理來處理回應。硬式即時分散式系統具有最嚴格的可靠性要求。
對於硬式即時分散式系統而言， [分散式系統最困難的挑戰](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) 也稱為請求/回覆服務。較困難的是，無法預測請求何時抵達，且必須快速回應 (例如，客戶正在主動等待回應)。範例包括前端 Web 伺服器、訂單管道、信用卡交易、每個 AWS API 和電話語音。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 識別需要哪種分散式系統。分散式系統的挑戰包含延遲、擴展、了解聯網 API、資料編組和解編，以及 Paxos 等演算法的複雜性。隨著系統擴大並且益加分散，理論上的極端案例也變成經常發生的案例。
+ [Amazon Builders' Library：分散式系統的挑戰](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ 硬式即時分散式系統需要同步、快速給予回應。
+ 軟式即時系統則可以在更長的時段 (分鐘) 內來回應。
+ 離線系統會透過批次或非同步處理來處理回應。
+ 硬式即時分散式系統具有最嚴格的可靠性要求。
## 資源
**相關文件：**
+ [Amazon EC2：確保等冪性](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Amazon Builders' Library：分散式系統的挑戰](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library：可靠性、持續工作，以及咖啡時刻](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [什麼是 Amazon EventBridge？](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [什麼是 Amazon Simple Queue Service？](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**相關影片：**
+ [2019 年 AWS 紐約高峰會：事件驅動架構和 Amazon EventBridge 簡介 (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018：閉環與開放思維：如何取得大小型系統的控制權 (ARC337) (包括鬆耦合、持續工作、靜態穩定性)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019：移至事件驅動架構 (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP02 實作鬆散耦合相依性
佇列系統、串流系統、工作流程和負載平衡器之間具有鬆散耦合的相依性。鬆耦合有助於將某個元件的行為與依賴它的其他元件隔離，進而提高彈性和敏捷性。
如果一個元件的變更迫使依賴它的其他元件也變更，則屬於 *緊密* 耦合。 *鬆* 耦合會破壞此相依性，因此相依元件只需要知道受版本控制的和已發佈的界面。在相依性之間實作鬆耦合，可避免一個元件中的故障影響另一個元件。
鬆耦合可讓您將其他程式碼或功能新增至某個元件，同時將依賴該元件的其他元件的風險降至最低。此外，您可以向外擴展甚或變更相依性的基礎實作，因此可擴展性也會得到提升。
若要透過鬆耦合進一步改善彈性，請盡可能讓元件採用非同步互動。此模型適用於不需要立即回應的任何互動，以及確認已註冊請求便以足夠的狀況。它涉及產生事件的一個元件和取用事件的另一個元件。這兩個元件不會透過點對點直接互動來整合，但通常會透過中繼耐用儲存層來整合，例如 SQS 佇列，或如 Amazon Kinesis 或 AWS Step Functions 等串流資料平台。
![\[圖表：顯示佇列系統和負載平衡器之間具有鬆散耦合的相依性。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/loosely-coupled-dependencies.png)
Amazon SQS 佇列和 Elastic Load Balancer 只是為鬆耦合新增中繼層的兩種方式。事件驅動型架構也可以使用 Amazon EventBridge 在 AWS 雲端 建置。其可從用戶端依賴的服務 (事件消費者) 中抽取用戶端 (事件生產者)。當您需要高輸送量、推送架構的多對多傳訊時，Amazon Simple Notification Service (Amazon SNS) 是有效的解決方案。使用 Amazon SNS 主題，您的發佈者系統可以將訊息散發給大量訂閱者端點，以進行平行處理。
雖然佇列提供多項優勢，但在大多數硬式即時系統中，超過閾值時間 (通常為秒) 的請求應視為過時 (用戶端已放棄且不再等待回應) 且未處理。這樣才可以處理較新的 (且可能仍有效的) 請求。
**常用的反模式：**
+ 將單例部署為工作負載的一部分。
+ 在工作負載層之間直接叫用 API，沒有容錯移轉或非同步處理請求的功能。
**建立此最佳實務的優勢：** 鬆耦合有助於將某個元件的行為與依賴它的其他元件隔離，進而提高彈性和敏捷性。避免一個元件中的失敗影響其他元件。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 實作鬆散耦合相依性。佇列系統、串流系統、工作流程和負載平衡器之間具有鬆散耦合的相依性。鬆耦合有助於將某個元件的行為與依賴它的其他元件隔離，進而提高彈性和敏捷性。
+ [AWS re:Invent 2019：移至事件驅動架構 (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [什麼是 Amazon EventBridge？](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [什麼是 Amazon Simple Queue Service？](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ Amazon EventBridge 可讓您建置鬆散耦合和分散式的事件驅動型架構。
+ [2019 年 AWS 紐約高峰會：事件驅動架構和 Amazon EventBridge 簡介 (MAD205)](https://youtu.be/tvELVa9D9qU)
+ 如果一個元件的變更迫使依賴它的其他元件也變更，則屬於緊密耦合。鬆耦合會破壞此相依性，因此相依元件只需要知道受版本控制的和已發佈的界面。
+ 盡可能讓元件採用非同步互動。此模型適用於不需要立即回應的任何互動，以及確認已註冊請求便以足夠的狀況。
+ [AWS re:Invent 2019：使用 Amazon SQS 和 Lambda 的可擴展無伺服器事件驅動應用程式 (API304)](https://youtu.be/2rikdPIFc_Q)
## 資源
**相關文件：**
+ [AWS re:Invent 2019：移至事件驅動架構 (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon EC2：確保等冪性](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Amazon Builders' Library：分散式系統的挑戰](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library：可靠性、持續工作，以及咖啡時刻](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [什麼是 Amazon EventBridge？](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [什麼是 Amazon Simple Queue Service？](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**相關影片：**
+ [2019 年 AWS 紐約高峰會：事件驅動架構和 Amazon EventBridge 簡介 (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018：閉環與開放思維：如何取得大小型系統的控制權 (ARC337) (包括鬆耦合、持續工作、靜態穩定性)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019：移至事件驅動架構 (SVS308)](https://youtu.be/h46IquqjF3E)
+ [AWS re:Invent 2019：使用 Amazon SQS 和 Lambda 的可擴展無伺服器事件驅動應用程式 (API304)](https://youtu.be/2rikdPIFc_Q)
# REL04-BP03 持續執行工作
負載大幅快速變更時，系統可能會發生故障。例如，如果您的工作負載正在執行運作狀態檢查，監控數千部伺服器的運作狀態，應該每次傳送相同大小的承載 (目前狀態的完整快照)。無論伺服器全無故障或全部出現故障，運作狀態檢查系統都會持續執行工作，而無大幅快速變更。
例如，如果運作狀態檢查系統正在監控 100,000 部伺服器，則在一般輕型伺服器失敗率下，其負載為額定值。不過，如果重大事件讓一半的伺服器運作狀況不良，則運作狀態檢查系統會因嘗試更新通知系統並向其用戶端溝通狀態，而承受不住負載。因此，運作狀態檢查系統應每次都傳送目前狀態的完整快照。100,000 個伺服器運作狀態 (每個以一位元表示) 只是 12.5 KB 的承載。無論沒有伺服器發生故障，還是全部發生故障，運作狀態檢查系統都會持續執行工作，而大型的快速變更也不會對系統穩定性造成威脅。這實際上是 Amazon Route 53 處理端點 (例如 IP 地址) 的運作狀態檢查，以判斷最終使用者如何路由到其中的方式。
**若未建立此最佳實務，暴露的風險等級：** 低
## 實作指引
+ 執行持續工作，以便負載大量快速變更時，系統不會失敗。
+ 實作鬆散耦合相依性。佇列系統、串流系統、工作流程和負載平衡器之間具有鬆散耦合的相依性。鬆耦合有助於將某個元件的行為與依賴它的其他元件隔離，進而提高彈性和敏捷性。
+ [Amazon Builders' Library：可靠性、持續工作，以及咖啡時刻](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS re:Invent 2018：閉環與開放思維：如何取得大小型系統的控制權 (ARC337) (包括持續工作)](https://youtu.be/O8xLxNje30M?t=2482)
+ 針對運作狀態檢查系統監控 100,000 部伺服器的範例，將工作負載設計為無論成功或失敗的數量為何，承載大小都保持不變。
## 資源
**相關文件：**
+ [Amazon EC2：確保等冪性](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Amazon Builders' Library：分散式系統的挑戰](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library：可靠性、持續工作，以及咖啡時刻](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**相關影片：**
+ [2019 年 AWS 紐約高峰會：事件驅動架構和 Amazon EventBridge 簡介 (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018：閉環與開放思維：如何取得大小型系統的控制權 (ARC337) (包括持續工作)](https://youtu.be/O8xLxNje30M?t=2482)
+ [AWS re:Invent 2018：閉環與開放思維：如何取得大小型系統的控制權 (ARC337) (包括鬆耦合、持續工作、靜態穩定性)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019：移至事件驅動架構 (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP04 將所有回應設為等冪
等冪服務承諾每個請求只完成一次，使得發出多個相同請求與發出單一請求具有相同的效果。等冪服務可讓用戶端更輕鬆地實作重試，而不用擔心錯誤地多次處理請求。為此，用戶端可以使用等冪權杖發出 API 請求，即每次重複請求時，都會使用相同的權杖。等冪服務 API 會使用權杖來傳回與第一次完成請求時傳回之回應相同的回應。
在分散式系統中，執行最多一次動作 (用戶端只發出一個請求) 或至少一次動作 (持續發出請求，直到用戶端確認成功) 很容易。但很難保證動作是等冪的，這表示它 *只執行一次，* 使得發出多個相同的請求與發出單一請求具有相同效果。透過在 API 中使用等冪性權杖，服務可以收到一次或多次變異請求，而不會產生重複的記錄或副作用。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 將所有回應設為等冪。等冪服務承諾每個請求只完成一次，使得發出多個相同請求與發出單一請求具有相同的效果。
+ 用戶端可以使用等冪權杖發出 API 請求，即每次重複請求時，都會使用相同的權杖。等冪服務 API 會使用權杖來傳回與第一次完成請求時傳回之回應相同的回應。
+ [Amazon EC2：確保等冪性](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
## 資源
**相關文件：**
+ [Amazon EC2：確保等冪性](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Amazon Builders' Library：分散式系統的挑戰](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library：可靠性、持續工作，以及咖啡時刻](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**相關影片：**
+ [2019 年 AWS 紐約高峰會：事件驅動架構和 Amazon EventBridge 簡介 (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018：閉環與開放思維：如何取得大小型系統的控制權 (ARC337) (包括鬆耦合、持續工作、靜態穩定性)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019：移至事件驅動架構 (SVS308)](https://youtu.be/h46IquqjF3E)
# REL 5 如何設計分散式系統中的互動以緩解或承受故障？
分散式系統倚賴通訊網路來互連元件 (例如，伺服器或服務)。即使這些網路上的資料遺失或延遲，您的工作負載仍必須可靠運作。分散式系統的元件必須以不會對其他元件或工作負載造成負面影響的方式運作。這些最佳實務讓工作負載能夠承受壓力或故障，更快速地從其中復原，並減輕這類受損的影響。最終縮短平均復原時間 (MTTR)。
**Topics**
+ [REL05-BP01 實作適度降級以將適用的硬相依性轉換為軟相依性](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 調節請求](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 控制和限制重試呼叫](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 快速失敗和限制佇列](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 設定用戶端逾時](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 盡可能讓服務無狀態](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 實作緊急控制桿](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 實作適度降級以將適用的硬相依性轉換為軟相依性
當元件的相依性狀況不良，元件本身仍可運作，但以降級的方式運作。例如，當相依性呼叫失敗時，容錯移轉為預先決定的靜態回應。
考慮由服務 A 呼叫的服務 B，並接著呼叫服務 C。
![\[圖表：顯示從服務 B 呼叫服務 C 時失敗。服務 B 傳回降級回應給服務 A。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/graceful-degradation.png)
當服務 B 呼叫服務 C 時，其會從服務 C 收到錯誤或逾時。缺少來自服務 C 回應 (及其包含的資料) 的服務 B，會傳回其所能執行的回應。這可能是上次快取的良好值，或者服務 B 可使用預先決定的靜態回應，取代原可能從服務 C 收到的內容。然後它可以將降級的回應傳回給發起人，即服務 A。如果沒有此靜態回應，則服務 C 中的故障會透過服務 B 串聯到服務 A，導致失去可用性。
根據硬相依性可用性方程式中的乘法因數 (請參閱 [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122))，C 可用性的任何下降都會嚴重影響 B 的有效可用性。透過傳回靜態回應，服務 B 可減輕 C 的故障；而且雖然降級，但使服務 C 的可用性看起來像 100% (假設它在錯誤情況下可靠地傳回靜態回應)。請注意，靜態回應是傳回錯誤的簡單替代方法，並不會嘗試以不同方式重新計算回應。這種以完全不同的機制來嘗試達到相同結果的嘗試稱為備用行為，並且是一種可避免的反模式。
適度降級的另一個範例是 *斷路器模式*。當故障是暫時性時，應該使用重試策略。如果情況並非如此，且操作可能會失敗，則斷路器模式會阻止用戶端執行可能失敗的請求。在正常處理請求時，斷路器合閘，請求流過。當遠端系統開始傳回錯誤或出現高延遲時，斷路器會開啟，並忽略相依性，或是將結果取代為更輕鬆取得但不完整的回應 (可能只是回應快取)。系統會定期嘗試呼叫該相依性，以確定其是否已復原。發生這種情況時，斷路器將閉合。
![\[圖表：顯示處於開啟和關閉狀態的斷路器。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/circuit-breaker.png)
除圖中所示的關閉和開啟狀態外，在可設定的期間後，斷路器可在開啟狀態下轉換為半開啟狀態。在此狀態下，它會定期嘗試以比平常低得多的速率來呼叫服務。此探查用於檢查服務的運作狀態。在半開啟狀態下成功數次之後，斷路器會轉換為關閉，並恢復正常請求。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 實作適度降級以將適用的硬相依性轉換為軟相依性。當元件的相依性狀況不良，元件本身仍可運作，但以降級的方式運作。例如，當相依性呼叫失敗時，容錯移轉為預先決定的靜態回應。
+ 透過傳回靜態回應，您的工作負載可減輕在其相依性中發生的故障。
+ [Well-Architected 實驗室：第 300 級：實作運作狀態檢查和管理相依性以提升可靠性](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
+ 偵測重試操作何時可能失敗，並防止用戶端以斷路器模式進行失敗的呼叫。
+ [CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html)
## 資源
**相關文件：**
+ [Amazon API Gateway：調節 API 請求以獲得更佳的輸送量](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [CircuitBreaker (摘要說明「Release It\$1」書籍中的斷路器)](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [AWS 中的錯誤重試和指數退避](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Michael Nygard「Release It\$1 設計和部署生產就緒型軟體」](https://pragprog.com/titles/mnee2/release-it-second-edition/)
+ [Amazon Builders' Library：避免分散式系統的備用](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library：避免無法逾越的佇列待辦項目](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library：快取挑戰和策略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Amazon Builders' Library：逾時、重試、退避與抖動](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**相關影片：**
+ [重試、退避和抖動：AWS re:Invent 2019：Amazon Builders' Library 簡介 (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
**相關範例：**
+ [Well-Architected 實驗室：第 300 級：實作運作狀態檢查和管理相依性以提升可靠性](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL05-BP02 調節請求
調節請求是一種緩解模式，用於回應意外增加的需求。有些請求會接受，但超過定義限制的請求會遭到拒絕，並傳回訊息，指出它們已受到調節。預期用戶端會退避並放棄請求，或以較慢的速率再試一次。
您的服務應設計為處理每個節點或儲存格可以處理的已知請求容量。此容量可以透過負載測試來建立。然後，您需要追蹤請求的到達率，如果臨時到達率超過此限制，則適當的回應是發出訊號，指出已對其進行調節。其讓使用者可以進行重試，而重試可能具有可用容量的其他節點或儲存格。Amazon API Gateway 提供了調節請求的方法。Amazon SQS 和 Amazon Kinesis 可以緩衝請求、平滑請求率，以及減少對可非同步處理的請求進行調節的需求。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 調節請求。這是一種緩解模式，用於回應意外增加的需求。有些請求會接受，但超過定義限制的請求會遭到拒絕，並傳回訊息，指出它們已受到調節。預期用戶端會退避並放棄請求，或以較慢的速率再試一次。
+ 使用 Amazon API Gateway
+ [調節 API 請求以獲得更佳的輸送量](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
## 資源
**相關文件：**
+ [Amazon API Gateway：調節 API 請求以獲得更佳的輸送量](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS 中的錯誤重試和指數退避](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Amazon Builders' Library：避免分散式系統的備用](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library：避免無法逾越的佇列待辦項目](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library：逾時、重試、退避與抖動](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [調節 API 請求以獲得更佳的輸送量](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
**相關影片：**
+ [重試、退避和抖動：AWS re:Invent 2019：Amazon Builders' Library 簡介 (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP03 控制和限制重試呼叫
使用指數退避以在逐漸延長間隔後重試。引進抖動來隨機化這些重試間隔，並限制重試次數上限。
分散式軟體系統中的典型元件包括伺服器、負載平衡器、資料庫和 DNS 伺服器。在操作中，且操作可能失敗時，任何這些項目都可能開始產生錯誤。處理錯誤的預設技術是在用戶端實作重試。此技術可提高應用程式的可靠性和可用性。不過，如果用戶端在發生錯誤時立即嘗試重試失敗的操作，則網路很快就會因為新的和重試的請求而大規模地變得飽和，且每個請求都會爭奪網路頻寬。這可能會導致 *重試暴風，* 而該情況會降低服務的可用性。此模式可能會持續進行，直到整個系統出現故障為止。
若要避免這類情境，應該使用一般指數退避等 *退避演算法* 。指數退避演算法會逐漸降低執行重試的速率，從而避免網路擁塞。
許多開發套件和軟體程式庫 (包括來自 AWS 的程式庫) 都會實作這些演算法的一個版本。不過， **絕對不要假設退避演算法存在，請一律測試並驗證是否如此。**
單靠簡單退避是不夠的，因為在分散式系統中，所有用戶端都可能會同時退避，從而建立重試呼叫的叢集。Marc Brooker 在其部落格文章 [指數退避和抖動](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-italics%0djitter/)，說明了如何修改指數退避中的 wait () 函數，以防止重試呼叫的叢集。解決 *方法* 是在 wait() 函數中新增抖動。為避免重試太久，實作時應該將退避上限設為最大值。
最後，請務必設定 *最大重試次數* 或經過時間，之後重試就會失敗。AWS 開發套件預設情況下可實作此功能，並可以對其進行設定。對於堆疊中較低的服務，最大重試限制為零或一時可限制風險，但仍然有效，因為重試會委派給堆疊中較高的服務。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 控制和限制重試呼叫。使用指數退避以在逐漸延長間隔後重試。引進抖動來隨機化這些重試間隔，並限制重試次數上限。
+ [AWS 中的錯誤重試和指數退避](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ Amazon SDK 預設會實作重試和指數退避。呼叫自己的相依服務時，在相依性層中實作類似的邏輯。根據您的使用案例確定逾時時間以及何時停止重試。
## 資源
**相關文件：**
+ [Amazon API Gateway：調節 API 請求以獲得更佳的輸送量](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS 中的錯誤重試和指數退避](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Amazon Builders' Library：避免分散式系統的備用](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library：避免無法逾越的佇列待辦項目](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library：快取挑戰和策略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Amazon Builders' Library：逾時、重試、退避與抖動](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**相關影片：**
+ [重試、退避和抖動：AWS re:Invent 2019：Amazon Builders' Library 簡介 (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP04 快速失敗和限制佇列
如果工作負載無法成功回應請求，則快速失敗。如此將可釋放與請求關聯的資源，並且使服務在資源用盡時復原。如果工作負載能成功回應，但請求率太高，則改為使用佇列來緩衝請求。不過，請勿允許可能導致處理用戶端已放棄的過時請求之長佇列。
此最佳實務適用於該請求的伺服器端或接收者。
請注意，佇列可以在系統的多個層級建立，而且可能會嚴重阻礙快速復原的能力，因為較舊的過時請求 (不再需要回應) 在較新的請求之前處理。請注意佇列存在的位置。它們通常隱藏在記錄至資料庫的工作流程或工作中。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 快速失敗和限制佇列。如果工作負載無法成功回應請求，則快速失敗。如此將可釋放與請求關聯的資源，並且使服務在資源用盡時復原。如果工作負載能成功回應，但請求率太高，則改為使用佇列來緩衝請求。不過，請勿允許可能導致處理用戶端已放棄的過時請求之長佇列。
+ 服務受壓時實作快速失敗。
+ [快速失敗](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ 限制佇列：在佇列式系統中，當處理停止但訊息持續送達時，待處理訊息可能大量積存，使得處理時間增加。工作可能太晚完成而無效，基本上會導致佇列要防範的可用性問題。
+ [Amazon Builders' Library：避免無法逾越的佇列待辦項目](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
## 資源
**相關文件：**
+ [AWS 中的錯誤重試和指數退避](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [快速失敗](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [Amazon Builders' Library：避免分散式系統的備用](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library：避免無法逾越的佇列待辦項目](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library：快取挑戰和策略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Amazon Builders' Library：逾時、重試、退避與抖動](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**相關影片：**
+ [重試、退避和抖動：AWS re:Invent 2019：Amazon Builders' Library 簡介 (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP05 設定用戶端逾時
適當設定逾時、系統性對其進行驗證，並且不要依賴預設值，因為它們通常設定得太高。
此最佳實務適用於請求的用戶端或寄件者。
針對任何遠端呼叫 (通常為跨程序的任何呼叫) 同時設定連線逾時和請求逾時。許多框架都提供內建的逾時功能，但請注意，許多框架都有無限或過高的預設值。太高的值會降低逾時的實用性，因為當用戶端等待逾時發生時，資源會持續耗用。太低的值可能會增加後端流量和延遲，原因是重試的請求過多。在某些情況下，這可能導致完全停機，原因是正在重試所有請求。
若要進一步了解 Amazon 如何透過抖動使用逾時、重試和退避功能，請參閱 [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card)。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 針對任何遠端呼叫 (通常為跨程序的任何呼叫) 同時設定連線逾時和請求逾時。許多框架都提供內建的逾時功能，但請注意，許多框架都有無限或過高的預設值。太高的值會降低逾時的實用性，因為當用戶端等待逾時發生時，資源會持續耗用。太低的值可能會增加後端流量和延遲，原因是重試的請求過多。在某些情況下，這可能導致完全停機，原因是正在重試所有請求。
+ [AWS SDK：重試與逾時](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
## 資源
**相關文件：**
+ [AWS SDK：重試與逾時](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon API Gateway：調節 API 請求以獲得更佳的輸送量](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS 中的錯誤重試和指數退避](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Amazon Builders' Library：逾時、重試、退避與抖動](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**相關影片：**
+ [重試、退避和抖動：AWS re:Invent 2019：Amazon Builders' Library 簡介 (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP06 盡可能讓服務無狀態
服務不應要求狀態，或應該卸載狀態，以便在不同的用戶端請求之間，不依賴磁碟上和記憶體中本機儲存的資料。這讓伺服器能夠任意置換，而不會對可用性造成影響。Amazon ElastiCache 或 Amazon DynamoDB 是卸載狀態的適當目的地。
![\[在這個無狀態的 Web 應用程式中，工作階段狀態會卸載至 Amazon ElastiCache。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/stateless-webapp.png)
當使用者或服務與應用程式互動時，他們通常會執行形成工作階段的一系列互動。工作階段是使用者在使用應用程式時，在不同請求之間持續存在的唯一資料。無狀態應用程式是一種不需要了解先前互動，也不會儲存工作階段資訊的應用程式。
一旦設計為無狀態，您就可以使用 AWS Lambda 或 AWS Fargate 等無伺服器運算服務。
除了伺服器替換，無狀態應用程式的另一個好處是它們可以水平擴展，因為任何可用的運算資源 (例如，EC2 執行個體和 AWS Lambda 函數) 都可以處理所有請求。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 讓您的應用程式無狀態。無狀態應用程式支援水平擴展，並且可以容忍單個節點的故障。
+ 移除實際上可以儲存在請求參數中的狀態。
+ 在檢查了是否需要狀態之後，將狀態追蹤移至彈性多可用區域資料儲存，例如 Amazon ElastiCache、Amazon RDS、Amazon DynamoDB 或第三方分散式資料解決方案。儲存無法移動到彈性資料儲存的狀態。
+ 某些資料 (如 Cookie) 可以在標頭或查詢參數中傳遞。
+ 重構以移除可以在請求中快速傳遞的狀態。
+ 某個請求可能實際上並不需要某些資料，這些資料可以隨需擷取。
+ 移除可以非同步擷取的資料。
+ 確定滿足所需狀態要求的資料儲存。
+ 考慮將 NoSQL 資料庫用於非關聯式資料。
## 資源
**相關文件：**
+ [Amazon Builders' Library：避免分散式系統的備用](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library：避免無法逾越的佇列待辦項目](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library：快取挑戰和策略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
# REL05-BP07 實作緊急控制桿
緊急控制桿是可緩解對工作負載的可用性影響的快速程序。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 實作緊急控制桿。這是可緩解對工作負載的可用性影響的快速程序。它們可以在沒有根本原因的情況下操作。理想的緊急控制桿會提供完全決定性啟用和停用準則，將解析器的認知負擔降至零。控制桿通常是手動的，但也可以自動化
+ 範例控制桿包括
+ 封鎖所有機器人流量
+ 提供靜態頁面而非動態頁面
+ 減少對相依性的呼叫頻率
+ 調節來自相依性的呼叫
+ 實作和使用緊急控制桿的秘訣
+ 當啟用控制桿時，請少做，而非多做
+ 保持簡單，避免雙模式行為
+ 定期測試您的控制桿
+ 以下是非緊急控制桿動作的範例
+ 新增容量
+ 呼叫依賴您服務的用戶端服務擁有者，並要求他們減少呼叫
+ 變更程式碼並將其釋出
# 變更管理
**Topics**
+ [REL 6 如何監控工作負載資源？](w2aac19b9b9b5.md)
+ [REL 7 如何設計工作負載以適應需求變更？](w2aac19b9b9b7.md)
+ [REL 8 您如何實作變更？](w2aac19b9b9b9.md)
# REL 6 如何監控工作負載資源？
日誌和指標是深入了解工作負載運作狀態的強大工具。您可以設定工作負載以監控日誌和指標，並在超過閾值或發生重大事件時傳送通知。監控可讓您的工作負載識別何時會超過低效能閾值或發生故障，以便自動復原來回應。
**Topics**
+ [REL06-BP01 監控工作負載的所有元件 (產生)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 定義和計算指標 (彙總)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP03 傳送通知 (即時處理和警示)](rel_monitor_aws_resources_notification_monitor.md)
+ [REL06-BP04 自動化回應 (即時處理和警示)](rel_monitor_aws_resources_automate_response_monitor.md)
+ [REL06-BP05 分析](rel_monitor_aws_resources_storage_analytics.md)
+ [REL06-BP06 定期進行審查](rel_monitor_aws_resources_review_monitoring.md)
+ [REL06-BP07 透過您的系統監控請求的端對端追蹤](rel_monitor_aws_resources_end_to_end.md)
# REL06-BP01 監控工作負載的所有元件 (產生)
使用 Amazon CloudWatch 或第三方工具監控工作負載的元件。使用 AWS Health 儀表板監控 AWS 服務。
工作負載的所有元件都應該受到監控，包括前端、商業邏輯和儲存層。定義關鍵指標，描述如何從日誌擷取指標 (如果需要)，以及設定觸發對應警示事件的閾值。確保指標與工作負載的關鍵績效指標 (KPI) 相關，並使用指標和日誌來識別服務降級的早期預警訊號。例如，與業務成果相關的指標 (例如每分鐘成功處理的訂單數目) 可以比 CPU 使用率這類的技術指標更快地指出工作負載問題。使用 AWS Health 儀表板可針對 AWS 資源下 AWS 服務的效能和可用性，取得個人化檢視。
雲端監控提供新機遇。大部分雲端供應商都開發了可自訂的掛鉤，並且可以提供洞察力來協助您監控多層的工作負載。AWS 服務 (例如 Amazon CloudWatch) 會套用統計和機器學習演算法，以持續分析系統和應用程式的指標、決定正常基準，以及顯現使用者介入最少的異常。異常偵測演算法會考慮指標的季節性和趨勢變更。
AWS 提供大量可用於消費的監控和日誌資訊，這些資訊可以用來定義工作負載特有的指標、按需變更流程，以及採用機器學習技術，而不管 ML 專業知識為何。
此外，監控所有外部端點，以確保它們獨立於基本實作。此主動監控可透過綜合交易 (有時稱為 *使用者 Canary，*但請別與 Canary 部署混淆) 加以完成，後者會定期執行應用程式消費者執行的一些常見任務。在持續時間中讓這些任務保持簡單扼要，並確定在測試期間不會讓工作負載超載。Amazon CloudWatch Synthetics 讓您能夠 [建立綜合 Canary](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 以監控您的端點和 API。您也可以將綜合性 Canary 用戶端節點與 AWS X-Ray 主控台結合，以指出綜合性 Canary 在所選時段內發生錯誤、故障或調節率等問題。
**預期成果：**
收集和使用來自工作負載所有元件的關鍵指標，以確保工作負載可靠性和最佳使用者體驗。偵測到工作負載未實現業務成果可讓您快速宣佈災難並從事故中復原。
**常用的反模式：**
+ 僅監控工作負載的外部界面。
+ 不產生任何工作負載特有的指標，而且僅依賴工作負載使用的 AWS 服務提供給您的指標。
+ 僅在工作負載中使用技術指標，而且不監控與工作負載貢獻的非技術 KPI 相關的任何指標。
+ 依賴生產流量和簡單的運作狀態檢查來監控和評估工作負載狀態。
**建立此最佳實務的優勢：** 工作負載中的所有層級監控，可讓您更快速地預測和解決構成工作負載之元件中的問題。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
1. **在可用的地方啟用記錄。** 應該從工作負載的所有元件中取得監控資料。開啟額外記錄 (例如 S3 存取日誌)，並讓您的工作負載可以記錄工作負載特定資料。從 Amazon ECS、Amazon EKS、Amazon EC2、Elastic Load Balancing、AWS Auto Scaling 和 Amazon EMR 等服務中收集 CPU、網路 I/O 和磁碟 I/O 平均值的指標。請參閱 [發佈 CloudWatch 指標的 AWS 服務](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) 取得將指標發佈至 CloudWatch 的 AWS 服務清單。
1. **審查所有預設指標並探索任何資料收集差距。** 每個服務都會產生預設指標。收集預設指標可讓您更好地了解工作負載元件之間的相依性，以及元件可靠性和效能如何影響工作負載。您也可以建立 [自己的指標並將其](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 發佈至 CloudWatch，方法為使用 AWS CLI 或 API。此
1. **評估所有指標，以判斷哪些指標要對工作負載中的每個 AWS 發出提醒。** 您可以選擇要選取對工作負載可靠性有重大影響的指標子集。專注於關鍵指標和閾值可讓您微調 [提醒](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 數目，並可以協助將誤判的情形減至最少。
1. **定義提醒以及在觸發提醒之後工作負載的復原流程。** 定義提醒可讓您快速通知、呈報並遵循必要的步驟，從事故中復原並符合您指定的復原時間點目標 (RTO)。您可以使用 [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions) 叫用自動化工作流程，並根據定義的閾值啟動復原程序。
1. **探索如何使用綜合交易來收集有關工作負載狀態的相關資料。** 綜合監控會遵循相同的路由並執行與客戶相同的動作，這可讓您持續驗證您的客戶體驗，即使您的工作負載上沒有任何客戶流量也一樣。使用 [綜合交易](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)，您可以在客戶探索問題之前先行探索。
## 資源
**相關的最佳實務：**
+ [REL11-BP03 將所有分層的修復自動化](rel_withstand_component_failures_auto_healing_system.md)
**相關文件：**
+ [AWS Health 儀表板入門 – 您的帳戶運作狀態](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html)
+ [發佈 CloudWatch 指標的 AWS 服務](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Network Load Balancer 的存取日誌](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html)
+ [Application Load Balancer 的存取日誌](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html)
+ [存取 Amazon CloudWatch Logs 的 AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html)
+ [Amazon S3 伺服器存取記錄](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html)
+ [啟用 Classic Load Balancer 的存取日誌](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html)
+ [將日誌資料匯出至 Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [在 Amazon EC2 執行個體上安裝 CloudWatch 代理程式](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html)
+ [發布自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [使用 Amazon CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [使用 Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [使用 Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [什麼是 Amazon CloudWatch Logs？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
**使用者指南：**
+ [建立軌跡](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)
+ [監控 Amazon EC2 Linux 執行個體的記憶體和磁碟指標](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html)
+ [搭配容器執行個體使用 CloudWatch Logs](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [VPC Flow Logs](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html)
+ [什麼是 Amazon DevOps Guru？](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [什麼是 AWS X-Ray？](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
**相關部落格：**
+ [使用 Amazon CloudWatch Synthetics 和 AWS X-Ray 偵錯](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
**相關範例和研討會：**
+ [AWS Well-Architected 實驗室：卓越營運 - 相依性監控](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_dependency_monitoring/)
+ [Amazon Builders' Library：偵測分散式系統，以瞭解運作狀態](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [可觀測性研討會](https://catalog.workshops.aws/observability/en-US)
# REL06-BP02 定義和計算指標 (彙總)
視需要儲存日誌資料並套用篩選條件以計算指標，例如特定日誌事件的計數，或是從日誌事件時間戳記計算的延遲。
Amazon CloudWatch 和 Amazon S3 可作為主要的彙總和儲存層。對於某些服務 (例如 AWS Auto Scaling 和 Elastic Load Balancing)，預設會為跨叢集或執行個體的 CPU 負載或平均請求延遲提供預設指標。對於 VPC Flow Logs 及 AWS CloudTrail 等串流服務，事件資料將轉寄到 CloudWatch Logs，且您需要定義和套用指標篩選條件以從事件資料中擷取指標。這為您提供時間序列資料，而此資料可作為您定義用於觸發提醒之 CloudWatch 警示的輸入。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 定義和計算指標 (彙總)。視需要儲存日誌資料並套用篩選條件以計算指標，例如特定日誌事件的計數，或是從日誌事件時間戳記計算的延遲
+ 指標篩選條件會定義術語與模式，以在傳送到 CloudWatch Logs 的日誌資料中尋找資料。CloudWatch Logs 使用這些指標篩選條件，將日誌資料轉成數值 CloudWatch 指標，讓您可以對其繪製圖表或設定警示。
+ [搜尋和篩選日誌資料](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ 使用受信任的第三方來彙總日誌。
+ 請遵循第三方的指示。大部分第三方產品可與 CloudWatch 和 Amazon S3 整合。
+ 有些 AWS 服務可以直接將日誌發佈到 Amazon S3。如果您的日誌主要需求是儲存在 Amazon S3 中，則可以輕鬆讓產生日誌的服務直接將它們傳送到 Amazon S3，無須設定其他基礎設施。
+ [直接將日誌傳送至 Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
## 資源
**相關文件：**
+ [Amazon CloudWatch Logs Insights 範例查詢](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [使用 Amazon CloudWatch Synthetics 和 AWS X-Ray 偵錯](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [一個觀察工作坊](https://observability.workshop.aws/)
+ [搜尋和篩選日誌資料](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [直接將日誌傳送至 Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
+ [Amazon Builders' Library：偵測分散式系統，以瞭解運作狀態](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP03 傳送通知 (即時處理和警示)
當重大事件發生時，需要知道的組織會收到通知。
提醒可以傳送到 Amazon Simple Notification Service (Amazon SNS) 主題，然後推送給任何數量的訂閱者。例如，Amazon SNS 可以將提醒轉寄到電子郵件別名，以便技術人員可以回應。
**常用的反模式：**
+ 設定閾值太低的警示，導致傳送太多通知。
+ 不封存警示以供未來探索。
**建立此最佳實務的優勢：** 事件通知 (甚至是可回應和自動解決的通知) 可讓您擁有事件紀錄，並在未來可能以不同方式處理事件。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 執行即時處理和警示。當重大事件發生時，需要知道的組織會收到通知
+ Amazon CloudWatch 儀表板是 CloudWatch 主控台中的可自訂首頁，您可用來在單一檢視中監控資源，甚至是監控分散在不同區域的資源。
+ [使用 Amazon CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ 當指標超過限制時建立警示。
+ [使用 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## 資源
**相關文件：**
+ [一個觀察工作坊](https://observability.workshop.aws/)
+ [Amazon Builders' Library：偵測分散式系統，以瞭解運作狀態](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [使用 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [使用 Amazon CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [使用 Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
# REL06-BP04 自動化回應 (即時處理和警示)
偵測到事件時，使用自動化以採取動作，例如取代故障的元件。
提醒可以觸發 AWS Auto Scaling 事件，因此叢集可根據需求便能作出反應。提醒可傳送至 Amazon Simple Queue Service (Amazon SQS)，該服務可以用作第三方票證系統的整合點。AWS Lambda 還可以訂閱提醒，為使用者提供非同步無伺服器模型，以動態回應變更。AWS Config 會持續監控和記錄您的 AWS 資源組態，並可觸發 [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 以修復問題。
Amazon DevOps Guru 可以自動監控應用程式資源，以偵測異常行為並提供目標建議，以縮短問題識別和矯正時間。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 使用 Amazon DevOps Guru 來執行自動化動作。Amazon DevOps Guru 可以自動監控應用程式資源，以偵測異常行為並提供目標建議，以縮短問題識別和矯正時間。
+ [什麼是 Amazon DevOps Guru？](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ 使用 AWS Systems Manager 來執行自動化動作。AWS Config 會持續監控和記錄您的 AWS 資源組態，並可觸發 AWS Systems Manager 以修復問題。
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ 建立和使用 Systems Manager Automation 文件。當自動化流程執行時，這些會定義 Systems Manager 在受管執行個體和其他 AWS 資源上執行的動作。
+ [與自動化文件搭配使用 (程序手冊)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ Amazon CloudWatch 會將警示狀態變更事件傳送到 Amazon EventBridge。建立 EventBridge 規則以自動化回應。
+ [建立 EventBridge 規則，以透過 AWS 資源觸發事件](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ 建立和執行計畫以自動化回應。
+ 清查您的所有提醒回應程序。您必須先規劃提醒回應，再將任務排名。
+ 以必須採取的特定動作清查所有任務。這些動作大多記錄在執行手冊中。您也必須擁有適用於意外事件提醒的程序手冊。
+ 檢查所有適用於自動化動作的執行手冊和程序手冊。一般而言，如果某個動作可以受到定義，則很可能可以進行自動化。
+ 將容易出錯或耗時的活動排在第一位。移除錯誤來源並縮短解決時間是最有益的。
+ 建立完成自動化的計畫。維護作用中的計畫以自動化和更新自動化。
+ 檢查自動化機會的手動需求。挑戰您的手動程序，以找出自動化的機會。
## 資源
**相關文件：**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [建立 EventBridge 規則，以透過 AWS 資源觸發事件](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ [一個觀察工作坊](https://observability.workshop.aws/)
+ [Amazon Builders' Library：偵測分散式系統，以瞭解運作狀態](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [什麼是 Amazon DevOps Guru？](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [與自動化文件搭配使用 (程序手冊)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
# REL06-BP05 分析
收集日誌檔和指標歷史記錄，並分析這些檔案和歷史記錄，以了解更廣泛的趨勢和工作負載洞見。
Amazon CloudWatch Logs Insights 支援 [簡單但功能強大的查詢語言，](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html) 您可使用此語言來分析日誌資料。Amazon CloudWatch Logs 還支援訂閱，而這些訂閱允許資料無縫流至 Amazon S3，您可使用 Amazon S3 或 Amazon Athena 來查詢資料。其也支援對大量格式的查詢。請參閱 [請參閱](https://docs.aws.amazon.com/athena/latest/ug/supported-format.html) (位於 Amazon Athena 使用者指南中)，以取得詳細資訊。若要分析大型日誌檔集，您可以執行 Amazon EMR 叢集來執行 PB 級分析。
AWS 合作夥伴和第三方提供了許多工具，可用於彙總、處理、儲存和分析。這些工具包含 New Relic、Splunk、Loggly、Logstash、CloudHealth 和 Nagios。但是，系統和應用程式日誌之外的產生對於每個雲端提供者都是唯一的，並且通常對於每個服務也都是唯一的。
資料管理是監控程序中常常被忽略的部分。您需要確定監控資料的保留要求，然後相應地套用生命週期政策。Amazon S3 可支援 S3 儲存貯體層級的生命週期管理。該生命週期管理能以不同方式套用至儲存貯體中的不同路徑。在生命週期即將結束時，您可以將資料傳輸到 Amazon Glacier 進行長期儲存，然後在保留期結束後到期。S3 智慧型分層儲存類別旨在透過自動將資料移至最經濟實惠的存取層來優化成本，而不會影響效能或營運開銷。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
+ CloudWatch Logs Insights 可讓您以互動方式在 Amazon CloudWatch Logs 中搜尋和分析日誌資料。
+ [使用 CloudWatch Logs Insights 分析日誌資料](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Amazon CloudWatch Logs Insights 範例查詢](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ 使用 Amazon CloudWatch Logs 將日誌傳送至您可以在其中使用的 Amazon S3，或使用 Amazon Athena 來查詢資料。
+ [我要如何使用 Athena 分析 Amazon S3 伺服器存取日誌？](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ 為您的伺服器存取日誌儲存貯體建立 S3 生命週期政策。設定生命週期政策以定期移除日誌檔案。這樣做可減少 Athena 針對每個查詢所分析的資料量。
+ [我要如何為 S3 儲存貯體建立生命週期政策？](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
## 資源
**相關文件：**
+ [Amazon CloudWatch Logs Insights 範例查詢](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [使用 CloudWatch Logs Insights 分析日誌資料](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [使用 Amazon CloudWatch Synthetics 和 AWS X-Ray 偵錯](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [我要如何為 S3 儲存貯體建立生命週期政策？](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
+ [我要如何使用 Athena 分析 Amazon S3 伺服器存取日誌？](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ [一個觀察工作坊](https://observability.workshop.aws/)
+ [Amazon Builders' Library：偵測分散式系統，以瞭解運作狀態](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP06 定期進行審查
經常審查工作負載監控的實作方式，並根據重大事件和變更進行更新。
有效的監控是由關鍵業務指標推動。當業務優先事項變更時，確保您的工作負載中會包含這些指標。
稽核您的監控有助於您知道應用程式何時達到其可用性目標。根本原因分析需要能夠發現發生故障時的具體情況。AWS 提供的服務可讓您在事件發生時追蹤服務狀態：
+ **Amazon CloudWatch Logs：** 您可以將日誌儲存在此服務中並檢查其內容。
+ **Amazon CloudWatch Logs Insights**：是一項全受管服務，讓您可以在數秒內分析大量日誌。其可為您提供快速且互動式的查詢和視覺化。
+ **AWS Config：** 您可以查看在不同時間點使用的 AWS 基礎設施。
+ **AWS CloudTrail：** 您可以查看在什麼時間及透過什麼主體叫用了哪些 AWS API。
在 AWS，我們每週舉行一次會議， [以審查營運效能](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) 及在團隊之間分享經驗。由於 AWS 旗下有太多團隊，我們建立了 [The Wheel](https://aws.amazon.com/blogs/opensource/the-wheel/) 以隨機挑選要審查的工作負載。建立定期執行營運效能審查和知識共享的機制，可增強您從營運團隊獲得更高效能的能力。
**常用的反模式：**
+ 僅收集預設指標。
+ 設定監控策略，但絕不檢閱。
+ 部署重大變更時不討論監控。
**建立此最佳實務的優勢：** 定期檢閱監控可預期潛在問題，而不是在預期問題實際發生時對通知作出反應。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
+ 為工作負載建立多個儀表板。您必須擁有最上層儀表板，其中包含關鍵業務指標，以及經您確認與工作負載預估運作狀態最相關的 (因為用量不同) 技術指標。您也應該有可以檢查各種應用程式層和相依性的儀表板。
+ [使用 Amazon CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ 排程及定期檢閱工作負載儀表板。定期執行儀表板檢查。您對於檢查深度可能有不同規律。
+ 檢查指標中的趨勢。比較指標值與歷史值，以查看是否有可能指出某項需要調查的趨勢。這些範例包括：增加延遲、減少主要業務功能，以及增加失敗回應。
+ 檢查指標中的異常值/異常。平均值或中位數可以遮罩異常值。查看時間範圍內的最高和最低值，並調查極端分數的原因。隨著您持續消除這些原因，降低極端的定義可讓您持續改善工作負載效能的一致性。
+ 尋找行為中的急劇變化。指標的數量或方向立即變更，可能表示應用程式有所變更，或您可能需要新增其他指標以追蹤的外部因素。
## 資源
**相關文件：**
+ [Amazon CloudWatch Logs Insights 範例查詢](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [使用 Amazon CloudWatch Synthetics 和 AWS X-Ray 偵錯](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [一個觀察工作坊](https://observability.workshop.aws/)
+ [Amazon Builders' Library：偵測分散式系統，以瞭解運作狀態](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [使用 Amazon CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
# REL06-BP07 透過您的系統監控請求的端對端追蹤
使用 AWS X-Ray 或第三方工具，讓開發人員能夠更輕鬆地分析和偵錯分散式系統，以了解其應用程式及其基礎服務的執行成效。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 透過您的系統監控請求的端對端追蹤。AWS X-Ray 是一種服務，可收集應用程式處理請求的相關資料，並提供可用於檢視、篩選和取得資料洞見的工具，以識別問題和優化機會。對於任何受追蹤的應用程式請求，您不僅可以查看關於請求和回應的詳細資訊，還可以查看應用程式對下游 AWS 資源、微型服務、資料庫和 Web API 發出的呼叫的詳細資訊。
+ [什麼是 AWS X-Ray？](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [使用 Amazon CloudWatch Synthetics 和 AWS X-Ray 偵錯](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
## 資源
**相關文件：**
+ [使用 Amazon CloudWatch Synthetics 和 AWS X-Ray 偵錯](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [一個觀察工作坊](https://observability.workshop.aws/)
+ [Amazon Builders' Library：偵測分散式系統，以瞭解運作狀態](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [使用 Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [什麼是 AWS X-Ray？](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
# REL 7 如何設計工作負載以適應需求變更？
可擴展工作負載提供自動新增或移除資源的彈性，以便隨時盡可能符合目前需求。
**Topics**
+ [REL07-BP01 取得或擴展資源時使用自動化](rel_adapt_to_changes_autoscale_adapt.md)
+ [REL07-BP02 在偵測到工作負載受損時取得資源](rel_adapt_to_changes_reactive_adapt_auto.md)
+ [REL07-BP03 偵測到工作負載需要更多資源時取得資源](rel_adapt_to_changes_proactive_adapt_auto.md)
+ [REL07-BP04 對工作負載執行負載測試](rel_adapt_to_changes_load_tested_adapt.md)
# REL07-BP01 取得或擴展資源時使用自動化
替換受損的資源或擴展工作負載時，請使用 Amazon S3 和 AWS Auto Scaling 等受管的 AWS 服務進行自動化程序。您還可以使用第三方工具和 AWS 開發套件來自動調整規模。
受管 AWS 服務包括 Amazon S3、Amazon CloudFront、AWS Auto Scaling、AWS Lambda、Amazon DynamoDB、AWS Fargate 和 Amazon Route 53。
AWS Auto Scaling 讓您可以偵測和取代受損的執行個體。這也讓您可以為資源建立擴展計畫，包括 [Amazon EC2](https://aws.amazon.com/ec2/) 執行個體和 Spot 機群叢集、 [Amazon ECS](https://aws.amazon.com/ecs/) 任務、 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 資料表和索引，以及 [Amazon Aurora](https://aws.amazon.com/aurora/) 複本。
擴展 EC2 執行個體時，請確保您使用多個可用區域 (最好至少有三個) 並新增或移除容量，以便在這些可用區域之間維持平衡。ECS 任務或 Kubernetes Pod (使用 Amazon Elastic Kubernetes Service 時) 也應該分散到多個可用區域。
使用 AWS Lambda 時，執行個體會自動擴展。每次收到函數的事件通知時，AWS Lambda 會在其運算叢集內快速找到可用容量，然後執行您的程式碼，直到達到配置的並行為止。您需要確保已在特定 Lambda 和 Service Quotas 中設定必要的並行。
Amazon S3 會自動調整規模以處理高請求率。例如，您的應用程式可以在儲存貯體的每個字首達到每秒至少 3,500 個 PUT/COPY/POST/DELETE 或 5,500 個 GET/HEAD 請求。儲存貯體中的字首數量沒有限制。您可以透過平行化讀取來提升讀取或寫入效能。例如，如果您在 Amazon S3 儲存貯體中建立 10 個字首來平行讀取，則可以將讀取效能擴展為每秒 55,000 個讀取請求。
設定和使用 Amazon CloudFront 或受信任的內容交付網路 (CDN)。CDN 可以提供更快的最終使用者回應時間，而且可以為快取中的內容請求提供服務，因此可減少擴展工作負載的需求。
**常用的反模式：**
+ 實作 Auto Scaling 群組以進行自動修復，但不實作彈性。
+ 使用自動調整規模來回應大幅增加的流量。
+ 部署高度狀態應用程式，免除彈性選項。
**建立此最佳實務的優勢：** 自動化會移除在部署和除役資源時可能出現的手動錯誤。自動化可免除因部署或除役需求回應緩慢而造成成本超支和拒絕服務的風險。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 設定和使用 AWS Auto Scaling。這會監控您的應用程式並自動調整容量，以盡可能低的成本維持穩定、可預測的效能。您可以使用 AWS Auto Scaling 為多個服務的多個資源設定應用程式擴展。
+ [什麼是 AWS Auto Scaling？](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ 在 Amazon EC2 執行個體和 Spot 機群、Amazon ECS 任務、Amazon DynamoDB 表格和索引、Amazon Aurora 複本和 AWS Marketplace 設備上設定 Auto Scaling (如適用)。
+ [使用 DynamoDB Auto Scaling 自動管理輸送量](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ 使用服務 API 操作來指定警示、擴展原則、準備時間和冷卻時間。
+ 使用 Elastic Load Balancing。負載平衡器可以按路徑或網路連線來分配負載。
+ [什麼是 Elastic Load Balancing？](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ Application Load Balancers 可以按路徑分配負載。
+ [什麼是 Application Load Balancer？](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ 設定 Application Load Balancer，以根據網域名稱下的路徑將流量分配到不同的工作負載。
+ Application Load Balancers 可用於以與 AWS Auto Scaling 整合的方式分配負載，以管理需求。
+ [搭配 Auto Scaling 群組使用負載平衡器](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ Network Load Balancer 可以透過連線分配負載。
+ [什麼是 Network Load Balancer？](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ 設定 Network Load Balancer，以使用 TCP 將流量分配到不同的工作負載，或為您的工作負載分配固定的 IP 地址集。
+ Network Load Balancer 可用於以與 AWS Auto Scaling 整合的方式分配負載，以管理需求。
+ 使用高度可用的 DNS 供應商。DNS 名稱讓您的使用者可以輸入名稱 (而不是 IP 地址) 來存取您的工作負載，並將此資訊分發到已定義的範圍 (通常是工作負載的所有使用者)。
+ 使用 Amazon Route 53 或信任的 DNS 供應商。
+ [什麼是 Amazon Route 53？](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ 使用 Route 53 來管理您的 CloudFront 分發和負載平衡器。
+ 確定要管理的網域和子網域。
+ 使用 ALIAS 或 CNAME 紀錄建立適當的紀錄集。
+ [處理記錄](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)
+ 使用 AWS 全球網路，優化從使用者到應用程式的路徑。AWS Global Accelerator 可持續監控應用程式端點的運作狀態，並在 30 秒內將流量重新導向到運作狀態良好的端點。
+ AWS Global Accelerator 是一種可改善具備當地或全球使用的應用程式可用性和效能的服務。它提供靜態 IP 地址，做為單一或多個 AWS 區域 (例如 Application Load Balancers、Network Load Balancers 或 Amazon EC2 執行個體) 應用程式端點的固定進入點。
+ [什麼是 AWS Global Accelerator？](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ 設定和使用 Amazon CloudFront 或受信任的內容交付網路 (CDN)。內容交付網路可以提供更快的最終使用者回應時間，並且可以處理可能導致不必要的工作負載擴展的內容請求。
+ [什麼是 Amazon CloudFront？](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ 為您的工作負載設定 Amazon CloudFront 分發，或使用第三方 CDN。
+ 您可以限制對工作負載的存取，使其只能透過在端點安全群組或存取政策中使用 CloudFront 的 IP 範圍從 CloudFront 存取。
## 資源
**相關文件：**
+ [APN 合作夥伴：可以幫助您建立自動化運算解決方案的合作夥伴](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27)
+ [AWS Auto Scaling：擴展計畫的運作方式](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace：可與 Auto Scaling 結合使用的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [使用 DynamoDB Auto Scaling 自動管理輸送量](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [搭配 Auto Scaling 群組使用負載平衡器](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ [什麼是 AWS Global Accelerator？](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [什麼是 Amazon EC2 Auto Scaling？](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [什麼是 AWS Auto Scaling？](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ [什麼是 Amazon CloudFront？](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected)
+ [什麼是 Amazon Route 53？](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [什麼是 Elastic Load Balancing？](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [什麼是 Network Load Balancer？](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [什麼是 Application Load Balancer？](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [處理記錄](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)
# REL07-BP02 在偵測到工作負載受損時取得資源
在可用性受到影響時視需要主動擴展資源，以還原工作負載可用性。
您必須先設定運作狀態檢查和這些檢查的條件，以指出可用性因資源不足而受到影響的時間。然後，通知適當的人員手動擴展資源，或觸發自動化以自動調整資源規模。
您可以針對工作負載手動調整規模，例如，透過AWS 管理主控台或 AWS CLI 變更 Auto Scaling 群組中的 EC2 執行個體數量，或修改 DynamoDB 資料表的輸送量。但是，應該盡可能使用自動化 (請參閱 **取得或擴展資源時使用自動化**) 建立持續整合/持續部署 (CI/CD) 管道。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 在偵測到工作負載受損時取得資源。在可用性受到影響時視需要主動擴展資源，以還原工作負載可用性。
+ 使用擴展計劃 (這是 AWS Auto Scaling 的核心元件) 來設定一組擴展資源的指示。如果您使用 AWS CloudFormation 或將標籤新增至 AWS 資源，則可以針對每個應用程式的不同資源集設定擴展計畫。AWS Auto Scaling 為針對每個資源自訂擴展的策略提供建議。建立擴展計畫之後，AWS Auto Scaling 會將動態擴展和預測擴展方法結合在一起，以支援您的擴展策略。
+ [AWS Auto Scaling：擴展計畫的運作方式](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ Amazon EC2 Auto Scaling 可協助您確保您擁有正確的 Amazon EC2 執行個體數量來處理應用程式的負載。您可以建立稱為 Auto Scaling 群組的 EC2 執行個體集合。您可以在每個 Auto Scaling 群組中指定執行個體的最小數量，而 Amazon EC2 Auto Scaling 可確保您的群組大小永遠不會低於此值。您可以在每個 Auto Scaling 群組中指定執行個體的最大數量，而 Amazon EC2 Auto Scaling 可確保您的群組大小永遠不會高於此大小。
+ [什麼是 Amazon EC2 Auto Scaling？](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ Amazon DynamoDB Auto Scaling 使用 AWS Application Auto Scaling 服務代替您動態調整佈建的輸送容量，以回應實際的流量模式。這可讓資料表或全域次要索引增加其佈建的讀取與寫入容量，以在不需調節的情況下處理突然增加的流量。
+ [使用 DynamoDB Auto Scaling 自動管理輸送量](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
## 資源
**相關文件：**
+ [APN 合作夥伴：可以幫助您建立自動化運算解決方案的合作夥伴](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27)
+ [AWS Auto Scaling：擴展計畫的運作方式](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace：可與 Auto Scaling 結合使用的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [使用 DynamoDB Auto Scaling 自動管理輸送量](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [什麼是 Amazon EC2 Auto Scaling？](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP03 偵測到工作負載需要更多資源時取得資源
主動擴展資源以滿足需求並避免可用性影響。
許多 AWS 服務會自動調整規模以滿足需求。如果使用 Amazon EC2 執行個體或 Amazon ECS 叢集，您可以將這些叢集的自動調整規模功能設定為根據與工作負載需求對應之用量指標來執行。對於 Amazon EC2，平均 CPU 使用率、負載平衡器請求計數或網路頻寬可用於擴展 (或縮減) EC2 執行個體。對於 Amazon ECS，平均 CPU 使用率、負載平衡器請求計數和記憶體使用率可用於橫向擴展 (或縮減) ECS 任務。透過在 AWS 上使用 Target Auto Scaling，自動調整規模裝置的作用就像家用恆溫器一樣，可新增或移除資源以維持您指定的目標值 (例如，70% 的 CPU 使用率)。
AWS Auto Scaling 也可以執行 [Predictive Auto Scaling](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)，其會使用機器學習分析每個資源的歷史工作負載，並定期預測未來兩天的未來負載。
「利特爾法則」有助於計算您需要的運算執行個體 (EC2 執行個體、並行 Lambda 函數等) 的數量。
*L* = *λW*
L = 執行個體數量 (或系統中的平均並行)
λ = 請求到達時的平均速率 (請求/秒)
W = 每個請求在系統中花費的平均時間 (秒)
例如，在 100 rps 時，如果每個請求需要 0.5 秒才能處理，您就需要 50 個執行個體才能因應需求。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
+ 偵測到工作負載需要更多資源時取得資源。主動擴展資源以滿足需求並避免可用性影響。
+ 計算處理指定請求率所需的運算資源 (運算並行)。
+ [說說「利特爾法則」的故事](https://brooker.co.za/blog/2018/06/20/littles-law.html)
+ 當您有使用的歷史模式時，請設定 Amazon EC2 Auto Scaling 的排程擴展。
+ [Amazon EC2 Auto Scaling 的排程擴展](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ 使用 AWS 預測擴展。
+ [EC2 的預測擴展，採用機器學習技術](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
## 資源
**相關文件：**
+ [AWS Auto Scaling：擴展計畫的運作方式](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace：可與 Auto Scaling 結合使用的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [使用 DynamoDB Auto Scaling 自動管理輸送量](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [EC2 的預測擴展，採用機器學習技術](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
+ [Amazon EC2 Auto Scaling 的排程擴展](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ [說說「利特爾法則」的故事](https://brooker.co.za/blog/2018/06/20/littles-law.html)
+ [什麼是 Amazon EC2 Auto Scaling？](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP04 對工作負載執行負載測試
採用負載測試方法來衡量擴展活動是否滿足工作負載要求。
重要的是執行持續的負載測試。負載測試應探索中斷點並和測試工作負載的效能。AWS 讓您可以輕鬆設定臨時測試環境，以塑造生產工作負載的規模。在雲端，您可隨需建立生產規模的測試環境、完成測試，再將資源除役。因為您只為執行中的測試環境付費，所以能以與內部部署測試相較之下相當微小比例的成本來模擬即時環境。
在生產系統承受壓力的演練日，以及客戶使用量較低的時間內，您也應考慮在生產中進行負載測試，並且讓可用的所有人員解釋結果並解決所發生的任何問題。
**常用的反模式：**
+ 在與生產組態不同的部署上執行負載測試。
+ 只對工作負載的個別部分而非整個工作負載執行負載測試。
+ 使用請求的子集而非代表的實際請求集合來執行負載測試。
+ 對高於預期負載的小型安全係數執行負載測試。
**建立此最佳實務的優勢：** 您會知道架構中的哪些元件在負載時失敗，並能夠識別要監看哪些指標，指出您正在及時處理該負載來解決問題，避免受到該故障的影響。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 執行負載測試，以識別工作負載的哪些層面指出您必須新增或移除容量。負載測試的代表性流量應該與您在生產環境中收到的流量相似。在觀看您已檢測的指標時增加負載，以判斷哪些指標指出何時必須新增或移除資源。
+ [AWS 上的分散式負載測試：模擬數千名連線的使用者](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ 識別請求混合。您可能會有不同的請求混合，因此您應該在識別流量混合時查看各種時間範圍。
+ 實作載入驅動程式。您可以使用自訂程式碼、開放原始碼或商業軟體實作載入驅動程式。
+ 最初使用小容量的負載測試。您將負載驅動到較小容量 (可能和單一執行個體或容器一樣小)，看到一些立即的影響。
+ 針對較大容量的負載測試。在分散式負載上的效果會有所不同，因此您必須盡可能在接近產品環境的條件下進行測試。
## 資源
**相關文件：**
+ [AWS 上的分散式負載測試：模擬數千名連線的使用者](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
# REL 8 您如何實作變更？
需有控制變更以部署新功能，並確保工作負載和運作環境執行已知軟體，且能以可預測的方式修補或取代。如果這些變更不受控制，則難以預測這些變更的效果，或是解決肇因於這些變更的問題。
**Topics**
+ [REL08-BP01 將執行手冊用於部署等標準活動](rel_tracking_change_management_planned_changemgmt.md)
+ [REL08-BP02 將功能測試整合為部署的一部分](rel_tracking_change_management_functional_testing.md)
+ [REL08-BP03 將彈性測試整合為部署的一部分](rel_tracking_change_management_resiliency_testing.md)
+ [REL08-BP04 使用不可變基礎設施進行部署](rel_tracking_change_management_immutable_infrastructure.md)
+ [REL08-BP05 使用自動化部署變更](rel_tracking_change_management_automated_changemgmt.md)
# REL08-BP01 將執行手冊用於部署等標準活動
執行手冊是實現特定成果的預定義程序。使用執行手冊執行手動或自動進行的標準活動。範例包括部署工作負載、修補工作負載或進行 DNS 修改。
例如，實施程序 [以確保部署期間的回復安全性](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)。確保您可以回復部署，且不會對客戶造成任何中斷，這對於打造可靠的服務而言至為關鍵。
對於執行手冊程序，從有效的手動流程開始，以程式碼實作並在適當時將其觸發為自動執行。
即使是高度自動化的複雜工作負載， [執行手冊仍然適用於執行演練日](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays) 或滿足嚴格的報告和稽核要求。
請注意，程序手冊用於回應特定事件，而執行手冊用於實現特定成果。執行手冊通常用於例行活動，而程序手冊則用於回應非例行事件。
**常用的反模式：**
+ 在生產環境中對組態執行非計畫中的變更。
+ 為了更快速地部署而略過計畫中的步驟，會導致部署失敗。
+ 在不測試變更反轉的情況下進行變更。
**建立此最佳實務的優勢：** 有效的變更規劃可提高您成功執行變更的能力，因為您知道所有受影響的系統。在測試環境中驗證變更可提高您的可信度。
**若未建立此最佳實務，暴露的風險等級為：** 高
## 實作指引
+ 透過在執行手冊中記錄程序，對熟知的事件做出一致且迅速的回應。
+ [AWS Well-Architected Framework：概念：執行手冊](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ 使用基礎設施即程式碼的原則來定義您的基礎設施。透過使用 AWS CloudFormation (或受信任的第三方) 來定義您的基礎設施，您可以使用版本控制軟體對變更進行版本控制和追蹤。
+ 使用 AWS CloudFormation (或受信任的第三方供應商) 來定義您的基礎設施。
+ [什麼是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ 使用良好的軟體設計原則，建立單一、解偶的範本。
+ 確定實作的許可、範本和負責方。
+ [ 使用 AWS Identity and Access Management 控制存取 ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html)
+ 使用原始檔控制 (例如 AWS CodeCommit 或受信任的第三方工具) 進行版本控制。
+ [什麼是 AWS CodeCommit？](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
## 資源
**相關文件：**
+ [APN 合作夥伴：可以幫助您建立自動化部署解決方案的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [AWS Marketplace：可用於自動化部署的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [AWS Well-Architected Framework：概念：執行手冊](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ [什麼是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [什麼是 AWS CodeCommit？](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
**相關範例：**
+ [使用程序手冊和執行手冊將操作自動化](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL08-BP02 將功能測試整合為部署的一部分
功能測試會作為自動化部署的一部分執行。如果未符合成功條件，則會終止或回復管道。
這些測試會在生產前環境中執行，而且會在生產前暫存於管道中。理想情況下，這是做為部署管道的一部分來完成。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 將功能測試整合為部署的一部分。功能測試會作為自動化部署的一部分執行。如果未符合成功條件，則會終止或回復管道。
+ 在 AWS CodePipeline 中建立模型之軟體發行管道的「測試動作」期間叫用 AWS CodeBuild。此功能可讓您輕鬆針對程式碼執行各種測試，例如單元測試、靜態程式碼分析和整合測試。
+ [AWS CodePipeline 新增對於單位的支援，以及透過 AWS CodeBuild 自訂整合測試](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ 使用 AWS Marketplace 解決方案，在軟體交付管道中執行自動化測試。
+ [軟體和測試自動化](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## 資源
**相關文件：**
+ [AWS CodePipeline 新增對於單位的支援，以及透過 AWS CodeBuild 自訂整合測試](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [軟體和測試自動化](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [什麼是 AWS CodePipeline？](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
# REL08-BP03 將彈性測試整合為部署的一部分
彈性測試 (使用 [混沌工程的原則](https://principlesofchaos.org/)) 會在生產前環境中做為自動化部署管道的一部分執行。
這些測試會在生產前環境暫存於管道中並在其中執行。這些測試也應該在生產環境中執行，以 [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays)。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 將彈性測試整合為部署的一部分。使用混沌工程，這是對工作負載進行實驗的專業領域，以建立可承受生產環境中的動盪條件能力的可信度。
+ 彈性測試會注入故障或資源降級，以評估工作負載是否回應其設計的彈性。
+ [Well-Architected 實驗室：第 300 級：測試 EC2 RDS 和 S3 的彈性](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
+ 這些測試可以定期在自動化部署管道的生產前環境中執行。
+ 這些測試也應該在生產環境中執行，但是以演練日的一部分執行。
+ 使用混沌工程原則，提出各種損害下工作負載表現方式的假設，然後使用彈性測試來測試您的假設。
+ [混沌工程的原則](https://principlesofchaos.org/)
## 資源
**相關文件：**
+ [混沌工程的原則](https://principlesofchaos.org/)
+ [什麼是 AWS Fault Injection Simulator？](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**相關範例：**
+ [Well-Architected 實驗室：第 300 級：測試 EC2 RDS 和 S3 的彈性](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
# REL08-BP04 使用不可變基礎設施進行部署
不可變基礎設施會強制規定生產工作負載上不得就地進行更新、安全性修補程式或組態方面的變更。需要進行變更時，會在新的基礎設施上建置架構並部署到生產環境。
不可變基礎設施範例最常見的實作是 ***不可變的伺服器***。這表示如果伺服器需要更新或修正，則會部署新的伺服器，而非更新已在使用中的伺服器。因此，應用程式中的每個變更都會從軟體推送至程式碼儲存庫 (例如 git push) 開始，而不會透過 SSH 登入伺服器並更新軟體版本。不可變的基礎設施不允許進行變更，因此您可以確定已部署系統的狀態。不可變的基礎設施在本質上更一致、更可靠且更可預測，而且它們可簡化軟體開發和操作的許多方面。
在不可變的基礎設施中部署應用程式時，請使用 Canary 或藍/綠部署。
[https://martinfowler.com/bliki/CanaryRelease.html](https://martinfowler.com/bliki/CanaryRelease.html) 是將少量客戶導向至新版本的實務，通常會在單一服務執行個體 (Canary) 上執行。之後，您可以仔細檢查所產生的任何行為變更或錯誤。如果遇到嚴重問題，可以從 Canary 中刪除流量，然後將使用者傳送回以前的版本。如果部署成功，則您可以繼續以期望的速度進行部署，同時監控變更是否有錯誤，直到完全部署為止。AWS CodeDeploy 可以使用將支援 Canary 部署的部署組態來設定 AWS CodeDeploy。
[https://martinfowler.com/bliki/BlueGreenDeployment.html](https://martinfowler.com/bliki/BlueGreenDeployment.html) 與 Canary 部署類似，不同之處在於整個應用程式須並行部署。您可在兩個堆疊 (藍色和綠色) 之間交替部署。再次強調，您可以將流量傳送到新版本，且如果發現部署問題，則可以回復到舊版本。通常會一次切換所有流量，但您也可以將一小部分的流量用於每個版本，以使用 Amazon Route 53 的加權 DNS 路由功能，提高新版本的採用率。可以使用將支援藍/綠部署的部署組態來設定 AWS CodeDeploy 及 AWS Elastic Beanstalk。
![\[圖表：顯示使用 AWS Elastic Beanstalk 和 Amazon Route 53 進行藍/綠部署\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/blue-green-deployment.png)
不可變基礎設施的優勢：
+ **降低組態偏移：** 透過經常從基本、已知和版本控制的組態取代伺服器，可將基礎設施 **重設為已知狀態，並避免組態偏移。** 重設為已知狀態，並避免組態偏移。
+ **簡化部署**：部署不需要支援升級，因此會得到簡化。升級只是新的部署。
+ **不可部分完成的可靠部署：** 部署成功完成，或是未進行任何變更。其可為部署程序賦予更多信任。
+ **利用快速的回復及復原程序打造更安全的部署：** 前一個運作版本並未變更，因此部署變得更加安全。如果偵測到錯誤，您可以回復至該版本。
+ **一致的測試和偵錯環境：** 所有伺服器都會使用相同的映像，因此環境之間沒有差異。一個組建會部署到多個環境中。它還能預防不一致的環境並簡化測試與偵錯。
+ **提高可擴展性：** 伺服器使用基礎映像，具有一致性和可重複性，因此自動調整規模相當簡單。
+ **簡化工具鏈**：您可以擺脫管理生產軟體升級的組態管理工具，因此工具鏈得到簡化。不會在伺服器上安裝額外的工具或代理程式。會對基礎映像進行變更、並對變更進行測試然後推出。
+ **提高安全性：** 藉由拒絕對伺服器進行的所有變更，您可以停用執行個體上的 SSH 並移除金鑰。這可減少攻擊向量，從而改善組織的安全狀態。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 使用不可變基礎設施進行部署。不可變基礎設施是一種模型，其中不會進行更新、安全性修補程式或組態方面的變更。 *就地* 進行更新、安全性修補程式或組態方面的變更。需要進行變更時，系統會建置新版本的架構並部署到生產環境。
+ [藍/綠部署概觀](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [逐步部署無伺服器應用程式](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [不可變基礎設施：透過不可變實現可靠性、一致性和可信度](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html)
## 資源
**相關文件：**
+ [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html)
+ [逐步部署無伺服器應用程式](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [不可變基礎設施：透過不可變實現可靠性、一致性和可信度](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [藍/綠部署概觀](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [Amazon Builders' Library：確保部署期間的回復安全](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
# REL08-BP05 使用自動化部署變更
部署和修補經過自動化以消除負面影響。
改變生產系統是許多組織的最大風險領域之一。我們認為，相較於軟體要解決的業務問題，部署才是我們要解決的首要問題。如今，這表示在營運中實際可行的地方使用自動化，包括測試和部署變更，新增或刪除容量以及移轉資料。AWS CodePipeline 讓您可以管理釋出工作負載所需的步驟。這包含使用 AWS CodeDeploy 的部署狀態，以自動將應用程式程式碼部署到 Amazon EC2 執行個體、內部部署執行個體、無伺服器 Lambda 函數或 Amazon ECS 服務。
**建議**
儘管傳統觀點建議您將業內人員安排在營運程序中最困難的部分，但是出於這個原因，我們建議您能自動化最困難的程序。
**常用的反模式：**
+ 手動執行變更。
+ 在緊急工作流程中略過自動化步驟。
+ 不遵循您的計畫。
**建立此最佳實務的優勢：** 使用自動化部署所有變更可免除引進人為錯誤的可能性，並可在變更生產前進行測試，以確保您的計畫順利完成。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 自動化您的部署管道。部署管道讓您可以叫用自動測試、偵測異常，或者在生產部署之前的某個步驟中停止管道，或者自動回復變更。
+ [Amazon Builders' Library：確保部署期間的回復安全](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [Amazon Builders' Library：使用持續交付加快腳步](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ 使用 AWS CodePipeline (或受信任的第三方產品) 來定義和執行管道。
+ 設定管道以在對程式碼儲存器提交變更時啟動。
+ [什麼是 AWS CodePipeline？](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ 使用 Amazon Simple Notification Service (Amazon SNS) 和 Amazon Simple Email Service (Amazon SES) 傳送有關管道中問題的通知，或與團隊聊天工具 (如 Amazon Chime) 整合。
+ [什麼是 Amazon Simple Notification Service？](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
+ [什麼是 Amazon SES？](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [什麼是 Amazon Chime？](https://docs.aws.amazon.com/chime/latest/ug/what-is-chime.html)
+ [使用 Webhook 自動化聊天訊息。](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
## 資源
**相關文件：**
+ [APN 合作夥伴：可以幫助您建立自動化部署解決方案的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [AWS Marketplace：可用於自動化部署的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [使用 Webhook 自動化聊天訊息。](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
+ [Amazon Builders' Library：確保部署期間的回復安全](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [Amazon Builders' Library：使用持續交付加快腳步](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ [什麼是 AWS CodePipeline？](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ [什麼是 CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
+ [什麼是 Amazon SES？](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [什麼是 Amazon Simple Notification Service？](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
**相關影片：**
+ [2019 年 AWS 高峰會：AWS 上的 CI/CD](https://youtu.be/tQcF6SqWCoY)
# 失敗管理
**Topics**
+ [REL 9 您如何備份資料？](w2aac19b9c11b5.md)
+ [REL 10 如何使用故障隔離來保護您的工作負載？](w2aac19b9c11b7.md)
+ [REL 11 如何設計工作負載以承受元件失敗？](w2aac19b9c11b9.md)
+ [REL 12 如何測試可靠性？](w2aac19b9c11c11.md)
+ [REL 13 您如何規劃災難復原 (DR)？](w2aac19b9c11c13.md)
# REL 9 您如何備份資料？
備份資料、應用程式和組態，以符合復原時間目標 (RTO) 和復原點目標 (RPO) 的要求。
**Topics**
+ [REL09-BP01 識別並備份所有需要備份的資料，或從來源複製資料](rel_backing_up_data_identified_backups_data.md)
+ [REL09-BP02 保護和加密備份](rel_backing_up_data_secured_backups_data.md)
+ [REL09-BP03 自動執行資料備份](rel_backing_up_data_automated_backups_data.md)
+ [REL09-BP04 定期執行資料復原以驗證備份的完整性和程序](rel_backing_up_data_periodic_recovery_testing_data.md)
# REL09-BP01 識別並備份所有需要備份的資料，或從來源複製資料
所有 AWS 資料存放區都會提供備份功能。Amazon RDS 和 Amazon DynamoDB 等服務會額外地支援啟用時間點復原 (PITR) 的自動備份，這可讓您將備份還原到目前時間之前最多五分鐘或更短的任何時間。許多 AWS 服務提供將備份複製到另一個 AWS 區域 的能力。AWS Backup 是一種工具，可讓您跨 AWS 服務集中化和自動化資料保護。
Amazon S3 可以用作自行受管和 AWS 受管資料來源的備份目的地。Amazon EBS、Amazon RDS 和 Amazon DynamoDB 等 AWS 服務具有內建功能來建立備份。也可以使用第三方備份軟體。
內部部署資料可以備份至 AWS 雲端，方法為使用 [AWS Storage Gateway](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) 或 [AWS Datasync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)。Amazon S3 儲存貯體可以用來將此資料儲存在 AWS 上。Amazon S3 提供多個儲存層，例如 [Amazon Glacier 或 S3 Glacier Deep Archive](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/amazon-s3-glacier.html) 來減少資料儲存的成本。
您能夠從其他資源重現資料來符合資料復原需求。例如， [Amazon Elasticache 複本節點](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) 或 [RDS 讀取複本](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) 可以用來重現資料，如果主要節點遺失的話。如果像這樣的來源可以用來符合您的 [復原時間目標 (RTO) 和復原點目標 (RPO)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html)，您可能不需要備份。另一個範例，如果使用 Amazon EMR，可能不需要備份 HDFS 資料存放區，只要您可以 [從 S3 將資料重現至 EMR。](https://aws.amazon.com/premiumsupport/knowledge-center/copy-s3-hdfs-emr/)。
選取備份策略時，請考慮復原資料所需的時間。復原資料所需的時間取決於備份的類型 (若有備份策略)，或資料重現機制的複雜性。此時間應該落在工作負載的 RTO 內。
**預期成果：**
已根據關鍵性識別和分類資料來源。然後，根據 RPO 建立資料復原的策略。此策略涉及備份這些資料來源，或具有從其他來源重現資料的能力。若遺失資料，實作的策略可讓您在定義的 RPO 和 RTO 內復原或重現資料。
**雲端成熟度階段：** 基礎級
**常用的反模式：**
+ 未注意工作負載的所有資料來源及其關鍵性。
+ 未備份關鍵資料來源。
+ 只備份某些資料來源，而未使用關鍵性做為準則。
+ 沒有已定義的 RPO，或備份頻率無法符合 RPO。
+ 未評估是否需要備份，或是否可從其他來源重現資料。
**建立此最佳實務的優勢：** 識別需要備份的位置並實作機制來建立備份，或者能夠從外部源重現資料，可以改善在中斷期間還原和復原資料的能力。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
了解和使用工作負載所使用的 AWS 服務和資源的備份功能。大部分 AWS 服務都會提供備份工作負載資料的功能。
**實作步驟：**
1. **識別工作負載的資料來源**。資料可以儲存在多個來源上，例如 [資料庫](https://aws.amazon.com/products/databases/)， [磁碟區](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)， [檔案系統](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)， [記錄系統](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)和 [物件儲存](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)。如需有關 Web 應用程式後端的建議，請參閱 **資源** 一節來尋找 **相關文件** ，其中關於儲存資料的不同 AWS 服務，以及這些服務提供的備份功能。
1. **根據關鍵性將資料來源分類**。不同的資料集對工作負載具有不同的關鍵性等級，因此對彈性具有不同的要求。例如，有些資料可能至關重要，且需要接近零的 RPO，而其他資料可能不太重要，且可以容忍更高的 RPO 和一些資料遺失。同樣地，不同的資料集也可能具有不同的 RTO 要求。
1. **使用 AWS 或第三方服務來建立資料的備份**。 [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 是受管服務，可讓您在 AWS 上建立各種資料來源的備份。其中大部分服務也具有建立備份的原生功能。AWS Marketplace 具有許多也提供這些功能的解決方案。如需有關 Web 應用程式後端的建議，請參閱 **資源** ，以取得如何從各種 AWS 服務建立資料備份的相關資訊。
1. **對於未備份的資料，請建立資料重現機制**。您可能基於各種原因選擇不備份可從其他來源重現的資料。可能有一種情況，即在需要時從來源重現資料比建立備份更便宜，因為可能有與儲存備份相關聯的成本。另一個範例是從備份中還原比從來源重現資料需要更長的時間，因而導致 RTO 中出現缺口。在這類情況下，考慮取捨並建立一個妥善定義的流程，其中指出在需要資料復原時如何從這些來源重現資料。例如，如果您已將資料從 Amazon S3 載入至資料倉儲 (如 Amazon Redshift) 或 MapReduce 叢集 (如 Amazon EMR)，對該資料執行分析，則這可能是可從其他來源重現的資料範例。只要這些分析的結果存放在某處或可複製，您就不會因為資料倉儲或 MapReduce 叢集故障而遺失資料。其他可從來源複製的範例包括快取 (如 Amazon ElastiCache) 或 RDS 的僅供讀取複本。
1. **建立備份資料的規律。**。建立資料來源的備份是一種定期流程，而且頻率應取決於 RPO。
**實作計劃的工作量：** 中
## 資源
**相關的最佳實務：**
[REL13-BP01 定義停機和資料遺失的復原目標](rel_planning_for_recovery_objective_defined_recovery.md)
[REL13-BP02 使用定義的復原策略來滿足復原目標](rel_planning_for_recovery_disaster_recovery.md)
**相關文件：**
+ [什麼是 AWS Backup？](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [什麼是 AWS DataSync？](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)
+ [什麼是磁碟區閘道？](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html)
+ [APN 合作夥伴：可以幫助備份的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace：可用於備份的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Amazon EBS 快照](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [備份 Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)
+ [備份 Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)
+ [ElastiCache for Redis 備份與還原](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)
+ [在 Neptune 中建立資料庫叢集快照](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-create-snapshot.html)
+ [建立資料庫快照](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html)
+ [建立依照排程觸發的 EventBridge 規則](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [跨區域複寫](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) 搭配 Amazon S3
+ [EFS-to-EFS AWS Backup](https://aws.amazon.com/solutions/efs-to-efs-backup-solution/)
+ [將日誌資料匯出至 Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [物件生命週期管理](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)
+ [DynamoDB 的隨需備份和還原](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorks.html)
+ [DynamoDB 的時間點復原](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html)
+ [使用 Amazon OpenSearch Service 索引快照](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html)
**相關影片：**
+ [AWS re:Invent 2021 - 使用 AWS 進行備份、災難復原和勒索軟體防護](https://www.youtube.com/watch?v=Ru4jxh9qazc)
+ [AWS Backup 示範：跨帳戶和跨區域備份](https://www.youtube.com/watch?v=dCy7ixko3tE)
+ [AWS re:Invent 2019：深入探討 AWS Backup，ft.Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
**相關範例：**
+ [Well-Architected 實驗室：實作 Amazon S3 雙向跨區域複寫 (CRR)](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
+ [Well-Architected 實驗室：測試備份並還原資料](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
+ [Well-Architected 實驗室：透過適用於分析工作負載的容錯回復進行備份和還原](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/)
+ [Well-Architected 實驗室：災難復原 - 備份和還原](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/)
# REL09-BP02 保護和加密備份
使用身分驗證和授權 (例如AWS IAM) 控制並偵測對備份的存取。使用加密來防止並檢測是否危及備份的資料完整性。
Amazon S3 支援多種靜態資料的加密方法。使用伺服器端加密時，Amazon S3 會以未加密資料的形式接受物件，然後在儲存這些物件之前將其加密。使用用戶端加密時，您的工作負載應用程式需負責加密資料，然後將資料傳送至 Amazon S3。這兩種方法都可讓您使用 AWS Key Management Service (AWS KMS) 來建立和存放資料金鑰，或者您也可以提供自己的金鑰，之後由您對其負責。使用 AWS KMS 時，您可以透過 IAM 設定政策，設定誰可以和誰無法存取您的資料金鑰和解密資料。
對於 Amazon RDS，如果您已選擇加密資料庫，則備份也會加密。DynamoDB 備份一律加密。
**常用的反模式：**
+ 讓備份和還原自動化的存取權與資料的存取權相同。
+ 不加密您的備份。
**建立此最佳實務的優勢：** 保護您的備份可防止資料遭到竄改，加密資料可防止意外暴露時存取該資料。
**若未建立此最佳實務，暴露的風險等級為：** 高
## 實作指引
+ 在每個資料存放區使用加密。如果來源資料已加密，則備份也會加密。
+ 在 RDS 中啟用加密。您可以在建立 RDS 執行個體時，使用 AWS Key Management Service 設定靜態加密。
+ [加密 Amazon RDS 資源](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ 在 EBS 磁碟區上啟用加密。您可以在建立磁碟區時設定預設加密或指定唯一金鑰。
+ [Amazon EBS 加密](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ 使用必要的 Amazon DynamoDB 加密。DynamoDB 會加密所有靜態資料。您可以使用 AWS 自有的 AWS KMS 金鑰或 AWS 受管 KMS 金鑰，指定帳戶中儲存的金鑰。
+ [DynamoDB 靜態加密](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [管理加密表格](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ 加密存放在 Amazon EFS 中的資料。在建立檔案系統時設定加密。
+ [在 EFS 中加密資料和中繼資料](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ 在來源和目的地區域設定加密。您可以使用 KMS 中存放的金鑰來設定 Amazon S3 中的靜態加密，但金鑰受到區域限定。您可以在設定複寫時指定目的地金鑰。
+ [CRR 其餘組態：複寫使用 AWS KMS 中存放的加密金鑰，透過伺服器端加密 (SSE) 所建立的物件。](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)
+ 實作存取備份的最低許可。遵循最佳實務，以根據安全最佳實務限制對備份、快照和複本的存取。
+ [安全支柱：AWS Well-Architected](./wat.pillar.security.en.html)
## 資源
**相關文件：**
+ [AWS Marketplace：可用於備份的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Amazon EBS 加密](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ [Amazon S3：利用加密保護資料](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html)
+ [CRR 其餘組態：複寫使用 AWS KMS 中存放的加密金鑰，透過伺服器端加密 (SSE) 所建立的物件。](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)
+ [DynamoDB 靜態加密](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [加密 Amazon RDS 資源](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ [在 EFS 中加密資料和中繼資料](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ [AWS 中的備份加密](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html)
+ [管理加密表格](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ [安全支柱：AWS Well-Architected](./wat.pillar.security.en.html)
**相關範例：**
+ [Well-Architected 實驗室：實作 Amazon S3 雙向跨區域複寫 (CRR)](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
# REL09-BP03 自動執行資料備份
設定備份以根據復原點目標 (RPO) 所通知的定期排程或資料集中的變更自動執行。資料遺失要求低的關鍵資料集需要經常自動備份，而可以接受一些遺失的不太重要資料可以較不頻繁地備份。
AWS Backup 可以用來建立各種 AWS 資料來源的自動資料備份。Amazon RDS 執行個體幾乎可以持續每五分鐘備份一次，而且 Amazon S3 物件幾乎可以持續每十五分鐘備份一次，同時將時間點復原 (PITR) 提供至備份歷史記錄內的特定時間點。針對其他 AWS 資料來源，例如 Amazon EBS 磁碟區、Amazon DynamoDB 資料表或 Amazon FSx 檔案系統，AWS Backup 可以頻繁地每小時執行自動備份。這些服務也會提供原生備份功能。提供自動備份與時間點復原的 AWS 服務包括 [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html)、 [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html)和 [Amazon
Keyspaces (適用於 Apache Cassandra)](https://docs.aws.amazon.com/keyspaces/latest/devguide/PointInTimeRecovery.html) – 這些可以還原至備份歷史記錄內的特定時間點。大部分其他 AWS 資料儲存服務都會提供定期備份排程的能力，頻率為每小時備份一次。
Amazon RDS 和 Amazon DynamoDB 會提供連續備份與時間點復原。一旦啟用了 Amazon S3 版本控制，就會自動執行。[Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html) 可以用來自動建立、複製和刪除 Amazon EBS 快照。其也可以自動建立、複製、棄用和取消註冊 Amazon EBS 支援的 Amazon Machine Image (AMI) 及其基礎 Amazon EBS 快照。
為了集中檢視備份自動化和歷史記錄，AWS Backup 提供全受管的、基於政策的備份解決方案。它使用 AWS Storage Gateway 在雲端和內部部署中跨多個 AWS 服務，自動集中進行資料備份。
除版本控制之外，Amazon S3 還具有複寫功能。整個 S3 儲存貯體可自動複寫至相同或不同 AWS 區域中的另一個儲存貯體。
**預期成果：**
以建立的規律建立資料來源備份的自動化流程。
**常用的反模式：**
+ 手動執行備份。
+ 使用具有備份功能的資源，但不包含您的自動化中的備份。
**建立此最佳實務的優勢：** 自動化備份可確保它們根據您的 RPO 定期進行備份，如果未進行備份則會提醒您。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
1. **識別目前正在** 手動備份的資料來源。請參閱 [REL09-BP01 識別並備份所有需要備份的資料，或從來源複製資料](rel_backing_up_data_identified_backups_data.md) 以取得此動作的指引。
1. **判斷工作負載的 ** PRO。請參閱 [REL13-BP01 定義停機和資料遺失的復原目標](rel_planning_for_recovery_objective_defined_recovery.md) 以取得此動作的指引。
1. **使用自動化備份解決方案或受管服務**。AWS Backup 是全受管服務，可讓您 [輕鬆地在雲端和內部部署跨 AWS 服務集中和自動保護資料。](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html#creating-automatic-backups)。備份計劃是 AWS Backup 的功能，可讓您建立規則，定義要備份的資源，以及應以何種頻率建立這些備份。此頻率應由步驟 2 中建立的 RPO 通知。 [此 WA 實驗室](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) 提供如何使用 AWS Backup 建立自動備份的實作指引。大多數存放資料的 AWS 服務都會提供原生備份功能。例如，可以利用 RDS 搭配時間點復原 (PITR) 進行自動備份。
1. **針對自動化備份解決方案或** 受管服務不支援的資料來源 (例如內部部署資料來源或訊息佇列)，請考慮使用信任的第三方解決方案建立自動化備份。或者，您可以使用 AWS CLI 或 SDK 建立自動化來執行此動作。您可以使用 AWS Lambda Functions 或 AWS Step Functions，定義涉及建立資料備份的邏輯，以及使用 Amazon EventBridge，以基於步驟 2 中所建立 RPO 的頻率執行它。
**實作計劃的工作量：** 低
## 資源
**相關文件：**
+ [APN 合作夥伴：可以幫助備份的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace：可用於備份的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [建立依照排程觸發的 EventBridge 規則](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [什麼是 AWS Backup？](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [什麼是 AWS Step Functions？](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
**相關影片：**
+ [AWS re:Invent 2019：深入探討 AWS Backup，ft.Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
**相關範例：**
+ [Well-Architected 實驗室：測試備份並還原資料](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# REL09-BP04 定期執行資料復原以驗證備份的完整性和程序
透過執行復原測試，驗證您的備份程序實作是否符合復原時間目標 (RTO) 和復原點目標 (RPO)。
使用 AWS 時，您可以建立一個測試環境，還原備份來評估 RTO 和 RPO 功能，並針對資料內容和完整性執行測試。
此外，Amazon RDS 和 Amazon DynamoDB 允許時間點復原 (PITR)。使用持續備份時，您可以將資料集還原到指定日期和時間當時的狀態。
**預期成果：** 使用妥善定義的機制定期復原來自備份的資料，以確保可在工作負載的既定復原時間點目標 (RTO) 內復原。驗證從備份中還原是否會導致資源包含原始資料 (而其中沒有任何損壞或無法存取)，但在復原點目標 (RPO) 內發生資料遺失。
**常用的反模式：**
+ 還原備份，但不查詢或擷取任何資料，以確保還原可用。
+ 假設備份存在。
+ 假設系統的備份可以完全運作，而且可以從中復原資料。
+ 假設從備份中還原或復原資料的時間落在工作負載的 RTO 內。
+ 假設備份上包含的資料落在工作負載的 RPO 內。
+ 在不使用執行手冊的情況下，或在建立的自動化程序外部，還原特定資料。
**建立此最佳實務的優勢：** 測試備份的復原確保可在需要時還原資料，而不必擔心資料可能丟失或損壞，也可確保還原和復原可在工作負載的 RTO 內進行，而且任何資料遺失都會落在工作負載的 RPO 內。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
測試備份和還原功能可以提高能夠在中斷期間執行這些動作的信心。定期將備份還原至新位置，並執行測試以驗證資料的完整性。某些應該執行的常用測試正在檢查
所有資料是否可用、未損壞、可存取，並且任何資料遺失都落在工作負載的 RPO 內。此類測試也可以協助確定，復原機制是否足夠快到適應工作負載的 RTO。
1. **識別目前正在** 備份的資料來源，以及這些備份的存放位置。請參閱 [REL09-BP01 識別並備份所有需要備份的資料，或從來源複製資料](rel_backing_up_data_identified_backups_data.md) 以取得如何實作此動作的指引。
1. **建立每個資料來源的** 資料驗證準則。不同類型的資料將具有不同的屬性，可能需要不同的驗證機制。在您自信可於生產環境中使用此資料之前，請考慮如何驗證它。一些驗證資料的常用方法是使用資料和備份屬性，例如資料類型、格式、檢查總和、大小，或這些屬性與自訂驗證邏輯的組合。例如，這可能是建立備份時所還原資源與資料來源之間的檢查總和值比較。
1. **建立 RTO 和 RPO，** 根據資料關鍵性還原資料。請參閱 [REL13-BP01 定義停機和資料遺失的復原目標](rel_planning_for_recovery_objective_defined_recovery.md) 以取得如何實作此動作的指引。
1. **存取您的復原功能**。審查您的備份和還原策略，以了解它是否可以符合您的 RTO 和 RPO，並視需要調整策略。您可以使用 [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-policy.html)，執行工作負載的評定。此評定會針對彈性政策評估您的應用程式組態，並報告您的 RTO 和 RPO 目標是否可以實現。
1. **使用目前建立且用於** 生產環境進行資料還原的程序執行測試還原。這些程序取決於原始資料來源的備份方式、備份本身的格式和儲存位置，或是否已從其他源重現資料。例如，如果您是使用類似 [AWS Backup 的受管服務，這可能與將備份還原至新資源一樣簡單](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html)。如果已使用 AWS 彈性災難復原，您可以 [啟動復原練習。](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html)。
1. **根據您先前** 在步驟 2 中針對資料驗證建立的準則，驗證從已還原的資源 (來自上一個步驟) 進行的資料復原。還原和復原的資料是否包含備份時最新的記錄/項目？ 此資料是否落在工作負載的 RPO 內？
1. **測量還原和復原** 所需的時間，並將其與步驟 3 中建立的 RTO 進行比較。此程序是否落在工作負載的 RTO 內？ 例如，比較從還原程序開始到復原驗證完成的時間戳記，以計算此程序需要多長時間。所有 AWS API 都會加上時間戳記，而且此資訊可用於 [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)。儘管此資訊可以提供有關還原程序何時開始的詳細資訊，但驗證完成時的結束時間戳記應由驗證邏輯記錄。如果使用自動程序，則 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 之類服務可以用來存放此資訊。此外，許多 AWS 服務會提供事件歷史記錄，其中提供特定動作何時發生的時間戳記資訊。在 AWS Backup 內，備份和還原動作都稱為 *工作*，而且這些工作包含時間戳記資訊做為其中繼資料的一部分，而此中繼資料可以用來測量還原和復原所需的時間。
1. **通知利害關係人** 如果資料驗證失敗，或如果還原和復原所需的時間超出針對工作負載建立的 RTO。實作自動化來執行此動作 [(例如在此實驗室中)](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)時，Amazon Simple Notification Service (Amazon SNS) 之類服務可以用來將電子郵件或 SMS 等通知推送至利害關係人。 [這些訊息也可以推送至傳訊應用程式，例如 Amazon Chime、Slack 或 Microsoft Teams，](https://aws.amazon.com/premiumsupport/knowledge-center/sns-lambda-webhooks-chime-slack-teams/) 或用來 [使用 AWS Systems Manager OpsCenter 建立任務做為 OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-creating-OpsItems.html)。
1. **將此程序自動化為定期執行**。例如，服務 (例如 AWS Lambda 或 AWS Step Functions 中的狀態機器) 可以用來將還原和復原程序自動化，而且 Amazon EventBridge 可以用來定期觸發此自動化工作流程，如下面架構圖所示。了解如何 [使用 AWS Backup 將資料復厡驗證自動化](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/)。此外， [這個 Well-Architected 實驗室](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) 會提供實作體驗，有關在這裡為數個步驟執行自動化的方式。
![\[圖表：顯示自動的備份和還原程序\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/automated-backup-restore-process.png)
**實作計劃的工作量：** 中到高，取決於驗證準則的複雜性。
## 資源
**相關文件：**
+ [使用 AWS Backup 將資料復厡驗證自動化](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/)
+ [APN 合作夥伴：可以幫助備份的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace：可用於備份的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [建立依照排程觸發的 EventBridge 規則](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [DynamoDB 的隨需備份和還原](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BackupRestore.html)
+ [什麼是 AWS Backup？](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [什麼是 AWS Step Functions？](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [什麼是 AWS 彈性災難復原](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [AWS 彈性災難復原](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
**相關範例：**
+ [Well-Architected 實驗室：測試備份並還原資料](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# REL 10 如何使用故障隔離來保護您的工作負載？
故障隔離界限會在工作負載內將失敗影響限制至有限數量的元件。界限外的元件不受失敗影響。使用多個故障隔離界限時，您可以限制對工作負載的影響。
**Topics**
+ [REL10-BP01 將工作負載部署至多個位置](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 為您的多位置部署選取適當位置](rel_fault_isolation_select_location.md)
+ [REL10-BP03 針對限制在單一位置的元件將復原自動化](rel_fault_isolation_single_az_system.md)
+ [REL10-BP04 使用隔板架構限制影響範圍](rel_fault_isolation_use_bulkhead.md)
# REL10-BP01 將工作負載部署至多個位置
跨多個可用區域或視需要跨 AWS 區域，分配工作負載資料和資源。這些位置可以根據需要多樣化。
AWS 服務設計的基本原則之一是避免底層實體基礎設施中出現單點故障。這樣一來，我們將能建置可使用多個可用區域且能應對單一區故障的軟體和系統。同樣地，可將系統建置為能應對單一運算節點、單一儲存磁碟區或資料庫的單一執行個體的故障。建置依賴冗餘元件的系統時，務必要確保元件能獨立運行，而對於 AWS 區域而言，應能自主運行。具有冗餘元件的理論可用性計算，其優點只有在符合此條件時才有效。
**可用區域 (AZ)**
AWS 區域由多個可用區域組成，它們設計為彼此獨立作業。每個可用區域與其他可用區域是以有意義的實體距離隔開，從而可避免因火災、洪水和龍捲風等環境危害導致相關的失敗情境。每個可用區域也都具有獨立的實體基礎設施：可用區域內部和外部的公用電源專用連接、獨立的備用電源、獨立的機械服務以及獨立的網路連線。這種設計會將任何這些系統中的錯誤僅限制在受影響的可用區域。儘管在地理位置上是分開的，但可用區域位於啟用高輸送量、低延遲聯網的同一區域。整個 AWS 區域 (跨所有可用區域，由多個實體上獨立的資料中心組成) 可以視為工作負載的單一邏輯部署目標，包括同步複寫資料的能力 (例如，在資料庫之間)。這可讓您在主動/主動或主動/待命組態中使用可用區域。
可用區域是各自獨立的，因此當工作負載架構為使用多個區域時，工作負載的可用性也會隨之提高。一些 AWS 服務 (包括 Amazon EC2 執行個體資料平面) 會部署為嚴格的區域服務，其中它們與其所在的可用區域共享命運。不過，其他 AZ 中的 Amazon EC2 執行個體將不受影響並繼續運作。同樣地，如果可用區域中的失敗導致 Amazon Aurora 資料庫失敗，則未受影響 AZ 中的讀取副本 Aurora 執行個體可以自動提升為主要執行個體。另一方面，區域 AWS 服務 (例如 Amazon DynamoDB) 可內部使用主動/主動組態中的多個可用區域，以實現該服務的可用性設計目標，無需您設定 AZ 置放。
![\[圖表：顯示跨三個可用區域部署的多層架構。請注意，Amazon S3 和 Amazon DynamoDB 一律自動採用異地同步備份策略。ELB 也會部署至全部三個區域。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/multi-tier-architecture.png)
儘管 AWS 控制平面通常有能力管理整個區域 (多個可用區域) 內的資源，但是某些控制平面 (包括 Amazon EC2 和 Amazon EBS) 能夠將結果篩選至單一可用區域。完成此操作後，僅在指定的可用區域中處理該請求，從而減少其他可用區域中的中斷風險。此 AWS CLI 範例說明僅從 us-east-2c 可用區域取得 Amazon EC2 執行個體資訊：
```
AWS ec2 describe-instances --filters Name=availability-zone,Values=us-east-2c
```
*AWS Local Zones*
AWS Local Zones 的作用與各自 AWS 區域內的可用區域類似，它們可在其中被選取為區域 AWS 資源 (如子網路和 EC2 執行個體) 的置放位置。特別之處在於它們不是位於相關聯的 AWS 區域，而是鄰近目前沒有 AWS 區域的大型人口、產業和 IT 中心。然而，它們仍可在本機區域的本機工作負載與在 AWS 區域中執行的本機工作負載之間保持高頻寬、安全的連線。您應該使用 AWS Local Zones，針對低延遲要求部署離使用者更近的工作負載。
**Amazon Global Edge Network**
Amazon Global Edge Network 由分布在全球各城市的節點組成。Amazon CloudFront 使用此網路以較低的延遲將內容交付給最終使用者。AWS Global Accelerator 讓您可以在這些節點建立工作負載端點，以便在靠近使用者的 AWS 全球網路提供引導服務。Amazon API Gateway 使用 CloudFront 分配啟用邊緣最佳化的 API 端點，以透過最接近的節點加快用戶端存取。
*AWS 區域*
AWS 區域都設計為自主的，因此，若要使用多區域方法，您要部署專用的服務副本至每個區域。
多區域方法常用於 *災難復原* 策略，以在一次性大規模事件發生時符合復原目標。請參閱 [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) 以取得這些策略的詳細資訊。然而在此，我們反而專注於 *可用性*，尋求隨時間交付平均運行時間目標。對於高可用性目標，多區域架構通常會設計為主動/主動，其中每個服務副本 (在其各自的區域中) 都是主動的 (服務請求)。
**建議**
您可以在單一 AWS 區域 內使用異地同步備份策略，滿足大部分工作負載的可靠性目標。僅在工作負載具有極端的可用性要求或其他需要多區域架構的業務目標時，才考慮多區域架構。
AWS 可讓您跨區域操作服務。例如，AWS 使用 Amazon Simple Storage Service (Amazon S3) 複寫、Amazon RDS 讀取複本 (包括 Aurora 讀取複本) 和 Amazon DynamoDB 全域表提供資料的連續、非同步資料複寫。透過持續複寫，您的資料版本幾乎可以立即在您的每個作用中區域中使用。
使用 AWS CloudFormation，您可以定義基礎設施，並以一致方式跨 AWS 帳戶 和跨 AWS 區域 進行部署。為了擴充此功能，AWS CloudFormation StackSets 會讓您可以使用單一作業跨多個帳戶和區域建立、更新或刪除 AWS CloudFormation 堆疊。對於 Amazon EC2 部署執行個體，AMI (Amazon Machine Image) 用來提供資訊，例如硬體組態和安裝的軟體。您可以實作 Amazon EC2 Image Builder 管道，建立您需要的 AMI，並將這些 AMI 複製到作用中區域。這可確保這些 *黃金 AMI* 具備您在每個新區域中部署和橫向擴展工作負載所需的一切。
若要路由流量，Amazon Route 53 和 AWS Global Accelerator 會啟用政策的定義，而這些政策可決定哪些使用者前往哪個作用中區域端點。透過 Global Accelerator，您可以設定流量刻度盤，來控制導向到每個應用程式端點的流量百分比。Route 53 支援這種百分比方法，也支援多種其他可用政策，包括地理位置臨近性和延遲型政策。Global Accelerator 自動利用廣泛的 AWS 邊緣伺服器網路，盡快將流量上線至 AWS 網路主幹，這會導致降低請求延遲。
所有這些功能都會運作，以保留每個區域的自主權。這種方法幾乎不存在例外情況，包括我們可提供全域交付的服務 (例如 Amazon CloudFront 和 Amazon Route 53) 以及 AWS Identity and Access Management (IAM) 服務的控制平面。大部分服務完全在單一區域內運行。
**內部部署資料中心**
對於在內部部署資料中心執行的工作負載，請盡可能架構混合式體驗。AWS Direct Connect 提供從內部設施連接至 AWS 的專用網路連線，讓您可以在兩種環境中執行。
另一個選項是使用 AWS Outposts 在內部設施執行 AWS 基礎設施和服務。AWS Outposts 是一種全受管服務，可將 AWS 基礎設施、AWS 服務、API 和工具延伸到您的資料中心。AWS 雲端中使用的硬體基礎設施與資料中心安裝的硬體基礎設施相同。AWS Outposts 會接著連接至最近的 AWS 區域 區域。然後，您可以使用 AWS Outposts 來支援低延遲或有本機資料處理要求的工作負載。
**若未建立此最佳實務，暴露的風險等級為：** 高
## 實作指引
+ 使用多個可用區域和 AWS 區域。跨多個可用區域或視需要跨 AWS 區域，分配工作負載資料和資源。這些位置可以根據需要多樣化。
+ 區域服務固有地跨可用區域部署。
+ 這包括 Amazon S3、Amazon DynamoDB 和 AWS Lambda (未連線至 VPC 時)
+ 將容器、執行個體和函數中的工作負載部署到多個可用區域中。使用多區域資料存放區，包括快取。使用 EC2 Auto Scaling 的功能、ECS 任務放置、AWS Lambda 函數組態 (在 VPC 中執行時) 和 ElastiCache 叢集。
+ 部署 Auto Scaling 群組時，使用單獨的可用區域中的子網路。
+ [範例：將執行個體分散到多個可用區域](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Amazon ECS 任務置放策略](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [設定 AWS Lambda 函數以存取 Amazon VPC 中的資源](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ [選擇區域和可用區域](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ 部署 Auto Scaling 群組時，使用單獨的可用區域中的子網路。
+ [範例：將執行個體分散到多個可用區域](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ 使用 ECS 任務置放參數，指定資料庫子網路群組。
+ [Amazon ECS 任務置放策略](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ 將函數設定為在 VPC 中執行時，在多個可用區域中使用子網路。
+ [設定 AWS Lambda 函數以存取 Amazon VPC 中的資源](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ 將多個可用區域與 ElastiCache 叢集一起使用。
+ [選擇區域和可用區域](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ 如果您的工作負載必須部署至多個區域，請選擇多區域策略。大多數的可靠性需求都可透過多個可用區域策略，在單一 AWS 區域內滿足。視需要使用多區域策略，以符合您的業務需求。
+ [AWS re:Invent 2018：適用於多區域主動-主動應用程式的架構模式 (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ 在另一個 AWS 區域的備份可以進一步確保資料在需要時可用。
+ 有些工作負載會有法規要求，規定要使用多區域策略。
+ 針對您的工作負載評估 AWS Outposts。如果您的工作負載需要內部部署資料中心達到低延遲要求，或有本機資料處理要求。然後使用 AWS Outposts 在內部部署執行 AWS 基礎設施和服務
+ [什麼是 AWS Outposts？](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
+ 判斷 AWS Local Zones 是否協助您為使用者提供服務。如果您有低延遲要求，請查看 AWS Local Zones 是否靠近您的使用者。如果是如此，則使用它來部署更靠近這些使用者的工作負載。
+ [AWS Local Zones 常見問答集](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
## 資源
**相關文件：**
+ [AWS 全球基礎設施](https://aws.amazon.com/about-aws/global-infrastructure)
+ [AWS Local Zones 常見問答集](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [Amazon ECS 任務置放策略](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [選擇區域和可用區域](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ [範例：將執行個體分散到多個可用區域](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [全域資料表：使用 DynamoDB 進行多區域複寫](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [使用 Amazon Aurora 全球資料庫](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [使用 AWS Services 部落格系列建立多區域應用程式](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [什麼是 AWS Outposts？](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
**相關影片：**
+ [AWS re:Invent 2018：適用於多區域主動-主動應用程式的架構模式 (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019：AWS 全球網路基礎設施的創新和營運 (NET339)](https://youtu.be/UObQZ3R9_4c)
# REL10-BP02 為您的多位置部署選取適當位置
## 預期成果
如需高可用性，請一律 (如果可能) 將工作負載元件部署到多個可用區域 (AZ)，如圖 10 所示。對於具有極端彈性要求的工作負載，請仔細評估多區域架構的選項。
![\[圖表：顯示備份至另一個 AWS 區域的彈性異地同步備份資料庫部署\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/multi-az-architecture.png)
## 常用的反模式
+ 當異地同步備份架構滿足要求時，選擇設計多區域架構。
+ 如果這些元件之間的彈性和多位置要求不同，則不考慮應用程式元件之間的相依性。
## 建立此最佳實務的優勢
對於彈性，您應該使用建置防禦層的方法。一層透過使用多個 AZ 建置高度可用的架構來防範更小、更常見的中斷。另一防御層旨在防範發生罕見事件，例如廣泛的自然災害和區域級中斷。這第二層涉及架構您的應用程序以跨越多個 AWS 區域。
+ 99.5% 可用性和 99.99% 可用性之間的差異每月超過 3.5 小時。如果工作負載位於多個可用區域中，則工作負載的預期可用性只能達到「四個九」。
+ 透過在多個可用區域中執行您的工作負載，您可以隔離電源、冷卻和聯網中的故障，以及火災和洪水等大多數自然災害。
+ 針對您的工作負載實作多區域策略有助於其防範影響國家一大片地理區域的廣泛自然災害，或整個區域範圍的技術失敗。請注意，實作多區域架構可能相當複雜，並且通常對於大多數工作負載而言不是必要的。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
若是基於一個可用區域之中斷或局部損失的災難事件，在單一 AWS 區域內的多個可用區域中實作高可用工作負載，可緩解自然發生的災難和技術性災難。每個 AWS 區域都是由多個可用區域構成，每個可用區域都會與其他區域中的錯誤隔離開來，而且會隔開有意義的距離。不過，災難事件若包括失去多個可用區域元件的風險，而這些元件彼此相距甚遠，您應該實作災難復原選項，以緩解整個區域範圍的失敗。對於需要極端彈性的工作負載 (關鍵基礎設施、健康相關應用程式、金融系統基礎設施等)，可能需要多區域策略。
## 實作步驟
1. 評估您的工作負載並判斷異地同步備份方法 (單一 AWS 區域) 是否可以滿足彈性需求，或者它們是否需要多區域方法。實作多區域架構來滿足這些要求將引進額外的複雜性，因此請仔細考慮您的使用案例及其要求。使用單一 AWS 區域，幾乎可以一律符合彈性要求。在判斷是否需要使用多個區域時，請考慮以下可能的要求：
1. **災難復原 (DR)**：若是基於一個可用區域之中斷或局部損失的災難事件，在單一 AWS 區域內的多個可用區域中實作高可用工作負載，可緩解自然發生的災難和技術性災難。災難事件若包括失去多個可用區域元件的風險，而這些元件彼此相距甚遠，您應該跨多個區域實作災難復原，以緩解整個區域範圍的自然災難或技術失敗。
1. **高可用性 (HA)**：多區域架構 (在每個區域中使用多個可用區域) 可以用來實現大於四個 9 (> 99.99%) 的可用性。
1. **堆疊本地化**：將工作負載部署到全球對象時，您可以在不同的 AWS 區域 中部署本地化的堆疊，為這些區域中的對象提供服務。本地化可以包括語言、貨幣及存放的資料類型。
1. **接近使用者：** 將工作負載部署到全球對象時，您可以在接近最終使用者所在位置的 AWS 區域中部署堆疊來減少延遲。
1. **資料落地**：某些工作負載受制於資料落地要求，其中來自特定使用者的資料必須保留在特定國家/地區的邊界內。根據討論中的法規，您可以選擇將整個堆疊或只將資料部署到這些邊界內的 AWS 區域。
1. 以下是 AWS 服務提供的異地同步備份功能的一些範例：
1. 若要使用 EC2 或 ECS 保護工作負載，請在運算資源前面部署 Elastic Load Balancer。然後，Elastic Load Balancing 會提供解決方案，以偵測運作狀態不佳區域中的執行個體，並將流量路由至運作良好的區域。
1. [Application Load Balancers 入門](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancer-getting-started.html)
1. [Network Load Balancer 入門](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancer-getting-started.html)
1. 如果執行商務現成軟體的 EC2 執行個體不支援負載平衡，您可以透過實作異地同步備份災難復原方法來實現某種形式的容錯。
1. [REL13-BP02 使用定義的復原策略來滿足復原目標](rel_planning_for_recovery_disaster_recovery.md)
1. 對於 Amazon ECS 任務，將您的服務平均地部署在三個可用區域之中，以實現可用性與成本的平衡。
1. [Amazon ECS 可用性最佳實務 \$1 容器](https://aws.amazon.com/blogs/containers/amazon-ecs-availability-best-practices/)
1. 對於非 Aurora Amazon RDS，您可以選擇異地同步備份做為組態選項。在主資料庫執行個體失敗時，Amazon RDS 會自動提升備用資料庫，以接收另一個可用區域中的流量。也可以建立多區域讀取複本來改善彈性。
1. [Amazon RDS 異地同步備份部署](https://aws.amazon.com/rds/features/multi-az/)
1. [在不同的 AWS 區域 中建立讀取複本](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.XRgn.html)
1. 以下是 AWS 服務提供的多區域功能的一些範例：
1. 對於服務自動提供異地同步備份可用性的 Amazon S3 工作負載，如果需要多區域部署，請考慮使用多區域存取點。
1. [Amazon S3 中的多區域存取點](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html)
1. 對於服務自動提供異地同步備份可用性的 DynamoDB 資料表，您可以輕鬆地將現有的資料表轉換為全域表，以利用多個區域。
1. [將您的單一區域 Amazon DynamoDB 資料表轉換為全域表](https://aws.amazon.com/blogs/aws/new-convert-your-single-region-amazon-dynamodb-tables-to-global-tables/)
1. 如果您的工作負載面臨 Application Load Balancers 或 Network Load Balancer，請使用 AWS Global Accelerator，透過將流量導向到多個包含運作狀態良好之端點的區域，來改善應用程式的可用性。
1. [AWS Global Accelerator - AWS Global Accelerator 中標準加速器的端點 (amazon.com)](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoints.html)
1. 對於利用 AWS EventBridge 的應用程式，請考慮跨區域匯流排，將事件轉送到您選取的其他區域。
1. [在 AWS 區域 之間傳送和接收 Amazon EventBridge 事件](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html)
1. 對於 Amazon Aurora 資料庫，請考慮跨越多個 AWS 區域的 Aurora 全球資料庫。您也可以修改現有的叢集來新增區域。
1. [Amazon Aurora 全球資料庫入門](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-getting-started.html)
1. 如果您的工作負載包括 AWS Key Management Service (AWS KMS ) 加密金鑰，請考慮多區域金鑰是否適合您的應用程式。
1. [AWS KMS 中的多區域金鑰](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
1. 如需其他 AWS 服務功能，請在下列一文參閱此部落格系列： [使用 AWS Services 系列建立多區域應用程式](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
**實作計劃的工作量： **中到高
## 資源
**相關文件：**
+ [使用 AWS Services 系列建立多區域應用程式](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [AWS 上的災難復原 (DR) 架構，第 IV 部分：多站點主動/主動](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)
+ [AWS 全球基礎設施](https://aws.amazon.com/about-aws/global-infrastructure)
+ [AWS Local Zones 常見問答集](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [AWS 上的災難復原 (DR) 架構，第 I 部分：在雲端中復原的策略](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [災難復原在雲端中有所不同](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-is-different-in-the-cloud.html)
+ [全域資料表：使用 DynamoDB 進行多區域複寫](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
**相關影片：**
+ [AWS re:Invent 2018：適用於多區域主動-主動應用程式的架構模式 (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Auth0：多區域高可用架構，可擴展至 1.5B\$1搭配自動容錯移轉的一個月登入](https://www.youtube.com/watch?v=vGywoYc_sA8)
**相關範例：**
+ [AWS 上的災難復原 (DR) 架構，第 I 部分：在雲端中復原的策略](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [DTCC 所達成的彈性程度遠超乎其在內部部署所能達到的](https://aws.amazon.com/solutions/case-studies/DTCC/)
+ [Expedia Group 使用多區域、多可用區域架構，搭配專有的 DNS 服務，為應用程式提高彈性](https://aws.amazon.com/solutions/case-studies/expedia/)
+ [使用者：多區域 Kafka 的災難復原](https://eng.uber.com/kafka/)
+ [Netflix：多區域彈性的主動-主動](https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b)
+ [我們如何為 Atlassian Cloud 建置資料彈性](https://www.atlassian.com/engineering/how-we-build-data-residency-for-atlassian-cloud)
+ [Intuit TurboTax 在兩個區域上執行](https://www.youtube.com/watch?v=286XyWx5xdQ)
# REL10-BP03 針對限制在單一位置的元件將復原自動化
如果工作負載的元件只能在單一可用區域或內部部署資料中心執行，您必須在定義的復原目標內實作完整重建工作負載的功能。
如果因為技術限制而無法實作將工作負載部署至多個位置的最佳實務，您必須實作彈性的替代路徑。您必須將以下能力自動化：重新建立必要基礎設施、重新部署應用程式，以及針對這些案例重新建立必要資料。
例如，Amazon EMR 會在相同可用區域中啟動指定叢集的所有節點，因為在相同區域執行叢集可以提供更高的資料存取速率，從而能提高任務流程的效能。如果為實現工作負載彈性而需要此元件，您必須要有方法重新部署叢集及其資料。此外，對於 Amazon EMR，您還應以異地同步備份以外的方式佈建冗餘。您可以佈建 [多個節點](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html)。使用 [EMR 檔案系統 (EMRFS)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html)時，EMR 中的資料可存放在 Amazon S3 中，然後可複寫至多個可用區域或 AWS 區域。
同樣地，對於 Amazon Redshift，它預設會將叢集佈建在您所選 AWS 區域內隨機選取的可用區域中。所有叢集節點都佈建在相同區域中。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 實作自我修復。盡可能使用 Automatic Scaling 來部署執行個體或容器。如果無法使用 Automatic Scaling，則對 EC2 執行個體使用自動復原，或者根據 Amazon EC2 或 ECS 容器生命週期事件實作自我修復自動化。
+ 對於不需要單個執行個體 IP 地址、私有 IP 地址、彈性 IP 地址和執行個體中繼資料的執行個體和容器工作負載，使用 Auto Scaling 群組。
+ [什麼是 EC2 自動擴展？](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [服務自動擴展](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ 啟動組態使用者資料可用於實作自動自我修復大多數工作負載。
+ 對於需要單個執行個體 IP 地址、私有 IP 地址、彈性 IP 地址和執行個體中繼資料的工作負載，使用 EC2 執行個體的自動復原。
+ [復原您的執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ 在偵測到執行個體失敗時，自動復原會將提醒傳送到 SNS 主題。
+ 在無法使用 Auto Scaling 或 EC2 復原的情況下，使用 EC2 執行個體生命週期事件或 ECS 事件自動執行自我修復。
+ [EC2 Auto Scaling 生命週期掛鉤](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Amazon ECS 事件](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ 使用事件來叫用自動化，以根據您所需的過程邏輯來修復您的元件。
## 資源
**相關文件：**
+ [Amazon ECS 事件](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ [EC2 Auto Scaling 生命週期掛鉤](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [復原您的執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [服務自動擴展](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ [什麼是 EC2 自動擴展？](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL10-BP04 使用隔板架構限制影響範圍
如同船舶上的隔板一樣，此模式可確保失敗限制在一小部分的請求或用戶端中，如此一來才能限制受損的請求數量，讓大部分的請求可以繼續運行，而不會發生錯誤。資料的隔板通常稱為分割區，而服務的隔板稱為儲存格。
在 *以儲存格為基礎的架構中*，每個儲存格都是完整的獨立服務執行個體，且具有固定的大小上限。隨著負載增加，工作負載會增加更多儲存格。分割區索引鍵用於傳入流量，以判斷使用哪個儲存格處理請求。任何失敗都會限制在它發生的單一儲存格之中，因此受損的請求數量會受到限制，而其他儲存格會繼續運行，且不會發生錯誤。務必要識別適當的分割區索引鍵，以最大程度地減少跨儲存格互動，並避免在每個請求中都加入複雜的對應服務。需要複雜對應的服務最終僅僅是將問題移轉到了對應服務，而需要跨儲存格互動的服務則會在儲存格之間建立相依性 (因此減低了假定的可用性改善)。
![\[圖表：顯示儲存格型架構\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/cell-based-architecture.png)
Colm MacCarthaigh 在他的 AWS 部落格文章中說明 Amazon Route 53 如何使用 [https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/) 將客戶請求隔離為分區。此案例中的分區包含兩個或更多個儲存格。根據分割區索引鍵，來自客戶 (或資源，或任何您想要隔離的項目) 的流量會路由至其指派的分區。如果有八個儲存格，每個分區為兩個儲存格，客戶會分割成四個分區，有 25% 的客戶會在發生問題時受到影響。
![\[圖表：顯示分為傳統分區的服務\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/service-divided-into-traditional-shards.png)
透過隨機切換分區，您可以建立每個都含有兩個儲存格的虛擬分區，並將您的客戶指派至其中一個虛擬分區。發生問題時，您仍可能會失去整個服務的四分之一，但透過此方式來指派客戶或資源，隨機切換分區的影響範圍遠小於 25%。若有八個儲存格，則會有 28 個含有兩個儲存格的獨特組合，這表示可能會有 28 個隨機切換分區 (虛擬分區)。如果您有數百或數千位客戶，並將每位客戶指派至一個隨機切換分區，則問題造成的影響範圍只有 1/28。這比一般分區好七倍。
![\[圖表：顯示分為切換分區的服務。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/service-divided-into-shuffle-shards.png)
除儲存格之外，分區還可用於伺服器、佇列或其他資源。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 使用隔板架構。如同船舶上的隔板一樣，此模式可確保失敗限制在一小部分的請求/使用者中，如此一來才能限制受損的請求數量，讓大部分的請求可以繼續運行，而不會發生錯誤。資料的隔板通常稱為分割區，而服務的隔板稱為儲存格。
+ [Well-Architected 實驗室：搭配隨機分片的故障隔離](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
+ [隨機切換分區：AWS re:Invent 2019：Amazon Builders’ Library 簡介 (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS re:Invent 2018：AWS 如何最大程度地減小故障的影響範圍 (ARC338)](https://youtu.be/swQbA4zub20)
+ 評估小組型架構是否適用於您的工作負載。在以儲存格為基礎的架構中，每個儲存格都是完整的獨立服務執行個體，且具有固定的大小上限。隨著負載增加，工作負載會增加更多儲存格。分割區索引鍵用於傳入流量，以判斷使用哪個儲存格處理請求。任何失敗都會限制在它發生的單一儲存格之中，因此受損的請求數量會受到限制，而其他儲存格會繼續運行，且不會發生錯誤。務必要識別適當的分割區索引鍵，以最大程度地減少跨儲存格互動，並避免在每個請求中都加入複雜的對應服務。需要複雜對應的服務最終僅僅是將問題移轉到了對應服務，而需要跨儲存格互動的服務則會降低儲存格的自主性 (因此提高了假定的可用性)。
+ Colm MacCarthaigh 在他的 AWS 部落格文章中說明 Amazon Route 53 如何使用隨機切換分區的概念，將客戶請求隔離為分區
+ [隨機分片：神奇的大型故障隔離](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
## 資源
**相關文件：**
+ [隨機分片：神奇的大型故障隔離](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
+ [Amazon Builders' Library：使用隨機切換分區隔離工作負載](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
**相關影片：**
+ [AWS re:Invent 2018：AWS 如何最大程度地減小故障的影響範圍 (ARC338)](https://youtu.be/swQbA4zub20)
+ [隨機切換分區：AWS re:Invent 2019：Amazon Builders’ Library 簡介 (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
**相關範例：**
+ [Well-Architected 實驗室：搭配隨機分片的故障隔離](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
# 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)
# REL 12 如何測試可靠性？
在將工作負載設計為可彈性應對生產壓力之後，測試是確保其依設計運作並交付您預期之彈性的唯一方法。
**Topics**
+ [REL12-BP01 使用程序手冊調查失敗](rel_testing_resiliency_playbook_resiliency.md)
+ [REL12-BP02 執行事件後分析](rel_testing_resiliency_rca_resiliency.md)
+ [REL12-BP03 測試功能要求](rel_testing_resiliency_test_functional.md)
+ [REL12-BP04 測試擴展和效能需求](rel_testing_resiliency_test_non_functional.md)
+ [REL12-BP05 使用混沌工程測試彈性](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL12-BP06 定期執行演練日](rel_testing_resiliency_game_days_resiliency.md)
# REL12-BP01 使用程序手冊調查失敗
透過在程序手冊中記錄調查程序，實現對無法充分理解的失敗情境進行快速一致的回應。程序手冊是為識別造成失敗情境的因素所執行的預先定義步驟。在確定或向上呈報問題之前，任何程序步驟的結果都用於確定要採取的後續步驟。
程序手冊是您必須進行的主動規劃，然後才能有效地採取回應動作。在生產環境中遇到程序手冊未涵蓋的故障情境時，請先解決問題 (解決燃眉之急)。然後返回並查看您為解決問題所採取的步驟，並使用這些步驟在程序手冊中新增新的項目。
請注意，程序手冊用於回應特定事件，而執行手冊則用於實現特定成果。執行手冊通常用於例行活動，而程序手冊則用於回應非例行事件。
**常用的反模式：**
+ 在不知道診斷問題或回應事件的程序之情況下，規劃部署工作負載。
+ 調查事件時，未規劃即決定要向哪些系統收集日誌和指標。
+ 指標和事件的保留時間過短，無法用以擷取資料。
**建立此最佳實務的優勢：** 擷取程序手冊可確保一致地遵循程序。有系統地編纂您的程序手冊可限制手動活動引入錯誤。程序手冊自動化可免除團隊成員介入的需要，或在介入開始時提供其他資訊，從而縮短事件回應時間。
**若未建立此最佳實務，暴露的風險等級為：** 高
## 實作指引
+ 使用程序手冊識別出問題。程序手冊是調查問題的書面程序。透過在程序手冊中記錄程序，對失敗情境做出一致且迅速的回應。程序手冊包含的資訊和指南必須能夠讓技能嫻熟的人員得以收集適用資訊、識別潛在的失敗來源、隔離故障，以及判斷成因 (執行事件後分析)。
+ 將程序手冊實作為程式碼。透過編寫程序手冊指令碼，以程式碼形式執行操作，確保一致性並限制和減少手動程序引起的錯誤。程序手冊可由多個指令碼組成，這些指令碼代表識別成因時可能需要的不同步驟。執行手冊活動可以作為程序手冊活動的一部分被觸發或執行，或者在程序手冊中提示執行，以回應已識別的事件。
+ [透過 AWS Systems Manager 自動化您的操作程序手冊](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [AWS Systems Manager Run Command](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)
## 資源
**相關文件：**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Run Command](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 執行事件後分析
審查影響客戶的事件，並識別成因和預防性行動項目。使用此資訊來開發緩解措施，以限制或防止事件再次發生。制定可快速有效回應的程序。適當地傳達成因和為目標受眾量身打造的糾正措施。建立一種可以根據需要將這些原因傳達給其他人的方法。
評估現有測試找不到問題的原因。如果測試尚未存在，請為此案例新增測試。
**常用的反模式：**
+ 尋找成因，但未繼續深入尋找其他潛在問題和減輕方法。
+ 僅確定人為錯誤原因，不未嘗試可防止人為錯誤發生的任何培訓或或自動化。
**建立此最佳實務的優勢：** 進行事件後分析並分享結果，以讓其他實作了相同成因的工作負載減輕風險，並讓工作負載能夠在事件發生前實作減輕措施或自動復原。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 建立事件後分析標準。良好的事件後分析提供了機會，為系統中其他地方使用的架構模式問題提出通用解決方案。
+ 確保成因真實且不責備相關人員。
+ 如果您不記錄問題，則無法糾正它們。
+ 確保事件後分析不會讓相關人員受到責備，這樣您就可以平心靜氣看待建議的糾正措施，並促進應用程式團隊誠實地自我評估與合作。
+ 使用程序判斷成因。建立程序來識別和記錄事件的成因，以便您可以制定緩解措施來限制或防止事件再次發生。另外，您還可以制定快速有效地做出回應的程序。適當地傳達成因和為目標受眾量身打造的糾正措施。
+ [什麼是日誌分析？](https://aws.amazon.com/log-analytics/)
## 資源
**相關文件：**
+ [什麼是日誌分析？](https://aws.amazon.com/log-analytics/)
+ [為什麼您應該開發錯誤糾正 (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
# REL12-BP03 測試功能要求
使用驗證所需功能的單位測試和整合測試等技術。
當這些測試做為建置和部署動作的一部分自動執行時，您會獲得最佳成果。例如，使用 AWS CodePipeline 時，開發人員會將變更遞交至來源儲存庫，而 CodePipeline 會在該儲存庫中自動偵測變更。系統會建置這些變更，並執行測試。測試完成後，會將內建的程式碼部署至預備伺服器以進行測試。CodePipeline 會從預備伺服器執行更多測試，例如整合或負載測試。成功完成這些測試後，CodePipeline 會將已測試及已核准的程式碼部署至生產執行個體。
此外，經驗顯示可執行和模擬客戶行為的綜合交易測試 (也稱為 *Canary 測試，*但請別與 Canary 部署混淆)，是最重要的測試程序之一。針對來自不同遠端位置的工作負載端點持續執行這些測試。Amazon CloudWatch Synthetics 讓您能夠 [建立 Canary，](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 以監控您的端點和 API。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 測試功能要求。這包括驗證所需功能的單位測試和整合測試。
+ [搭配使用 CodePipeline 與 AWS CodeBuild 以測試程式碼和執行建置](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [AWS CodePipeline 新增對於單位的支援，以及透過 AWS CodeBuild 自訂整合測試](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [持續交付與持續整合](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [使用 Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [軟體和測試自動化](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## 資源
**相關文件：**
+ [APN 合作夥伴：可以幫助實作持續整合管道的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=Continuous+Integration)
+ [AWS CodePipeline 新增對於單位的支援，以及透過 AWS CodeBuild 自訂整合測試](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [AWS Marketplace：可用於持續整合的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Continuous+integration)
+ [持續交付與持續整合](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [軟體和測試自動化](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [搭配使用 CodePipeline 與 AWS CodeBuild 以測試程式碼和執行建置](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [使用 Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
# REL12-BP04 測試擴展和效能需求
使用負載測試等技術，以驗證工作負載是否滿足擴展和效能需求。
在雲端，您可以隨需建立工作負載的生產規模測試環境。如果您在縮減的基礎設施上執行這些測試，您必須將觀察到的結果擴展到您認為在生產環境中會發生的情況。如果您很謹慎，力求不影響實際使用者，也可以在生產環境中執行負載和效能測試，並將您的測試資料加上標籤，以免與實際使用者資料混淆並損毀使用統計資料或生產報告。
透過測試，確保您的基本資源、擴展設定、服務配額和彈性設計能夠在負載下如預期運作。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 測試擴展和效能需求。進行負載測試，以驗證工作負載是否滿足擴展和效能需求。
+ [AWS 上的分散式負載測試：模擬數千名連線的使用者](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
+ 在與生產環境相同的環境中部署應用程式並執行負載測試。
+ 使用基礎設施即程式碼概念來建立與您的生產環境盡可能相似的環境。
## 資源
**相關文件：**
+ [AWS 上的分散式負載測試：模擬數千名連線的使用者](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
# REL12-BP05 使用混沌工程測試彈性
定期在位於或盡可能鄰近生產環境的環境中執行混沌試驗，以了解您的系統因應不良狀況的能力。
** 預期成果： **
除了以彈性測試驗證您的工作負載在某事件期間的已知預期行為以外，還可以藉由在錯誤注入試驗中套用混沌工程或注入非預期的負載，來定期驗證工作負載的彈性。結合混沌工程與彈性測試，您將可確信工作負載在經歷元件失敗後仍可存留，並且可在 (幾乎) 不受影響的情況下從非預期的中斷復原。
** 常見的反模式： **
+ 針對彈性進行設計，但未確認工作負載在錯誤發生時的整體運作情形。
+ 未曾在真實的情況和預期的負載下試驗。
+ 未將試驗視為程式碼或透過開發週期加以維護。
+ 未在 CI/CD 管道中與部署以外執行混沌試驗。
+ 在決定要以哪些錯誤進行試驗時，未使用過去的事故後分析。
** 建立此最佳實務的優勢：** 注入錯誤以驗證工作負載的彈性，可讓您確信在發生真正的錯誤時，彈性設計的復原程序將可發揮作用。
**未建立此最佳實務時的曝險等級：** 中
## 實作指引
混沌工程可讓您的團隊有能力以受控的方式，持續在服務供應商、基礎架構、工作負載和元件層級注入真實的中斷 (模擬)，且對客戶 (幾乎) 不會造成影響。它可讓您的團隊從錯誤中學習，並且觀察、測量及改善工作負載的彈性，以及驗證在事件發生時會引發提醒，且團隊會收到通知。
持續執行時，混沌工程可能會凸顯您工作負載中的缺陷，且若未解決，可能會對可用性與操作產生負面影響。
**注意**
混沌工程是在系統中進行試驗的專業領域，旨在建立對系統承受生產環境中紊亂情況的能力的信心。 [混沌工程的原則](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/2022-03-31/framework/images/fault-injection-simulator.png)
錯誤注入試驗也有數個第三方選項。其中包括開放原始碼工具，例如 [Chaos Toolkit](https://chaostoolkit.org/)，[Chaos Mesh](https://chaos-mesh.org/)和 [Litmus Chaos](https://litmuschaos.io/)，以及 Gremlin 之類的商業選項。為了擴展可在 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 執行壓力測試。
## 實作步驟
+ 決定要將哪些錯誤用於試驗。
評估您的工作負載設計是否有彈性。這類設計 (使用 [Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)的最佳實務建立的) 可根據重大相依性、過去的事件、已知問題和合規要求來衡量風險。列出要用來維護彈性的每個設計元素，及其依設計要減輕的錯誤。如需關於建立這類清單的詳細資訊，請參閱 [「營運準備度審查」白皮書，](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 中提供了 FMEA 的詳細說明](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5)。
+ 指派每個錯誤的優先順序。
請從粗略的分類開始著手，例如高、中或低。若要評估優先順序，請考量錯誤的頻率，以及失敗對整體工作負載的影響。
考量特定錯誤的頻率時，請分析此工作負載過去的資料 (如果可用)。如果無法使用，請使用在類似環境中執行的其他工作負載所包含的資料。
考量特定錯誤的影響時，錯誤的範圍愈大，通常影響就愈大。另請考量工作負載的設計和用途。例如，對執行資料轉換和分析的工作負載而言，存取來源資料存放區的能力至關重要。在此情況下，您應優先執行存取錯誤以及限流存取和延遲注入的試驗。
事故後分析是您了解失敗模式的頻率與影響的理想資料來源。
請使用指派的優先順序，決定要先以哪些錯誤進行試驗，以及要以何種順序開發新的錯誤注入試驗。
+ 對於您所執行的每個試驗，均應依循混沌工程和連續彈性飛輪操作。
![\[混沌工程和連續彈性飛輪的圖表，顯示「改善」、「穩定狀態」、「假設」、「執行試驗」和「驗證」等階段。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/chaos-engineering-flywheel.png)
+ 將穩定狀態定義為顯示出正常行為之工作負載的某種可測量輸出。
工作負載的運作若可靠且符合預期，就會呈現穩定狀態。因此，在定義穩定狀態前，請先驗證工作負載的運作狀態良好。穩定狀態不一定表示在錯誤發生時完全不會影響到工作負載，因為有特定百分比的錯誤可能會在可接受的限制內。穩定狀態是您在試驗期間將觀察到的基準，如果您在下一步定義的假設未符合預期，就會凸顯異常。
例如，支付系統的穩定狀態可定義為 300 TPS、成功率 99%、且來回時間為 500 毫秒的處理。
+ 形成關於工作負載將如何回應錯誤的假設。
良好的假設奠基於工作負載應如何減輕錯誤以維護穩定狀態。假設指出，在發生特定類型的錯誤時，系統或工作負載將持續保有穩定狀態，因為工作負載設有特定緩解機制。特定類型的錯誤和緩解機制應指定於假設中。
以下是可用於假設的範本 (但也接受其他措辭)：
**注意**
若 *特定錯誤* 發生， *工作負載名稱* 工作負載將 *說明緩解控制* 以維護 *業務或技術指標影響*。
例如：
+ 若 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 分鐘的資料庫讀取或寫入錯誤 (穩定狀態)。
+ 藉由注入錯誤來執行試驗。
試驗依預設應處於安全模式，並獲得工作負載的容許。如果您確知工作負載將失敗，請不要執行試驗。混沌工程應該用來尋找已知的未知或未知的未知。*已知的未知* 是指您知道，但未能完全了解的事物， *未知的未知* 則是指您不知道也未能完全了解的事物。對您確知已失效的工作負載執行試驗，將不會為您帶來新的見解。試驗應經過審慎規劃、具有明確的影響範圍，並且提供在非預期的錯亂發生時可供套用的回復機制。如果您的盡職調查顯示工作負載應可承受試驗，請繼續執行試驗。有數種選項可用來注入錯誤。對於 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 的各種試驗，另請參閱 [「將彈性和 Well-Architected 應用程式用於混沌工程」實驗室](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 中實作並執行的試驗。
**注意**
對於每一項試驗，您都應明確了解其範圍與影響。我們建議，錯誤應先在非生產環境中模擬，再於生產環境中執行。
試驗應在真實的負載下執行於生產環境中，且應使用 [金絲雀部署](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) 也稱為使用者金絲雀，是您在一般情況下應納入作為使用者代理的指標之一。[AWS FIS 的停止條件](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html) 被視為試驗範本的一部分受到支援，每個範本最多可啟用五個停止條件。
混沌的準則之一，是盡可能縮小試驗的範圍與影響：
儘管容許某些短期負面影響是必要的，但混沌工程師有責任和義務將試驗的副作用控制在最低限度。
驗證範圍和潛在影響的方法之一，是先在非生產環境中執行試驗，驗證停止條件的閾值在試驗期間會依預期啟動，且有可觀測性會捕捉例外狀況，而不是直接在生產環境中試驗。
執行錯誤注入試驗時，請驗證所有的責任方都會及時獲得通知。請與營運團隊、服務可靠性團隊和客戶支援等適當的團隊通訊，讓他們知道試驗將於何時執行，且預期會有何情況。請為這些團隊提供通訊工具，以便他們在試驗執行期間發現任何不利影響時發出通知。
您必須將工作負載及其基礎系統還原為原始的已知良好狀態。工作負載的彈性設計通常具有自癒能力。但某些錯誤設計或失敗的試驗可能會使您的工作負載處於非預期的失敗狀態。試驗結束時，您必須察覺到這一點，並還原工作負載和系統。透過 AWS FIS，您可以在動作參數內設定回復組態 (也稱為後置動作)。後置動作會將目標回復為動作執行前原有的狀態。無論是自動 (例如使用 AWS FIS) 還是手動，這些後續動作皆應為程序手冊的一部分，以說明如何偵測及處理失敗。
+ 驗證假設。
[混沌工程的原則](https://principlesofchaos.org/) 提供了下列關於如何驗證工作負載穩定狀態的指引：
著重於可測量的系統輸出，而不是系統的內部屬性。這類輸出在一段時間內的測量，會構成系統穩定狀態的代理。整體系統的輸送量、錯誤率和延遲百分位數，全都可能成為呈現穩定狀態行為的相關指標。著重於試驗期間的系統行為模式，混沌工程會驗證系統是否可運作，而非試著驗證其運作情形。
在先前的兩個範例中，我們納入了伺服器端 (5xx) 錯誤的增量低於 0.01% 的穩定狀態指標，以及資料庫讀取和寫入錯誤不到一分鐘的穩定狀態指標。
5xx 錯誤是工作負載的用戶端在失敗模式下將直接經歷的結果，因此可說是良好的指標。資料庫錯誤測量是錯誤的直接產物，因此有其效用，但應同時輔以用戶端影響測量，例如失敗的客戶請求或用戶端遇到的錯誤。此外，請在工作負載的用戶端直接存取的任何 API 或 URI 納入綜合監控 (也稱為使用者金絲雀)。
+ 改善工作負載設計的彈性。
如果未維持穩定狀態，請調查工作負載設計可經由哪些改進來減輕錯誤，運用 [AWS Well Architected 可靠性支柱的最佳實務](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)。如需其他指引和資源，請前往 [AWS Builder’s Library](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/)，以及其他主題。
這些變更實作完成後，請再次執行試驗 (在混沌工程飛輪中以虛線表示) 以判斷其有效性。若驗證步驟指出假設成立，則工作負載將處於穩定狀態，且週期會繼續。
+ 請定期執行試驗。
混沌試驗是一個週期，而試驗應被視為混沌工程的一部分定期執行。當工作負載符合試驗的假設後，即應將試驗自動化，以將其視為 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-BP06 定期執行演練日](rel_testing_resiliency_game_days_resiliency.md)) 建立持續整合/持續部署 (CI/CD) 管道。演練日會模擬失敗或事件，以驗證系統、程序和團隊的應變。目的是實際執行在異常事件發生時團隊將要執行的動作。
+ 擷取並儲存試驗結果。
錯誤注入試驗的結果必須擷取並保存。請納入所有必要資料 (例如時間、工作負載和條件)，以便後續能分析試驗結果和趨勢。舉例來說，結果可包括儀表板的螢幕擷取畫面、指標的資料庫產生的 CSV 傾印，或是試驗中的事件與觀察的手寫記錄。[AWS FIS 的試驗記錄](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html) 可作為此資料擷取的一部分。
## 資源
**相關的最佳實務：**
+ [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/)
+ [混沌試驗的金絲雀部署](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)
**相關範例：**
+ [Well-Architected 實驗室：第 300 級：測試 Amazon EC2、Amazon RDS 和 Amazon S3 的彈性](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
+ [「AWS 上的混沌工程」實驗室](https://chaos-engineering.workshop.aws/en/)
+ [「將彈性和 Well-Architected 應用程式用於混沌工程」實驗室](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US)
+ [「無伺服器混沌」實驗室](https://catalog.us-east-1.prod.workshops.aws/workshops/3015a19d-0e07-4493-9781-6c02a7626c65/en-US/serverless)
+ [「使用 AWS Resilience Hub 測量及改善您的應用程式彈性」實驗室](https://catalog.us-east-1.prod.workshops.aws/workshops/2a54eaaf-51ee-4373-a3da-2bf4e8bb6dd3/en-US/200-labs/1wordpressapplab)
** 相關工具： **
+ [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-BP06 定期執行演練日
使用演練日定期執行回應事件和失敗的程序，盡可能接近生產環境 (包括在生產環境中)，並與實際參與失敗情境的人員共同演練。在演練日當天強制執行措施，以確保生產事件不會影響使用者。
演練日模擬失敗或事件，以測試系統、流程和團隊的回應。目的是實際執行在異常事件發生時團隊將要執行的動作。如此可協助您了解何處有改善空間，並能協助發展組織處理活動的經驗。這些應該定期進行，以便您的團隊建置 *有關如何回應的* 肌肉記憶。
在彈性設計就緒，並已在非生產環境中進行測試之後，演練日就是確保生產中的一切按照計畫運作。演練日，特別是第一個演練日，是一個「全員參與」活動，工程師和操作人員會被告知何時發生，以及會發生什麼情況。執行手冊已就緒。以規定的方式在生產系統中執行模擬事件 (包括可能的失敗事件)，並評估影響。如果所有系統都如設計運作，偵測和自我修復將幾乎不會產生影響。不過，如果觀察到負面影響，測試會回復並視需要手動修復工作負載問題 (使用執行手冊)。由於演練日通常會在生產環境中進行，因此應採取所有預防措施，以確保不會對客戶的可用性造成影響。
**常用的反模式：**
+ 記載您的程序，但絕不練習程序。
+ 未在測試練習中納入業務決策者。
**建立此最佳實務的優勢：** 定期進行演練日可確保所有員工在發生實際事件時遵守政策和程序，並驗證這些政策和程序是否適當。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 安排演練日以定期練習您的執行手冊和程序手冊。演練日應納入生產事件發生時參與的每個人：企業擁有者、開發人員、營運人員和事件反應團隊。
+ 執行負載或效能測試，然後執行錯誤注入。
+ 尋找執行手冊上的異常情況，並尋找練習程序手冊的機會。
+ 如果您偏離了執行手冊，應優化執行手冊或更正該行為。如果您練習程序手冊，確定應使用的執行手冊，或建立一個新的執行手冊。
## 資源
**相關文件：**
+ [什麼是 AWS GameDay？](https://aws.amazon.com/gameday/)
**相關影片：**
+ [AWS re:Invent 2019：透過混沌工程提升彈性 (DOP309-R1)](https://youtu.be/ztiPjey2rfY)
**相關範例：**
+ [AWS Well-Architected 實驗室 - 測試彈性](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL 13 您如何規劃災難復原 (DR)？
備妥備份和冗餘工作負載元件是 DR 策略的開始。[RTO 和 RPO 是您還原](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) 工作負載的目標。根據業務需求設定這些目標。實作策略以滿足這些目標，考量工作負載資源和資料的位置和功能。發生中斷的可能性和復原成本也是重要因素，可反映為工作負載提供災難復原的商業價值。
**Topics**
+ [REL13-BP01 定義停機和資料遺失的復原目標](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02 使用定義的復原策略來滿足復原目標](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 測試災難復原實作以驗證實作](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 管理 DR 站點或區域的組態偏移](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05 自動化復原](rel_planning_for_recovery_auto_recovery.md)
# REL13-BP01 定義停機和資料遺失的復原目標
工作負載具有復原時間目標 (RTO) 和復原點目標 (RPO)。
*復原時間目標 (RTO)* 是服務中斷與恢復服務之間的最大可接受延遲。這會決定可接受的服務無法使用之時間長度。
*復原點目標 (RPO)* 是自上次資料復原點之後的最大可接受時間長度。這會決定最後一個復原點與服務中斷之間可接受的資料遺失。
在為您的工作負載選取適用的災難復原 (DR) 策略時，RTO 和 RPO 值是重要的考慮因素。這些目標是由企業決定，然後由技術團隊用來選取和實作 DR 策略。
**預期成果：**
每個工作負載都獲指派一個 RTO 和 RPO，其是根據業務影響來定義的。工作負載會指派給預先定義的層級，定義服務可用性和可接受的資料遺失，以及相關聯的 RTO 和 RPO。如果這類分層不可行，則可以根據工作負載以定制方式指派此分層，旨在稍後建立層級。RTO 和 RPO 會在選取工作負載的災難復原策略實作時的主要考量之一。挑選 DR 策略的其他考量是成本限制、工作負載相依性和營運要求。
對於 RTO，了解基於中斷持續時間的影響。它是線性的，還是有非線性的影響？(例如，四個小時後，您關閉了一條生產線，直到下一個輪班開始)。
如下的災難復原方法可以協助您了解工作負載關鍵性與復原目標之間的關係。(請注意，X 軸和 Y 軸的實際值應根據您的組織需求加以自訂)。
![\[圖表：顯示災難復原方法\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/disaster-recovery-matrix.png)
**常用的反模式：**
+ 沒有已定義的復原目標。
+ 選擇任意復原目標。
+ 選擇過於寬鬆且不符合業務目標的復原目標。
+ 不了解關機時間和資料遺失的影響。
+ 選取不切實際的復原目標，例如零時間復原和零資料遺失，這對於您的工作負載組態可能無法實現。
+ 選擇比實際業務目標更嚴格的復原目標。這會被迫進行比工作負載所需更昂貴和更複雜的 DR 實作。
+ 選取的復原目標與工作負載的復原目標不相容。
+ 您的復原目標未考慮法規合規性要求。
+ 已定義工作負載的 RTO 和 RPO，但從未進行測試。
**建立此最佳實務的優勢：** 需以時間和資料損失的復原目標來引導 DR 實作。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
對於給定的工作負載，您必須了解停機時間和資料遺失對您業務的影響。隨著停機時間或資料遺失的增加，影響會大幅地增長，但這種增長形式可能會根據工作負載類型而有所不同。例如，您可以容忍長達一小時的停機時間而影響不大，但在此之後影響會迅速加大。對業務的影響會以多種形式顯現，包括貨幣成本 (例如收益損失)、客戶信任 (以及對信譽的影響)、營運問題 (例如發不出薪資或生產力下降)，以及監管風險。使用下列步驟來了解這些影響，並為您的工作負載設定 RTO 和 RPO。
**實作步驟**
1. 確定此工作負載的業務利害關係人，並與他們一起實作這些步驟。工作負載的復原目標是業務決策。然後，技術團隊與業務利害關係人合作，使用這些目標來選取 DR 策略。
**注意**
針對步驟 2 和 3，您可以使用 [實作工作表](#implementation-worksheet)。
1. 收集必要資訊，藉由回答下列問題來做出決策。
1. 對於組織中的工作負載影響，您是否具有關鍵性的類別或層級？
1. 若是，請將此工作負載指派給類別。
1. 若否，請建立這些類別。建立五個或更少的類別，然後縮小每個類別的復原時間目標範圍。範例類別包括：重大、高、中、低。若要了解工作負載如何對應至類別，請考慮工作負載是任務為主、業務為主，還是非業務推動。
1. 根據類別設定工作負載 RTO 和 RPO。一律選擇比進入此步驟所計算的原始值更嚴格的類別 (更低的 RTO 和 RPO)。如果這導致值發生不適當的大變更，則考慮建立一個新類別。
1. 根據這些答案，將 RTO 和 RPO 指派給工作負載。這可以直接完成，也可以透過將工作負載指派給預先定義的服務層來完成。
1. 在工作負載團隊和利害關係人可存取的位置記錄此工作負載的 [災難復原計劃 (DRP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)，這是貴組織業務持續性計劃 (BCP) 的一部分。
1. 記錄 RTO 和 RPO，以及用來決定這些值的資訊。包括用於評估對業務之工作負載影響的策略。
1. 記錄除 RTO 和 RPO 之外的其他指標，您是否正在追蹤或規劃追踨災難復原目標。
1. 建立 DR 策略和執行手冊的詳細資訊時，會將這些資訊新增至此計劃。
1. 藉由在如圖 15 所示的矩陣中查看工作負載的關鍵性，您可以開始建立針對組織定義的預先定義服務層。
1. 在您根據 實作了 DR 策略 (或 DR 策略的概念證明) 之後[REL13-BP02 使用定義的復原策略來滿足復原目標](rel_planning_for_recovery_disaster_recovery.md)，請測試此策略以判定工作負載的實際 RTC (復原時間能力) 和 RPC (復原點能力)。如果這些不符合目標復原目標，則可與您的業務利害關係人合作，一起調整這些目標，或可對 DR 策略進行變更以符合目標。
**主要問題**
1. 在對業務產生嚴重影響之前，工作負載可以關閉的時間上限
1. 如果工作負載中斷，請判定每分鐘對業務造成的貨幣成本 (直接財務影響)。
1. 考慮到影響並非總是線性的。一開始影響可能會受到限制，然後在超過關鍵時間點後迅速增加。
1. 在對業務產生嚴重影響之前，可以遺失的資料量上限
1. 考慮將此值用於您最關鍵的資料存放區。識別其他資料存放區的各自關鍵性。
1. 如果遺失工作負載資料，可以重建嗎？ 如果在操作上這樣做比備份和還原更容易，則根據用來重建工作負載資料之來源資料的關鍵性來選擇 RPO。
1. 依賴下游游相依性的工作負載或依賴上游相依性的工作負載，其復原目標和可用性期望是什麼？
1. 選擇可讓此工作負載符合上游相依性要求的復原目標
1. 鑑於下游相依性的復原能力，選擇可實現的復原目標。可以執行非關鍵的下游相依性 (您可以「解決」的相依性)。或者，使用關鍵的下游相依性，在必要時改善其復原能力。
**其他問題**
考慮這些問題，以及它們如何套用至這個工作負載：
1. 您是否有不同的 RTO 和 RPO，取決於中斷的類型 (區域與可用區域等)？
1. 您的 RTO/RPO 是否會在特定時間 (季節性、銷售活動、產品發佈) 發生變化？ 若是，有什麼不同的測量和時間界限？
1. 如果工作負載中斷，有多少客戶會受到影響？
1. 如果工作負載中斷，對信譽有何影響？
1. 如果工作負載中斷，可能會發生哪些其他營運影響？ 例如，如果電子郵件系統無法使用，或如果薪資系統無法提交交易，則會影響員工的生產力。
1. 工作負載 RTO 和 RPO 如何與業務線和組織 DR 策略保持一致？
1. 是否有提供服務的內部合約義務？ 未符合它們時會受到處罰嗎？
1. 資料的法規或合規限制是什麼？
## 實作工作表
您可以將此工作表用於實作步驟 2 和 3。您可以調整此工作表以滿足您的特定需求，例如新增其他問題。
![\[工作表\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/worksheet.png)
**實作計劃的工作量： **低
## 資源
**相關的最佳實務：**
+ [REL09-BP04 定期執行資料復原以驗證備份的完整性和程序](rel_backing_up_data_periodic_recovery_testing_data.md)
+ [REL13-BP02 使用定義的復原策略來滿足復原目標](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 測試災難復原實作以驗證實作](rel_planning_for_recovery_dr_tested.md)
**相關文件：**
+ [AWS 架構部落格：災難復原系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS 上工作負載的災難復原：在雲端中復原 (AWS 白皮書)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [使用 AWS Resilience Hub 管理彈性政策](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [APN 合作夥伴：可以幫助災難復原的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace：可用於災難復原的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**相關影片：**
+ [AWS re:Invent 2018：適用於多區域主動-主動應用程式的架構模式 (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS 上工作負載的災難復原](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02 使用定義的復原策略來滿足復原目標
定義一個符合工作負載復原目標的災難復原 (DR) 策略。選擇如下策略：備份與還原；待命 (主動/被動)；或是主動/主動。
如果您的主要位置變成無法執行工作負載，則災難復原策略會依賴在復原站點中支持您工作負載的能力。最常見的復原目標為 RTO 和 RPO，其討論在 [REL13-BP01 定義停機和資料遺失的復原目標](rel_planning_for_recovery_objective_defined_recovery.md)。
單一 AWS 區域 內跨多個可用區域 (AZ) 的 DR 策略可以緩解火災、洪水和重大停電等災難事件。如果需要實作保護，以防範阻止您的工作負載在給定 AWS 區域 中執行且不太可能發生的事件，您可以使用一個使用多個區域的 DR 策略。
在跨多個區域架構 DR 策略時，您應該選擇下列其中一個策略。這些策略按成本和複雜度遞增的順序列出，以及按 RTO 和 RPO 的遞減順序列出。 *復原區域* 稱為 AWS 區域，而不是用於工作負載的主要區域。
![\[圖表：顯示 DR 策略\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/disaster-recovery-strategies.png)
+ **備份與恢復** (RPO 幾小時，RTO 24 小時以內)：將您的資料和應用程式備份至復原區域。使用自動或連續備份將啟用時間點復原，在某些情況下可以將 RPO 降低至 5 分鐘。如果發生災難，您將部署您的基礎設施 (使用基礎設施架構即程式碼來減少 RTO)、部署您的程式碼，並還原備份的資料以從復原區域中的災難中復原。
+ **指示燈** (RPO 幾分鐘，RTO 幾十分鐘)：在復原區域中佈建核心工作負載基礎設施的副本。將您的資料複寫到復原區域並在該處建立其備份。支援資料複寫和備份所需的資源 (例如資料庫和物件儲存) 始終處於開啟狀態。其他元素 (例如應用程式伺服器或無伺服器運算) 未部署，但可在需要時使用必要的組態和應用程式碼建立。
+ **暖待命** (RPO 幾秒鐘，RTO 幾分鐘)：維持工作負載的縮減但完整功能版本，該工作負載始終在復原區域中執行。業務關鍵系統會完全複製且持續開啟，但叢集會縮小。資料會被複寫並存在於復原區域中。當需要復原時，系統會迅速擴展以處理生產負載。熱待命的縱向擴增越多，對 RTO 和控制平面的依賴就越低。完全擴展時，稱之為 **熱待命**。
+ **多區域 (多站點) 主動-主動** (RPO 近乎零，RTO 可能為零) 您的工作負載會部署至多個 AWS 區域，並主動處理來自多個 AWS 區域 的流量。此策略需要您跨區域同步資料。必須避免或處理在兩個不同區域複本中寫入同一記錄所引起的可能衝突，這可能很複雜。資料複寫對於資料同步很有用，而且可以保護您防範某些類型的災難，但它不能保護您防範資料損毀或破壞，除非您的解決方案也包括時間點復原的選項。
**注意**
指示燈和暖待命之間的差異有時可能很難理解。這兩者都在您的復原區域中包含一個環境，其中具有主要區域資產的副本。區別在於，若未先採取額外動作，指示燈無法處理請求，而暖待命可以立即處理流量 (容量層級降低)。指示燈將需要您開啟伺服器，可能會部署額外 (非核心) 基礎設施並縱向擴展，而暖待命只需要您縱向擴展 (一切都已部署並執行中)。根據您的 RTO 和 RPO 需求在這兩者之間進行選擇。
**預期成果：**
對於每個工作負載，都有一個已定義和實作的 DR 策略，讓該工作負載能夠實現 DR 目標。工作負載之間的 DR 策略會利用可重複使用模式 (例如上述策略)。
**常用的反模式：**
+ 針對具有類似 DR 目標的工作負載實作不一致的復原程序。
+ 災難發生時臨時實作 DR 策略。
+ 沒有 DR 計劃。
+ 復原期間依賴控制平面操作。
**建立此最佳實務的優勢：**
+ 使用定義的復原策略可讓您使用常用的工具和測試程序。
+ 使用定義的復原策略可讓您更有效地在團隊之間分享知識，並更輕鬆地在他們擁有的工作負載上實作 DR。
**若未建立此最佳實務，暴露的風險等級為：** 高
+ 若沒有事先規劃、實作和測試災難復原策略，您就不可能在發生災難時實現復原目標。
## 實作指引
對於其中每一個步驟，請參閱下列詳細資訊。
1. 確定將滿足此工作負載之復原要求的 DR 策略。
1. 審查如何實作所選 DR 策略的模式。
1. 評估工作負載的資源，以及在容錯移轉之前 (在正常操作期間) 其哪個組態將位於復原區域中。
1. 確定並實作如何在需要時 (在災難事件期間) 使您的復原區域為容錯移轉做好準備。
1. 確定並實作如何在需要時 (在災難事件期間) 將流量路由至容錯移轉。
1. 設計您的工作負載將如何復原的計劃。
**實作步驟**
1. **確定將滿足此工作負載之復原要求的 DR 策略。**
選擇 DR 策略是在減少停機時間和資料遺失 (RTO 和 RPO) 與實作策略的成本和復雜性之間進行取捨。您應該避免實作比其所需更嚴格的策略，因為這會產生不必要的成本。
例如，在下圖中，企業已確定其最大允許的 RTO 以及其可以在服務還原策略上花費的限制。鑑於業務目標，DR 策略指示燈或暖待命將同時滿足 RTO 和成本準則。
![\[圖形：顯示根據 RTO 和成本選擇 DR 策略\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/choosing-a-dr-strategy.png)
若要深入了解，請參閱 [業務持續性計劃 (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)。
1. **審查如何實作所選 DR 策略的模式。**
此步驟在於了解您將如何實作所選策略。使用 AWS 區域 做為主要站點和復原站點來解釋這些策略。不過，您也可以選擇使用單一區域內的可用區域，做為您的 DR 策略，這會利用其中多個策略的元素。
在此步驟之後的後續步驟中，您會將此策略套用至您的特定工作負載。
**備份與恢復**
*備份與恢復* 是最不複雜的實作策略，但需要更多時間和精力來還原工作負載，從而導致更高的 RTO 和 RPO。始終對資料進行備份並將其複製到另一個站點 (例如另一個 AWS 區域) 是一種很好的做法。
![\[圖表：顯示備份和還原架構\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/backup-restore-architecture.png)
如需此策略的詳細資訊，請參閱 [AWS 上的災難復原 (DR) 架構，第 II 部分：具有快速復原的備份和還原](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/)。
**指示燈**
使用 *指示燈* 方法，您可以將資料從主要區域複寫至復原區域。用於工作負載基礎設施的核心資源會部署在復原區域中，不過，仍需要額外的資源和任何相依性，才能使其成為功能堆疊。例如，在圖 20 中，未部署任何運算執行個體。
![\[圖表：顯示指示燈架構\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/pilot-light-architecture.png)
如需此策略的詳細資訊，請參閱 [AWS 上的災難復原 (DR) 架構，第 III 部分：指示燈和暖待命](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)。
**暖待命**
AWS Well-Architected *基礎架構* 方法涉及確保在另一個區域中有一個縮減規模，但功能完全的生產環境副本。這種方法擴充了指示燈概念並減少了復原時間，因為您的工作負載始終在另一個區域中開啟。如果部署完整容量的復原區域，這稱為 *熱待命*。
![\[顯示圖 21 的圖表：暖待命架構\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/warm-standby-architecture.png)
使用暖待命或指示燈需要縱向擴展復原區域中的資源。若要確保需要時容量可用，請考慮針對 [EC2 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) 使用容量保留。如果使用 AWS Lambda，則 [佈建的並行](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) 可以確保執行環境，以便它們準備好立即回應您的函數叫用。
如需此策略的詳細資訊，請參閱 [AWS 上的災難復原 (DR) 架構，第 III 部分：指示燈和暖待命](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)。
**多站點主動/主動**
您可以同時在多個區域中執行工作負載，做為 *多站點主動/主動* 策略。多站點主動/主動會為來自其部署至的所有區域的流量提供服務。基於 DR 以外的理由，客戶可能會選取此策略。它可以用來提高可用性，或在將工作負載部署至全球對象 (使端點更靠近使用者和/或將本地化的堆疊部署到該區域的對象) 時使用它。作為 DR 策略，如果工作負載無法在其部署至的其中一個 AWS 區域中得到支援，則會撤離該區域，而其餘區域則會用來維護可用性。多站點主動/主動是災難復原策略中操作最複雜的策略，因此只有在業務要求有此需要時才應選取它。
![\[圖表：顯示多站點主動/主動架構\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/multi-site-active-active-architecture.png)
如需此策略的詳細資訊，請參閱 [AWS 上的災難復原 (DR) 架構，第 IV 部分：多站點主動/主動](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)。
**其他保護資料的做法**
使用所有策略時，您還必須緩解資料災難。持續資料複寫可以保護您防範某些類型的災難，但它不能保護您防範資料損毀或破壞，除非您的策略也包括所存放資料的版本控制，或時間點復原的選項。除了複本之外，您還必須備份復原站點中的複寫資料，以建立時間點備份。
**在單一 AWS 區域 內使用多個可用區域 (AZ)**
在單一區域內使用多個 AZ 時，您的 DR 實作會使用上述策略的多個元素。首先，您必須建立高可用性 (HA) 架構，使用多個 AZ，如圖 23 所示。此架構會利用多站點主動/主動方法，因為 [Amazon EC2 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) 和 [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) 已在多個 AZ 中部署資源，主動處理請求。架構也會示範熱待命，其中如果主要 [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) 執行個體失敗 (或 AZ 本身失敗)，則待命執行個體會提升至主要執行個體。
![\[顯示圖 23 的圖表：異地同步備份架構\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/multi-az-architecture2.png)
除了這種 HA 架構之外，您還需要新增執行工作負載所需之所有資料的備份。這對於受制於單一區域的資料尤其重要，例如 [Amazon EBS 磁碟區](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) 或 [Amazon Redshift 叢集](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html)。如果 AZ 失敗，您需要將此資料還原至另一個 AZ。可能的話，您也應該將資料備份複製到另一個 AWS 區域，做為額外的保護層。
下列部落格文章中描述了一種不太常見的單一區域替代方法 (異地同步備份 DR)： [使用 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/)。在這裡，策略是盡可能地在 AZ 之間保持隔離，就像區域的操作方式一樣。使用這種替代策略，您可以選擇主動/主動或主動/被動方法。
注意：某些工作負載具有法規資料落地要求。如果在目前只有一個 AWS 區域的區域性中，這適用於您的工作負載，則多區域將不適合您的業務需求。異地同步備份策略提供良好的保護，可防範大部分災難。
1. **評估工作負載的資源，以及在容錯移轉之前 (在正常操作期間) 其哪個組態將位於復原區域中。**
對於基礎設施和 AWS 資源，使用基礎設施即程式碼，例如 [AWS CloudFormation](https://aws.amazon.com/cloudformation) ，或使用第三方工具，例如 Hashicorp Terraform。若要使用單一作業跨多個帳戶和區域進行部署，您可以使用 [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)。對於多站點主動/主動和熱待命策略，您的復原區域中部署的基礎設施具有與您主要區域相同的資源。對於指示燈和暖待命策略，部署的基礎設施將需要額外的動作，才能為生產做好準備。使用 CloudFormation [參數](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) 和 [條件式邏輯](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html)，您可以使用單一範本控制部署的堆疊是主動還是待命。這類 CloudFormation 範本的範例包含在 [這篇部落格文章](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)。
所有 DR 策略都要求在 AWS 區域內備份資料來源，然後將這些備份複製到復原區域。[AWS Backup](https://aws.amazon.com/backup/) 提供了一個集中檢視，您可以在其中設定、排定和監控這些資源的備份。對於指示燈、暖待命和多站點主動/主動，您還應該將資料從主要區域複寫到復原區域中的資料資源，例如 [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds) 資料庫執行個體或 [Amazon DynamoDB](https://aws.amazon.com/dynamodb) 資料表。因此，這些資料資源是即時的，而且可以為復原區域中的請求提供服務。
若要深入了解 AWS 服務如何跨區域操作，請參閱此部落格系列，其位於 [使用 AWS Services 建立多區域應用程式](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)。
1. **確定並實作如何在需要時 (在災難事件期間) 使您的復原區域為容錯移轉做好準備。**
對於多站點主動/主動，容錯移轉意味著撤離一個區域，並依賴剩餘的主 動區域。通常，這些區域已準備好接受流量。對於指示燈和暖待命策略，您的復原動作將需要部署遺漏的資源，例如圖 20 中的 EC2 執行個體，以及任何其他遺漏的資源。
對於上述所有策略，您可能需要提升資料庫的唯讀執行個體，以變成主要讀取/寫入執行個體。
對於備份和還原，從備份還原資料會為該資料建立資源，例如 EBS 磁碟區、RDS 資料庫執行個體和 DynamoDB 資料表。您也需要還原基礎設施和部署程式碼。您可以使用 AWS Backup，還原復原區域中的資料。請參閱 [REL09-BP01 識別並備份所有需要備份的資料，或從來源複製資料](rel_backing_up_data_identified_backups_data.md) 以取得詳細資訊。重建基礎設施包括建立 EC2 執行個體之類的資源，還有 [Amazon Virtual Private Cloud (Amazon VPC))](https://aws.amazon.com/vpc)、子網路，以及所需的安全群組。您可以將大部分還原程序自動化。若要了解做法，請參閱 [這篇部落格文章](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/)。
1. **確定並實作如何在需要時 (在災難事件期間) 將流量路由至容錯移轉。**
此容錯移轉作業可以自動或手動啟動。應謹慎使用根據運作狀態檢查或警示自動啟動的容錯移轉，因為不必要的容錯移轉 (誤報) 會產生非可用性和資料遺失等成本。因此通常使用手動啟動的容錯移轉。在此情況下，您仍應將容錯移轉的步驟自動化，讓手動啟動就像按下按鈕一樣簡易。
使用 AWS 服務時，有數個流量管理選項需要考慮。其中一個選項是使用 [Amazon Route 53](https://aws.amazon.com/route53)。使用 Amazon Route 53，您可以將一個或多個 AWS 區域中的 IP 端節與一個 Route 53 網域名稱建立關聯。若要實作手動啟動的容錯移轉，您可以使用 [Amazon Route 53 應用程式復原控制器](https://aws.amazon.com/route53/application-recovery-controller/)，其會提供一個高度可用的資料平面 API，將流量重新路由到復原區域。實作容錯移轉時，使用資料平面作業並避免控制平面作業，其描述在 [REL11-BP04 復原期間需使用資料平面，而非控制平面](rel_withstand_component_failures_avoid_control_plane.md)。
若要深入了解這個和其他選項，請參閱 [災難復原白皮書的這一節](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light)。
1. **設計您的工作負載將如何復原的計劃。**
復原是指在災難事件減弱後將工作負載操作回復到主要區域。將基礎設施和程式碼佈建到主要區域通常遵循最初使用的相同步驟，依賴基礎設施即程式碼和程式碼部署管道。復原的挑戰是還原資料存放區，並確保它們與操作中的復原區域保持一致。
在容錯移轉狀態下，復原區域中的資料庫是即時的並具有最新資料。後續目標是從復原區域重新同步到主要區域，確保它是最新的。
有些 AWS 服務將會自動執行此動作。如果使用 [Amazon DynamoDB 全域資料表](https://aws.amazon.com/dynamodb/global-tables/)，即使主要區域中的資料表變成無法可用，則當它重新上線時，DynamoDB 仍會繼續傳播任何擱置的寫入。如果使用 [Amazon Aurora 全球資料庫](https://aws.amazon.com/rds/aurora/global-database/) 和使用 [受管規劃容錯移轉](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover)，則會維護 Aurora 全球資料庫的現有複寫拓撲。因此，主要區域中先前的讀取/寫入執行個體將成為複本，並從復原區域中接收更新。
如果這不是自動的，您將需要在主要區域中重建資料庫，做為復原區域中資料庫的複本。在許多情況下，這將涉及刪除舊的主要資料庫並建立新的複本。例如，如需如何在假設非計劃容錯移轉的情況下使用 Amazon Aurora *全球資料庫* 執行此動作的指示，請參閱此實驗室： [復原全球資料庫](https://awsauroralabsmy.com/global/failback/)。
容錯移轉後，如果您可以繼續在復原區域中執行，請考慮使其成為新的主要區域。您仍會執行上述所有步驟，使先前的主要區域成為復原區域。有些組織會執行排程輪換，定期 (例如每三個月) 交換其主要區域和復原區域。
容錯移轉和復原所需的所有步驟都應保持在可供所有團隊成員使用的程序手冊中，並定期進行審查。
**實作計劃的工作量**：高
## 資源
**相關的最佳實務：**
+ [REL09-BP01 識別並備份所有需要備份的資料，或從來源複製資料](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 復原期間需使用資料平面，而非控制平面](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL13-BP01 定義停機和資料遺失的復原目標](rel_planning_for_recovery_objective_defined_recovery.md)
**相關文件：**
+ [AWS 架構部落格：災難復原系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS 上工作負載的災難復原：在雲端中復原 (AWS 白皮書)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [雲端中的災難復原選項](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)
+ [一小時建置無伺服器的多區域、主動-主動後端解決方案](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [多區域無伺服器後端 - 重新載入](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0)
+ [RDS：跨區域複寫僅供讀取複本](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn)
+ [Route 53：設定 DNS 備援](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [S3：跨區域複寫](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html)
+ [什麼是 AWS Backup？](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [什麼是 Route 53 應用程式復原控制器？](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS 彈性災難復原](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [HashiCorp Terraform：入門 - AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started)
+ [APN 合作夥伴：可以幫助災難復原的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace：可用於災難復原的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**相關影片：**
+ [AWS 上工作負載的災難復原](https://www.youtube.com/watch?v=cJZw5mrxryA)
+ [AWS re:Invent 2018：適用於多區域主動-主動應用程式的架構模式 (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS 彈性災難復原入門 \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
**相關範例：**
+ [AWS Well-Architected 實驗室 - 災難復原](https://wellarchitectedlabs.com/reliability/disaster-recovery/) - 說明 DR 系列的研討會系列
# REL13-BP03 測試災難復原實作以驗證實作
定期測試容錯移轉到您的復原站點以確保正常操作，並符合 RTO 和 RPO。
要避免的模式是：開發鮮少執行的復原路徑。例如，您可能有一個次要資料存放區，只供唯讀查詢之用。當您寫入資料存放區而主資料存放區發生故障時，您可能需要容錯移轉到次要資料存放區。如果您不經常測試此容錯移轉，則可能會發現您對次要資料存放區的功能的假設不正確。次要資料存放區的容量 (在您上次測試時可能已經足夠) 在這種情況下可能無法再容忍負載。我們的經驗顯示，唯一能發揮功用的錯誤復原，是您經常測試的路徑。因此，最好擁有少量的復原路徑。您可建立復原模式，並定期進行測試。若擁有複雜或關鍵復原路徑，您還是需要定期在生產環境中執行該故障，說服自己該復原路徑能發揮功用。在我們剛剛討論的範例中，無論是否需要，您都應定期容錯移轉到備用資料庫。
**常用的反模式：**
+ 切勿在生產環境中執行容錯移轉。
**建立此最佳實務的優勢：** 定期測試您的災難復原計畫，可確保該計畫能在需要時運作，也能讓您的團隊知道如何執行策略。
**若未建立此最佳實務，暴露的風險等級為：** 高
## 實作指引
+ 為復原設計您的工作負載。定期測試您的復原路徑：復原導向運算 (ROC) 可識別系統中能增強復原能力的特性。這些特性包括：隔離和冗餘，系統範圍內的回復變更能力，監控和確定運行狀態的能力，提供診斷、自動復原和模組化設計的能力，以及重新啟動的能力。練習復原路徑，以確保您可以在指定時間內完成復原到指定狀態。在復原過程中使用您的執行手冊，以記錄問題並在下一次測試前找出其解決方案。
+ [柏克萊加州大學/史丹佛大學復原導向的運算專案](http://roc.cs.berkeley.edu/)
+ 使用 CloudEndure Disaster Recovery 實作和測試您的 DR 策略。
+ [透過 CloudEndure 測試災難復原解決方案](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [AWS 的 CloudEndure Disaster Recovery](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
## 資源
**相關文件：**
+ [APN 合作夥伴：可以幫助災難復原的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS 架構部落格：災難復原系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace：可用於災難復原的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [AWS 上工作負載的災難復原：在雲端中復原 (AWS 白皮書)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [透過 CloudEndure 測試災難復原解決方案](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [柏克萊加州大學/史丹佛大學復原導向的運算專案](http://roc.cs.berkeley.edu/)
+ [什麼是 AWS Fault Injection Simulator？](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**相關影片：**
+ [AWS re:Invent 2018：適用於多區域主動-主動應用程式的架構模式 (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019：使用 AWS 的備份與還原和災難復原解決方案 (STG208)](https://youtu.be/7gNXfo5HZN8)
**相關範例：**
+ [AWS Well-Architected 實驗室 - 測試彈性](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL13-BP04 管理 DR 站點或區域的組態偏移
確保根據需要在 DR 站點或區域提供基礎設施、資料和組態。例如，檢查 AMI 和服務配額是否為最新版本。
AWS Config 會持續監控和記錄 AWS 資源組態。它可以偵測偏移，並觸發 [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 修正並引發警示。AWS CloudFormation 可額外偵測您已部署之堆疊中的偏移。
**常用的反模式：**
+ 當您在主要位置進行組態或基礎設施變更時，無法在復原位置進行更新。
+ 未考量主要和復原位置中潛在的限制 (例如服務差異)。
**建立此最佳實務的優勢：** 確保 DR 環境與現有環境一致，便可保證完整復原。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 確保您的交付管道同時交付到主要站點和備份站點。用於將應用程式部署到生產中的交付管道，應分發到所有指定的災難復原策略位置，包括開發和測試環境。
+ 啟用 AWS Config 追蹤潛在的偏移位置。使用 AWS Config 規則建立系統，以執行災難復原策略，並在發現偏移時產生提醒。
+ [依 AWS Config 規則 修補不合規的 AWS 資源](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ 使用 AWS CloudFormation 偵測您的基礎設施。AWS CloudFormation 可以偵測 CloudFormation 範本指定項目與實際部署項目之間的偏移。
+ [AWS CloudFormation：在整個 CloudFormation 堆疊上偵測偏移](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
## 資源
**相關文件：**
+ [APN 合作夥伴：可以幫助災難復原的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS 架構部落格：災難復原系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS CloudFormation：在整個 CloudFormation 堆疊上偵測偏移](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [AWS Marketplace：可用於災難復原的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS 上工作負載的災難復原：在雲端中復原 (AWS 白皮書)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [如何在 AWS 上實作基礎設施組態管理解決方案？](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected)
+ [依 AWS Config 規則 修補不合規的 AWS 資源](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**相關影片：**
+ [AWS re:Invent 2018：適用於多區域主動-主動應用程式的架構模式 (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
# REL13-BP05 自動化復原
使用 AWS 或第三方工具自動化系統復原，並將流量路由到 DR 站點或區域。
根據設定的運作狀態檢查，Elastic Load Balancing 和 AWS Auto Scaling 等 AWS 服務可將負載分散到運作狀態良好的可用區域，而 Amazon Route 5、AWS 和 Global Accelerator 等服務則可將負載路由到運作狀態良好的 AWS 區域。Amazon Route 53 應用程式復原控制器可協助您使用準備度檢查和路由控制功能，來管理和協調容錯移轉。這些功能會持續監控應用程式從失敗中復原的功能，以便您跨多個 AWS 區域、可用區域和內部部署來控制應用程式復原。
對於現有實體或虛擬資料中心或私有雲端上的工作負載， [AWS 彈性災難復原](https://aws.amazon.com/cloudendure-disaster-recovery/)(可透過 AWS Marketplace 取得) 可讓組織設定 AWS 的自動化災難復原策略。CloudEndure 也支援 AWS 中的跨區域/跨可用區域災難復原。
**常用的反模式：**
+ 實作相同的自動化容錯移轉和容錯回復會在失敗發生時導致翻動。
**建立此最佳實務的優勢：** 自動化復原可以消除手動錯誤的機會，減少您的復原時間。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
+ 自動化復原路徑。若復原時間較短，則人為判斷和行動無法用於可用性高的方案。系統應在每種情況下都能自動復原。
+ 使用 CloudEndure Disaster Recovery 進行自動化容錯移轉和容錯回復：CloudEndure Disaster Recovery 會持續將您的機器 (包括作業系統、系統狀態組態、資料庫、應用程式和檔案) 複寫至您的目標 AWS 帳戶和慣用區域中的低成本階段區域。發生災難時，您可以指示 CloudEndure Disaster Recovery 在數分鐘內自動啟動處於完全佈建狀態的數千部機器。
+ [執行災難復原容錯移轉和退回](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Performing_a_Disaster_Recovery_Failover/Performing_a_Disaster_Recovery_Failover.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
## 資源
**相關文件：**
+ [APN 合作夥伴：可以幫助災難復原的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS 架構部落格：災難復原系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace：可用於災難復原的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS 的 CloudEndure Disaster Recovery](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
+ [AWS 上工作負載的災難復原：在雲端中復原 (AWS 白皮書)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
**相關影片：**
+ [AWS re:Invent 2018：適用於多區域主動-主動應用程式的架構模式 (ARC209-R2)](https://youtu.be/2e29I3dA8o4)