

# 變更管理
<a name="a-change-management"></a>

**Topics**
+ [REL 6  如何監控工作負載資源？](w2aac19b9b9b5.md)
+ [REL 7  如何設計工作負載以適應需求變更？](w2aac19b9b9b7.md)
+ [REL 8  您如何實作變更？](w2aac19b9b9b9.md)

# REL 6  如何監控工作負載資源？
<a name="w2aac19b9b9b5"></a>

日誌和指標是深入了解工作負載運作狀態的強大工具。您可以設定工作負載以監控日誌和指標，並在超過閾值或發生重大事件時傳送通知。監控可讓您的工作負載識別何時會超過低效能閾值或發生故障，以便自動復原來回應。

**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 監控工作負載的所有元件 (產生)
<a name="rel_monitor_aws_resources_monitor_resources"></a>

 使用 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 相關的任何指標。 
+  依賴生產流量和簡單的運作狀態檢查來監控和評估工作負載狀態。 

 **建立此最佳實務的優勢：** 工作負載中的所有層級監控，可讓您更快速地預測和解決構成工作負載之元件中的問題。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

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

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)，您可以在客戶探索問題之前先行探索。 

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

 **相關的最佳實務：** 
+ [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 定義和計算指標 (彙總)
<a name="rel_monitor_aws_resources_notification_aggregation"></a>

 視需要儲存日誌資料並套用篩選條件以計算指標，例如特定日誌事件的計數，或是從日誌事件時間戳記計算的延遲。 

 Amazon CloudWatch 和 Amazon S3 可作為主要的彙總和儲存層。對於某些服務 (例如 AWS Auto Scaling 和 Elastic Load Balancing)，預設會為跨叢集或執行個體的 CPU 負載或平均請求延遲提供預設指標。對於 VPC Flow Logs 及 AWS CloudTrail 等串流服務，事件資料將轉寄到 CloudWatch Logs，且您需要定義和套用指標篩選條件以從事件資料中擷取指標。這為您提供時間序列資料，而此資料可作為您定義用於觸發提醒之 CloudWatch 警示的輸入。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  定義和計算指標 (彙總)。視需要儲存日誌資料並套用篩選條件以計算指標，例如特定日誌事件的計數，或是從日誌事件時間戳記計算的延遲 
  +  指標篩選條件會定義術語與模式，以在傳送到 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) 

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

 **相關文件：** 
+  [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 傳送通知 (即時處理和警示)
<a name="rel_monitor_aws_resources_notification_monitor"></a>

 當重大事件發生時，需要知道的組織會收到通知。 

 提醒可以傳送到 Amazon Simple Notification Service (Amazon SNS) 主題，然後推送給任何數量的訂閱者。例如，Amazon SNS 可以將提醒轉寄到電子郵件別名，以便技術人員可以回應。 

 **常用的反模式：** 
+  設定閾值太低的警示，導致傳送太多通知。 
+  不封存警示以供未來探索。 

 **建立此最佳實務的優勢：** 事件通知 (甚至是可回應和自動解決的通知) 可讓您擁有事件紀錄，並在未來可能以不同方式處理事件。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  執行即時處理和警示。當重大事件發生時，需要知道的組織會收到通知 
  +  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) 

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

 **相關文件：** 
+  [一個觀察工作坊](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 自動化回應 (即時處理和警示)
<a name="rel_monitor_aws_resources_automate_response_monitor"></a>

 偵測到事件時，使用自動化以採取動作，例如取代故障的元件。 

 提醒可以觸發 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 可以自動監控應用程式資源，以偵測異常行為並提供目標建議，以縮短問題識別和矯正時間。 

 **若未建立此最佳實務，暴露的風險等級：** 中 

## 實作指引
<a name="implementation-guidance"></a>
+  使用 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) 
+  建立和執行計畫以自動化回應。 
  +  清查您的所有提醒回應程序。您必須先規劃提醒回應，再將任務排名。
  +  以必須採取的特定動作清查所有任務。這些動作大多記錄在執行手冊中。您也必須擁有適用於意外事件提醒的程序手冊。
  +  檢查所有適用於自動化動作的執行手冊和程序手冊。一般而言，如果某個動作可以受到定義，則很可能可以進行自動化。
  +  將容易出錯或耗時的活動排在第一位。移除錯誤來源並縮短解決時間是最有益的。
  +  建立完成自動化的計畫。維護作用中的計畫以自動化和更新自動化。
  +  檢查自動化機會的手動需求。挑戰您的手動程序，以找出自動化的機會。

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

 **相關文件：** 
