# 變更管理
**Topics**
+ [REL 6. 如何監控工作負載資源？](rel-06.md)
+ [REL 7. 如何設計工作負載以因應需求的變化？](rel-07.md)
+ [REL 8. 如何實作變更？](rel-08.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 服務的效能和可用性，為您提供個人化檢視。
雲端監控提供新機遇。大多數雲端供應商都開發了可自訂的勾點，並且可以提供深入解析，協助您監控工作負載的多個層面。Amazon CloudWatch 等 AWS 服務會在使用者介入程度最低的情況下，套用統計和機器學習演算法來持續分析系統和應用程式的指標、判斷正常基準以及披露異常情況。異常偵測演算法會考慮指標的季節性和趨勢變化。
AWS 提供大量可供使用的監控和日誌資訊，可用於定義工作負載特定的指標、需求變更程序，並採用機器學習技術，而不論機器學習專業知識如何。
此外，監控所有外部端點，以確保它們獨立於基本實作。此主動監控可透過綜合交易 (有時稱為*使用者 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 Access Logs，並允許您的工作負載記錄工作負載特定資料。從 Amazon ECS、Amazon EKS、Amazon EC2、Elastic Load Balancing、AWS Auto Scaling 和 Amazon EMR 等服務中收集 CPU、網路 I/O 和磁碟 I/O 平均值的指標。如需將指標發佈到 CloudWatch 的 AWS 服務清單，請參閱 [AWS Services That Publish CloudWatch Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)。
1. **審核所有預設指標，並探索任何資料收集漏洞。**每個服務都會產生預設指標。收集預設指標可讓您進一步了解工作負載元件之間的相依性，以及元件可靠性和效能如何影響工作負載。您也可以使用 AWS CLI 或 API 建立自己的自訂指標並[發佈](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)到 CloudWatch。
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)
+ [存取 AWS Lambda 的 Amazon CloudWatch Logs](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 Agent](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 流量日誌](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/)
**相關範例：**
+ [Amazon 建置者資料中心：偵測分散式系統，以了解運作狀態](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [可觀測性研討會](https://catalog.workshops.aws/observability/en-US)
# REL06-BP02 定義和計算指標 (彙總)
從工作負載元件收集指標和日誌，並從中計算相關的彙總指標。這些指標可提供廣泛且深入的工作負載可觀測性，並可大幅改善您的彈性狀態。
可觀測性不只是從工作負載元件收集指標以及能夠檢視指標並設定提醒。重點在於全面了解工作負載的行為。此行為資訊來自工作負載中的所有元件，包括其所依賴的雲端服務、精心製作的日誌及指標。此資料可讓您全面監督工作負載的行為，並了解每個元件與每個工作單元的互動及其細節。
**預期成果：**
+ 您可以從工作負載元件和 AWS 服務相依性收集日誌，並將其發布到方便存取和處理的集中位置。
+ 您的日誌包含高保真度且準確的時間戳記。
+ 您的日誌包含處理內容的相關資訊，例如追蹤識別碼、使用者或帳戶識別碼，以及遠端 IP 位址。
+ 您可以從日誌建立彙總指標，以便從高層級的角度來呈現工作負載的行為。
+ 您可以查詢彙總日誌，以取得有關工作負載的深入分析，並識別實際和潛在的問題。
**常見的反模式：**
+ 您未從工作負載執行所在的運算執行個體或其使用的雲端服務收集相關的日誌或指標。
+ 您忽略了收集與業務關鍵績效指標 (KPI) 相關的日誌和指標。
+ 您單獨分析工作負載相關的遙測，而未彙總和建立相互關聯。
+ 您太快讓指標和日誌過期，導致阻礙了趨勢分析和週期性問題識別。
**建立這些最佳實務的優勢：**您可以偵測更多異常情況，並將工作負載的不同元件之間的事件與指標相互關聯。您可以根據日誌中通常無法單獨用於指標的資訊，從工作負載元件建立深入分析。您可以大規模查詢日誌來加速判斷失敗原因。
**未建立這些最佳實務時的曝險等級：**高
## 實作指引
識別與您的工作負載及其元件相關的遙測資料來源。此資料不僅來自發布指標的元件 (例如作業系統 (OS) 和 Java 等應用程式執行時期)，也來自應用程式和雲端服務日誌。例如，Web 伺服器通常會記錄每個請求的詳細資訊，例如時間戳記、處理延遲、使用者 ID、遠端 IP 位址、路徑和查詢字串。這些日誌中的詳細資訊層級可協助您執行詳細的查詢，並產生其他方式無法提供的指標。
使用適當的工具和程序收集指標和日誌。Amazon EC2 執行個體上執行的應用程式所產生的日誌，可透過 [Amazon CloudWatch 代理程式](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)等代理程式收集並發布至 [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) 等集中儲存服務。AWS 受管運算服務 (例如 [AWS Lambda](https://aws.amazon.com/lambda/) 和 [Amazon Elastic Container Service](https://aws.amazon.com/ecs/)) 會自動將日誌發布至 CloudWatch Logs。為 [Amazon CloudFront](https://aws.amazon.com/cloudfront/)、[Amazon S3](https://aws.amazon.com/s3/)、[Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) 和 [Amazon API Gateway](https://aws.amazon.com/api-gateway/) 等工作負載所使用的 AWS 儲存和處理服務啟用日誌收集。
利用*[維度](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension)*讓您的遙測資料更豐富，如此您就能更清楚地看見行為模式，並將相互關聯的問題隔離成相關元件的群組。新增後，您可以觀測更詳細的元件行為、偵測相互關聯的故障，並採取適當的補救措施。有用的維度範例包括可用區域、EC2 執行個體 ID，以及容器任務或 Pod ID。
收集指標和日誌後，您可以撰寫查詢並從中產生彙總指標，以針對正常和異常行為提供實用的深入分析。例如，您可以使用 [Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 從您的應用程式日誌產生自訂指標、使用 [Amazon CloudWatch Metrics Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html) 大規模查詢您的指標、使用 [Amazon CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) 從容器化應用程式和微服務收集、彙總及摘要整理指標與日誌，或者，如果您使用 AWS Lambda 函數，則可以使用 [Amazon CloudWatch Lambda 洞察](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights.html)。若要建立彙總錯誤率指標，您可以在每次元件日誌中出現錯誤回應或訊息時讓計數器累進，或計算現有錯誤率指標的彙總值。您可以使用此資料來產生顯示*結尾行為*的長條圖，例如效能最差的請求或程序。您也可以使用 CloudWatch Logs [異常偵測](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/LogsAnomalyDetection.html)等解決方案來即時掃描此資料中是否有異常模式。這些深入分析可以放置在儀表板上，並根據您的需求和偏好組織整理。
查詢日誌可協助您了解工作負載元件如何處理特定請求，並顯示請求模式或其他影響工作負載彈性的內容。根據您對應用程式和其他元件行為的了解，事先研究和準備查詢會很實用，讓您更方便視需要執行該程式或元件。舉例來說，若使用 [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)，您能以互動方式搜尋和分析 CloudWatch Logs 中存放的日誌資料。您也可以使用 [Amazon Athena](https://aws.amazon.com/athena/) 查詢多個來源的日誌，包括 PB 規模的[許多 AWS 服務](https://docs.aws.amazon.com/athena/latest/ug/querying-aws-service-logs.html)。
當您定義日誌保留政策時，請考慮歷史日誌的價值。歷史日誌有助於識別工作負載效能的長期使用情形及行為模式、迴歸與改善。日誌永久刪除後，即無法再供分析。然而，歷史日誌的價值往往會隨著時間而降低。選擇一項政策來適當平衡您的需求，並應付您可能須遵循的任何法律或合約要求。
### 實作步驟
1. 為您的可觀測性資料選擇收集、儲存、分析和顯示機制。
1. 在工作負載的適當元件上安裝並設定指標和日誌收集器 (例如，在 Amazon EC2 執行個體上和[附屬容器](https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/)中)。設定這些收集器，讓它們在意外停止時自動重新啟動。啟用收集器的磁碟或記憶體緩衝，不要讓臨時發布失敗影響您的應用程式或導致資料遺失。
1. 在做為工作負載的一部分使用的 AWS 服務上啟用記錄功能，並將這些日誌轉送到您選取的儲存服務 (如有需要)。如需詳細說明，請參閱個別服務的使用者或開發人員指南。
1. 根據您的遙測資料，定義與工作負載相關的營運指標。這些指標可以根據工作負載元件發出的直接指標，包括業務 KPI 相關指標，或彙總計算的結果，例如總和、速率、百分位數或長條圖。使用日誌分析器計算這些指標，並將其放在儀表板上適當的位置。
1. 視需要準備適當的日誌查詢，以分析工作負載元件、請求或交易行為。
1. 為您的元件日誌定義和啟用日誌保留政策。當日誌比政策允許的時間更早時，請定期刪除日誌。
## 資源
**相關的最佳實務：**
+ [REL06-BP01 監控工作負載的所有元件 (產生)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html)
+ [REL06-BP03 傳送通知 (即時處理和警示)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_monitor.html)
+ [REL06-BP04 自動化回應 (即時處理和警示)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_automate_response_monitor.html)
+ [REL06-BP05 分析日誌](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_storage_analytics.html)
+ [REL06-BP06 定期審查監控範圍和指標](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_review_monitoring.html)
+ [REL06-BP07 透過您的系統監控請求的端對端追蹤](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_end_to_end.html)
**相關文件：**
+ [Amazon CloudWatch 的運作方式](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_architecture.html)
+ [Amazon Managed Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html)
+ [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html)
+ [使用 CloudWatch Logs Insights 分析日誌資料](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [Amazon CloudWatch Lambda 洞察](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights.html)
+ [Amazon CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html)
+ [使用 CloudWatch Metrics Insights 查詢您的指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html)
+ [AWS Distro for OpenTelemetry](https://aws.amazon.com/otel/)
+ [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://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 建置者資料中心：偵測分散式系統，以了解運作狀態](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
**相關研討會：**
+ [一個可觀測性研討會](https://observability.workshop.aws/)
**相關工具：**
+ [AWS Distro for OpenTelemetry (GitHub)](https://aws-otel.github.io/)
# REL06-BP03 傳送通知 (即時處理和警示)
當組織偵測到潛在問題時，他們會將即時通知和警示傳送給適當的人員和系統，以便快速有效地應對這些問題。
**預期成果：**根據服務和應用程式指標設定相關警示，就可以快速回應操作事件。違反警示閾值時，系統會通知適當的人員和系統，以便解決潛在問題。
**常見的反模式：**
+ 將警示的閾值設得過高，會導致無法傳送重要通知。
+ 將警示的閾值設得太低，導致使用者因通知過多的干擾而無法針對重要提醒採取行動。
+ 當使用情況改變時，未更新警示及其閾值。
+ 針對透過自動化動作解決的最佳警示，將通知傳送給人員而未引發自動化動作，會導致傳送過多的通知。
**建立此最佳實務的優勢：**將即時通知和警示傳送給適當的人員和系統，以便及早發現問題並快速回應操作事故。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
工作負載應具備即時處理和警示功能，以改善可能影響應用程式可用性問題的可偵測性，並作為自動化回應的觸發程式。組織可以透過使用已定義的指標建立警示來執行即時處理和警示，以便在發生重大事件或指標超過閾值時收到通知。
[Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 可讓您根據靜態閾值、異常偵測和其他條件，使用 CloudWatch 警示來建立[指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)和複合警示。如需有關可使用 CloudWatch 來設定的警示類型的詳細資訊，請參閱 [CloudWatch 文件的警示一節](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)。
您可以使用 [CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)為團隊建構 AWS 資源的指標和警示的自訂檢視。CloudWatch 主控台中的可自訂首頁可讓您在單一檢視中監控多個區域的資源。
警示可執行一個或多個動作，例如向 [Amazon SNS 主題](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)傳送通知、執行 [Amazon EC2](https://aws.amazon.com/ec2/) 動作或 [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) 動作，或在 AWS Systems Manager 中建立 [OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) 或[事故](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)。
Amazon CloudWatch 使用 [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 於警示變更狀態時傳送通知，將訊息傳遞從發布者 (生產者) 提供給訂閱用戶 (消費者)。如需有關設定 Amazon SNS 通知的詳細資訊，請參閱 [Configuring Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-configuring.html)。
每當建立、更新、刪除 CloudWatch 警示或變更其狀態時，CloudWatch 就會傳送 [EventBridge](https://aws.amazon.com/eventbridge/) [事件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-eventbridge.html)。您可以使用 EventBridge 搭配這些事件來建立執行動作的規則，例如，當警示狀態變更時就通知您，或使用 [Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 自動觸發您帳戶中的事件。
利用 [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) 隨時掌握新知。AWS Health 是 AWS 雲端 資源運作狀態的權威資訊來源。使用 AWS Health 來接收任何已確認服務事件的通知，方便您快速採取行動來緩解任何影響。透過 [AWS 使用者通知](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) 建立符合用途的 AWS Health 事件通知，以利用電子郵件和聊天管道傳送，並透過 [Amazon EventBridge 以程式設計方式與您的監控和警示工具](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)整合。如果使用 AWS Organizations，則跨帳戶彙總 AWS Health 事件。
**應何時使用 EventBridge 或 Amazon SNS？**
EventBridge 和 Amazon SNS 可用於開發事件驅動的應用程式，將視具體需求來做出選擇。
當您想要建立應用程式以回應您自己的應用程式、SaaS 應用程式和 AWS 服務中的事件時，建議使用 Amazon EventBridge。EventBridge 是唯一可直接與第三方 SaaS 合作夥伴整合的事件型服務。EventBridge 也會自動擷取來自 200 多個 AWS 服務的事件，而不需要開發人員在其帳戶中建立任何資源。
EventBridge 會將已定義的 JSON 架構用於事件，並協助您建立在整個事件內文中套用的規則，以選取要轉寄至[目標](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)的事件。EventBridge 目前支援超過 20 種 AWS 服務作為目標，包括 [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)、[Amazon SQS](https://aws.amazon.com/sqs/)、Amazon SNS、[Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) 和 [Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/)。
針對需要高散發的應用程式 (數千或數百萬個端點)，建議使用 Amazon SNS。我們看到的常見模式是客戶使用 Amazon SNS 做為規則的目標，以篩選所需的事件並散發到多個端點。
訊息是非結構化的，可以是任何格式。Amazon SNS 支援將訊息轉寄到六種不同類型的目標，包括 Lambda、Amazon SQS、HTTP/S 端點、SMS、行動推送和電子郵件。Amazon SNS [一般的延遲時間短於 30 毫秒](https://aws.amazon.com/sns/faqs/)。透過將服務設定為傳送 Amazon SNS 訊息，各種 AWS 服務就能做到這一點 (超過 30 個，包括 Amazon EC2、[Amazon S3](https://aws.amazon.com/s3/) 和 [Amazon RDS](https://aws.amazon.com/rds/))。
### 實作步驟
1. 使用 [Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)建立警示。
1. 指標警示會監控單一 CloudWatch 指標或與 CloudWatch 指標相依的表達式。與超過一段時間間隔的閾值相比，警示會根據指標或表達式的值起始一或多個動作。該動作可能包含將通知傳送至 [Amazon SNS 主題](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)、執行 [Amazon EC2](https://aws.amazon.com/ec2/) 動作或 [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) 動作，或在 AWS Systems Manager 中[建立 OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) 或[事故](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)。
1. 複合警示由規則表達式組成，該規則表達式會將您已建立的其他警示條件納入考量。只有在符合所有規則條件時，複合警示才會進入警示狀態。在複合警示規則表達式中指定的警示可能會包括指標警示和其他複合警示。複合警示可以在變更狀態時傳送 Amazon SNS 通知，並且可以在進入警示狀態時建立 Systems Manager [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) 或[事故](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)，但無法執行 Amazon EC2 動作或 Auto Scaling 動作。
1. 設定 [Amazon SNS 通知](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)。建立 CloudWatch 警示時，可以包含 Amazon SNS 主題，以便在警示變更狀態時傳送通知。
1. [在 EventBridge 中建立](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html)符合指定 CloudWatch 警示的規則。每個規則都支援多個目標，包括 Lambda 函數。例如，您可以定義在可用磁碟空間不足時啟動的警示，該警示會透過 EventBridge 規則觸發 Lambda 函數以清理空間。如需有關 EventBridge 目標的詳細資訊，請參閱 [EventBridge targets](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)。
## 資源
**相關 Well-Architected 的最佳實務：**
+ [REL06-BP01 監控工作負載的所有元件 (產生)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 定義和計算指標 (彙總)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL12-BP01 使用程序手冊調查失敗](rel_testing_resiliency_playbook_resiliency.md)
**相關文件：**
+ [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [CloudWatch Logs 洞察](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [使用 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)
+ [設定 Amazon SNS 通知](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)
+ [CloudWatch 異常偵測](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [CloudWatch Logs 資料保護](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/protect-sensitive-log-data-types.html)
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
+ [Amazon Simple Notification Service](https://aws.amazon.com/sns/)
**相關影片：**
+ [重塑 2022 年可觀測性影片](https://www.youtube.com/results?search_query=reinvent+2022+observability)
+ [AWS re:Invent 2022 - Amazon 的可觀測性最佳實務](https://www.youtube.com/watch?v=zZPzXEBW4P8)
**相關範例：**
+ [一個可觀測性研討會](https://observability.workshop.aws/)
+ [Amazon EventBridge 到 AWS Lambda，由 Amazon CloudWatch 警示進行回饋控制](https://serverlessland.com/patterns/cdk-closed-loop-serverless-control-pattern)
# REL06-BP04 自動化回應 (即時處理和警示)
偵測到事件時，使用自動化以採取動作，例如取代故障的元件。
實作警示的自動即時處理，以便系統可以採取快速的糾正措施，並嘗試在觸發警示時防止故障或服務降級。對警示的自動回應可能包括替換故障元件、調整運算容量、將流量重新導向到運作狀態良好的主機、可用區域或其他區域，以及操作人員通知。
**預期成果：**識別即時警示，並設定警示的自動處理，以調用採取的適當動作，維護服務水準目標和服務水準協議 (SLA)。自動化的範圍從單一元件的自我修復活動到全站點的容錯移轉。
**常見的反模式：**
+ 針對關鍵的即時警示沒有清晰的清單或目錄。
+ 對關鍵警示沒有自動回應 (例如，當運算資源即將耗盡時，發生自動擴展)。
+ 矛盾的警示回應動作。
+ 操作人員在收到提醒通知時沒有可以遵循的標準作業程序 (SOP)。
+ 未監控組態變更，因為未偵測到的組態變更可能會導致工作負載停機。
+ 沒有復原意外組態變更的策略。
**建立此最佳實務的優勢：**自動化警示處理可改善系統復原能力。系統會自動採取糾正措施，減少人為介入時容易出錯的手動活動。工作負載運作符合可用性目標，並減少服務中斷。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
為了有效管理提醒並自動化其回應，請根據提醒的重要性和影響來進行分類，記錄回應程序，並在為任務排名前規劃好回應。
識別需要特定動作的任務 (通常會在執行手冊中詳細說明)，並檢查所有執行手冊和程序手冊以確定哪些任務可以自動化。可以定義的動作通常也可以自動化。如果動作無法自動化，請在 SOP 中記錄手動步驟，並對操作人員進行相關培訓。持續挑戰手動程序以尋求自動化機會，以便您可以建立和維護用來自動化提醒回應的計畫。
### 實作步驟
1. **建立警示清單：**若要取得所有警示的清單，可以透過 [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 命令 `[describe-alarms](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarms.html)` 來使用 [AWS CLI](https://aws.amazon.com/cli/)。視設定的警示數量而定，您可能必須使用分頁來擷取每個呼叫的警示子集，或者也可以使用 AWS SDK [透過 API 呼叫](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-describing-alarms.html)來取得警示。
1. **記錄所有警報動作：**更新執行手冊與所有警示及其動作，無論其為手動還是自動。[AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/APIReference/Welcome.html) 可提供預先定義的執行手冊。如需有關執行手冊的詳細資訊，請參閱 [Working with runbooks](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)。如需有關如何檢視執行手冊內容的詳細資訊，請參閱[檢視執行手冊內容](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-runbook-reference.html#view-automation-json)。
1. **設定和管理警示動作：**對於任何需要動作的警示，請[使用 CloudWatch SDK 指定自動化動作](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-using-alarm-actions.html)。例如，您可以建立和啟用警示的動作，或停用警示的動作，以根據 CloudWatch 警示自動變更 Amazon EC2 執行個體的狀態。
也可使用 [Amazon EventBridge](https://aws.amazon.com/eventbridge/) 來自動回應系統事件，例如應用程式可用性問題或資源變動。您可建立規則來指示您在意的事件，以及當事件符合規則時執行的動作。可以自動啟動的動作包括調用 [AWS Lambda](https://aws.amazon.com/lambda/) 函數、調用 [Amazon EC2](https://aws.amazon.com/ec2/) `Run Command`、將事件轉送至 [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) 以及查看[使用 EventBridge 自動化 Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/automating_with_eventbridge.html)。
1. **標準操作程序 (SOP)：**根據您的應用程式元件，[AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) 會建議多個 [SOP 範本](https://docs.aws.amazon.com/resilience-hub/latest/userguide/sops.html)。您可以使用這些 SOP 記錄在發出提醒時操作員應遵循的所有程序。也可以根據 Resilience Hub 建議來[建構 SOP](https://docs.aws.amazon.com/resilience-hub/latest/userguide/building-sops.html)，其中您需要具有相關彈性政策的 Resilience Hub 應用程式，以及針對該應用程式的歷史彈性評估。SOP 的建議會由彈性評估產生。
Resilience Hub 與 Systems Manager 合作，透過提供許多 [SSM 文件](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-custom-ssm-doc.html)作為這些 SOP 的基礎來自動執行 SOP 的步驟。例如，Resilience Hub 可能會建議使用 SOP 來根據現有的 SSM 自動化文件新增磁碟空間。
1. **使用 Amazon DevOps Guru 執行自動化動作：**可使用 [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) 來自動監控應用程式資源，以偵測異常行為並提供目標建議，以縮短問題識別和矯正時間。使用 DevOps Guru，可以近乎即時地監控多個來源的操作資料串流，包括 Amazon CloudWatch 指標、[AWS Config](https://aws.amazon.com/config/)、[AWS CloudFormation](https://aws.amazon.com/cloudformation/) 和 [AWS X-Ray](https://aws.amazon.com/xray/)。也可以使用 DevOps Guru 在 OpsCenter 中自動建立 [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html)，並將事件傳送至 [EventBridge 以實現額外的自動化](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-eventbridge.html)。
## 資源
**相關的最佳實務：**
+ [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)
+ [REL08-BP01 將執行手冊用於部署等標準活動](rel_tracking_change_management_planned_changemgmt.md)
**相關文件：**
+ [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 建置者資料中心：偵測分散式系統，以了解運作狀態](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)
**相關影片：**
+ [AWS re:Invent 2022 - Amazon 的可觀測性最佳實務](https://www.youtube.com/watch?v=zZPzXEBW4P8)
+ [AWS re:Invent 2020：使用 AWS Systems Manager 自動執行任何操作](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [AWS Resilience Hub 簡介](https://www.youtube.com/watch?v=_OTTCOjWqPo)
+ [為 Amazon DevOps Guru 通知建立自訂票證系統](https://www.youtube.com/watch?v=Mu8IqWVGUfg)
+ [使用 Amazon DevOps Guru 啟用多帳戶洞察彙總](https://www.youtube.com/watch?v=MHezNcTSTbI)
**相關範例：**
+ [Amazon CloudWatch 和 Systems Manager 研討會](https://catalog.us-east-1.prod.workshops.aws/workshops/a8e9c6a6-0ba9-48a7-a90d-378a440ab8ba/en-US)
# 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 來查詢資料。它也支援對大量格式的查詢。如需詳細資訊，請參閱 Amazon Athena 使用者指南中 [Supported SerDes and Data Formats](https://docs.aws.amazon.com/athena/latest/ug/supported-format.html)。若要分析大型日誌檔集，可以執行 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 建置者資料中心：偵測分散式系統，以了解運作狀態](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP06 定期審查監控範圍和指標
經常檢閱工作負載監控的實作情形，並隨著工作負載及其架構的演進更新。定期稽核監控有助於降低遺漏或忽略問題指標的風險，並進一步協助工作負載達成其可用性目標。
有效的監控是以關鍵業務指標為基礎，這些指標會隨著業務優先事項的改變而演進。您的監控審查程序應強調服務層級指標 (SLI)，並納入基礎設施、應用程式、用戶端和使用者的深入分析。
**預期成果：**您擬訂一套有效的監控策略，它會定期審查和更新，以及在任何重大事件或變更之後更新。您確認隨著工作負載和業務需求的發展，關鍵應用程式運作狀態指標仍保持相關。
**常見的反模式：**
+ 您只收集預設指標。
+ 您擬訂了監控策略，但未曾檢閱它。
+ 您未在部署重大變更時討論監控。
+ 您相信過時的指標來判斷工作負載運作狀態。
+ 由於指標和閾值過時，導致您的營運團隊因誤報而疲於奔命。
+ 您缺乏未受監控之應用程式元件的可觀測性。
+ 您只專注於低層級技術指標，並排除業務指標未加監控。
**建立此最佳實務的優勢：**若您定期審查監控，就可以預測潛在問題，並確認您能夠偵測到這些問題。它還能讓您發現在早期審查期間可能遺漏的盲點，藉此進一步改善您偵測問題的能力。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
在您的[營運整備度審查 (ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) 程序中檢閱監控指標和範圍。依照一致的排程執行定期營運整備度審查，以評估目前工作負載與您設定的監控之間是否有任何差距。建立定期執行營運效能審查和知識共享的機制，以增強您從營運團隊獲得更高效能的能力。驗證現有的警示閾值是否仍適當，並確認是否發生營運團隊收到誤報，或未監控應監控之應用程式層面的情況。
[彈性分析架構](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/introduction.html)提供了實用的指引，可協助您進行整個程序。架構的重點在於識別潛在的失敗模式，以及您可採用哪些預防和修正控制來減輕其影響。這些知識可協助您確定要監控和警示的正確指標和事件。
### 實作步驟
1. 排程及定期審查工作負載儀表板。您對於檢查深度可能有不同規律。
1. 檢查指標中的趨勢。比較指標值與歷史值，以查看是否有趨勢可能指出某項需要調查的事務。這類範例包括：延遲增加、主要業務功能降低，以及失敗回應增加。
1. 檢查指標中是否有極端值和異常，這些可能被平均值或中位數掩蓋。查看時間範圍內的最高和最低值，並調查遠超出正常界限的觀測原因。當您繼續消除這些原因，您就可以設定更嚴格的預期指標界限，來回應獲得改善的工作負載效能一致性。
1. 尋找行為中的急劇變化。指標的數量或方向立即變更，可能表示應用程式有所變更，或您可能需要新增其他指標以追蹤的外部因素。
1. 檢閱目前的監控策略是否仍與應用程式相關。根據先前事件 (或彈性分析架構) 的分析，評估是否有其他應用程式層面應納入監控範圍。
1. 檢閱您的實際使用者監控 (RUM) 指標，以判斷應用程式功能涵蓋範圍是否有任何差距。
1. 檢閱您的變更管理程序。視需要更新您的程序，以納入應在核准變更之前執行的監控分析步驟。
1. 在營運整備度審查過程中確實檢閱監控並修正錯誤程序。
## 資源
**相關的最佳實務**
+ [REL06-BP01 監控工作負載的所有元件 (產生)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html)
+ [REL06-BP02 定義和計算指標 (彙總)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_aggregation.html)
+ [REL06-BP07 透過您的系統監控請求的端對端追蹤](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_end_to_end.html)
+ [REL12-BP02 執行事件後分析](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_rca_resiliency.html)
+ [REL12-BP06 定期進行演練日](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_game_days_resiliency.html)
**相關文件：**
+ [為什麼您應該制定錯誤糾正 (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
+ [使用 Amazon CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [建置用於檢視營運狀況的儀表板](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/?did=ba_card&trk=ba_card)
+ [進階多可用區域彈性模式 - 微小故障](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.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 建置者資料中心：偵測分散式系統，以了解運作狀態](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)
+ [AWS 可觀測性最佳實務](https://aws-observability.github.io/observability-best-practices/)
+ [彈性分析架構](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/introduction.html)
+ [彈性分析架構 - 可觀測性](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/observability.html)
+ [營運整備度審查 - ORR](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)
# REL06-BP07 透過您的系統監控請求的端對端追蹤
在透過服務元件處理請求時追蹤請求，讓產品團隊可以更輕鬆地分析和偵錯問題，並改善效能。
**預期成果：**對所有元件進行全面追蹤的工作負載易於偵錯，透過簡化根本原因探查，提高了錯誤和延遲的[平均解決時間](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html) (MTTR)。端對端追蹤可縮短探索受影響的元件時間，並詳細剖析錯誤或延遲的根本原因。
**常見的反模式：**
+ 追蹤可用於某些元件，但不適用於所有元件。例如，在未追蹤 AWS Lambda 的情況下，團隊可能無法清楚了解尖峰工作負載中的冷啟動所造成的延遲。
+ 未對追蹤設定綜合 Canary 或實際使用者監控 (RUM)。若沒有 Canary 或 RUM，追蹤分析就會省略用戶端互動遙測，而產生不完整的效能設定檔。
+ 混合式工作負載同時包含雲端原生和第三方追蹤工具，但未採取相關步驟來選擇及完全整合單一追蹤解決方案。根據選擇的追蹤解決方案，應使用雲端原生追蹤 SDK 來檢測不是雲端原生的元件，或使用第三方工具來擷取雲端原生追蹤遙測。
**建立此最佳實務的優勢：**當開發團隊收到問題的提醒時，他們可以看到系統元件互動的全貌，包括個別元件與日誌記錄、效能和失敗的關聯性。由於追蹤可讓您輕鬆地以視覺化方式識別根本原因，調查根本原因的所需時間將可縮短。詳細了解元件互動的團隊，可在解決問題時做出更明智、更快速的決策。諸如何時應叫用災難復原 (DR) 容錯移轉，或何處最適合實作自我修復策略之類的決策，可藉由分析系統追蹤來改善，最終提升客戶對服務的滿意度。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
操作分散式應用程式的團隊，可使用追蹤工具來建立關聯性識別碼、收集請求追蹤，以及建置連網元件的服務圖。所有應用程式元件均應包含在請求追蹤中，包括服務用戶端、中介軟體閘道和事件匯流排、運算元件和儲存體 (包括鍵值存放區和資料庫)。在端對端追蹤組態中包含綜合 Canary 和實際使用者監控，以測量遠端用戶端互動和延遲，以便您根據服務水準協議和目標正確評估系統效能。
您可以使用 [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 和 [Amazon CloudWatch 應用程式監控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html)檢測服務，在請求透過您的應用程式傳送時提供完整檢視。X-Ray 會收集應用程式遙測，並可讓您跨承載、函數、追蹤、服務、API 進行視覺化和篩選，並可針對無程式碼或低程式碼的系統元件開啟。CloudWatch 應用程式監控包括 ServiceLens，可將您的追蹤與指標、記錄和警示整合。CloudWatch 應用程式監控也包含用來監控端點和 API 的綜合功能，以及用來檢測 Web 應用程式用戶端的實際使用者監控。
## 實作步驟
+ 在所有受支援的原生服務 (例如 [Amazon S3、AWS Lambda 和 Amazon API Gateway](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html)) 上使用 AWS X-Ray。這些 AWS 服務可使用基礎設施即程式碼、AWS SDK 或 AWS 管理主控台 來啟用具有組態切換的 X-Ray。
+ 檢測應用程式 [AWS Distro for Open Telemetry 和 X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html) 或第三方收集代理程式。
+ 審核 [AWS X-Ray 開發人員指南](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)，了解程式設計語言特定實作。這些文件章節會詳細說明如何檢測 HTTP 請求、SQL 查詢，以及應用程式設計語言特有的其他程序。
+ 使用適用於 [Amazon CloudWatch Synthetics Canary](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 和 [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 的 X-Ray 追蹤，分析從最終使用者用戶端到下游 AWS 基礎設施的請求路徑。
+ 根據資源運作狀態和 Canary 遙測來設定 CloudWatch 指標和警示，以便團隊快速收到問題的提醒，然後可使用 ServiceLens 深入探討追蹤和服務圖。
+ 如果將第三方工具用於主要追蹤解決方案，請為第三方追蹤工具 (例如 [Datadog](https://docs.datadoghq.com/tracing/guide/serverless_enable_aws_xray/)、[New Relic](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/aws-integrations-list/aws-x-ray-monitoring-integration/) 或 [Dynatrace](https://www.dynatrace.com/support/help/setup-and-configuration/setup-on-cloud-platforms/amazon-web-services/amazon-web-services-integrations/aws-service-metrics)) 啟用 X-Ray 整合。
## 資源
**相關的最佳實務：**
+ [REL06-BP01 監控工作負載的所有元件 (產生)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL11-BP01 監控工作負載的所有元件以偵測故障](rel_withstand_component_failures_monitoring_health.md)
**相關文件：**
+ [什麼是 AWS X-Ray？](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [Amazon CloudWatch：應用程式監控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html)
+ [使用 Amazon CloudWatch Synthetics 和 AWS X-Ray 進行偵錯](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Amazon 建置者資料中心：偵測分散式系統，以了解運作狀態](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [將 AWS X-Ray 與其他 AWS 服務整合](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html)
+ [AWS Distro for OpenTelemetry 和 AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html)
+ [Amazon CloudWatch：使用綜合監控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Amazon CloudWatch：使用 CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [設定 Amazon CloudWatch Synthetics Canary 和 Amazon CloudWatch 警示](https://docs.aws.amazon.com/solutions/latest/devops-monitoring-dashboard-on-aws/set-up-amazon-cloudwatch-synthetics-canary-and-amazon-cloudwatch-alarm.html)
+ [ 可用性和超越各種可能：了解和改善 AWS 上分散式系統的恢復能力](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html)
**相關範例：**
+ [一個可觀測性研討會](https://catalog.workshops.aws/observability/en-US)
**相關影片：**
+ [AWS re:Invent 2022 - 如何跨多個帳戶監控應用程式](https://www.youtube.com/watch?v=kFGOkywu-rw)
+ [如何監控您的 AWS 應用程式](https://www.youtube.com/watch?v=UxWU9mrSbmA)
**相關工具：**
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [Amazon CloudWatch](https://aws.amazon.com/pm/cloudwatch/)
+ [Amazon Route 53](https://aws.amazon.com/route53/)
# 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 Load 測試您的工作負載](rel_adapt_to_changes_load_tested_adapt.md)
# REL07-BP01 取得或擴展資源時使用自動化
雲端可靠性的基石，是基礎設施和資源的程式設計定義、佈建和管理。自動化可協助您簡化資源佈建、促進一致且安全的部署，以及在整個基礎設施中擴展資源。
**預期成果：**您管理自己的基礎設施即程式碼 (IaC)。您可以在版本控制系統 (VCS) 中定義和維護自己的基礎設施程式碼。您可以將佈建 AWS 資源的工作委派給自動化機制，並利用 Application Load Balancer (ALB)、Network Load Balancer (NLB) 和 Auto Scaling 群組等受管服務。您使用持續整合/持續交付 (CI/CD) 管道來佈建資源，以讓程式碼變更自動初始化資源更新，包括 Auto Scaling 組態的更新。
**常見的反模式：**
+ 您使用命令列或在 AWS 管理主控台 (也稱為 *click-ops*) 手動部署資源。
+ 您緊密耦合應用程式元件或資源，因而建立了缺乏彈性的架構。
+ 您實作缺乏彈性的擴展政策，因而無法適應不斷變化的業務需求、流量模式或新的資源類型。
+ 您手動預估容量來應付預測的需求。
**建立此最佳實務的優勢**：基礎設施即程式碼 (IaC) 可讓您以程式設計方式定義基礎設施。這可協助您透過與應用程式變更相同的軟體開發生命週期來管理基礎設施變更，進而提高一致性和可重複性，並降低手動易出錯任務的風險。您可以使用自動化交付管道實作 IaC，以進一步簡化佈建和更新資源的程序。您採取可靠且有效率的方式部署基礎設施更新，而無需手動介入。在擴展資源以應付不斷變化的需求時，這種敏捷性尤其重要。
您可以結合 IaC 和交付管道來實現動態的自動化資源擴展。透過監控關鍵指標並套用預先定義的擴展政策，Auto Scaling 就可視需要自動佈建或取消佈建資源，進而改善效能和成本效益。這可降低手動錯誤或延遲的可能性，以回應應用程式或工作負載需求的改變。
IaC、自動化交付管道與 Auto Scaling 相互結合之下，可協助組織安心佈建、更新和擴展其環境。這種自動化對於維護反應靈敏、具彈性且高效管理的雲端基礎設施至關重要。
**未建立此最佳實務時的風險暴露等級**：高
## 實作指引
若要為您的 AWS 架構設定具有 CI/CD 管道和基礎設施即程式碼 (IaC) 的自動化，請選擇 Git 這類版本控制系統來儲存您的 IaC 範本和組態。這些範本可以使用 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 等工具撰寫。請從在這些範本內定義您的基礎設施元件開始 (例如 AWS VPC、Amazon EC2 Auto Scaling 群組和 Amazon RDS 資料庫)。
接著將這些 IaC 範本與 CI/CD 管道整合，以自動化部署程序。[AWS CodePipeline](https://aws.amazon.com/codepipeline/) 提供了順暢的 AWS 原生解決方案，您也可以使用其他第三方 CI/CD 解決方案。建立管道，當您的版本控制儲存庫發生變更時，就會啟用該管道。設定管道以包含檢查和驗證 IaC 範本的階段、將基礎設施部署到預備環境、執行自動化測試，最後再部署到正式作業環境。必要時納入核准步驟，以維持對變更的控制。此自動化管道不僅能加快部署速度，還能促進環境之間的一致性和可靠性。
在 IaC 中設定 Amazon EC2 執行個體、Amazon ECS 任務和資料庫複本等資源的 Auto Scaling，以視需要提供自動橫向擴充和縮減。此方法可增強應用程式可用性和效能，並根據需求動態調整資源來最佳化成本。如需支援的資源清單，請參閱 [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/application/userguide/what-is-application-auto-scaling.html)。
### 實作步驟
1. 建立並使用原始程式碼儲存庫來存放控制基礎設施組態的程式碼。對此儲存庫執行變更，以反映您要進行的任何持續變更。
1. 選取基礎設施即程式碼解決方案 (例如 AWS CloudFormation) 讓您的基礎設施保持最新狀態，並偵測與您預期狀態不一致 (偏離) 的情況。
1. 將 IaC 平台與您的 CI/CD 管道整合，以自動化部署。
1. 確定並收集適當的指標，以自動擴展資源。
1. 使用適合您工作負載元件的橫向擴充和縮減政策來設定自動擴展資源。考慮針對可預測的用量模式使用排程擴展。
1. 監控部署以偵測失敗和迴歸。在 CI/CD 平台內實作回復機制，以在必要時還原變更。
## 資源
**相關文件：**
+ [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)
+ [將 Jenkins 與 AWS CodeBuild 和 AWS CodeDeploy 整合](https://aws.amazon.com/blogs/devops/setting-up-a-ci-cd-pipeline-by-integrating-jenkins-with-aws-codebuild-and-aws-codedeploy/)
+ [使用 AWS CodePipeline 建立一個四階段的管道](https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-four-stage-pipeline.html)
**相關影片：**
+ [回歸基礎：將程式碼部署至 Amazon EC2](https://www.youtube.com/watch?v=f2wvEQ_sWS8)
+ [AWS 支援您 \$1 使用 AWS CloudFormation 範本開始使用您的基礎設施即程式碼解決方案](https://www.youtube.com/watch?v=bgfx76jr7tA)
+ [使用 AWS CodePipeline 簡化您的軟體版本程序](https://www.youtube.com/watch?v=zMa5gTLrzmQ)
+ [使用 Amazon CloudWatch 儀表板監控 AWS 資源](https://www.youtube.com/watch?v=I7EFLChc07M)
+ [建立跨帳戶和跨區域 CloudWatch 儀表板 \$1 Amazon Web Services](https://www.youtube.com/watch?v=eIUZdaqColg)
# REL07-BP02 在偵測到工作負載受損時取得資源
在可用性受到影響時視需要主動擴展資源，以還原工作負載可用性。
您必須先設定運作狀態檢查和這些檢查的條件，以指出可用性因資源不足而受到影響的時間。然後，通知適當的人員手動擴展資源，或啟動自動化以自動調整資源規模。
您可以針對工作負載手動調整規模 (例如，變更 Auto Scaling 群組中的 EC2 執行個體數量，或透過 AWS 管理主控台 或 AWS CLI 修改 DynamoDB 資料表的輸送量)。但是，應盡可能使用自動化 (請參閱**取得或擴展資源時使用自動化**)。
**預期成果：**啟動擴展活動 (自動或手動)，以在偵測到故障或客戶體驗降級時恢復可用性。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
在工作負載中的所有元件實作可觀測性和監控，以監控客戶體驗並偵測故障。定義可調整所需資源的手動或自動化程序。o 如需詳細資訊，請參閱 [REL11-BP01 監控工作負載的所有元件以偵測故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html)。
### 實作步驟
+ 定義會擴展所需資源的手動或自動程序。
+ 擴展程序取決於工作負載內不同元件的設計方式。
+ 擴展程序也會根據所使用的基礎技術而有所不同。
+ 使用 AWS Auto Scaling 的元件可以使用擴展計劃來設定用於擴展資源的一組指示。如果使用 AWS CloudFormation 或新增標籤到 AWS 資源，您可以針對每個應用程式的不同資源組來設定擴展計畫。Auto Scaling 為針對每個資源自訂的擴展策略提供建議。建立擴展計畫之後，Auto Scaling 會將動態擴展和預測擴展方法結合在一起，以支援您的擴展策略。有關詳細資訊，請參閱 [How scaling plans work](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)。
+ Amazon EC2 Auto Scaling 會確認您有數量正確的 Amazon EC2 執行個體來處理應用程式的負載。您可以建立 EC2 執行個體的集合，此集合稱為「Auto Scaling 群組」。您可以在每個 Auto Scaling 群組中指定執行個體的最小和最大數量，而 Amazon EC2 Auto Scaling 可確保您的群組大小永遠不會低於或高於這些限制。如需詳細資訊，請參閱 [What is Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ Amazon DynamoDB Auto Scaling 功能使用 Application Auto Scaling 服務代您動態調整佈建的輸送容量，以此回應實際流量模式。這可讓資料表或全域次要索引增加其佈建的讀取與寫入容量，以處理突然增加的流量，而不需限流。如需詳細資訊，請參閱 [Managing throughput capacity automatically with DynamoDB auto scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)。
## 資源
**相關的最佳實務：**
+ [ REL07-BP01 取得或擴展資源時使用自動化](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_adapt_to_changes_autoscale_adapt.html)
+ [REL11-BP01 監控工作負載的所有元件以偵測故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html)
**相關文件：**
+ [AWS Auto Scaling：擴展計劃的運作方式](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [使用 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 偵測到工作負載需要更多資源時取得資源
雲端運算最有價值的功能之一，就是動態佈建資源的能力。
在傳統的內部部署運算環境中，您必須預先確定和佈建足夠的容量，以滿足尖峰需求。這點卻是問題所在，因為它很昂貴，而且如果您低估工作負載的尖峰容量需求，它可能會對可用性造成風險。
在雲端中，您就不需要這樣做。而是能夠視需要佈建運算、資料庫和其他資源容量，以滿足目前和預測的需求。Amazon EC2 Auto Scaling 和 Application Auto Scaling 等自動化解決方案可以根據您指定的指標，自動線上提供資源。這使得擴展程序更容易且可預測，同時可確保您隨時有足夠的資源可用，進而大幅提高工作負載的可靠性。
**預期成果：**您設定自動擴展運算和其他資源以滿足需求。您在擴展政策中提供足夠的預留空間，以便在其他資源上線時處理激增的流量。
**常見的反模式：**
+ 您佈建固定數量的可擴展資源。
+ 您選擇的擴展指標與實際需求無關。
+ 您無法在擴展計畫中提供足夠的預留空間來應付需求激增的情況。
+ 您的擴展政策太晚增加容量，以致於在其他資源上線時造成容量耗盡和服務降級的情況。
+ 您未能正確設定資源計數的下限和上限，因而導致擴展失敗。
**建立此最佳實務的優勢：**擁有足夠的資源可滿足目前的需求，這點對於提供工作負載的高可用性並遵守您定義的服務層級目標 (SLO) 來說至關重要。自動擴展可讓您提供工作負載所需的確切運算、資料庫和其他資源數量，以便處理目前和預測的需求。您不需要判斷尖峰容量需求，並靜態配置資源來處理這些需求。您可以改為隨著需求增加配置更多資源來應付這些需求，並且在需求減少之後停用資源以降低成本。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
首先，確定工作負載元件是否適合自動擴展。這些元件稱為*可水平擴展*，因為它們提供相同的資源且行為相同。可水平擴展元件的範例包括相似設定的 EC2 執行個體、[Amazon Elastic Container Service (ECS)](https://aws.amazon.com/ecs/) 任務，以及在 [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/) 上執行的 Pod。這些運算資源通常位於負載平衡器後方，稱為*複本*。
其他複寫資源可能包括資料庫讀取複本、[Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 資料表和 [Amazon ElastiCache](https://aws.amazon.com/elasticache/) (Redis OSS) 叢集。如需可支援資源的完整清單，請參閱[可與 Application Auto Scaling 搭配使用的 AWS 服務](https://docs.aws.amazon.com/autoscaling/application/userguide/integrated-services-list.html)。
對於容器型架構，您可能需要採用兩種不同的方式進行擴展。第一種方式是，您可能需要擴展提供可水平擴展服務的容器。第二種方式是，您可能需要擴展運算資源以騰出空間給新容器。每一層都有不同的自動擴展機制。若要擴展 ECS 任務，您可以使用 [Application Auto Scaling](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)。若要擴展 Kubernetes Pod，您可以使用 [Horizontal Pod Autoscaler (HPA)](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) 或 [Kubernetes Event-driven Autoscaling (KEDA)](https://keda.sh/)。若要擴展運算資源，您可以針對 ECS 使用[容量提供者](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html)，對於 Kubernetes，您可以使用 [Karpenter](https://karpenter.sh) 或 [Cluster Autoscaler](https://kubernetes.io/docs/concepts/cluster-administration/cluster-autoscaling/)。
接著選取您要執行自動擴展的方式。有三個主要選項：指標型擴展、排程擴展和預測性擴展。
**指標型擴展**
指標型擴展會根據一或多個*擴展指標*的值佈建資源。擴展指標是指對應工作負載需求的指標。確定擴展指標是否適當的好方法，就是在非正式作業環境中執行負載測試。在負載測試期間，將可擴展資源的數量固定，並慢慢增加需求 (例如輸送量、並行或模擬的使用者)。然後尋找隨著需求增加 (或減少) 而增加的指標，以及隨著需求下降而減少 (或增加) 的指標。典型的擴展指標包括 CPU 使用率、工作佇列深度 (例如 [Amazon SQS](https://aws.amazon.com/sqs/) 佇列)、作用中使用者數量，以及網路輸送量。
**注意**
AWS 已觀測到，在大多數應用程式中，記憶體使用率會隨著應用程式暖機而增加，然後達到穩定值。當需求減少時，記憶體使用率通常會保持在升高處，而不會跟著減少。由於記憶體使用率不會隨著需求增加和減少而對應升降，因此在選取此指標用於自動擴展時，務必審慎考慮。
指標型擴展是*延遲操作*。利用率指標可能需要幾分鐘的時間才能傳播至自動擴展機制，而且這些機制通常會等待需求增加的明確訊號，然後才做出反應。於是，當自動擴展器建立新資源時，可能需要額外的時間才能提供完整服務。因此，請務必不要將擴展指標目標設定得太接近完全使用率 (例如 90% CPU 使用率)。這樣做可能產生在額外容量上線之前就耗盡現有資源容量的風險。典型的資源使用率目標範圍介於 50-70% 之間，此範圍可實現最佳可用性，具體取決於佈建其他資源的需求模式和所需的時間。
**排程擴展**
排程擴展會根據行事曆或一天當中的時間佈建或移除資源。它經常用於具有可預測需求的工作負載，例如工作日營業時間或銷售活動的尖峰使用率。[Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html) 和 [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) 都支援排程擴展。KEDA 的 [cron 擴展器](https://keda.sh/docs/latest/scalers/cron/)支援 Kubernetes Pod 的排程擴展。
**預測性擴展**
預測性擴展使用機器學習，根據預期的需求自動擴展資源。預測性擴展會分析您提供的使用率指標的歷史值，並持續預測其未來值。然後使用預測的值來向上擴展資源或縮減其規模。[Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html) 可執行預測性擴展
### 實作步驟
1. 確定工作負載元件是否適合自動擴展。
1. 確定哪一種擴展機制最適合工作負載：指標型擴展、排程擴展或預測性擴展。
1. 為元件選取適當的自動擴展機制。對於 Amazon EC2 執行個體，使用 Amazon EC2 Auto Scaling。對於其他 AWS 服務，使用 Application Auto Scaling。對於 Kubernetes Pod (例如在 Amazon EKS 叢集中執行的 Pod)，請考慮 Horizontal Pod Autoscaler (HPA) 或 Kubernetes Event-driven Autoscaling (KEDA)。對於 Kubernetes 或 EKS 節點，請考慮 Karpenter 和 Cluster Auto Scaler (CAS)。
1. 對於指標或排程擴展，請執行負載測試，以確定適合工作負載的擴展指標和目標值。對於排程擴展，確定您選取的日期和時間所需的資源數量。確定滿足預期的尖峰流量所需的資源數量上限。
1. 根據上面收集的資訊設定自動擴展器。如需詳細資訊，請參閱自動擴展服務的文件。確認已正確設定擴展的上限和下限。
1. 確認擴展組態依預期運作。在非正式作業環境中執行負載測試，以及觀察系統如何反應，並視需要調整。在正式作業環境中啟用自動擴展時，請設定適當的警報來通知您任何非預期的行為。
## 資源
**相關文件：**
+ [什麼是 Amazon EC2 Auto Scaling？](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [AWS 規範性指引：負載測試應用程式](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/)
+ [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)
# REL07-BP04 Load 測試您的工作負載
採用負載測試方法來衡量擴展活動是否滿足工作負載要求。
重要的是執行持續的負載測試。負載測試應探索突破點，並測試工作負載的效能。 AWS 可讓您輕鬆設定臨時測試環境，以建立生產工作負載規模的模型。在雲端，您可隨需建立生產規模的測試環境、完成測試，然後再停用資源。因為您只為執行中的測試環境付費，所以能以與內部部署測試相較之下相當微小比例的成本來模擬即時環境。
在生產系統承受壓力的演練日，以及客戶使用量較低的時間內，您也應考慮在生產中進行負載測試，並且讓可用的所有人員解釋結果並解決所發生的任何問題。
**常見的反模式：**
+ 在與生產組態不同的部署上執行負載測試。
+ 僅對工作負載的個別部分執行負載測試，而非整個工作負載。
+ 使用一部分請求而非代表性的一組實際請求來執行負載測試。
+ 對高於預期負載的小型安全係數執行負載測試。
**建立此最佳實務的優勢：**您會知道架構中的哪些元件在負載時失敗，並能夠識別要監看哪些指標，指出您正在及時處理該負載來解決問題，避免受到該故障的影響。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
+ 執行負載測試，以識別工作負載的哪些層面指出您必須新增或移除容量。負載測試的代表性流量應與您在生產環境中收到的流量相似。在觀看您已檢測的指標時增加負載，以判斷哪些指標指出何時須新增或移除資源。
+ [上的分散式負載測試 AWS：模擬數千個連線使用者](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ 識別請求混合。您可能會有不同的請求混合，因此您應該在識別流量混合時查看各種時間範圍。
+ 實作載入驅動程式。您可以使用自訂程式碼、開放原始碼或商業軟體實作載入驅動程式。
+ 最初使用小容量的負載測試。您將負載驅動到較小容量 (可能和單一執行個體或容器一樣小)，看到一些立即的影響。
+ 針對較大容量的負載測試。在分散式負載上的效果會有所不同，因此您必須盡可能在接近產品環境的條件下進行測試。
## 資源
**相關文件：**
+ [上的分散式負載測試 AWS：模擬數千個連線的使用者](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [負載測試應用程式](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html)
**相關影片：**
+ [AWS Summit ANZ 2023：透過 AWS 分散式負載測試，放心加速](https://www.youtube.com/watch?v=4J6lVqa6Yh8)
# 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 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)
+ 使用以 Git 等常用技術為基礎的託管原始程式碼管理系統，來儲存原始程式碼和基礎設施即程式碼 (IaC) 組態。
## 資源
**相關文件：**
+ [APN 合作夥伴：可以幫助您建立自動化部署解決方案的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [AWS Marketplace：可用於自動化部署的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [什麼是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
**相關範例：**
+ [使用程序手冊和執行手冊將操作自動化](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL08-BP02 將功能測試整合為部署的一部分
使用可驗證所需功能的技術，例如單元測試和整合測試。
單元測試是您測試程式碼的最小功能單元以驗證其行為的程序。整合測試旨在驗證每一項應用程式功能是否根據軟體需求運作。單元測試著重於單獨測試應用程式的部分，整合測試則會考量副作用 (例如，透過改變操作變更資料的影響)。無論在哪一種情況下，測試都應整合到部署管道中，如果不符合成功條件，則管道會停止或復原。這些測試會在生產前環境中執行，而且會在生產前暫存於管道中。
當這些測試做為建置和部署動作的一部分自動執行時，您會獲得最佳成果。例如，使用 AWS CodePipeline 時，開發人員會將變更遞交至來源儲存庫，而 CodePipeline 會在該儲存庫中自動偵測變更。系統會建置應用程式並執行單元測試。通過單元測試後，建置的程式碼會部署至預備伺服器以進行測試。CodePipeline 會從預備伺服器執行更多測試，例如整合或負載測試。成功完成這些測試後，CodePipeline 會將已測試及已核准的程式碼部署至生產執行個體。
**預期成果：**您會使用自動化來執行單元和整合測試，以驗證程式碼的行為如預期。這些測試會整合到部署程序中，若測試失敗，則會中止部署。
**常見的反模式：**
+ 您為了加快部署時間表，而忽略或略過在部署過程中的測試失敗和計畫。
+ 可以在部署管道之外手動執行測試。
+ 您透過手動緊急工作流程，跳過自動化中的測試步驟。
+ 您執行自動化測試的環境與正式作業環境並非十分相似。
+ 您建置的測試套件不夠靈活，且不易隨著應用程式發展進行維護、更新或擴展。
**建立此最佳實務的優勢：**在部署過程中進行自動化測試可及早發現問題，進而降低將有錯誤或非預期行為的版本發布至正式作業環境的風險。單元測試會驗證程式碼的行為確實依照要求，並遵循 API 合約。整合測試會驗證系統確實根據指定的需求運作。這些類型的測試會驗證元件 (例如使用者介面、API、資料庫和原始程式碼) 的預定工作順序。
**未建立此最佳實務時的風險暴露等級：**高
## 實作指引
採用測試驅動的開發 (TDD) 方法來撰寫軟體，藉此開發測試案例來指定和驗證程式碼。若要開始進行，請為每個函數建立測試案例。如果測試失敗，您會撰寫新的程式碼來通過測試。此方法可協助您驗證每個函數的預期結果。在將程式碼遞交至原始程式碼儲存庫之前，先執行單元測試並確認其通過測試。
在 CI/CD 管道的建置、測試和部署階段，實作單元和整合測試。自動化測試，並在應用程式有新版本可進行部署時自動初始化測試。如果未符合成功條件，則會終止或回復管道。
如果應用程式為 Web 或行動應用程式，則在多個桌面瀏覽器或實際的裝置上執行自動化整合測試。此方法對於驗證行動應用程式在各種不同裝置之間的相容性和功能特別有用。
### 實作步驟
1. 在撰寫功能程式碼 (*測試驅動的開發*或 TDD) 之前，先撰寫單元測試。建立程式碼指引，讓寫入和執行單元測試成為非功能性的編碼需求。
1. 建立自動化整合測試套件，當中涵蓋已識別的可測試功能。這些測試應模擬使用者互動並驗證預期結果。
1. 建立必要的測試環境以執行整合測試。當中可能包括與正式作業環境十分相似的預備或正式作業前環境。
1. 使用 AWS CodePipeline 主控台或 AWS Command Line Interface (CLI) 設定來源、建置、測試和部署階段。
1. 程式碼建置並測試完成後，部署應用程式。AWS CodeDeploy 可以將它部署到您的預備 (測試) 和正式作業環境。這些環境可包括 Amazon EC2 執行個體、AWS Lambda 函數或內部部署伺服器。您應使用相同的部署機制將應用程式部署到所有環境。
1. 監控管道的進度和每個階段的狀態。使用品質檢查，根據測試的狀態封鎖管道。也可以接收任何管道階段失敗或管線完成的通知。
1. 持續監控測試結果，並尋找較需要關注的模式、迴歸或區域。利用這些資訊改進測試套件、找出應用程式中需要更完善測試的區域，以及最佳化部署程序。
## 資源
**相關的最佳實務：**
+ [REL07-BP04 對工作負載執行負載測試](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_adapt_to_changes_load_tested_adapt.html)
+ [REL08-BP03 將彈性測試整合為部署的一部分](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_resiliency_testing.html)
+ [REL12-BP04 使用混沌工程測試彈性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_failure_injection_resiliency.html)
**相關文件：**
+ [AWS 規範性指引：測試自動化](https://docs.aws.amazon.com/prescriptive-guidance/latest/performance-engineering-aws/test-automation.html)
+ [持續交付和持續整合](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [功能測試指標](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/indicators-for-functional-testing.html)
+ [監控管道](https://docs.aws.amazon.com/codepipeline/latest/userguide/monitoring.html)
+ [搭配 AWS CodeBuild 使用 AWS CodePipeline 以測試程式碼並執行建置](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [AWS Device Farm](https://docs.aws.amazon.com/codepipeline/latest/userguide/action-reference-DeviceFarm.html)
# REL08-BP03 將彈性測試整合為部署的一部分
通過有意識地在系統中引入故障來整合彈性測試，以在破壞性情況下衡量其能力。彈性測試與通常整合在部署週期中的單元和功能測試不同，因為它們專注於識別系統中的意外故障。雖然從生產前的彈性測試整合開始是安全的，但應設定一個目標，在生產環境中實作這些測試，作為[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)的一部分。
**預期成果**：彈性測試有助於建立系統承受生產降級能力的信心。實驗可識別會導致故障的弱點，這有助於您改善系統，以自動且有效地緩解故障和降級。
**常見的反模式：**
+ 在部署過程中缺乏可觀測性和監控
+ 依賴人類解決系統故障
+ 品質不佳的分析機制
+ 專注於系統中的已知問題，缺乏識別任何未知因素的實驗
+ 可識別故障，但沒有解決方案
+ 沒有調查結果和執行手冊文件
**建立最佳實務的優勢：**在部署中整合的彈性測試有助於識別系統中未知的問題，否則這些問題會被忽視，從而導致生產中停機。在系統中識別這些未知因素可協助您記錄調查結果、將測試整合到您的 CI/CD 程序中以及建置執行手冊，透過高效率、可重複的機制簡化緩解作業。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
可以整合到系統部署中的最常見彈性測試表單是災難復原和混沌工程。
+ 在任何重要部署中包含災難復原計畫和標準操作程序 (SOP) 的更新。
+ 將可靠性測試整合至您的自動化部署管道。諸如 [AWS Resilience Hub](https://aws.amazon.com/resilience-hub/) 的服務可[整合到您的 CI/CD 管道](https://aws.amazon.com/blogs/architecture/continually-assessing-application-resilience-with-aws-resilience-hub-and-aws-codepipeline/)中，以建立持續的彈性評估，並在每次部署中自動進行評估。
+ 在 AWS Resilience Hub 中定義您的應用程式。彈性評估會產生程式碼片段，協助您將復原程序建立為應用程式的 AWS Systems Manager 文件，並提供建議的 Amazon CloudWatch 監控和警示清單。
+ DR 計畫和 SOP 更新後，請完成災難復原測試以驗證其是否有效。災難復原可協助您判斷是否可以在事件發生後還原系統並恢復正常操作。您可以模擬各種災難復原策略，並確定您的規劃是否足以滿足您的正常運行時間需求。常見的災難復原策略包括備份與還原、指示燈、冷待命、暖待命、熱待命和主動-主動式，而且成本和複雜性都有所不同。在災難復原之前，建議您定義復原時間點目標 (RTO) 和復原點目標 (RPO)，以簡化要模擬的策略選擇。AWS 提供災難復原工具，例如 [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)，協助您開始規劃和測試。
+ 混沌工程實驗引入了系統中斷，例如網路中斷和服務故障。透過模擬受控故障，您可以發現系統的漏洞，同時控制注入故障的影響。就像其他策略一樣，在非生產環境中使用諸如 [AWS Fault Injection Service](https://aws.amazon.com/fis/) 等服務執行受控故障模擬，以在部署到生產環境之前獲得信心。
## 資源
**相關文件：**
+ [使用彈性測試進行故障實驗以建立復原備](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/qa.nt.6-experiment-with-failure-using-resilience-testing-to-build-recovery-preparedness.html)
+ [使用 AWS Resilience Hub 和 AWS CodePipeline 持續評估應用程式彈性](https://aws.amazon.com/blogs/architecture/continually-assessing-application-resilience-with-aws-resilience-hub-and-aws-codepipeline/)
+ [AWS 上的災難復原 (DR) 架構，第 1 部分：雲端復原策略](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [使用混沌工程確認工作負載的彈性](https://aws.amazon.com/blogs/architecture/verify-the-resilience-of-your-workloads-using-chaos-engineering/)
+ [混沌工程的原則](https://principlesofchaos.org/)
+ [混沌工程研討會](https://disaster-recovery.workshop.aws/en/intro/concepts/chaos-engineering.html)
**相關影片：**
+ [AWS re:Invent 2020：使用混沌工程測試彈性](https://www.youtube.com/watch?v=OlobVYPkxgg)
+ [利用 AWS 故障注入服務來提升應用程式彈性](https://www.youtube.com/watch?v=N0aZZVVZiUw)
+ [使用 AWS Resilience Hub 準備並保護您的應用程式免受中斷](https://www.youtube.com/watch?v=xa4BVl4N1Gw)
# REL08-BP04 使用不可變基礎設施進行部署
不可變基礎設施是一種模式，要求在生產工作負載上不進行現場的更新、安全性修補或組態變更。需要進行變更時，會在新的基礎設施上建置架構並部署到生產環境。
請遵循不可變基礎設施的部署策略，以提高工作負載部署中的可靠性、一致性和可重複性。
**預期成果：**使用不可變基礎設施，不允許[就地修改](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/deployment-strategies.html#in-place-deployments)以執行工作負載內的基礎設施資源。相反地，在需要變更時，會以平行方式與現有資源一起部署新的、包含所有必要變更的更新後基礎設施資源集。此部署會自動進行驗證，如果成功，流量會逐漸轉移到新的資源集。
此部署策略適用於軟體更新、安全修補程式、基礎設施變更、組態更新和應用程式更新等。
**常見的反模式：**
+ 對執行中的基礎設施資源實作就地變更。
**建立此最佳實務的優勢：**
+ **提高跨環境的一致性：**由於跨環境的基礎設施資源沒有差異，因此可以提高一致性並簡化測試。
+ **降低組態偏移：**透過將基礎設施資源取代為已知且版本控制的組態，可將基礎設施設為已知、經過測試且可信狀態，以避免組態偏移。
+ **可靠的不可分割部署：**部署可以順利完成，也可以保持不變，從而提高部署流程的一致性和可靠性。
+ **簡化部署：**部署不需要支援升級，因此會得到簡化。升級只是新的部署。
+ **利用快速的回復及復原程序打造更安全的部署：**前一個運作版本並未變更，因此部署變得更加安全。如果偵測到錯誤，您可以回復至該版本。
+ **增強的安全狀態：**透過不允許變更基礎設施，可以停用遠端存取機制 (例如 SSH)。這可減少攻擊媒介，從而改善組織的安全狀態。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
** Automation**
定義不可變基礎設施部署策略時，建議盡可能使用[自動化](https://aws.amazon.com/iam/)來提高可重複性並將人為錯誤的可能性降至最低。如需詳細資訊，請參閱 [REL08-BP05 透過自動化部署變更](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_automated_changemgmt.html)和[安全且無需人為干預的自動化部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)。
使用[基礎設施即程式碼 (IaC)](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html) 時，基礎設施佈建、協同運作和部署步驟會以程式設計、描述性和宣告式的方式定義，並儲存在原始檔控制系統中。利用基礎設施即程式碼可讓您更輕鬆地自動部署基礎設施，並協助您實現基礎設施不可變性。
**部署模式**
需要變更工作負載時，不可變基礎設施的部署策略會要求您部署一組新的基礎設施資源，包括所有必要的變更。這組新資源必須遵循推出模式，以最大程度地降低使用者所受到的影響。此部署有兩個主要策略：
[https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html)：將少量客戶導向至新版本的實務，通常會在單一服務執行個體 (Canary) 上執行。之後，您可以仔細檢查所產生的任何行為變更或錯誤。如果遇到嚴重問題，可以從 Canary 中刪除流量，然後將使用者傳送回以前的版本。如果部署成功，則您可以繼續以期望的速度進行部署，同時監控變更是否有錯誤，直到完全部署為止。可以使用允許 Canary 部署的[部署組態](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)來設定 AWS CodeDeploy。
[https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html)：與 Canary 部署類似，不同之處在於整個應用程式須並行部署。您可在兩個堆疊 (藍色和綠色) 之間交替部署。再次強調，您可以將流量傳送到新版本，且如果發現部署問題，則可以回復到舊版本。通常，會一次切換所有流量，但您也可以將一小部分的流量用於每個版本，以使用 Amazon Route 53 的加權 DNS 路由功能，提高新版本的採用率。可以使用允許藍/綠部署的部署組態來設定 AWS CodeDeploy 和 [AWS Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2020-05-18-ts-deploy.html)。
![\[顯示使用 AWS Elastic Beanstalk 和 Amazon Route 53 進行藍/綠部署的圖表\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/images/blue-green-deployment.png)
**漂移偵測**
*漂移*被定義為導致基礎設施資源具有與預期不同的狀態或配置的任何變更。任何類型的未受管組態變更都違反了不可變基礎設施的概念，應加以偵測並修正，以便能成功實作不可變基礎設施。
### 實作步驟
+ 禁止就地修改執行中的基礎設施資源。
+ 您可以使用 [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) 指定誰或哪些服務可以存取 AWS 中的服務和資源、集中管理精細權限，以及分析存取以完善 AWS 中的權限。
+ 自動部署基礎設施資源以提高可重複性，並最大限度地減少發生人為錯誤的可能性。
+ 如 [DevOps on AWS 簡介](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)中所述，自動化是 AWS 服務的基石，並在所有服務、功能和產品中獲得內部支援。
+ *[預製](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/prebaking-vs.-bootstrapping-amis.html)*您的 Amazon Machine Image (AMI) 可以加快啟動它們的時間。[EC2 Image Builder](https://aws.amazon.com/image-builder/) 是一項全受管 AWS 服務，可協助您自動建立、維護、驗證、共用和部署自訂、安全且最新的 Linux 或 Windows 自訂 AMI。
+ 支援自動化的一些服務包括：
+ [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/) 是一項服務，可在熟悉的伺服器 (例如 Apache、Nginx、Passenger 和 IIS) 上部署和擴展以 Java、.NET、PHP、Node.js、Python、Ruby、Go 和 Docker 開發的 Web 應用程式。
+ [AWS Proton](https://aws.amazon.com/proton/) 協助平台團隊連接並協調開發團隊在基礎設施佈建、程式碼部署、監控和更新方面所需的所有不同工具。AWS Proton 可啟用無伺服器和容器型應用程式的自動化基礎設施即程式碼佈建和部署。
+ 利用基礎設施即程式碼可讓您輕鬆地自動部署基礎設施，並協助實現基礎設施的不可變性。AWS 會提供能以程式化、描述性和宣告式的方式建立、部署和維護基礎設施的服務。
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 幫助開發人員以有序和可預測的方式建立 AWS 資源。資源會使用 JSON 或 YAML 格式以文字檔撰寫。範本需要特定語法和結構，而這取決於所建立和管理的資源類型。您可以使用任何程式碼編輯器以 JSON 或 YAML 撰寫資源、將其簽入版本控制系統，然後 CloudFormation 便會以安全、可重複的方式建置指定的服務。
+ [AWS Serverless Application Model (AWS SAM)](https://aws.amazon.com/serverless/sam/) 是可用來在 AWS 上建置無伺服器應用程式的開放原始碼架構。AWS SAM 與其他 AWS 服務整合，是 CloudFormation 的擴展功能。
+ [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/) 是一個開放原始碼軟體開發架構，可用來建模，並使用熟悉的程式設計語言來佈建您的雲端應用程式資源。您可以使用 AWS CDK 透過 TypeScript、Python、Java 和 .NET 來建模應用程式基礎設施。AWS CDK 會在背景中使用 CloudFormation 以透過安全、可重複的方式佈建資源。
+ [AWS 雲端控制 API](https://aws.amazon.com/cloudcontrolapi/) 引入一組通用的「建立」、「讀取」、「更新」、「刪除」和「清單」(CRUDL) API，協助開發人員以簡單且一致的方式管理雲端基礎設施。Cloud Control API 通用 API 可讓開發人員統一管理 AWS 和第三方服務的生命週期。
+ 實作可將使用者所受到的影響降到最低的部署模式。
+ Canary 部署：
+ [設定 API Gateway Canary 發行部署](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [使用 AWS App Mesh 為 Amazon ECS 建立具有 Canary 部署的管道](https://aws.amazon.com/blogs/containers/create-a-pipeline-with-canary-deployments-for-amazon-ecs-using-aws-app-mesh/)
+ 藍/綠部署：[《AWS 上的藍/綠部署》白皮書](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html)說明了實作藍/綠部署策略的[範例技術](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/implementation-techniques.html)。
+ 偵測組態或狀態的偏移。如需詳細資訊，請參閱 [Detecting unmanaged configuration changes to stacks and resources](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)。
## 資源
**相關的最佳實務：**
+ [ REL08-BP05 使用自動化部署變更](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_automated_changemgmt.html)
**相關文件：**
+ [自動化安全、無人為介入的部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+ [利用 AWS CloudFormation 在 Nubank 建立不可變基礎設施](https://aws.amazon.com/blogs/mt/leveraging-immutable-infrastructure-nubank/)
+ [基礎設施即程式碼](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)
+ [實作警示以自動檢測 AWS CloudFormation 堆疊中的漂移](https://docs.aws.amazon.com/blogs/mt/implementing-an-alarm-to-automatically-detect-drift-in-aws-cloudformation-stacks/)
**相關影片：**
+ [AWS re:Invent 2020：透過不變性實現可靠性、一致性和信心](https://www.youtube.com/watch?v=jUSYnRztttY)
# REL08-BP05 使用自動化部署變更
部署和修補經過自動化以消除負面影響。
改變生產系統是許多組織的最大風險領域之一。我們認為，相較於軟體要解決的業務問題，部署才是我們要解決的首要問題。如今，這表示在營運中實際可行的地方使用自動化，包括測試和部署變更，新增或刪除容量以及移轉資料。
**期望成果：**可以透過廣泛的生產前測試、自動復原和交錯的生產部署，在發佈過程中建置自動化部署安全性。這種自動化可將部署失敗所造成的潛在影響降到最低，而且開發人員不再需要主動觀察部署到生產環境的情況。
**常見的反模式：**
+ 可以執行手動變更。
+ 可以透過手動緊急工作流程，略過自動化中的步驟。
+ 您不會遵循既定的計劃和流程，以加快時間表。
+ 可以在不考慮封裝時間的情況下執行快速後續部署。
**建立此最佳實務的優勢：**當您使用自動化來部署所有變更時，可以移除導致人為錯誤的可能性，並能夠在變更生產之前進行測試。在生產推送之前執行此程序可驗證您的計劃是否已完成。此外，自動復原至您的發佈程序可以識別生產問題，並將工作負載恢復到先前的作業狀態。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
自動化您的部署管道。部署管道讓您可以叫用自動測試、偵測異常，或者在生產部署之前的某個步驟中停止管道，或者自動回復變更。其中不可或缺的一部分就是採用[持續整合和持續交付/部署 (CI/CD)](https://en.wikipedia.org/wiki/CI/CD) 的文化，在這種文化中，提交或程式碼變更會經過各種自動化階段，從建置和測試階段到生產環境的部署。
儘管傳統觀點建議您將業內人員安排在營運程序中最困難的部分，但是出於這個原因，我們建議您能自動化最困難的程序。
### 實作步驟
可以依照下列步驟自動化部署以移除手動作業：
+ **設定程式碼儲存庫以安全地儲存您的程式碼：**使用以 Git 等常用技術為基礎的託管原始程式碼管理系統，來儲存原始程式碼和基礎設施即程式碼 (IaC) 組態。
+ **設定持續整合服務以編譯原始程式碼、執行測試及建立部署成品：**若要針對此目的設定建置專案，請參閱 [Getting started with AWS CodeBuild using the console](https://docs.aws.amazon.com/codebuild/latest/userguide/getting-started.html)。
+ **設定可自動化應用程式部署並處理應用程式更新複雜性的部署服務，而不需依賴容易出錯的手動部署：**[AWS CodeDeploy](https://aws.amazon.com/codedeploy/) 可將軟體部署自動化至各種運算服務，例如 Amazon EC2、[AWS Fargate](https://aws.amazon.com/fargate/)、[AWS Lambda](https://aws.amazon.com/lambda) 和內部部署伺服器。若要設定這些步驟，請參閱 [Getting started with CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/getting-started-codedeploy.html)。
+ **設定持續交付服務，自動化您的發行管道，以便實現更快且更可靠的應用程式和基礎設施更新：**請考慮使用 [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/getting-started-codepipeline.html) 來協助您自動化發行管道。如需詳細資訊，請參閱 [CodePipeline tutorials](https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials.html)。
## 資源
**相關的最佳實務：**
+ [OPS05-BP04 使用建置和部署管理系統](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_build_mgmt_sys.html)
+ [OPS05-BP10 完全自動化整合和部署](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_auto_integ_deploy.html)
+ [OPS06-BP02 測試部署](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_mit_deploy_risks_test_val_chg.html)
+ [OPS06-BP04 自動化測試和復原](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_mit_deploy_risks_auto_testing_and_rollback.html)
**相關文件：**
+ [使用 AWS CodePipeline 連續交付巢狀 AWS CloudFormation 堆疊](https://aws.amazon.com/blogs/devops/continuous-delivery-of-nested-aws-cloudformation-stacks-using-aws-codepipeline)
+ [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 建置者資料中心：確保部署期間的回復安全](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [Amazon 建置者資料中心：使用持續交付加快腳步](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)