# 準備
**Topics**
+ [OPS 4 您如何設計工作負載以便了解其狀況？](w2aac19b5b7b5.md)
+ [OPS 5 您如何減少缺陷、幫助輕鬆修復，以及改善生產流程？](w2aac19b5b7b7.md)
+ [OPS 6 您如何緩解部署風險？](w2aac19b5b7b9.md)
+ [OPS 7 您如何知道自己準備好支援工作負載？](w2aac19b5b7c11.md)
# OPS 4 您如何設計工作負載以便了解其狀況？
設計工作負載，以便它為您提供了解其內部狀態所需的跨全部元件 (例如指標、日誌和追蹤) 的資訊。這讓您能在適當時機提供有效回應。
**Topics**
+ [OPS04-BP01 實作應用程式遙測](ops_telemetry_application_telemetry.md)
+ [OPS04-BP02 實作和設定工作負載遙測](ops_telemetry_workload_telemetry.md)
+ [OPS04-BP03 實作使用者活動遙測](ops_telemetry_customer_telemetry.md)
+ [OPS04-BP04 實作相依性遙測](ops_telemetry_dependency_telemetry.md)
+ [OPS04-BP05 實作交易可追溯性](ops_telemetry_dist_trace.md)
# OPS04-BP01 實作應用程式遙測
應用程式遙是工作負載可觀察性的基礎。您的應用程式應該發出遙測，讓您洞悉應用程式的狀態和業務成果的成就。從疑難排解到衡量新功能的影響，應用程式遙測可告知您建置、操作和發展工作負載的方式。
應用程式遙測由指標和日誌組成。指標是診斷資訊，就如您的脈搏或體溫。指標是共同用來描述應用程式的狀態。隨時間收集指標可以用來開發基準和偵測異常。日誌是應用程式傳送的訊息，其中關於內部狀態或發生的事件。錯誤碼、交易識別碼和使用者動作都是所記錄事件的範例。
**預期成果：**
+ 您的應用程式會發出指標和日誌，讓您洞悉其運作狀態和業務成果的成就。
+ 所有應用程式的指標和日誌會集中儲存在工作負載中。
**常用的反模式：**
+ 您的應用程式不會發出遙測。當發生錯誤時，您必須仰賴客戶來告知您。
+ 客戶已回報，您的應用程式沒有回應。不親自使用應用程式來了解目前的使用者體驗，您便沒有遙測功能，且無法確認問題存在或描述問題特性。
**建立此最佳實務的優勢：**
+ 您可以了解應用程式的運作狀態、使用者體驗，以及業務成果的成就。
+ 您可以快速反映應用程式運作狀態中的變更。
+ 您可以開發應用程式運作狀態趨勢。
+ 您可以做出明智的決策，改善您的應用程式。
+ 您可以更快地偵測並解決應用程式問題。
**若未建立此最佳實務，暴露的風險等級為：** 高
## 實作指引
實作應用程式遙測包含三個步驟：識別儲存遙測的位置、識別描述應用程式狀態的遙測，以及檢測要發出遙測的應用程式。
舉例來說，商務公司具有以微型服務為基礎的架構。作為架構設計程序的一部分，他們識別了應用程序遙測，而其會協助他們了解每個微型服務的狀態。例如，使用者購物車服務已發出遙測，其中包括關於新增到購物車、放棄購物車，以及將商品新增到購物車所需時間長度等事件。所有微型服務都會記錄錯誤、警告和交易資訊。遙測會傳送至 Amazon CloudWatch 進行儲存和分析。
**實作步驟**
第一步是針對工作負載中的應用程式識別儲存遙測的中心位置。如果您沒有現有的平台， [Amazon CloudWatch](https://aws.amazon.com/cloudwatch) 會提供遙測收集、儀表板、分析和事件產生功能。
若要識別您需要的遙測，請參考下列問題：
+ 我的應用程式的運作狀態是否良好？
+ 我的應用程式是否實現了業務成果？
您的應用程式應該發出日誌和指標，並共同回答這些問題。如果您無法使用現有的應用程式遙測來回答這些問題，請與商務和工程利害關係人合作，以建立可以回答這些問題的遙測清單。當識別並開發新的應用程式遙測時，您可以向 AWS 帳戶 團隊要求專家技術建議。
一旦識別了其他應用程式遙測，請與您的工程利害關係人合作，以檢測您的應用程式。 [適用於 Open Telemetry 的 AWS Distro](https://aws-otel.github.io/) 提供 API、程式庫和代理程式，收集應用程式遙測。 [此範例示範如何使用自訂指標檢測 JavaScript 應用程式。](https://aws-otel.github.io/docs/getting-started/js-sdk/metric-manual-instr)。
客戶若想要了解 AWS 提供的可觀察性服務，可以透過自己的 [一個觀察工作坊](https://catalog.workshops.aws/observability/en-US) 來運作或向其 AWS 帳戶 團隊要求支援來指引他們。此工作坊會透過 AWS 的可觀察性解決方案指引您，並提供如何使用它們的實際操作範例。
如需更深入探討應用程式遙測，請閱讀 Amazon Builder’s Library 中的 [偵測分散式系統，以了解運作狀態](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 一文。它會說明 Amazon 如何檢測應用程式，以及如何指引您開發自己的檢測指導方針。
**實作計劃的工作量：** 中
## 資源
**相關的最佳實務：**
[OPS04-BP02 實作和設定工作負載遙測](ops_telemetry_workload_telemetry.md) – 應用程式遙測是工作負載遙測的元件。若要了解整體工作負載的運作狀態，您必須了解構成工作負載之個別應用程式的運作狀態。
[OPS04-BP03 實作使用者活動遙測](ops_telemetry_customer_telemetry.md) – 使用者活動遙測通常是應用程式遙測的子集。新增至購物車事件、點擊流或已完成交易等使用者活動，可讓您洞悉使用者體驗。
[OPS04-BP04 實作相依性遙測](ops_telemetry_dependency_telemetry.md) – 相依性與應用程式遙測相關，而且可能會配備至您的應用程式。如果您的應用程式依賴 DNS 或資料庫等外部相依性，您的應用程式可以發出有關連線能力、逾時和其他事件的指標和日誌。
[OPS04-BP05 實作交易可追溯性](ops_telemetry_dist_trace.md) – 跨工作負載追蹤交易需要每個應用程式發出其如何處理共用事件的相關資訊。個別應用程式處理這些事件的方式是透過其應用程式遙測發出的。
[OPS08-BP02 定義工作負載指標](ops_workload_health_design_workload_metrics.md) – 工作負載遙測是工作負載的重要運作狀態指標。重要應用程式指標是工作負載指標的一部分。
**相關文件：**
+ [AWS Builders' Library – 偵測分散式系統，以瞭解運作狀態](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [適用於 OpenTelemetry 的 AWS Distro](https://aws-otel.github.io/)
+ [AWS Well-Architected 卓越營運支柱白皮書 – 設計遙測](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design-telemetry.html)
+ [使用篩選條件從日誌事件建立指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [使用 Amazon CloudWatch 實作記錄和監控](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/welcome.html)
+ [使用適用於 OpenTelemetry 的 AWS Distro 監控應用程式運作狀態和效能](https://aws.amazon.com/blogs/opensource/monitoring-application-health-and-performance-with-aws-distro-for-opentelemetry/)
+ [新增功能 – 如何使用 Amazon CloudWatch Agent 更好地監控自訂應用程式指標](https://aws.amazon.com/blogs/devops/new-how-to-better-monitor-your-custom-application-metrics-using-amazon-cloudwatch-agent/)
+ [AWS 的可觀測性](https://aws.amazon.com/products/management-and-governance/use-cases/monitoring-and-observability/)
+ [案例 – 將指標發佈至 CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/PublishMetrics.html)
+ [開始建置 – 如何有效率地監控您的應用程式](https://aws.amazon.com/startups/start-building/how-to-monitor-applications/)
+ [使用 CloudWatch 搭配 AWS SDK](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/sdk-general-information-section.html)
**相關影片：**
+ [AWS re:Invent 2021 - 可觀察性開放原始碼方式](https://www.youtube.com/watch?v=vAnIhIwE5hY)
+ [使用 CloudWatch Agent 從 Amazon EC2 執行個體收集指標和日誌](https://www.youtube.com/watch?v=vAnIhIwE5hY)
+ [如何輕鬆地為您的 AWS 工作負載設定應用程式監控 - AWS 線上技術會談](https://www.youtube.com/watch?v=LKCth30RqnA)
+ [精通無伺服器應用程式的可觀察性 - AWS 線上技術會談](https://www.youtube.com/watch?v=CtsiXhiAUq8)
+ [搭配 AWS 的開放原始碼可觀察性 - AWS 虛擬研討會](https://www.youtube.com/watch?v=vAnIhIwE5hY)
**相關範例：**
+ [AWS 記錄和監控範例資源](https://github.com/aws-samples/logging-monitoring-apg-guide-examples)
+ [AWS 解決方案：Amazon CloudWatch 監控架構](https://aws.amazon.com/solutions/implementations/amazon-cloudwatch-monitoring-framework/?did=sl_card&trk=sl_card)
+ [AWS 解決方案︰集中式記錄](https://aws.amazon.com/solutions/implementations/centralized-logging/)
+ [一個觀察工作坊](https://catalog.workshops.aws/observability/en-US)
# OPS04-BP02 實作和設定工作負載遙測
設計和設定您的工作負載，以發出有關其內部狀態和當前狀況的資訊，例如 API 呼叫量、HTTP 狀態碼和擴展事件。使用此資訊來協助確定何時需要回應。
使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 這類服務彙總工作負載元件的日誌和指標 (例如， [AWS CloudTrail 的 API 日誌](https://aws.amazon.com/cloudtrail/)、 [AWS Lambda 指標](https://docs.aws.amazon.com/lambda/latest/dg/lambda-monitoring.html)， [Amazon VPC 流程日誌](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)和 [其他服務](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/aws-services-sending-logs.html)) 建立持續整合/持續部署 (CI/CD) 管道。
**常用的反模式：**
+ 您的客戶在抱怨效能不佳。您的應用程式最近無變更，因此您懷疑工作負載元件發生問題。您沒有可分析的遙測資料，以判斷哪個或哪些元件造成效能不佳。
+ 您的應用程式無法連線。您缺乏遙測資料來判斷它是否為網路問題。
**建立此最佳實務的優勢：** 了解工作負載內部發生的情況，讓您可以視需要做出回應。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 實作日誌和指標遙測：檢測您的工作負載，以發出有關其內部狀態、狀況和業務成果實現情況的資訊。使用此資訊來確定何時需要回應。
+ [使用 Amazon CloudWatch 更好地了解您的 VM - AWS 線上技術會談](https://youtu.be/1Ck_me4azMw)
+ [Amazon CloudWatch 的運作方式](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_architecture.html)
+ [什麼是 Amazon CloudWatch？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [使用 Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [什麼是 Amazon CloudWatch Logs？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ 實作和設定工作負載遙測：設計和設定您的工作負載，以發出有關其內部狀態和當前狀況的資訊 (例如 API 呼叫量、HTTP 狀態碼和擴展事件)。
+ [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [什麼是 AWS CloudTrail？](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
+ [VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
## 資源
**相關文件：**
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [Amazon CloudWatch 文件](https://docs.aws.amazon.com/cloudwatch/index.html)
+ [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Amazon CloudWatch 的運作方式](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_architecture.html)
+ [使用 Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
+ [什麼是 AWS CloudTrail？](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
+ [什麼是 Amazon CloudWatch Logs？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ [什麼是 Amazon CloudWatch？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
**相關影片：**
+ [AWS 上的應用程式效能管理](https://www.youtube.com/watch?v=5T4stR-HFas)
+ [使用 Amazon CloudWatch 更好地了解您的 VM](https://youtu.be/1Ck_me4azMw)
+ [使用 Amazon CloudWatch 更好地了解您的 VM - AWS 線上技術會談](https://youtu.be/1Ck_me4azMw)
# OPS04-BP03 實作使用者活動遙測
檢測您的應用程式程式碼，以發出有關使用者活動的資訊 (例如，點按流或已開始、已放棄和已完成的交易)。使用此資訊來了解應用程式如何被使用、使用模式以及確定何時需要回應。
**常用的反模式：**
+ 您的開發人員已部署新功能，而不需使用者遙測功能，而且使用率也已提升。您無法判斷提高的使用率是來自新功能的使用，還是新程式碼產生的問題。
+ 您的開發人員已部署新功能，而不需使用者遙測功能。若不主動詢問您的客戶，您無法判斷客戶是否正在使用它。
**建立此最佳實務的優勢：** 了解客戶如何使用您的應用程式來識別使用模式、意外行為，並讓您能夠在必要時做出回應。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
+ 實作使用者活動遙測：設計您的應用程式程式碼，以發出有關使用者活動的資訊 (例如，點按流或已開始、已放棄和已完成的交易)。使用此資訊來了解應用程式如何被使用、使用模式以及確定何時需要回應。
# OPS04-BP04 實作相依性遙測
設計和設定您的工作負載，以發出有關其相依資源之狀態 (例如，可達性或回應時間) 的資訊。外部相依性的範例可包含外部資料庫、DNS 和網路連線。使用此資訊來確定何時需要回應。
**常用的反模式：**
+ 若未手動執行檢查來查看您的 DNS 供應商是否正常運作，您將無法判斷應用程式無法存取的原因是否是 DNS 問題。
+ 您的購物車應用程式無法完成交易。如果沒有聯絡信用卡處理供應商進行驗證，您就無法判斷是否是供應商的問題。
**建立此最佳實務的優勢：** 了解依存項目的運作狀態，讓您可以視需要做出回應。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 實作相依性遙測：設計和設定您的工作負載，以發出有關其所依賴系統的狀態和狀況的資訊。此處提供的一些範例包括：外部資料庫、DNS、網路連線和外部信用卡處理服務。
+ [Amazon CloudWatch Agent 與 AWS Systems Manager 整合 - 適用於 Linux 和 Windows 的統一指標和日誌收集](https://aws.amazon.com/blogs/aws/new-amazon-cloudwatch-agent-with-aws-systems-manager-integration-unified-metrics-log-collection-for-linux-windows/)
+ [使用 CloudWatch Agent 從 Amazon EC2 執行個體和內部部署伺服器收集指標和日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
## 資源
**相關文件：**
+ [Amazon CloudWatch Agent 與 AWS Systems Manager 整合 - 適用於 Linux 和 Windows 的統一指標和日誌收集](https://aws.amazon.com/blogs/aws/new-amazon-cloudwatch-agent-with-aws-systems-manager-integration-unified-metrics-log-collection-for-linux-windows/)
+ [使用 CloudWatch Agent 從 Amazon EC2 執行個體和內部部署伺服器收集指標和日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
**相關範例：**
+ [Well-Architected 實驗室 – 相依性監控](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_dependency_monitoring/)
# OPS04-BP05 實作交易可追溯性
實作您的應用程式程式碼並設定您的工作負載元件，以發出有關整個工作負載交易流的資訊。使用此資訊來確定何時需要回應，並幫助確定問題的根本原因。
在 AWS 上，您可以使用 [AWS X-Ray](https://aws.amazon.com/xray/)等分散式追蹤服務，在交易通過工作負載時收集和記錄追蹤、產生地圖以查看交易如何在不同的工作負載和服務之間流動、深入了解元件之間的關係，以及即時確定和分析問題。
**常用的反模式：**
+ 您已實作跨多個帳戶的無伺服器微型服務架構。您的客戶遇到了間歇性的效能問題。因為缺少讓您能找出應用程式中存在效能問題及造成問題原因的軌跡，所以您無法找出哪個函數或元件應該負責。
+ 您正嘗試判斷工作負載中效能瓶頸的位置，以便在開發工作中解決這些瓶頸。您無法查看應用程式元件和與其互動的服務之間的關係，以判斷瓶頸的位置，原因是您缺少讓自己可深入檢視影響應用程式效能的特定服務和路徑之軌跡。
**建立此最佳實務的優勢：** 了解工作負載中的交易流程，讓您可以了解工作負載交易的預期行為，以及工作負載中預期行為的變化，讓您能夠在必要時做出回應。
**若未建立此最佳實務，暴露的風險等級：** 低
## 實作指引
+ 實作交易可追溯性：設計您的應用程式和工作負載，以發出有關跨系統元件的交易流的資訊，例如交易階段、作用中元件和完成活動的時間。使用此資訊確定正在進行的活動、已經完成的活動以及已完成活動的結果。這可以幫助您確定何時需要回應。例如，某個元件內的交易回應時間比預期的長，可能表示該元件存在問題。
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [什麼是 AWS X-Ray？](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
## 資源
**相關文件：**
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [什麼是 AWS X-Ray？](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
# OPS 5 您如何減少缺陷、幫助輕鬆修復，以及改善生產流程？
採用改善改變生產流程的方法，藉此重構、快速提供品質意見回饋及修復錯誤。這會加快有助益的改變發揮作用的速度、限制部署問題，並快速識別和修復部署活動造成的問題。
**Topics**
+ [OPS05-BP01 使用版本控制](ops_dev_integ_version_control.md)
+ [OPS05-BP02 測試並驗證變更](ops_dev_integ_test_val_chg.md)
+ [OPS05-BP03 使用組態管理系統](ops_dev_integ_conf_mgmt_sys.md)
+ [OPS05-BP04 使用建置和部署管理系統](ops_dev_integ_build_mgmt_sys.md)
+ [OPS05-BP05 執行修補程式管理](ops_dev_integ_patch_mgmt.md)
+ [OPS05-BP06 共用設計標準](ops_dev_integ_share_design_stds.md)
+ [OPS05-BP07 實作用於提高程式碼品質的實務](ops_dev_integ_code_quality.md)
+ [OPS05-BP08 使用多個環境](ops_dev_integ_multi_env.md)
+ [OPS05-BP09 進行頻繁、細微和可逆的變更](ops_dev_integ_freq_sm_rev_chg.md)
+ [OPS05-BP10 完全自動化整合和部署](ops_dev_integ_auto_integ_deploy.md)
# OPS05-BP01 使用版本控制
使用版本控制來追蹤變更和發佈。
許多 AWS 服務都提供版本控制功能。使用修訂版或原始程式碼控制系統 (例如 [AWS CodeCommit](https://aws.amazon.com/codecommit/) )，管理程式碼和其他成品，例如基礎架構之版本控制的 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 範本。
**常用的反模式：**
+ 您已在工作站上開發和存放程式碼。您在遺失程式碼的工作站上發生無法復原的儲存失敗。
+ 在您的變更覆寫現有的程式碼之後，您需重新啟動應用程式，且它將無法再運作。您無法還原為變更版本。
+ 您對另一人需要編輯的報告檔案加上了寫入鎖定。他們會與您聯絡，要求您停止處理該檔案，以便他們完成任務。
+ 您的研究團隊一直在進行詳細的分析，以塑造您未來的工作。某人意外地將他們的購物清單儲存在最終報告中。您無法還原變更，且必須重新建立報告。
**建立此最佳實務的優勢：** 透過使用版本控制功能，您可以輕鬆回復為已知的良好狀態、舊版本，並限制資產遺失的風險。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 使用版本控制：在版本控制的儲存庫中維護資產。此舉可實現變更追蹤、新版本部署、對現有版本的變更偵測以及還原到先前的版本 (例如，在發生故障時復原到已知的良好狀態)。將組態管理系統的版本控制功能整合到您的程序中。
+ [AWS CodeCommit 簡介](https://youtu.be/46PRLMW8otg)
+ [什麼是 AWS CodeCommit？](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
## 資源
**相關文件：**
+ [什麼是 AWS CodeCommit？](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
**相關影片：**
+ [AWS CodeCommit 簡介](https://youtu.be/46PRLMW8otg)
# OPS05-BP02 測試並驗證變更
測試和驗證變更以幫助限制和偵測錯誤。自動化測試以減少由手動程序引起的錯誤，並減少測試工作量。
許多 AWS 服務都提供版本控制功能。使用修訂版或原始程式碼控制系統 (例如 [AWS CodeCommit](https://aws.amazon.com/codecommit/) )，管理程式碼和其他成品，例如基礎架構之版本控制的 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 範本。
**常用的反模式：**
+ 您將新程式碼部署到生產環境中，然後客戶開始來電，因為您的應用程式不再運作。
+ 您可以套用新的安全群組，以增強週邊安全。它在運作時隨附意外後果；您的使用者無法存取您的應用程式。
+ 您可以修改新函數所叫用的方法。另一個函數也依賴該方法，且不再運作。問題無法偵測到並進入生產環境。另一函數有一段時間不會被叫用，最後在生產環境中失敗，而無原因的任何關聯。
**建立此最佳實務的優勢：** 透過及早測試和驗證變更，您能以最低的成本來解決問題，並限制對客戶的影響。在部署前進行測試，可將引入的錯誤數量降到最低。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 測試並驗證變更：應該在生命週期的所有階段 (例如，開發、測試和生產) 測試變更並驗證結果。使用測試結果來確認新功能，並減輕失敗部署的風險和影響。自動執行測試和驗證，以確保檢閱的一致性，減少由手動程序引起的錯誤，並減少工作量。
+ [什麼是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [對 AWS CodeBuild 本機建置支援](https://aws.amazon.com/blogs/devops/announcing-local-build-support-for-aws-codebuild/)
## 資源
**相關文件：**
+ [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/)
+ [對 AWS CodeBuild 本機建置支援](https://aws.amazon.com/blogs/devops/announcing-local-build-support-for-aws-codebuild/)
+ [什麼是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
# OPS05-BP03 使用組態管理系統
使用組態管理系統進行和追蹤組態變更。這些系統可減少由手動程序引起的錯誤，並減少部署變更的工作量。
靜態組態管理在初始化資源時設定值，這些值預期在資源的整個生命週期內保持一致。部分範例包括在執行個體上設定 Web 或應用程式伺服器的組態，或定義 AWS 服務 (在 [AWS 管理主控台](https://docs.aws.amazon.com/awsconsolehelpdocs/index.html) 內) 的組態，或透過下列項目定義該組態： [AWS CLI](https://aws.amazon.com/cli/)。
動態組態管理在初始化時設定值，這些值可以預期在資源的整個生命週期內保持一致。例如，您可以設定功能切換，透過組態變更啟用程式碼中的功能，或者在事故期間變更日誌詳細資訊等級以擷取更多資料，然後在事故後改回來，這會消除目前不需要的日誌及其相關費用。
如果您在執行個體、容器、無伺服器功能或裝置上執行的應用程式中具有動態組態，則可以使用 [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) 跨您的環境管理和部署它們。
在 AWS 上，您可以使用 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 跨帳戶和區域持續監控 AWS [資源組態](https://docs.aws.amazon.com/config/latest/developerguide/aggregate-data.html)。它可讓您追蹤其組態歷史紀錄、了解組態變更如何影響其他資源、以及針對預期或所需的組態稽核它們，方法是使用 [AWS Config 規則](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) 和 [AWS Config 合規套件](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html)。
在 AWS 上，您可以使用 [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/) 等服務 (例如，AWS CodeCommit、 [AWS CodeBuild](https://aws.amazon.com/codebuild/)、 [AWS CodePipeline](https://aws.amazon.com/codepipeline/)、 [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)和 [AWS CodeStar](https://aws.amazon.com/codestar/)) 建立持續整合/持續部署 (CI/CD) 管道。
製作變更行事曆，並追蹤可能受到變更實作影響的計劃的重要業務或營運活動或事件。調整活動以管理這些計畫的風險。 [AWS Systems Manager 變更行事曆](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html) AWS Systems Manager 變更行事曆提供一種機制，可將時間區塊記錄為變更開啟或變更關閉， [以及紀錄原因，](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-calendar-share.html) 並與其他 AWS 帳戶 分享該資訊。AWS Systems Manager Automation 指令碼可設定為遵照變更行事曆狀態。
[AWS Systems Manager 維護時段](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html) 可用來在指定的時間排程 AWS SSM Run Command 或 Automation 指令碼、AWS Lambda 叫用或 AWS Step Functions 活動的效能。在變更行事曆中標記這些活動，以便將它們納入您的評估中。
**常用的反模式：**
+ 您跨機群手動更新 Web 伺服器組態，而且由於更新錯誤，許多伺服器無法回應。
+ 您在數小時內手動更新應用程式伺服器機群。變更期間的組態不一致會導致未預期的行為。
+ 某人已更新您的安全群組，無法再存取您的 Web 伺服器。若不知道發生了什麼變更，您需花大量時間來調查問題，從而延長復原的時間。
**建立此最佳實務的優勢：** 採用組態管理系統可減少進行和追蹤變更的工作量，以及手動程序造成的錯誤頻率。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
+ 使用組態管理系統：使用組態管理系統來追蹤和實作變更，以減少由手動程序引起的錯誤，並減少工作量。
+ [基礎設施組態管理](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [什麼是 AWS Config？](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS CloudFormation 簡介](https://youtu.be/Omppm_YUG2g)
+ [什麼是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [AWS OpsWorks](https://aws.amazon.com/opsworks/)
+ [什麼是 AWS OpsWorks？](https://docs.aws.amazon.com/opsworks/latest/userguide/welcome.html)
+ [AWS Elastic Beanstalk 簡介](https://youtu.be/SrwxAScdyT0)
+ [什麼是 AWS Elastic Beanstalk？](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html)
## 資源
**相關文件：**
+ [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html)
+ [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/)
+ [AWS OpsWorks](https://aws.amazon.com/opsworks/)
+ [AWS Systems Manager 變更行事曆](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html)
+ [AWS Systems Manager 維護時段](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html)
+ [基礎設施組態管理](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/)
+ [什麼是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [什麼是 AWS Config？](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [什麼是 AWS Elastic Beanstalk？](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html)
+ [什麼是 AWS OpsWorks？](https://docs.aws.amazon.com/opsworks/latest/userguide/welcome.html)
**相關影片：**
+ [AWS CloudFormation 簡介](https://youtu.be/Omppm_YUG2g)
+ [AWS Elastic Beanstalk 簡介](https://youtu.be/SrwxAScdyT0)
# OPS05-BP04 使用建置和部署管理系統
使用建置和部署管理系統。這些系統可減少由手動程序引起的錯誤，並減少部署變更的工作量。
在 AWS 中，您可以使用 [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/) 等服務 (例如，AWS CodeCommit、 [AWS CodeBuild](https://aws.amazon.com/codebuild/)、 [AWS CodePipeline](https://aws.amazon.com/codepipeline/)、 [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)和 [AWS CodeStar](https://aws.amazon.com/codestar/)) 建立持續整合/持續部署 (CI/CD) 管道。
**常用的反模式：**
+ 在開發系統中編譯程式碼之後，您將可執行檔複製到生產系統中，然後其無法啟動。本機日誌檔案指出其因缺少相依性而失敗。
+ 您在開發環境中使用新功能成功建置應用程式，並將程式碼提供給品質保證 (QA)。它的 QA 失敗，原因是它缺少靜態資產。
+ 在花費大量精力之後的星期五，您已在開發環境中成功手動建置應用程式，包括您新編碼的功能。在星期一，您無法重複讓您成功建置應用程式的步驟。
+ 您執行為新版本建立的測試。然後，您會在下週設定測試環境，並執行所有現有的整合測試，接著執行效能測試。新的程式碼具有無法接受的效能影響，必須重新開發，然後重新測試。
**建立此最佳實務的優勢：** 透過提供用於管理建置和部署活動的機制，您可以減少執行重複性任務的工作量，讓團隊成員專注於高價值的創意任務，並限制手動程序引入錯誤。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 使用建置和部署管理系統：使用建置和部署管理系統來追蹤和實作變更，以減少由手動流程引起的錯誤，並減少工作量。從程式碼簽入到建置、測試、部署和驗證，完全自動化整合和部署管道。此舉可減少前置時間，增加變更頻率，並降低工作量。
+ [什麼是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [軟體開發持續整合最佳實務](https://www.youtube.com/watch?v=GEPJ7Lo346A)
+ [Slalom：AWS 上適用於無伺服器應用程式的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE)
+ [AWS CodeDeploy 簡介 - 使用 Amazon Web Services 進行自動化軟體部署](https://www.youtube.com/watch?v=Wx-ain8UryM)
+ [什麼是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
## 資源
**相關文件：**
+ [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/)
+ [什麼是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [什麼是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
**相關影片：**
+ [軟體開發持續整合最佳實務](https://www.youtube.com/watch?v=GEPJ7Lo346A)
+ [AWS CodeDeploy 簡介 - 使用 Amazon Web Services 進行自動化軟體部署](https://www.youtube.com/watch?v=Wx-ain8UryM)
+ [Slalom：AWS 上適用於無伺服器應用程式的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE)
# OPS05-BP05 執行修補程式管理
執行修補程式管理以獲取功能，解決問題並保持遵循管控。自動化修補程式管理，以減少由手動程序引起的錯誤，並減少修補工作量。
修補程式和漏洞管理屬於您利益和風險管理活動的一部分。最好擁有不可變的基礎設施，並在已驗證的已知良好狀態下部署工作負載。如果這不可行，可選擇剩餘的方法，即實施修補程式。
更新機器映像、容器映像或 Lambda [或 Lambda 自訂執行階段和其他程式庫](https://docs.aws.amazon.com/lambda/latest/dg/security-configuration.html) 以移除漏洞，屬於修補程式管理的一部分。您 [應該](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) 使用 [EC2 Image Builder，](https://aws.amazon.com/image-builder/)管理適用於 Linux 或 Windows Server 映像的 Amazon Machine Image (AMIs) 更新。您可以使用 [Amazon Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) 搭配現有管道來 [管理 Amazon ECS 映像](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html) 和 [管理 Amazon EKS 映像](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_EKS.html)。AWS Lambda 包含 [版本](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html) 管理功能。
若未首先在安全環境中進行測試，就不應在生產系統上執行修補程式。只有在修補程式能夠支援營運或業務成果時，才應套用修補程式。在 AWS 上，您可以使用 [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 自動化受管系統的修補程序，以及 [使用 AWS Systems Manager 維護時段](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html)。
**常用的反模式：**
+ 您必須在兩小時內套用所有新的安全性修補程式，結果導致應用程式與修補程式不相容而致使多次停機。
+ 未修補的程式庫會導致意外後果，因為未知方利用其中的漏洞來存取您的工作負載。
+ 您自動修補開發人員環境，而未通知開發人員。您收到來自開發人員的多個投訴，開發人員表示其環境如預期停止運作。
+ 您尚未在持久性執行個體上修補商用現成軟體。當您有軟體問題並聯絡廠商時，他們會通知您該版本不受支援，您必須修補至特定程度才能獲得任何協助。
+ 您使用的加密軟體的最新修補程式可大幅改善效能。未修補的系統因未修補仍存在效能問題。
**建立此最佳實務的優勢：** 透過建立修補程式管理程序 (包括修補的條件和跨環境分佈的方法)，您將能夠實現其優勢並控制其影響。這樣一來，便能採用所需的功能和特性、消除問題，並持續遵循管控要求。實作修補程式管理系統和自動化，以減少部署修補程式的工作量，並限制手動程序引起的錯誤。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 修補程式管理：修補系統以補救問題，獲得所需的功能或特性，並保持符合管控政策和供應商支援要求。在不可變系統中，部署適當的修補程式集以實現所需的結果。自動化修補程式管理機制，以縮短修補時間，減少由手動程序引起的錯誤並降低修補工作量。
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
## 資源
**相關文件：**
+ [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/)
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
**相關影片：**
+ [AWS 上適用於無伺服器應用程式的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE)
+ [設計時考量 OPS](https://youtu.be/uh19jfW7hw4)
**相關範例：**
+ [Well-Architected 實驗室 – 庫存和修補程式管理](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/)
# OPS05-BP06 共用設計標準
在團隊之間共用最佳實務，以提高認識並最大化開發工作的效益。
在 AWS 上，可使用程式碼方法來定義和管理應用程式、運算、基礎設施和營運。如此一來，您可輕鬆進行發佈、分享及採用。
許多 AWS 服務和資源旨在跨帳戶進行分享，從而讓您可跨團隊分享已建立的資產和經驗。例如，您可將 [CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/cross-account.html) 儲存庫、 [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-permissions.html) 函數、 [Amazon S3 儲存貯體](https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-s3/)和 [AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html) 分享給特定帳戶。
發佈新資源或更新時，請使用 Amazon SNS 提供 [發佈通知](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html)。訂閱者可以使用 Lambda 獲得新版本。
如果您的組織中強制執行共用標準，則必須存在用於請求標準新增、變更及例外狀況的機制，以支援團隊的活動。如果沒有此選項，標準就會限制創新。
**常用的反模式：**
+ 您已建立自己的使用者身份驗證機制，且組織中的每一個其他開發團隊也是一樣。您的使用者必須針對要存取的系統的每一部分，維護一組單獨的登入資料。
+ 您已建立自己的使用者身份驗證機制，且組織中的每一個其他開發團隊也是一樣。必須滿足的新合規要求已加諸於您的組織。每個開發團隊現在都必須投資資源來實作新要求。
+ 您已建立自己的畫面版面配置，且組織中的每一個其他開發團隊也是一樣。您的使用者抱怨很難導覽不一致的介面。
**建立此最佳實務的優勢：** 使用共用標準來支援最佳實務之採用，並在標準滿足多個應用程式或組織的要求時，將開發工作的效益發揮到最大。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
+ 共用設計標準：在團隊之間分享現有的最佳實務、設計標準、檢查清單、操作程序以及指導和管控要求，以降低複雜性並最大化開發工作的收益。確保存在用於請求對設計標准進行變更、新增和例外的程序，以支援持續的改進和創新。確保團隊了解發佈的內容，以便他們可以利用內容，限制重新作業以及工作上徒勞無功。
+ [委託存取您的 AWS 環境](https://www.youtube.com/watch?v=0zJuULHFS6A&t=849s)
+ [共用 AWS CodeCommit 儲存庫](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-share-repository.html)
+ [輕鬆授權 AWS Lambda 函數](https://aws.amazon.com/blogs/compute/easy-authorization-of-aws-lambda-functions/)
+ [與特定 AWS 帳戶共用 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html)
+ [使用 AWS CloudFormation Designer URL 加速範本共用](https://aws.amazon.com/blogs/devops/speed-template-sharing-with-an-aws-cloudformation-designer-url/)
+ [搭配 Amazon SNS 使用 AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html)
## 資源
**相關文件：**
+ [輕鬆授權 AWS Lambda 函數](https://aws.amazon.com/blogs/compute/easy-authorization-of-aws-lambda-functions/)
+ [共用 AWS CodeCommit 儲存庫](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-share-repository.html)
+ [與特定 AWS 帳戶共用 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html)
+ [使用 AWS CloudFormation Designer URL 加速範本共用](https://aws.amazon.com/blogs/devops/speed-template-sharing-with-an-aws-cloudformation-designer-url/)
+ [搭配 Amazon SNS 使用 AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html)
**相關影片：**
+ [委託存取您的 AWS 環境](https://www.youtube.com/watch?v=0zJuULHFS6A&t=849s)
# OPS05-BP07 實作用於提高程式碼品質的實務
實作實務以提高程式碼品質並將缺陷降至最少。部分範例包括測試驅動的開發、程式碼檢閱和標準採用。
在 AWS 上，您可以整合 [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) 這類服務與管道，以自動 [識別潛在程式碼和安全問題，](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/how-codeguru-reviewer-works.html) 方法為使用程式分析和機器分學習。CodeGuru 提供如何實作 AWS 最佳實務來解決這些問題的建議。
**常用的反模式：**
+ 為了能夠更快測試您的功能，您已決定不整合您的標準輸入清理程式庫。測試之後，您忘記要完成程式庫合併，就遞交程式碼。
+ 對於正在處理的資料集，您的經驗不多，且不知道資料集中可能存在一連串邊緣案例。這些邊緣案例與您實作的程式碼不相容。
**建立此最佳實務的優勢：** 透過採用提高程式碼品質的實務，您可以協助將引入生產中的問題降至最低。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 實作用於提高程式碼品質的實務：實作實務以提高程式碼品質，將缺陷和缺陷被部署的風險降至最低。例如，測試驅動的開發、結對程式設計、程式碼審查和標准採用。
+ [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
## 資源
**相關文件：**
+ [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
# OPS05-BP08 使用多個環境
使用多個環境進行實驗、開發和測試您的工作負載。當環境接近生產環境時使用更高的控制等級，以確保您的工作負載在部署後將按預期執行。
**常用的反模式：**
+ 您在共享開發環境中進行開發，而另一名開發人員覆寫您的程式碼變更。
+ 對共享開發環境的限制性安全控制，讓您無法試驗新服務和功能。
+ 您對生產系統執行負載測試，並給使用者造成停機。
+ 在生產環境中發生導致資料遺失的嚴重錯誤。在您的生產環境中，您嘗試重新建立導致資料遺失的條件，以便您能夠識別其發生情況並防止再次發生。為防止更多資料在測試期間遺失，您必須讓使用者無法使用應用程式。
+ 您正在操作多租用戶服務，且無法支援客戶對專用環境的要求。
+ 您可能不一定總是進行測試，但當在生產環境中時，請務必測試。
+ 您認為簡單的單一環境會覆寫環境內變更的影響範圍。
**建立此最佳實務的優勢：** 透過部署多個環境，您可以支援多個同時開發、測試和生產環境，而不會在開發人員或使用者社群之間產生衝突。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 使用多個環境：為開發人員沙盒環境施加最少的控制，以推動實驗。提供多個單獨的開發環境，以使並行工作成為可能，從而提高開發敏捷性。在接近生產的環境中實作更嚴格的控制，以允許開發人員創新。使用基礎設施即程式碼和組態管理系統，以部署設定了與生產環境一致控制的環境，從而確保系統在部署時能夠按預期執行。當不使用環境時，關閉環境以避免與空閒資源相關的成本 (例如，在夜間和周末關閉開發系統)。進行負載測試時，部署與生產環境等效的環境，以獲得有效結果。
+ [什麼是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [如何使用 AWS Lambda 定期停止和啟動 Amazon EC2 執行個體？](https://aws.amazon.com/premiumsupport/knowledge-center/start-stop-lambda-cloudwatch/)
## 資源
**相關文件：**
+ [如何使用 AWS Lambda 定期停止和啟動 Amazon EC2 執行個體？](https://aws.amazon.com/premiumsupport/knowledge-center/start-stop-lambda-cloudwatch/)
+ [什麼是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
# OPS05-BP09 進行頻繁、細微和可逆的變更
頻繁、細微和可逆的變更會縮小變更的範圍和影響。這樣可以簡化故障診斷，實現更快的修復，並提供回復變更的選項。
**常用的反模式：**
+ 您在每一季都部署應用程式的新版本。
+ 您經常變更資料庫結構描述。
+ 您執行手動就地更新，並覆寫現有的安裝和組態。
**建立此最佳實務的優勢：** 您透過經常部署小的變更，更快認識到開發工作帶來的效益。當變更很小時，可更容易識別它們是否會產生意外的後果。如果變更可逆，由於復原得到簡化，實作變更的風險會更小。
**若未建立此最佳實務，暴露的風險等級為：** 低
## 實作指引
+ 進行頻繁、細微、可逆的變更：頻繁、細微和可逆的變更可縮小變更範圍和變更影響。這樣可以簡化故障診斷，實現更快的修復，並提供回復變更的選項。它還可以提高您為企業帶來價值的速度。
# OPS05-BP10 完全自動化整合和部署
自動化工作負載的建置、部署和測試。此舉可減少由手動程序引起的錯誤，以及部署變更的工作量。
依照一致的標記策略，使用 [資源標籤](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 和 [AWS Resource Groups](https://docs.aws.amazon.com/ARG/latest/APIReference/Welcome.html) 來套用 [中繼資料，](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/) 以識別您的資源。標記您的資源，以用於組織、成本會計、存取控制，以及將自動執行營運活動設為目標。
**常用的反模式：**
+ 週五，您完成了為功能分支編寫新程式碼。週一，在執行您的程式碼品質測試指令碼和每個單位測試指令碼之後，您將針對下一排程版本來檢查程式碼。
+ 系統會指派您編寫修正程式碼，以解決影響生產環境中大量客戶的重大問題。測試修正後，您遞交程式碼和電子郵件變更管理內容，以請求核准將其部署到生產環境中。
**建立此最佳實務的優勢：** 透過實作自動化建置和部署管理系統，您可以減少手動程序引起的錯誤，以及部署變更的工作量，讓您的團隊成員能夠專注於提供商業價值。
**若未建立此最佳實務，暴露的風險等級：** 低
## 實作指引
+ 使用建置和部署管理系統：使用建置和部署管理系統來追蹤和實作變更，以減少由手動流程引起的錯誤，並減少工作量。從程式碼簽入到建置、測試、部署和驗證，完全自動化整合和部署管道。此舉可減少前置時間，增加變更頻率，並降低工作量。
+ [什麼是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [軟體開發持續整合最佳實務](https://www.youtube.com/watch?v=GEPJ7Lo346A)
+ [Slalom：AWS 上適用於無伺服器應用程式的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE)
+ [AWS CodeDeploy 簡介 - 使用 Amazon Web Services 進行自動化軟體部署](https://www.youtube.com/watch?v=Wx-ain8UryM)
+ [什麼是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
## 資源
**相關文件：**
+ [什麼是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [什麼是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
**相關影片：**
+ [軟體開發持續整合最佳實務](https://www.youtube.com/watch?v=GEPJ7Lo346A)
+ [AWS CodeDeploy 簡介 - 使用 Amazon Web Services 進行自動化軟體部署](https://www.youtube.com/watch?v=Wx-ain8UryM)
+ [Slalom：AWS 上適用於無伺服器應用程式的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE)
# OPS 6 您如何緩解部署風險？
採用可快速提供品質意見回饋，並從成果不盡理想的改變中快速復原的方法。使用這些實務可緩解部署變更所帶來問題的影響。
**Topics**
+ [OPS06-BP01 為失敗變更進行規劃](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 測試並驗證變更](ops_mit_deploy_risks_test_val_chg.md)
+ [OPS06-BP03 使用部署管理系統](ops_mit_deploy_risks_deploy_mgmt_sys.md)
+ [OPS06-BP04 使用有限的部署進行測試](ops_mit_deploy_risks_test_limited_deploy.md)
+ [OPS06-BP05 使用平行環境進行部署](ops_mit_deploy_risks_deploy_to_parallel_env.md)
+ [OPS06-BP06 部署頻繁、細微和可逆的變更](ops_mit_deploy_risks_freq_sm_rev_chg.md)
+ [OPS06-BP07 完全自動化整合和部署](ops_mit_deploy_risks_auto_integ_deploy.md)
+ [OPS06-BP08 自動化測試和復原](ops_mit_deploy_risks_auto_testing_and_rollback.md)
# OPS06-BP01 為失敗變更進行規劃
計劃在變更未達到理想成果時，恢復到已知的良好狀態，或者在生產環境中進行補救。透過這樣準備可加快回應速度，以縮短復原時間。
**常用的反模式：**
+ 您執行了部署，而您的應用程式變得不穩定，但系統中似乎有作用中使用者。您必須決定是否要復原變更並影響作用中使用者，或在知道使用者無論如何都會受到影響的情況下，等待復原變更。
+ 在進行路由變更後，您可以存取新的環境，但其中一個子網路變成無法連線。您必須決定是否要復原所有項目，或嘗試修正無法存取的子網路。當您做出該決定時，子網路仍無法連線。
**建立此最佳實務的優勢：** 具有適當的計劃可減少從不成功變更中復原的平均時間 (MTTR)，從而減少對最終使用者的影響。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 為失敗變更進行規劃：計劃在變更未達到理想成果時，恢復到已知的良好狀態 (即回復變更)，或者在生產環境中進行補救 (即向前回復變更)。當您確定無法回復的變更時，在提交之前應進行盡職調查。
# OPS06-BP02 測試並驗證變更
在生命週期所有階段測試變更並驗證結果，以確認新功能，並將失敗部署的風險和影響降至最低。
在 AWS 上，您可以建立臨時平行環境，以降低試驗和測試的風險、工作量及成本。使用 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 自動化這些環境的部署，以確保臨時環境的一致實作。
**常用的反模式：**
+ 您為應用程式部署一個很酷的新功能。但它無法運作。您不知道。
+ 您更新憑證。您不小心將憑證安裝到錯誤的元件。您不知道。
**建立此最佳實務的優勢：** 透過在部署之後測試和驗證變更，您可以及早識別問題，藉此降低對客戶造成的影響。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 測試並驗證變更：在生命週期所有階段 (例如，開發、測試和生產) 測試變更並驗證結果，以確認新功能，並將失敗部署的風險和影響降至最低。
+ [AWS Cloud9](https://aws.amazon.com/cloud9/)
+ [什麼是 AWS Cloud9？](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html)
+ [在交付程式碼之前，如何在本機測試和偵錯 AWS CodeDeploy](https://aws.amazon.com/blogs/devops/how-to-test-and-debug-aws-codedeploy-locally-before-you-ship-your-code/)
## 資源
**相關文件：**
+ [AWS Cloud9](https://aws.amazon.com/cloud9/)
+ [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/)
+ [在交付程式碼之前，如何在本機測試和偵錯 AWS CodeDeploy](https://aws.amazon.com/blogs/devops/how-to-test-and-debug-aws-codedeploy-locally-before-you-ship-your-code/)
+ [什麼是 AWS Cloud9？](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html)
# OPS06-BP03 使用部署管理系統
使用部署管理系統來追蹤和實作變更。此舉可減少由手動程序引起的錯誤，以及部署變更的工作量。
在 AWS 中，您可以使用 [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/) 等服務 (例如，AWS CodeCommit、 [AWS CodeBuild](https://aws.amazon.com/codebuild/)、 [AWS CodePipeline](https://aws.amazon.com/codepipeline/)、 [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)和 [AWS CodeStar](https://aws.amazon.com/codestar/)) 建立持續整合/持續部署 (CI/CD) 管道。
**常用的反模式：**
+ 您手動將更新部署到跨整個機群的應用程式伺服器，而由於更新錯誤，許多伺服器無法回應。
+ 您在數小時內手動部署到應用程式伺服器機群。變更期間的版本不一致會造成未預期的行為。
**建立此最佳實務的優勢：** 採用部署管理系統可減少部署變更的工作量，以及手動程序造成的錯誤頻率。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
+ 使用部署管理系統：使用部署管理系統來追蹤並實作變更。這可減少由手動流程引起的錯誤，並減少部署變更的工作量。從程式碼簽入到測試、部署和驗證，自動化整合和部署管道。此舉可減少前置時間，增加變更頻率，並進一步降低工作量。
+ [AWS CodeDeploy 簡介 - 使用 Amazon Web Services 進行自動化軟體部署](https://www.youtube.com/watch?v=Wx-ain8UryM)
+ [什麼是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [什麼是 AWS Elastic Beanstalk？](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html)
+ [什麼是 Amazon API Gateway？](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)
## 資源
**相關文件：**
+ [AWS CodeDeploy 使用者指南](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/)
+ [在 AWS CodeDeploy 中嘗試範例藍/綠部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [什麼是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [什麼是 AWS Elastic Beanstalk？](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html)
+ [什麼是 Amazon API Gateway？](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)
**相關影片：**
+ [深入了解使用 AWS 的進階持續交付技術](https://www.youtube.com/watch?v=Lrrgd0Kemhw)
+ [AWS CodeDeploy 簡介 - 使用 Amazon Web Services 進行自動化軟體部署](https://www.youtube.com/watch?v=Wx-ain8UryM)
# OPS06-BP04 使用有限的部署進行測試
繼續現有系統現有系統的同時，在有限的部署中進行測試，以在大規模部署之前確認理想成果達成與否。例如，使用部署 Canary 測試或一體式部署。
**常用的反模式：**
+ 您一次性將失敗的變更部署至所有生產環境。您不知道。
**建立此最佳實務的優勢：** 透過在受限部署之後測試和驗證變更，您可以及早識別出問題，並將對客戶的影響降至最低，從而有機會進一步緩解對客戶的影響。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
+ 使用有限的部署進行測試：使用有限的部署搭配現有系統進行測試，以在大規模部署之前確認理想成果達成與否。例如，使用部署 Canary 測試或一體式部署。
+ [AWS CodeDeploy 使用者指南](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [使用 AWS Elastic Beanstalk 進行藍/綠部署](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)
+ [設定 API Gateway Canary 版本部署](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [在 AWS CodeDeploy 中嘗試範例藍/綠部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [在 AWS CodeDeploy 中使用部署組態](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
## 資源
**相關文件：**
+ [AWS CodeDeploy 使用者指南](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [使用 AWS Elastic Beanstalk 進行藍/綠部署](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)
+ [設定 API Gateway Canary 版本部署](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [在 AWS CodeDeploy 中嘗試範例藍/綠部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [在 AWS CodeDeploy 中使用部署組態](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
# OPS06-BP05 使用平行環境進行部署
在平行環境中實作變更，然後轉換到新環境。維護先前的環境，直到確認已成功部署為止。此舉可透過還原到先前的環境來將還原時間減至最少。
**常用的反模式：**
+ 您透過修改現有系統來執行可變部署。發現變更失敗之後，您必須再次修改系統以還原延長復原時間的舊版本。
+ 在維護時段期間，您停用舊環境，然後開始建置新的環境。執行程序多個小時之後，您發現部署無法復原的問題。雖然非常疲倦，但您仍被迫找到先前的部署程序，並開始重建舊環境。
**建立此最佳實務的優勢：** 透過使用平行環境，您可以預先部署新的環境，並在需要時轉換至這些環境。如果新環境不成功，您可以轉換回原始環境來快速復原。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
+ 使用平行環境進行部署：在平行環境上實作變更，然後轉換到切換新環境。維護先前的環境，直到確認已成功部署為止。此舉可透過還原到先前的環境來將還原時間減至最少。例如，將不可變的基礎架構用於藍/綠部署。
+ [在 AWS CodeDeploy 中使用部署組態](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
+ [使用 AWS Elastic Beanstalk 進行藍/綠部署](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)
+ [設定 API Gateway Canary 版本部署](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [在 AWS CodeDeploy 中嘗試範例藍/綠部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
## 資源
**相關文件：**
+ [AWS CodeDeploy 使用者指南](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [使用 AWS Elastic Beanstalk 進行藍/綠部署](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)
+ [設定 API Gateway Canary 版本部署](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [在 AWS CodeDeploy 中嘗試範例藍/綠部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [在 AWS CodeDeploy 中使用部署組態](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
**相關影片：**
+ [深入了解使用 AWS 的進階持續交付技術](https://www.youtube.com/watch?v=Lrrgd0Kemhw)
# OPS06-BP06 部署頻繁、細微和可逆的變更
透過頻繁、細微和可逆的變更來縮小變更範圍。透過回復變更，可以更輕鬆地進行故障診斷並加快修復速度。
**常用的反模式：**
+ 您在每一季都部署應用程式的新版本。
+ 您經常變更資料庫結構描述。
+ 您執行手動就地更新，並覆寫現有的安裝和組態。
**建立此最佳實務的優勢：** 您透過經常部署小的變更，更快認識到開發工作帶來的效益。當變更很小時，可更容易識別它們是否會產生意外的後果。如果變更可逆，由於復原得到簡化，實作變更的風險會更小。
**若未建立此最佳實務，暴露的風險等級：** 低
## 實作指引
+ 部署頻繁、細微、可逆的變更：透過頻繁、細微和可逆的變更來縮小變更範圍。透過回復變更，可以更輕鬆地進行故障診斷並加快修復速度。
# OPS06-BP07 完全自動化整合和部署
自動化工作負載的建置、部署和測試。此舉可減少由手動程序引起的錯誤，以及部署變更的工作量。
依照一致的標記策略，使用 [資源標籤](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 和 [AWS Resource Groups](https://docs.aws.amazon.com/ARG/latest/APIReference/Welcome.html) 來套用 [中繼資料，](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/) 以識別您的資源。標記您的資源，以用於組織、成本會計、存取控制，以及將自動執行營運活動設為目標。
**常用的反模式：**
+ 週五，您完成了為功能分支編寫新程式碼。週一，在執行您的程式碼品質測試指令碼和每個單位測試指令碼之後，您將針對下一排程版本來檢查程式碼。
+ 系統會指派您編寫修正程式碼，以解決影響生產環境中大量客戶的重大問題。測試修正後，您遞交程式碼和電子郵件變更管理內容，以請求核准將其部署到生產環境中。
**建立此最佳實務的優勢：** 透過實作自動化建置和部署管理系統，您可以減少手動程序引起的錯誤，以及部署變更的工作量，讓您的團隊成員能夠專注於提供商業價值。
**若未建立此最佳實務，暴露的風險等級：** 低
## 實作指引
+ 使用建置和部署管理系統：使用建置和部署管理系統來追蹤和實作變更，以減少由手動流程引起的錯誤，並減少工作量。從程式碼簽入到建置、測試、部署和驗證，完全自動化整合和部署管道。此舉可減少前置時間，增加變更頻率，並降低工作量。
+ [什麼是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [軟體開發持續整合最佳實務](https://www.youtube.com/watch?v=GEPJ7Lo346A)
+ [Slalom：AWS 上適用於無伺服器應用程式的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE)
+ [AWS CodeDeploy 簡介 - 使用 Amazon Web Services 進行自動化軟體部署](https://www.youtube.com/watch?v=Wx-ain8UryM)
+ [什麼是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [深入了解使用 AWS 的進階持續交付技術](https://www.youtube.com/watch?v=Lrrgd0Kemhw)
## 資源
**相關文件：**
+ [在 AWS CodeDeploy 中嘗試範例藍/綠部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [什麼是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [什麼是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
**相關影片：**
+ [軟體開發持續整合最佳實務](https://www.youtube.com/watch?v=GEPJ7Lo346A)
+ [深入了解使用 AWS 的進階持續交付技術](https://www.youtube.com/watch?v=Lrrgd0Kemhw)
+ [AWS CodeDeploy 簡介 - 使用 Amazon Web Services 進行自動化軟體部署](https://www.youtube.com/watch?v=Wx-ain8UryM)
+ [Slalom：AWS 上適用於無伺服器應用程式的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE)
# OPS06-BP08 自動化測試和復原
自動測試部署的環境，以確認理想成果達成與否。當無法實現結果時，自動還原到先前的良好狀態，以最大限度縮短還原時間，並減少由手動程序引起的錯誤。
**常用的反模式：**
+ 您將變更部署至工作負載。在看到變更完成之後，您開始部署後測試。在您看到它們完成之後，您會發現工作負載無法運作，且客戶中斷連線。然後您開始復原到之前的版本。經過長時間偵測問題後，手動重新部署會延長復原時間。
**建立此最佳實務的優勢：** 透過在部署之後測試和驗證變更，您可以立即識別出問題。透過自動復原至舊版本，將對客戶的影響降至最低。
**若未建立此最佳實務，暴露的風險等級：** 低
## 實作指引
+ 自動化測試和還原：自動測試部署的環境，以確認理想成果達成與否。當無法實現結果時，自動還原到先前的良好狀態，以最大限度縮短還原時間，並減少由手動程序引起的錯誤。例如，在部署後執行詳細的綜合使用者事務，驗證結果，並在失敗時復原。
+ [使用 AWS CodeDeploy 重新部署和回復部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html)
## 資源
**相關文件：**
+ [使用 AWS CodeDeploy 重新部署和回復部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html)
# OPS 7 您如何知道自己準備好支援工作負載？
評估工作負載、流程和程序及人員的營運準備度，了解工作負載相關營運風險。
**Topics**
+ [OPS07-BP01 確保人員能力](ops_ready_to_support_personnel_capability.md)
+ [OPS07-BP02 確保對營運準備度進行一致的審查](ops_ready_to_support_const_orr.md)
+ [OPS07-BP03 使用執行手冊執行程序](ops_ready_to_support_use_runbooks.md)
+ [OPS07-BP04 使用程序手冊來調查問題](ops_ready_to_support_use_playbooks.md)
+ [OPS07-BP05 做出部署系統和變更的明智決策](ops_ready_to_support_informed_deploy_decisions.md)
# OPS07-BP01 確保人員能力
建立一種機制，用於驗證您有適當數量受過培訓的人員來為營運需求提供支援。培訓人員並根據需要調整人員能力，以保持有效的支援。
您需要擁有足夠的團隊成員，以妥善應對所有活動 (包括隨時待命)。確保您的團隊具備取得成功所需的必要技能，並進行工作負載、操作工具和 AWS 的培訓。
AWS 提供了許多資源，包括 [AWS 入門資源中心](https://aws.amazon.com/getting-started/)， [AWS 部落格](https://aws.amazon.com/blogs/)， [AWS 線上技術會談](https://aws.amazon.com/getting-started/)， [AWS 活動和網路研討會](https://aws.amazon.com/events/)以及 [AWS Well-Architected 實驗室](https://wellarchitectedlabs.com/)，而這些資源均提供了可教育您的團隊的說明、範例和演練。此外， [AWS 培訓 和認證](https://aws.amazon.com/training/) 透過 AWS 基礎原理自主進度數位課程提供一些免費培訓。您還可以報名參加講師指導下的培訓，以進一步協助開發團隊的 AWS 技能。
**常用的反模式：**
+ 在沒有能夠支援使用中平台和服務的熟練團隊成員之情況下，部署工作負載。
+ 在預期支援時數內無團隊成員可用的情況下部署工作負載。
+ 在團隊成員休假或生病請假而無足夠團隊成員提供支援的情況下，部署工作負載。
+ 在未檢閱對支援該工作負載和其他工作負載之團隊成員的額外影響情況下，部署額外工作負載。
**建立此最佳實務的優勢：** 擁有熟練的團隊成員可有效支援您的工作負載。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 人員能力：驗證人員是否已經過充分培訓，可有效支援工作負載。
+ 團隊規模：確保擁有足夠且訓練有素的團隊成員，以妥善應對營運活動，包括隨時待命。
+ 團隊技能：確保您的團隊成員就 AWS、工作負載和營運工具獲得足夠培訓，可履行其職責。
+ [AWS 活動和網路研討會](https://aws.amazon.com/about-aws/events/)
+ [歡迎來到 AWS 培訓 培訓與認證](https://aws.amazon.com/training/)
+ 審查能力：隨著營運條件和工作負載變化，審查團隊的規模和技能，以確保有足夠能力維持卓越營運。進行調整以確保團隊規模和技能與團隊支援的工作負載的營運要求相匹配。
## 資源
**相關文件：**
+ [AWS 部落格](https://aws.amazon.com/blogs/)
+ [AWS 活動和網路研討會](https://aws.amazon.com/about-aws/events/)
+ [AWS 入門資源中心](https://aws.amazon.com/getting-started/)
+ [AWS 線上技術會談](https://aws.amazon.com/getting-started/)
+ [歡迎來到 AWS 培訓 培訓與認證](https://aws.amazon.com/training/)
**相關範例：**
+ [Well-Architected 實驗室](https://wellarchitectedlabs.com/)
# OPS07-BP02 確保對營運準備度進行一致的審查
使用營運準備度審查 (ORR)，來確認您可以運行工作負載。 ORR 是在 Amazon 開發的機制，可確認團隊是否可放心地運行工作負載。ORR 是使用需求檢查清單的審查和檢查程序。ORR 是一種自助服務體驗，團隊會透過此體驗來進行工作負載的認證。ORR 包含的最佳實務皆汲取我們多年來建置軟體所獲得的經驗。
ORR 檢查清單包含架構建議、營運程序、事件管理和發行品質。錯誤糾正 (CoE) 程序是這些項目的主要驅動要素。您專屬的事件後分析應有助於專屬 ORR 的發展。ORR 不只是遵循最佳實務，還能防止先前發生過的事件再發。最後，ORR 中也能夠包含安全性、管控和合規需求。
在工作負載啟動以全面供應前，並在整個軟體開發生命週期執行 ORR。在啟動前執行 ORR 可改善安全運行工作負載的能力。定期針對工作負載重新執行 ORR 可捕捉最佳實務中的任何偏移。您可以為新服務的推出制定 ORR 檢查清單，並為定期審查制定 ORR。此可協助您掌握新出現的最佳實務最新狀態，並採納從事件後分析獲得的經驗。隨著您可以更熟練地使用雲端後，您就可以在架構中建置 ORR 需求作為預設值。
**預期成果：** 您制定 ORR 檢查清單，內含組織的最佳實務。ORR 會在工作負載啟動前執行。ORR 會在工作負載生命週期的過程中定期執行。
**常見的反模式：**
+ 您啟動工作負載，但不知道自己是否能夠運行工作負載。
+ 啟動工作負載的認證中未納入管控和安全性需求。
+ 不會定期重新評估工作負載。
+ 工作負載啟動，但不需設置必要的程序。
+ 您可以在多個工作負載中看到重複出現的相同根本原因失敗。
**建立此最佳實務的優勢：**
+ 工作負載包含架構、程序和管理最佳實務。
+ 經驗已納入 ORR 程序中。
+ 工作負載啟動時，已設置必要的程序。
+ ORR 會在工作負載的整個軟體生命週期執行。
**若未建立此最佳實務的風險等級：** 高
## 實作指引
ORR 有兩個部分：程序和檢查清單。貴組織應採用 ORR 程序，並由執行主辦人支援此程序。至少，必須在工作負載啟動以全面供應前執行 ORR。在整個軟體開發生命週期執行 ORR，使其與最佳實務或新需求保持同步。ORR 檢查清單應包含組態項目、安全性和管控需求，以及來自貴組織的最佳實務。在經過一段時間後，您可以使用服務，例如 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)、 [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)，和 [AWS Control Tower 防護機制](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)，來將 ORR 中的最佳實務建置在防護機制中，以便自動偵測最佳實務。
**客戶範例**
在發生數個生產事件後，AnyCompany Retail 決定實作 ORR 程序。他們建立了一份檢查清單，其中由最佳實務、管控和合規需求，以及從中斷中汲取的經驗教訓所組成。在工作負載啟動前，新的工作負載會執行 ORR。每個工作負載每年都會使用一部分的最佳實務來執行 ORR，以便納入在 ORR 檢查清單中新增的最佳實務和需求。經過一段時間後，AnyCompany Retail 使用 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 來偵測最佳實務，進而縮短 ORR 程序的時間。
**實作步驟**
若要進一步了解 ORR，請閱讀 [「營運準備度審查 (ORR)」白皮書](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)。其中提供詳細的資訊，說明 ORR 程序的歷史、如何建立您專屬的 ORR 實務，以及如何制定 ORR 檢查清單。以下步驟是該文件的精簡版本。如需深入了解 ORR 是什麼，以及如何建立您專屬的 ORR，我們建議閱讀該白皮書。
1. 召集關鍵利害關係人，包含安全性、營運和開發等團隊的代表人員。
1. 請每位利害關係人提供至少一個需求。對於第一次的反覆測試，請嘗試將項目數限制在三十個以下。
+ [附錄 B：來自「營運準備度審查 (ORR)」白皮書的](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/appendix-b-example-orr-questions.html) ORR 問題範例包含您可以開始使用的範例問題。
1. 將需求集中放在試算表中。
+ 您可以使用 [在](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) AWS Well-Architected Tool 中 [使用自訂聚焦](https://console.aws.amazon.com/wellarchiected/) 來制定 ORR 並在帳戶和 AWS 組織之間進行共用。
1. 找出要在其中執行 ORR 的一個工作負載。啟動前的工作負載或內部工作負載是理想的選擇。
1. 演練 ORR 檢查清單，並記下任何所探索的項目。如果採取緩解措施，那就可能無法進行探索。對於缺少緩解措施的任何探索，請將那些探索新增至項目的待辦清單中，然後在啟動前加以實作。
1. 隨著時間持續在 ORR 檢查清單中新增最佳實務和需求。
使用 Enterprise Support 的 支援 客戶可請求 [「營運準備度審查」研討會](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) (透過其技術客戶經理)。研討會是互動式的 *逆向思維* 課程，可讓您制定自己的 ORR 檢查清單。
**實作計劃的工作量：** 高。在組織中採用 ORR 實務需要高層和利害關係人的支持。使用貴組織提供的各方意見，來建立和更新檢查清單。
## 資源
**相關的最佳實務：**
+ [OPS01-BP03 評估管控要求](ops_priorities_governance_reqs.md) – ORR 檢查清單原本就很適合用來管控需求。
+ [OPS01-BP04 評估合規要求](ops_priorities_compliance_reqs.md) – ORR 檢查清單中有時會包含合規需求。有些時候，它們會是獨立的程序。
+ [OPS03-BP07 適當地為團隊提供資源](ops_org_culture_team_res_appro.md) – 團隊能力是 ORR 需求的絕佳候選項。
+ [OPS06-BP01 為失敗變更進行規劃](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) – 啟動工作負載前，必須先建立回復或向前回復計劃。
+ [OPS07-BP01 確保人員能力](ops_ready_to_support_personnel_capability.md) – 若要支援工作負載，您必須具備所需的人員。
+ [SEC01-BP03 識別和驗證控制目標](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_control_objectives.html) – 安全性控制目標是絕佳的 ORR 需求。
+ [REL13-BP01 定義停機和資料遺失的復原目標](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_objective_defined_recovery.html) – 災難復原計劃是絕佳的 ORR 需求。
+ [COST02-BP01 根據貴組織的需求制定政策](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_policies.html) – 將成本管理政策納入 ORR 檢查清單是很棒的做法。
**相關文件：**
+ [AWS Control Tower - AWS Control Tower 中的防護機制](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)
+ [AWS Well-Architected Tool - 自訂聚焦](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html)
+ [Adrian Hornsby 提供的營運準備度審查範本](https://medium.com/the-cloud-architect/operational-readiness-review-template-e23a4bfd8d79)
+ [「營運準備度審查 (ORR)」白皮書](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)
**相關影片：**
+ [AWS 支援 為您提供支援 \$1 建立有效的營運準備度審查 (ORR)](https://www.youtube.com/watch?v=Keo6zWMQqS8)
**相關範例：**
+ [營運準備度審查 (ORR) 聚焦範例](https://github.com/aws-samples/custom-lens-wa-sample/tree/main/ORR-Lens)
**相關服務：**
+ [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)
+ [使用自訂聚焦](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html)
# OPS07-BP03 使用執行手冊執行程序
路由層 *執行手冊* 是為了實現特定結果而記錄的程序。執行手冊由一系列可供遵循以完成某項工作的步驟組成。早在航空器製造初期，操作過程中就會使用執行手冊。在雲端操作中，我們使用執行手冊來降低風險及達到預期成果。簡言之，執行手冊就是完成一項工作的檢查清單。
執行手冊是工作負載的運作不可或缺的部分。從新團隊成員的上線到部署主要版本，執行手冊無論由誰使用，都是可提供一致結果的編碼程序。執行手冊應在集中發佈，並隨著程序的演進而更新，因為更新執行手冊是變更管理程序的重要環節。其中也應包含關於問題發生時的錯誤處理、工具、許可、例外狀況和呈報的指引。
隨著組織的成熟，您可以開始將執行手冊自動化。請從簡短且常用的執行手冊開始著手。使用指令碼語言自動執行步驟，或使步驟較容易執行。前幾個執行手冊完成自動化後，您會專注於將較複雜的執行手冊自動化。經過一段時間後，您大多數的執行手冊應該都已做了某種程度的自動化。
**預期成果：** 您的團隊有一系列執行工作負載任務的逐步指南。執行手冊中包含預期成果、必要的工具和許可，以及錯誤處理指示。這些執行手冊會集中存放，並且經常更新。
**常見的反模式：**
+ 憑藉記憶完成程序中的每個步驟。
+ 手動部署變更而不使用檢查清單。
+ 不同的團隊成員執行相同程序，但使用的步驟不同，或結果不同。
+ 執行手冊失去與系統變更和自動化的同步。
**建立此最佳實務的優勢：**
+ 降低手動工作的錯誤率。
+ 以一致的方式執行操作：
+ 新的團隊成員可更快開始執行工作。
+ 可將執行手冊自動化以節省人力。
**未建立此最佳實務時的曝險等級：** 中
## 實作指引
根據組織的成熟度，執行手冊採取數種形式。其中至少應包含逐步說明文字文件。預期成果應明確指出。明確記載必要的特殊許可或工具。提供詳細指引，說明在發生狀況時應如何處理錯誤及呈報。列出執行手冊擁有者，並將其集中發佈。執行手冊列入文件後，應請團隊的其他成員加以執行，以進行驗證。隨著程序的演進，請根據您的變更管理程序更新執行手冊。
隨著組織逐漸成熟，您的文字執行手冊應該要自動化。使用諸如 [AWS Systems Manager 自動化的服務](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)，您可以將一般文字轉換為可對工作負載執行的自動化。這些自動化可作為事件的應變動作來執行，以降低您維持工作負載的操作負擔。
**客戶範例**
AnyCompany Retail 必須在軟體部署期間執行資料庫結構描述更新。雲端維運團隊與資料庫管理團隊共同建置用來手動部署這些變更的執行手冊。執行手冊以檢查清單格式列出了程序中的每個步驟。其中包含相關發生狀況時進行錯誤處理的章節。他們將執行手冊發佈於內部 Wiki，與其他執行手冊放在一起。雲端維運團隊規劃要在未來的衝刺期間將執行手冊自動化。
## 實作步驟
如果您沒有現有的文件儲存庫，版本控制儲存庫將是您開始建置執行手冊程式庫的絕佳選擇。您可以使用 Markdown 來建置執行手冊。我們提供了範例執行手冊範本，讓您用來開始建置執行手冊。
```
# 執行手冊標題 ## 執行手冊資訊 | 執行手冊 ID | 描述 | 使用的工具 | 特殊許可 | 執行手冊作者 | 上次更新日期 | 呈報 POC | |-------|-------|-------|-------|-------|-------|-------| | RUN001 | 此執行手冊的用途為何？ 預期成果為何？ | 工具 | 許可 | 您的名稱 | 2022-09-21 | 呈報名稱 | ## 步驟 1.步驟一 2.步驟二
```
1. 如果您沒有現有的文件儲存庫或 Wiki，請在您的版本控制系統中建立新的版本控制儲存庫。
1. 識別沒有執行手冊的程序。經常執行、步驟數較少，且失敗的影響程度不高的程序，就是理想的程序。
1. 在您的文件儲存庫中，使用範本建立新的草稿 Markdown 文件。填入 `「執行手冊標題」` 和必要欄位 (在 `「執行手冊資訊」底下)`。
1. 從第一個步驟開始，填入執行手冊的 `「步驟」` 部分。
1. 將執行手冊提供給團隊成員。讓他們使用執行手冊來驗證步驟。如有任何事項缺漏或需要釐清，請更新執行手冊。
1. 將執行手冊發佈至您的內部文件存放區。發佈後，請告知團隊和其他利害關係人。
1. 一段時間後，您會建置執行手冊程式庫。隨著該程式庫的擴增，您應開始設法將執行手冊自動化。
**實作計劃的工作量：** 低。執行手冊的最低標準是逐步文字指南。將執行手冊自動化可能會增加實作工作量。
## 資源
**相關的最佳實務：**
+ [OPS02-BP02 已為流程和程序識別擁有者](ops_ops_model_def_proc_owners.md)：執行手冊應有擁有者負責加以維護。
+ [OPS07-BP04 使用程序手冊來調查問題](ops_ready_to_support_use_playbooks.md)：執行手冊和程序手冊兩者相類似，但有一項顯著差異：執行手冊有預期成果。在許多情況下，當程序手冊識別出根本原因時，就會觸發執行手冊。
+ [OPS10-BP01 使用程序進行事件、事故和問題管理](ops_event_response_event_incident_problem_process.md)：執行手冊是良好事件、事故和問題管理實務的一部分。
+ [OPS10-BP02 每個提醒建立一個程序](ops_event_response_process_per_alert.md)：執行手冊和程序手冊應用來回應提醒。一段時間後，這些因應動作應該要自動化。
+ [OPS11-BP04 知識管理](ops_evolve_ops_knowledge_management.md)：維護執行手冊是知識管理的重要環節。
**相關文件：**
+ [使用自動化的執行手冊和程序手冊達成卓越營運](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+ [AWS Systems Manager：使用執行手冊](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [AWS 大型遷移的遷移程序手冊 - 任務 4：改進您的遷移執行手冊](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/task-four-migration-runbooks.html)
+ [使用 AWS Systems Manager 自動化執行手冊完成營運任務](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**相關影片：**
+ [AWS re:Invent 2019：執行手冊、事故報告和事故應變的 DIY 指南 (SEC318-R1)](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [如何使用 AWS \$1 Amazon Web Services 將 IT 營運自動化](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [將指令碼整合到 AWS Systems Manager 中](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**相關範例：**
+ [AWS Systems Manager：自動化演練](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [AWS Systems Manager：從最新的快照執行手冊還原根磁碟區](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-document-sample-restore.html)
+ [使用 Jupyter 筆記本和 CloudTrail Lake 建置 AWS 事故應變執行手冊](https://catalog.us-east-1.prod.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [Gitlab - 執行手冊](https://gitlab.com/gitlab-com/runbooks)
+ [Rubix - 用來在 Jupyter 筆記本中建置執行手冊的 Python 程式庫](https://github.com/Nurtch/rubix)
+ [使用 Document Builder 建立自訂執行手冊](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
+ [Well-Architected 實驗室：使用程序手冊和執行手冊將操作自動化](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
**相關服務：**
+ [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
# OPS07-BP04 使用程序手冊來調查問題
程序手冊是用來調查事件的逐步指南。事件發生時，我們會使用程序手冊來調查、確認影響範圍和找出根本原因。程序手冊可用於各種情境，從部署失敗到安全性事件皆涵蓋在內。在許多案例中，程序手冊可釐清根本原因，而執行手冊則用來緩解該根本原因。程序手冊是組織事件應變計劃的關鍵要素。
優良的程序手冊有幾個重要的特點。它會透過探索的過程來逐步引導使用者。請試著從各種角度思考，我們應遵循哪些步驟來診斷事件？ 透過程序手冊明確定義，在程序手冊中是否需要特殊工具或提高權限。制定溝通計劃，向利害關係人告知調查的最新狀態是關鍵要素。在無法釐清根本原因的狀況下，程序手冊應具備呈報計劃。如果已確定根本原因，程序手冊應指向執行手冊，後者會描述如何解決該根本原因。程序手冊應集中存放並定期維護。如果您使用程序手冊來發出特定警示，請為團隊提供警示中該程序手冊的指標。
隨著組織逐漸成熟，將程序手冊自動化。從涵蓋低風險事件的程序手冊開始。使用指令碼來自動化探索步驟。確保您有配套執行手冊來緩解常見的根本原因。
**預期成果：** 您的組織具備常見事件的程序手冊。該程序手冊存放在集中的位置，可供團隊成員使用。程序手冊會頻繁更新。對於任何已知的根本原因，都已建立配套執行手冊。
**常見的反模式：**
+ 調查事件並沒有標準的方法。
+ 團隊成員依賴肌肉記憶或機構知識，來針對失敗的部署進行疑難排解。
+ 新團隊成員會學習如何透過試錯來調查問題。
+ 各個團隊間並未共用調查問題的最佳實務。
**建立此最佳實務的優勢：**
+ 程序手冊可為您省下緩解事件所需的心力。
+ 不同的團隊成員可以使用相同的程序手冊，以一致的方式找出根本原因。
+ 您可以為已知的根本原因制定執行手冊，進而縮短復原時間。
+ 程序手冊可協助團隊成員更快開始做出貢獻。
+ 團隊可以透過可重複的程序手冊擴展其程序。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
您如何根據組織的成熟度來建立和使用程序手冊。如果您剛接觸雲端，請在中央文件儲存庫中建立文字形式的程序手冊。隨著組織逐漸成熟，您就可以透過 Python 之類的指令碼語言將程序手冊半自動化。您可以在 Jupyter 筆記本中執行這些指令碼來加快探索速度。先進的組織具有全自動化的程序手冊，這些手冊適用於透過執行手冊自動修復的常見問題。
透過列出在您工作負載中發生的常見事件，來開始建立程序手冊。為低風險以及根本原因的範圍已縮減至幾個問題的事件選擇程序手冊，然後開始。在您為較簡單情境建立程序手冊後，請接著嘗試風險較高或尚未確定根本原因的情境。
隨著組織逐漸成熟，應將您的文字程序手冊自動化。使用諸如 [AWS Systems Manager Automations 的服務](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)，可以將一般文字轉換為自動化。您可以針對工作負載執行這些自動化來加快調查速度。您可以啟動這些自動化來回應事件、縮短事件探索和解決的平均時間。
客戶可使用 [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 來回應事件。此服務提供單一介面，來分類事件、在探索和緩解期間通知利害關係人，並在整個事件期間進行合作。其使用 AWS Systems Manager Automations 來加快偵測和復原速度。
**客戶範例**
生產事件會影響 AnyCompany Retail。待命的工程師使用程序手冊來調查問題。隨著透過步驟取得進展時，該工程師會確保程序手冊中識別的重要利害關係人都能了解最新進展。他發現根本原因是後端服務中的一項競賽條件。該工程師使用執行手冊，重新啟動服務，使 AnyCompany Retail 重新上線。
## 實作步驟
如果您沒有現有的文件儲存庫，我們建議為程序手冊程式庫建立版本控制儲存庫。您可以使用 Markdown 建立程序手冊，Markdown 與多數程序手冊自動化系統都相容。如果您是從頭開始建立，請使用以下範例程序手冊範本。
```
# Playbook Title ## Playbook Info | Playbook ID | Description | Tools Used | Special Permissions | Playbook Author | Last Updated | Escalation POC | Stakeholders | Communication Plan | |-------|-------|-------|-------|-------|-------|-------|-------|-------| | RUN001 | What is this playbook for? What incident is it used for? | Tools | Permissions | Your Name | 2022-09-21 | Escalation Name | Stakeholder Name | How will updates be communicated during the investigation? | ## Steps 1.Step one 2.Step two
```
1. 如果您沒有現有的文件儲存庫或 Wiki，請在版本控制系統中為程序手冊建立新的版本控制儲存庫。
1. 找出需要調查的常見問題。應存在根本原因僅限於幾個問題的情境，解決方案的風險很低。
1. 使用 Markdown 範本，填寫 `程序手冊名稱` 區段以及程序手冊資訊 `下的欄位`。
1. 填寫疑難排解步驟。盡可能清楚說明要執行哪些動作或應調查哪些地方。
1. 將程序手冊提供給團隊成員，讓成員透過該手冊來進行驗證。如果缺少任何資訊或內容不清楚，請更新程序手冊。
1. 在文件儲存庫中發佈程序手冊，並通知團隊和任何利害關係人。
1. 此程序手冊程式庫會隨著您新增更多程序手冊而成長。在您有數本程序手冊後，請開始使用 AWS Systems Manager Automations 之類的工具來進行自動化，進而確保自動化和程序手冊都能保持同步。
**實作計劃的工作量：** 低。程序手冊應為集中存放的文字文件。越來越多發展成熟的組織會開始自動化程序手冊。
## 資源
**相關的最佳實務：**
+ [OPS02-BP02 已為流程和程序識別擁有者](ops_ops_model_def_proc_owners.md)：程序手冊應有擁有者，擁有者會負責維護這類手冊。
+ [OPS07-BP03 使用執行手冊執行程序](ops_ready_to_support_use_runbooks.md)：執行手冊和程序手冊兩者相類似，但有一項顯著差異：執行手冊有預期成果。在許多情況下，當程序手冊找出根本原因時，就會使用執行手冊。
+ [OPS10-BP01 使用程序進行事件、事故和問題管理](ops_event_response_event_incident_problem_process.md)：程序手冊是正常事件、事故和問題管理實務的一部分。
+ [OPS10-BP02 每個提醒建立一個程序](ops_event_response_process_per_alert.md)：執行手冊和程序手冊應用來回應警示。一段時間後，應將這些因應措施自動化。
+ [OPS11-BP04 知識管理](ops_evolve_ops_knowledge_management.md)：維護程序手冊是知識管理的重要環節。
**相關文件：**
+ [ 使用自動化的執行手冊和程序手冊達成卓越營運 ](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+ [AWS Systems Manager：使用執行手冊](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [ 使用 AWS Systems Manager Automation 執行手冊解決營運任務 ](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**相關影片：**
+ [AWS re:Invent 2019：執行手冊、事件報告和事件應變的 DIY 指南 (SEC318-R1) ](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [AWS Systems Manager Incident Manager - AWS 虛擬研討會 ](https://www.youtube.com/watch?v=KNOc0DxuBSY)
+ [ 將指令碼整合到 AWS Systems Manager 中 ](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**相關範例：**
+ [AWS 客戶程序手冊架構 ](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS Systems Manager：自動化演練 ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [ 使用 Jupyter 筆記本和 CloudTrail Lake 建置 AWS 事件應變執行手冊 ](https://catalog.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [ Rubix - 用來在 Jupyter 筆記本中建置執行手冊的 Python 程式庫 ](https://github.com/Nurtch/rubix)
+ [ 使用 Document Builder 建立自訂執行手冊 ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
+ [ Well-Architected 實驗室：使用程序手冊和執行手冊將操作自動化 ](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
+ [ Well-Architected 實驗室：使用 Jupyter 事件應變程序手冊 ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)
**相關服務：**
+ [AWS Systems Manager Automation ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
# OPS07-BP05 做出部署系統和變更的明智決策
評估團隊支援工作負載的能力以及工作負載對管控的遵從性。在確定是否轉換系統或將系統投入生產時，比照這些評估部署的收益。了解收益和風險，以做出明智決策。
事前剖析是一種演練，其中團隊會模擬失敗以開發緩解策略。使用事前剖析可預測失敗並適時建立程序。當您變更您用於評估工作負載的檢查清單時，請計劃如何處理不再合規的即時系統。
**常用的反模式：**
+ 在不了解工作負載中存在安全性風險的情況下，決定部署工作負載。
+ 在不了解工作負載是否符合您的管控和標準的情況下，決定部署工作負載。
+ 在不了解您的團隊是否能支援此工作負載的情況下，決定部署工作負載。
+ 在不了解工作負載對組織有何好處的情況下，決定部署工作負載。
**建立此最佳實務的優勢：** 擁有熟練的團隊成員可有效支援您的工作負載。
**若未建立此最佳實務，暴露的風險等級為：** 低
## 實作指引
+ 做出部署工作負載和變更的明智決策：評估團隊支援工作負載的能力以及工作負載對管控的合規性。在確定是否轉換系統或將系統投入生產時，比照這些評估部署的收益。了解收益和風險，並做出明智的決策。