+  [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 分析
<a name="rel_monitor_aws_resources_storage_analytics"></a>

 收集日誌檔和指標歷史記錄，並分析這些檔案和歷史記錄，以了解更廣泛的趨勢和工作負載洞見。 

 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 智慧型分層儲存類別旨在透過自動將資料移至最經濟實惠的存取層來優化成本，而不會影響效能或營運開銷。 

 **若未建立此最佳實務，暴露的風險等級為：** 中 

## 實作指引
<a name="implementation-guidance"></a>
+  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) 

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

 **相關文件：** 
+  [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 定期進行審查
<a name="rel_monitor_aws_resources_review_monitoring"></a>

 經常審查工作負載監控的實作方式，並根據重大事件和變更進行更新。 

 有效的監控是由關鍵業務指標推動。當業務優先事項變更時，確保您的工作負載中會包含這些指標。 

 稽核您的監控有助於您知道應用程式何時達到其可用性目標。根本原因分析需要能夠發現發生故障時的具體情況。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/) 以隨機挑選要審查的工作負載。建立定期執行營運效能審查和知識共享的機制，可增強您從營運團隊獲得更高效能的能力。 

 **常用的反模式：** 
+  僅收集預設指標。 
+  設定監控策略，但絕不檢閱。 
+  部署重大變更時不討論監控。 

 **建立此最佳實務的優勢：** 定期檢閱監控可預期潛在問題，而不是在預期問題實際發生時對通知作出反應。 

 **若未建立此最佳實務，暴露的風險等級為：** 中 

## 實作指引
<a name="implementation-guidance"></a>
+  為工作負載建立多個儀表板。您必須擁有最上層儀表板，其中包含關鍵業務指標，以及經您確認與工作負載預估運作狀態最相關的 (因為用量不同) 技術指標。您也應該有可以檢查各種應用程式層和相依性的儀表板。 
  +  [使用 Amazon CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
+  排程及定期檢閱工作負載儀表板。定期執行儀表板檢查。您對於檢查深度可能有不同規律。 
  +  檢查指標中的趨勢。比較指標值與歷史值，以查看是否有可能指出某項需要調查的趨勢。這些範例包括：增加延遲、減少主要業務功能，以及增加失敗回應。
  +  檢查指標中的異常值/異常。平均值或中位數可以遮罩異常值。查看時間範圍內的最高和最低值，並調查極端分數的原因。隨著您持續消除這些原因，降低極端的定義可讓您持續改善工作負載效能的一致性。
  +  尋找行為中的急劇變化。指標的數量或方向立即變更，可能表示應用程式有所變更，或您可能需要新增其他指標以追蹤的外部因素。

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

 **相關文件：** 
+  [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 透過您的系統監控請求的端對端追蹤
<a name="rel_monitor_aws_resources_end_to_end"></a>

 使用 AWS X-Ray 或第三方工具，讓開發人員能夠更輕鬆地分析和偵錯分散式系統，以了解其應用程式及其基礎服務的執行成效。 

 **若未建立此最佳實務，暴露的風險等級：** 中 

## 實作指引
<a name="implementation-guidance"></a>
+  透過您的系統監控請求的端對端追蹤。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/) 

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

 **相關文件：** 
+  [使用 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  如何設計工作負載以適應需求變更？
<a name="w2aac19b9b9b7"></a>

可擴展工作負載提供自動新增或移除資源的彈性，以便隨時盡可能符合目前需求。

**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 取得或擴展資源時使用自動化
<a name="rel_adapt_to_changes_autoscale_adapt"></a>

 替換受損的資源或擴展工作負載時，請使用 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 群組以進行自動修復，但不實作彈性。 
+  使用自動調整規模來回應大幅增加的流量。 
+  部署高度狀態應用程式，免除彈性選項。 

 **建立此最佳實務的優勢：** 自動化會移除在部署和除役資源時可能出現的手動錯誤。自動化可免除因部署或除役需求回應緩慢而造成成本超支和拒絕服務的風險。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  設定和使用 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 存取。

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

 **相關文件：** 
+  [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 在偵測到工作負載受損時取得資源
<a name="rel_adapt_to_changes_reactive_adapt_auto"></a>

 在可用性受到影響時視需要主動擴展資源，以還原工作負載可用性。 

 您必須先設定運作狀態檢查和這些檢查的條件，以指出可用性因資源不足而受到影響的時間。然後，通知適當的人員手動擴展資源，或觸發自動化以自動調整資源規模。 

 您可以針對工作負載手動調整規模，例如，透過AWS 管理主控台或 AWS CLI 變更 Auto Scaling 群組中的 EC2 執行個體數量，或修改 DynamoDB 資料表的輸送量。但是，應該盡可能使用自動化 (請參閱 **取得或擴展資源時使用自動化**) 建立持續整合/持續部署 (CI/CD) 管道。 

 **若未建立此最佳實務，暴露的風險等級：** 中 

## 實作指引
<a name="implementation-guidance"></a>
+  在偵測到工作負載受損時取得資源。在可用性受到影響時視需要主動擴展資源，以還原工作負載可用性。 
  +  使用擴展計劃 (這是 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) 

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

 **相關文件：** 
+  [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 偵測到工作負載需要更多資源時取得資源
<a name="rel_adapt_to_changes_proactive_adapt_auto"></a>

 主動擴展資源以滿足需求並避免可用性影響。 

 許多 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 個執行個體才能因應需求。 

 **若未建立此最佳實務，暴露的風險等級為：** 中 

## 實作指引
<a name="implementation-guidance"></a>
+  偵測到工作負載需要更多資源時取得資源。主動擴展資源以滿足需求並避免可用性影響。 
  +  計算處理指定請求率所需的運算資源 (運算並行)。
    +  [說說「利特爾法則」的故事](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/) 

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

 **相關文件：** 
+  [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 對工作負載執行負載測試
<a name="rel_adapt_to_changes_load_tested_adapt"></a>

 採用負載測試方法來衡量擴展活動是否滿足工作負載要求。 

 重要的是執行持續的負載測試。負載測試應探索中斷點並和測試工作負載的效能。AWS 讓您可以輕鬆設定臨時測試環境，以塑造生產工作負載的規模。在雲端，您可隨需建立生產規模的測試環境、完成測試，再將資源除役。因為您只為執行中的測試環境付費，所以能以與內部部署測試相較之下相當微小比例的成本來模擬即時環境。 

 在生產系統承受壓力的演練日，以及客戶使用量較低的時間內，您也應考慮在生產中進行負載測試，並且讓可用的所有人員解釋結果並解決所發生的任何問題。 

 **常用的反模式：** 
+  在與生產組態不同的部署上執行負載測試。 
+  只對工作負載的個別部分而非整個工作負載執行負載測試。 
+  使用請求的子集而非代表的實際請求集合來執行負載測試。 
+  對高於預期負載的小型安全係數執行負載測試。 

 **建立此最佳實務的優勢：** 您會知道架構中的哪些元件在負載時失敗，並能夠識別要監看哪些指標，指出您正在及時處理該負載來解決問題，避免受到該故障的影響。 

 **若未建立此最佳實務，暴露的風險等級：** 中 

## 實作指引
<a name="implementation-guidance"></a>
+  執行負載測試，以識別工作負載的哪些層面指出您必須新增或移除容量。負載測試的代表性流量應該與您在生產環境中收到的流量相似。在觀看您已檢測的指標時增加負載，以判斷哪些指標指出何時必須新增或移除資源。 
  +  [AWS 上的分散式負載測試：模擬數千名連線的使用者](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) 
    +  識別請求混合。您可能會有不同的請求混合，因此您應該在識別流量混合時查看各種時間範圍。
    +  實作載入驅動程式。您可以使用自訂程式碼、開放原始碼或商業軟體實作載入驅動程式。
    +  最初使用小容量的負載測試。您將負載驅動到較小容量 (可能和單一執行個體或容器一樣小)，看到一些立即的影響。
    +  針對較大容量的負載測試。在分散式負載上的效果會有所不同，因此您必須盡可能在接近產品環境的條件下進行測試。

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

 **相關文件：** 
+  [AWS 上的分散式負載測試：模擬數千名連線的使用者](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) 

# REL 8  您如何實作變更？
<a name="w2aac19b9b9b9"></a>

需有控制變更以部署新功能，並確保工作負載和運作環境執行已知軟體，且能以可預測的方式修補或取代。如果這些變更不受控制，則難以預測這些變更的效果，或是解決肇因於這些變更的問題。 

**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 將執行手冊用於部署等標準活動
<a name="rel_tracking_change_management_planned_changemgmt"></a>

 執行手冊是實現特定成果的預定義程序。使用執行手冊執行手動或自動進行的標準活動。範例包括部署工作負載、修補工作負載或進行 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) 或滿足嚴格的報告和稽核要求。 

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

 **常用的反模式：** 
+  在生產環境中對組態執行非計畫中的變更。 
+  為了更快速地部署而略過計畫中的步驟，會導致部署失敗。 
+  在不測試變更反轉的情況下進行變更。 

 **建立此最佳實務的優勢：** 有效的變更規劃可提高您成功執行變更的能力，因為您知道所有受影響的系統。在測試環境中驗證變更可提高您的可信度。 

 **若未建立此最佳實務，暴露的風險等級為：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  透過在執行手冊中記錄程序，對熟知的事件做出一致且迅速的回應。 
  +  [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) 

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

 **相關文件：** 
+  [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 將功能測試整合為部署的一部分
<a name="rel_tracking_change_management_functional_testing"></a>

 功能測試會作為自動化部署的一部分執行。如果未符合成功條件，則會終止或回復管道。 

 這些測試會在生產前環境中執行，而且會在生產前暫存於管道中。理想情況下，這是做為部署管道的一部分來完成。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  將功能測試整合為部署的一部分。功能測試會作為自動化部署的一部分執行。如果未符合成功條件，則會終止或回復管道。 
  +  在 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) 

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

 **相關文件：** 
+  [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 將彈性測試整合為部署的一部分
<a name="rel_tracking_change_management_resiliency_testing"></a>

 彈性測試 (使用 [混沌工程的原則](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)。 

 **若未建立此最佳實務，暴露的風險等級：** 中 

## 實作指引
<a name="implementation-guidance"></a>
+  將彈性測試整合為部署的一部分。使用混沌工程，這是對工作負載進行實驗的專業領域，以建立可承受生產環境中的動盪條件能力的可信度。 
  +  彈性測試會注入故障或資源降級，以評估工作負載是否回應其設計的彈性。
    +  [Well-Architected 實驗室：第 300 級：測試 EC2 RDS 和 S3 的彈性](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html) 
  +  這些測試可以定期在自動化部署管道的生產前環境中執行。
  +  這些測試也應該在生產環境中執行，但是以演練日的一部分執行。
  +  使用混沌工程原則，提出各種損害下工作負載表現方式的假設，然後使用彈性測試來測試您的假設。
    +  [混沌工程的原則](https://principlesofchaos.org/) 

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

 **相關文件：** 
+  [混沌工程的原則](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 使用不可變基礎設施進行部署
<a name="rel_tracking_change_management_immutable_infrastructure"></a>

 不可變基礎設施會強制規定生產工作負載上不得就地進行更新、安全性修補程式或組態方面的變更。需要進行變更時，會在新的基礎設施上建置架構並部署到生產環境。 

 不可變基礎設施範例最常見的實作是 ***不可變的伺服器***。這表示如果伺服器需要更新或修正，則會部署新的伺服器，而非更新已在使用中的伺服器。因此，應用程式中的每個變更都會從軟體推送至程式碼儲存庫 (例如 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 並移除金鑰。這可減少攻擊向量，從而改善組織的安全狀態。 

 **若未建立此最佳實務，暴露的風險等級：** 中 

## 實作指引
<a name="implementation-guidance"></a>
+  使用不可變基礎設施進行部署。不可變基礎設施是一種模型，其中不會進行更新、安全性修補程式或組態方面的變更。 *就地* 進行更新、安全性修補程式或組態方面的變更。需要進行變更時，系統會建置新版本的架構並部署到生產環境。 
  +  [藍/綠部署概觀](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) 

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

 **相關文件：** 
+  [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 使用自動化部署變更
<a name="rel_tracking_change_management_automated_changemgmt"></a>

 部署和修補經過自動化以消除負面影響。 

 改變生產系統是許多組織的最大風險領域之一。我們認為，相較於軟體要解決的業務問題，部署才是我們要解決的首要問題。如今，這表示在營運中實際可行的地方使用自動化，包括測試和部署變更，新增或刪除容量以及移轉資料。AWS CodePipeline 讓您可以管理釋出工作負載所需的步驟。這包含使用 AWS CodeDeploy 的部署狀態，以自動將應用程式程式碼部署到 Amazon EC2 執行個體、內部部署執行個體、無伺服器 Lambda 函數或 Amazon ECS 服務。 

**建議**  
 儘管傳統觀點建議您將業內人員安排在營運程序中最困難的部分，但是出於這個原因，我們建議您能自動化最困難的程序。 

 **常用的反模式：** 
+  手動執行變更。 
+  在緊急工作流程中略過自動化步驟。 
+  不遵循您的計畫。 

 **建立此最佳實務的優勢：** 使用自動化部署所有變更可免除引進人為錯誤的可能性，並可在變更生產前進行測試，以確保您的計畫順利完成。 

 **若未建立此最佳實務，暴露的風險等級：** 中 

## 實作指引
<a name="implementation-guidance"></a>
+  自動化您的部署管道。部署管道讓您可以叫用自動測試、偵測異常，或者在生產部署之前的某個步驟中停止管道，或者自動回復變更。 
  +  [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) 

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

 **相關文件：** 
+  [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) 