# 準備
**Topics**
+ [OPS 4. 如何在工作負載中實作可觀測性？](ops-04.md)
+ [OPS 5. 如何減少缺陷、幫助輕鬆修復，以及改善生產流程？](ops-05.md)
+ [OPS 6. 如何緩解部署風險？](ops-06.md)
+ [OPS 7. 如何知道自己準備好支援工作負載？](ops-07.md)
# OPS 4. 如何在工作負載中實作可觀測性？
在工作負載中實作可觀測性，以便了解其狀態，並根據業務需求做出資料驅動的決策。
**Topics**
+ [OPS04-BP01 識別關鍵績效指標](ops_observability_identify_kpis.md)
+ [OPS04-BP02 實作應用程式遙測](ops_observability_application_telemetry.md)
+ [OPS04-BP03 實作使用者體驗遙測](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 實作相依性遙測](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 實作分散式追蹤](ops_observability_dist_trace.md)
# OPS04-BP01 識別關鍵績效指標
想在工作負載中實作可觀測性，要先了解工作負載狀態，並根據業務需求做出資料驅動型決策。確保監控活動與業務目標保持一致的最有效方法之一，是透過定義和監控關鍵績效指標 （KPIs）。
**預期成果：**有效率的可觀測性實務會與業務目標密切保持一致，確保監控工作始終能夠帶來實際的業務成果。
**常見的反模式：**
+ 未定義 KPIs：在沒有明確的情況下工作KPIs可能會導致監控太多或太少，遺失重要訊號。
+ 靜態 KPIs：不會KPIs隨著工作負載或業務目標的發展而重新檢視或精簡。
+ 未能保持一致：專注於與業務成果沒有直接關係的技術指標，或難與實際問題相關聯的技術指標。
**建立此最佳實務的優勢：**
+ 問題識別的易用性：企業KPIs通常會比技術指標更清晰地呈現問題。企業的下降KPI可以比篩選多個技術指標更有效找出問題。
+ 業務一致性：確保監控活動可直接支援業務目標。
+ 效率：優先監控資源並關注重要指標。
+ 主動積極：找出並解決問題，不讓問題擴大影響業務。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
若要有效定義工作負載KPIs：
1. **從業務成果開始著手：**在深入研究指標之前，請先了解預期業務成果。想要增加銷售量、提高使用者參與度，還是加快回應時間？
1. **將技術指標與業務目標相關聯：**並非所有技術指標都會直接影響業務成果。識別這樣做的人，但使用 業務 識別問題通常更為簡單KPI。
1. **使用 [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)：**使用 CloudWatch 來定義和監控代表您 的指標KPIs。
1. **定期檢閱和更新 KPIs：**隨著工作負載和業務的發展，請保持KPIs關聯。
1. **讓利益相關者參與：**讓技術和業務團隊參與定義和檢閱 KPIs。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS04-BP02 實作應用程式遙測](ops_observability_application_telemetry.md)
+ [OPS04-BP03 實作使用者體驗遙測](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 實作相依性遙測](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 實作分散式追蹤](ops_observability_dist_trace.md)
**相關文件：**
+ [AWS 可觀測性最佳實務 ](https://aws-observability.github.io/observability-best-practices/)
+ [ CloudWatch 使用者指南 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [AWS 可觀測性技能建置器課程 ](https://explore.skillbuilder.aws/learn/course/external/view/elearning/14688/aws-observability)
**相關影片：**
+ [研擬可觀測性策略](https://www.youtube.com/watch?v=Ub3ATriFapQ)
**相關範例：**
+ [一個可觀測性研討會](https://catalog.workshops.aws/observability/en-US)
# OPS04-BP02 實作應用程式遙測
應用程式遙測是工作負載可觀測性的基礎。發出遙測至關重要，它為您的應用程式狀態以及技術和業務成果的實現提供了可行洞見。從疑難排解到測量新功能的影響，或確保與業務金鑰效能指標 （KPIs） 保持一致，應用程式遙測會告知您建置、操作和發展工作負載的方式。
指標、日誌和追蹤構成了可觀測性的三個主要支柱。其可作為描述應用程式狀態的診斷工具。隨著時間的推移，它們有助於建立基準並識別異常。不過，為了確保監控活動與業務目標之間的一致性，定義和監控 至關重要KPIs。與技術指標相比，企業KPIs通常更容易識別問題。
其他遙測類型，例如真實使用者監控 （RUM） 和合成交易，可補充這些主要資料來源。RUM 提供即時使用者互動的洞見，而合成交易模擬潛在的使用者行為，有助於在實際使用者遇到瓶頸之前進行偵測。
**預期成果：**獲得工作負載效能且可付諸行動的洞見。這些洞見可讓您做出有關效能最佳化的主動決策、提高工作負載穩定性、使 CI/CD 程序更順暢，並且有效利用資源。
**常見的反模式：**
+ **不完整的可觀測性：**忽略在工作負載的每一層納入可觀測性，導致出現可能遮蔽重要系統效能和行為洞見的盲點。
+ **分散的資料檢視：**當資料分散在多個工具和系統中時，便難以提供涵蓋工作負載運作狀況和效能的全面概覽。
+ **使用者報告問題：**缺乏透過遙測和業務KPI監控主動偵測問題的跡象。
**建立此最佳實務的優勢：**
+ **知情決策：**透過遙測和業務的洞察KPIs，您可以做出資料驅動的決策。
+ **改善運作效率：**資料驅動的資源利用率可帶來成本效益。
+ **提高工作負載穩定性：**更快偵測並解決問題，進而改善正常運作。
+ **更順暢的 CI/CD 程序：**從遙測資料獲得的洞見，有助於改進程序並交付可靠的程式碼。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
若要為工作負載實作應用程式遙測，請使用 AWS [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 和 等服務[AWS X-Ray](https://aws.amazon.com/xray/)。Amazon CloudWatch 提供全方位的監控工具套件，可讓您在內部部署環境中觀察資源 AWS 和應用程式。還會收集、追蹤和分析指標、合併和監控日誌資料，並且回應資源的變更，以增進您對工作負載運作方式的了解。在串聯中， AWS X-Ray 可讓您追蹤、分析和偵錯應用程式，讓您深入了解工作負載的行為。透過服務地圖、延遲分佈和追蹤時間表等功能， AWS X-Ray 可讓您深入了解工作負載的效能和影響工作負載的瓶頸。
### 實作步驟
1. **確定要收集的資料：**確定可提供工作負載運作狀況、效能和行為實質洞見的重要指標、日誌和追蹤。
1. **部署[CloudWatch代理程式 ](https://aws.amazon.com/cloudwatch/)：**代理 CloudWatch 程式對於從您的工作負載及其基礎基礎設施中取得系統和應用程式指標和日誌至關重要。 CloudWatch 代理程式也可以用來收集 OpenTelemetry 或 X-Ray 追蹤，並將其傳送至 X-Ray。
1. **實作日誌和指標的異常偵測：**使用[CloudWatch 日誌異常偵測](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/LogsAnomalyDetection.html)和[CloudWatch指標異常偵測](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)，自動識別應用程式操作中的異常活動。這些工具使用機器學習演算法來偵測異常並發出提醒，進而提升監控能力，並加快對潛在中斷或安全威脅的回應時間。設定這些功能以主動管理應用程式運作狀態和安全性。
1. **安全敏感日誌資料：**使用 [Amazon CloudWatch Logs 資料保護](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/mask-sensitive-log-data.html)來遮罩日誌中的敏感資訊。此功能可在存取敏感資料前進行自動偵測和遮罩，從而有助於維護隱私權與合規性。實作資料遮罩，以安全地處理和保護敏感詳細資訊，例如個人識別資訊 （PII）。
1. **定義和監控業務 KPIs：**建立與您的[業務成果相符的](https://aws-observability.github.io/observability-best-practices/guides/operational/business/monitoring-for-business-outcomes/)[自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)。
1. **使用 來測試您的應用程式 AWS X-Ray：**除了部署 CloudWatch代理程式之外，[測試應用程式](https://docs.aws.amazon.com/xray/latest/devguide/xray-instrumenting-your-app.html)以發出追蹤資料也很重要。此程序可提供工作負載行為和效能的進一步洞見。
1. **將整個應用程式的資料收集標準化：**將整個應用程式的資料收集實務標準化。採取一致的方式有助於找出資料關聯並進行分析，進而提供應用程式行為的全面概覽。
1. **實作跨帳戶可觀測性：** AWS 帳戶 使用 [Amazon CloudWatch 跨帳戶可觀測性](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)增強跨多個 的監控效率。使用此功能，您可以將不同帳戶的指標、日誌和警示合併為單一檢視，可簡化管理並改善組織 AWS 環境中已識別問題的回應時間。
1. **分析資料並採取行動：**資料收集和標準化完成後，請使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/features/) 進行指標和日誌分析，以及[AWS X-Ray](https://aws.amazon.com/xray/features/)追蹤分析。這類分析可產生有關工作負載運作狀況、效能和行為的洞見，進而引導您進行決策。
**實作計劃的工作量：**高
## 資源
**相關的最佳實務：**
+ [OPS04-BP01 定義工作負載 KPIs](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_identify_kpis.html)
+ [OPS04-BP03 實作使用者活動遙測](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_customer_telemetry.html)
+ [OPS04-BP04 實作相依性遙測](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_dependency_telemetry.html)
+ [OPS04-BP05 實作交易可追蹤性](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_dist_trace.html)
**相關文件：**
+ [AWS 可觀測性最佳實務](https://aws-observability.github.io/observability-best-practices/)
+ [CloudWatch使用者指南](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [AWS X-Ray 開發人員指南](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [檢測分散式系統，以了解運作狀態](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility)
+ [AWS 可觀測性 Skill Builder 課程](https://explore.skillbuilder.aws/learn/course/external/view/elearning/14688/aws-observability)
+ [Amazon 的新功能 CloudWatch](https://aws.amazon.com/about-aws/whats-new/management-and-governance/?whats-new-content.sort-by=item.additionalFields.postDateTime&whats-new-content.sort-order=desc&awsf.whats-new-products=general-products%23amazon-cloudwatch)
+ [新功能 AWS X-Ray](https://aws.amazon.com/about-aws/whats-new/developer-tools/?whats-new-content.sort-by=item.additionalFields.postDateTime&whats-new-content.sort-order=desc&awsf.whats-new-products=general-products%23aws-x-ray)
**相關影片：**
+ [AWS re：Invent 2022 - Amazon 的可觀測性最佳實務](https://youtu.be/zZPzXEBW4P8)
+ [AWS re：Invent 2022 - 開發可觀測性策略](https://youtu.be/Ub3ATriFapQ)
**相關範例：**
+ [一個可觀測性研討會](https://catalog.workshops.aws/observability)
+ [AWS 解決方案庫：使用 Amazon 進行應用程式監控 CloudWatch](https://aws.amazon.com/solutions/implementations/application-monitoring-with-cloudwatch)
# OPS04-BP03 實作使用者體驗遙測
深入了解客戶體驗以及與應用程式的互動情形非常重要。實際使用者監控 （RUM） 和合成交易可做為此目的的強大工具。RUM 提供有關真實使用者互動的資料，授予使用者滿意度的未篩選觀點，而合成交易模擬使用者互動，即使在影響真實使用者之前，也有助於偵測潛在問題。
**預期成果：**提供使用者體驗、主動偵測問題及最佳化使用者互動的整體概觀，從而獲得順暢的數位體驗。
**常見的反模式：**
+ 沒有實際使用者監控的應用程式 （RUM）：
+ 延遲問題偵測：如果沒有 RUM，在使用者投訴之前，您可能不會發現效能瓶頸或問題。這種被動回應的方式可能導致客戶不滿意。
+ 缺乏使用者體驗洞察：不使用 RUM表示您遺失了關鍵資料，這些資料顯示真實使用者如何與您的應用程式互動，限制了您最佳化使用者體驗的能力。
+ 沒有綜合交易的應用程式：
+ 缺少邊緣案例：綜合交易可協助您測試一般使用者可能不常使用，但對於某些業務功能來說相當關鍵的路徑和功能。缺少的話，這些路徑可能無法正常運作並遭到忽視。
+ 在應用程式未使用的情況下檢查問題：定期綜合測試可模擬實際使用者未積極與您的應用程式互動的情況，進而確保系統隨時正常運作。
**建立此最佳實務的優勢：**
+ 主動偵測問題：找出並解決潛在問題，避免進一步影響實際使用者。
+ 最佳化使用者體驗：RUM協助精簡和增強整體使用者體驗的持續意見回饋。
+ 裝置和瀏覽器效能的相關洞見：了解您的應用程式在不同裝置和瀏覽器上的效能表現，以便進一步最佳化。
+ 經驗證的業務工作流程：定期綜合交易可確保核心功能和重要路徑維持正常且高效率的運作。
+ 增強應用程式效能：利用收集自實際使用者資料的洞見來改善應用程式回應能力和可靠性。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
為了利用 RUM和 合成交易進行使用者活動遙測， AWS 提供 [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 和 [Amazon CloudWatch Synthetics ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)等服務。指標、日誌和追蹤搭配使用者活動資料，可提供深入應用程式運作狀態和使用者體驗的全方位檢視。
### 實作步驟
1. **部署 Amazon CloudWatch RUM：**將應用程式與 CloudWatch RUM 整合，以收集、分析和呈現實際使用者資料。
1. 使用 [CloudWatch RUM JavaScript 程式庫](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)RUM與您的應用程式整合。
1. 設定儀表板以視覺化和監控實際使用者資料。
1. **設定 CloudWatch 合成：**建立 Canary 或指令碼常式，以模擬使用者與應用程式的互動。
1. 定義關鍵應用程式工作流程和路徑。
1. 使用 [CloudWatch Synthetics 指令碼](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)設計 Canary，以模擬這些路徑的使用者互動。
1. 排定依指定間隔執行 Canary 並進行監控，確保一致的效能檢查。
1. **分析資料並對資料採取行動：**利用 RUM和 合成交易中的資料來取得洞察，並在偵測到異常時採取修正措施。使用 CloudWatch 儀表板和警示來隨時掌握最新資訊。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS04-BP01 識別關鍵績效指標](ops_observability_identify_kpis.md)
+ [OPS04-BP02 實作應用程式遙測](ops_observability_application_telemetry.md)
+ [OPS04-BP04 實作相依性遙測](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 實作分散式追蹤](ops_observability_dist_trace.md)
**相關文件：**
+ [ Amazon CloudWatch RUM 指南 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [ Amazon CloudWatch Synthetics 指南 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
**相關影片：**
+ [ 使用 Amazon 透過最終使用者洞察最佳化應用程式 CloudWatch RUM ](https://www.youtube.com/watch?v=NMaeujY9A9Y)
+ [AWS Air ft 上的 。 Amazon 的真實使用者監控 CloudWatch ](https://www.youtube.com/watch?v=r6wFtozsiVE)
**相關範例：**
+ [一個可觀測性研討會](https://catalog.workshops.aws/observability/en-US/intro)
+ [ Amazon CloudWatch RUM Web Client 的 Git 儲存庫 ](https://github.com/aws-observability/aws-rum-web)
+ [ 使用 Amazon CloudWatch Synthetics 來測量頁面載入時間 ](https://github.com/aws-samples/amazon-cloudwatch-synthetics-page-performance)
# OPS04-BP04 實作相依性遙測
對於監控工作負載所依賴的外部服務和元件運作狀況與效能，相依性遙測至關重要，可提供連線能力、逾時，以及像是 DNS、資料庫或第三方 API 等其他與相依性相關重要事件的寶貴洞見。檢測應用程式以產生有關這些相依性的指標、日誌和追蹤，便可更清楚了解可能影響工作負載的潛在瓶頸、效能問題或故障。
**預期成果：**確保工作負載所依賴的相依性如預期般正常運作，讓您能夠主動解決問題並確保最佳的工作負載效能。
**常見的反模式：**
+ **忽略外部相依性：**僅關注內部應用程式指標，而忽略與外部相依性相關的指標。
+ **缺乏主動監控：**等待問題出現，而非持續監控相依性的運作狀況與效能。
+ **單獨運作的監控：**使用多種分散的監控工具，如此可能導致僅片段掌握相依性運作狀況且獲得的資訊不一致。
**建立此最佳實務的優勢：**
+ **改善工作負載可靠性：**確保外部相依性穩定運作並保持最佳效能。
+ **更快偵測並解決問題：**主動找出並解決相依性相關問題，不讓問題影響工作負載。
+ **全方位視角：**獲得全方位視角，有效掌握影響工作負載運作狀況的內部和外部元件。
+ **增強工作負載可擴展性：**了解外部相依性的可擴展性限制與效能特性。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
從識別您的工作負載所依賴的服務、基礎設施和程序開始，實作相依性遙測。將相依性正常運作時的良好條件量化，然後判斷衡量時所需的資料。有了這些資訊，您就可以打造儀表板並設定警示，以便為營運團隊提供這些相依性狀態的洞見。相依性無法按需求運作時，使用 AWS 工具探索並量化其影響。持續重新檢視您的策略，以考量優先順序、目標和獲得的洞見的變化。
### 實作步驟
若要有效實作相依性遙測：
1. **識別外部相依性：**與利益相關者協作，共同找出工作負載所依賴的外部相依性。外部相依性可能包含各種服務，像是外部資料庫、第三方 API、前往其他環境的網路連線能力路由，以及 DNS 服務。實現有效相依性遙測的第一步，就是徹底了解這些相依性。
1. **擬訂監控策略：**清楚了解外部相依性之後，就可以為其量身打造監控策略。這包括了解每一項相依性的重要性、預期行為，以及任何相關的服務層級協議或目標 (SLA 或 SLT)。設定主動警示，以便在發生狀態變更或效能偏差時通知您。
1. **使用[網路監控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Network-Monitoring-Sections.html)：**使用[網際網路監控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-InternetMonitor.html)和[網路監控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/what-is-network-monitor.html)，全面了解全球網際網路和網路狀況。這些工具可協助您了解並回應影響外部相依性的停機、中斷或效能降低。
1. **利用 [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) 隨時掌握新知：**AWS Health 是 AWS 雲端 資源運作狀態的權威資訊來源。使用 AWS Health 視覺化並接收有關任何目前服務事件和近期變更的通知 (例如規劃的生命週期事件)，如此您就能採取行動來緩解衝擊。
1. 透過 [AWS 使用者通知](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) [建立符合用途的 AWS Health 事件通知](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html)，以利用電子郵件和聊天管道傳送，並[透過 Amazon EventBridge 或 [AWS Health API](https://docs.aws.amazon.com/health/latest/APIReference/Welcome.html) 以程式設計方式與您的監控和警示工具整合](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)。
1. 透過 Amazon EventBridge 或 AWS Health API 整合變更管理或您可能已在使用的 ITSM 工具 (如 [Jira](https://docs.aws.amazon.com/smc/latest/ag/cloud-sys-health.html) 或 [ServiceNow](https://docs.aws.amazon.com/smc/latest/ag/sn-aws-health.html))，以規劃並追蹤需要採取行動的運作狀態事件進度。
1. 如果您使用 AWS Organizations，請啟用 [AWS Health 的組織檢視](https://docs.aws.amazon.com/health/latest/ug/aggregate-events.html)，以彙總帳戶之間的 AWS Health 事件。
1. **使用 [AWS X-Ray](https://aws.amazon.com/xray/) 檢測您的應用程式：**AWS X-Ray 提供了深入了解應用程式及其基礎相依性運作效能的洞見。透過從頭到尾追蹤請求，您就可以找出應用程式所依賴的外部服務或元件的瓶頸或故障。
1. **使用 [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/)：**這項機器學習驅動的服務可識別操作問題，預測重大問題可能在什麼時候發生，並且建議可採取的特定行動。對於獲得相依性洞見並確保其不是造成操作問題的根源來說，這項服務非常寶貴。
1. **定期監控：**持續監控與外部相依性相關的指標和日誌。針對非預期的行為或效能降低的情況設定警示。
1. **變更後驗證：**每當有任何外部相依性更新或變更，便驗證其效能並檢查是否符合您的應用程式需求。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS04-BP01 定義工作負載 KPI](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_identify_kpis.html)
+ [OPS04-BP02 實作應用程式遙測](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_application_telemetry.html)
+ [OPS04-BP03 實作使用者活動遙測](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_customer_telemetry.html)
+ [OPS04-BP05 實作交易可追溯性](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_dist_trace.html)
+ [OP08-BP04 建立可執行的提醒](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_workload_observability_create_alerts.html)
**相關文件：**
+ [Amazon Personal Health 儀板表 使用者指南](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html)
+ [AWS 網際網路監控使用者指南](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-InternetMonitor.html)
+ 《AWS X-Ray 開發人員指南》[https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [AWS DevOps Guru 使用者指南](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
**相關影片：**
+ [深入了解影響應用程式效能的網際網路問題](https://www.youtube.com/watch?v=Kuc_SG_aBgQ)
+ [Amazon DevOps Guru 簡介](https://www.youtube.com/watch?v=2uA8q-8mTZY)
+ [使用 AWS Health 大規模管理資源生命週期事件](https://www.youtube.com/watch?v=VoLLNL5j9NA)
**相關範例：**
+ [AWS Health Aware](https://github.com/aws-samples/aws-health-aware/)
+ [使用以標籤為基礎的篩選來大規模管理 AWS Health 監控和提醒](https://aws.amazon.com/blogs/mt/using-tag-based-filtering-to-manage-health-monitoring-and-alerting-at-scale/)
# OPS04-BP05 實作分散式追蹤
分散式追蹤可讓您監控和以視覺化的方式了解，在分散式系統中各種來回移動元件的請求。透過從多個來源擷取追蹤資料並在統一的檢視中進行分析，團隊就能更了解請求的流程、瓶頸出現的位置，以及最佳化工作應著重的地方。
**預期成果：**提供分散式系統請求流程的全面概覽，實現精確偵錯、最佳化效能，並改善使用者體驗。
**常見的反模式：**
+ 不一致的檢測：並非所有分散式系統中的服務都經過檢測可進行追蹤。
+ 忽略延遲：僅專注於錯誤，而未考慮延遲或效能逐漸降低的現象。
**建立此最佳實務的優勢：**
+ 全方位的系統概觀：從進入到退出，徹底視覺化整個請求路徑。
+ 強化偵錯：快速識別失敗或效能問題發生的位置。
+ 改善使用者體驗：根據實際使用者資料進行監控與最佳化，確保系統符合實際需求。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
首先，識別工作負載中需要檢測的所有元素。計算所有元件後，請利用 AWS X-Ray 和 等工具 OpenTelemetry 來收集追蹤資料，以便使用 X-Ray 和 Amazon CloudWatch ServiceLens Map 等工具進行分析。與開發人員進行定期檢閱，並使用 Amazon DevOpsGuru、X-Ray Analytics 和 X-Ray Insights 等工具來補充這些討論，以協助探索更深入的調查結果。從追蹤資料建立警示，以便在工作負載監視計畫中定義的結果存在風險時發出通知。
### 實作步驟
若要有效實作分散式追蹤：
1. **採用 [AWS X-Ray](https://aws.amazon.com/xray/)：**將 X-Ray 整合到您的應用程式中，以獲得深入其行為的洞見、了解效能，並且找出瓶頸的確切位置。利用 X-Ray Insights 進行自動化追蹤分析。
1. **測試您的服務：**確認從 [AWS Lambda](https://aws.amazon.com/lambda/)函數到[EC2執行個體 ](https://aws.amazon.com/ec2/)的每個服務都會傳送追蹤資料。您測試的服務越多，檢視越清晰 end-to-end。
1. **整合[CloudWatch 實際使用者監控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)和[合成監控 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)：**將實際使用者監控 （RUM） 和合成監控與 X-Ray 整合。這樣就能擷取實際使用者體驗並模擬使用者互動，以從中找出潛在問題。
1. **使用[CloudWatch 代理程式 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)：**代理程式可以從 X-Ray 或 傳送追蹤 OpenTelemetry，增強所取得洞見的深度。
1. **使用 [Amazon DevOpsGuru ](https://aws.amazon.com/devops-guru/)：** DevOpsGuru 使用 X-Ray 的資料 CloudWatch AWS Config， AWS CloudTrail 並提供可行的建議。
1. **分析追蹤：**定期檢閱追蹤資料，以找出可能影響應用程式效能的模式、異常或瓶頸。
1. **設定警示：**在 中設定警示[CloudWatch](https://aws.amazon.com/cloudwatch/)是否有異常模式或延長延遲，允許主動解決問題。
1. **持續改善：**隨著服務增加或修改重新檢視您的追蹤策略，以擷取所有相關資料點。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS04-BP01 識別關鍵績效指標](ops_observability_identify_kpis.md)
+ [OPS04-BP02 實作應用程式遙測](ops_observability_application_telemetry.md)
+ [OPS04-BP03 實作使用者體驗遙測](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 實作相依性遙測](ops_observability_dependency_telemetry.md)
**相關文件：**
+ [AWS X-Ray 開發人員指南 ](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [ Amazon CloudWatch 代理程式使用者指南 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
+ [ Amazon DevOpsGuru 使用者指南 ](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
**相關影片：**
+ [ 使用 AWS X-Ray Insights ](https://www.youtube.com/watch?v=tl8OWHl6jxw)
+ [AWS Air ft 上的 。 可觀測性：Amazon CloudWatch 和 AWS X-Ray](https://www.youtube.com/watch?v=qBDBnPkZ-KI)
**相關範例：**
+ [ 測試您的應用程式 AWS X-Ray](https://aws.amazon.com/xray/latest/devguide/xray-instrumenting-your-app.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 服務都提供版本控制功能。使用修訂版或[原始程式碼控制](https://aws.amazon.com/devops/source-control/)系統 (例如 [Git](https://aws.amazon.com/devops/source-control/git/)) 來管理程式碼和其他成品，例如基礎結構的版本控制 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 範本。
**期望的結果：**您的團隊在程式碼上進行協作。合併後，程式碼會是一致的，且變更不會遺失。透過正確的版本控制就能輕鬆復原錯誤。
**常見的反模式：**
+ 您已在工作站上開發和儲存程式碼。您的工作站發生無法復原的儲存錯誤，造成程式碼遺失。
+ 變更覆寫現有的程式碼之後，您重新啟動應用程式卻無法運作。您無法還原變更。
+ 您對其他人要編輯的報告檔案加上了寫入鎖定。他們會與您聯絡，要求您停止處理該檔案，以便完成任務。
+ 您的研究團隊一直在進行詳細的分析，以規劃您未來的工作。某人意外地將自己的購物清單儲存在最終報告中。您無法還原變更，且必須重新建立報告。
**建立此最佳實務的優勢：**透過使用版本控制功能，您可以輕鬆還原為已知的良好狀態和舊版本，並有效降低資產遺失的風險。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
在版本控制的儲存庫中維護資產。此舉可實現變更追蹤、新版本部署、對現有版本的變更偵測以及還原到先前的版本 (例如，在發生故障時復原到已知的良好狀態)。將組態管理系統的版本控制功能整合到您的程序中。
## 資源
**相關的最佳實務：**
+ [OPS05-BP04 使用建置和部署管理系統](ops_dev_integ_build_mgmt_sys.md)
**相關影片：**
+ [AWS re:Invent 2023 - Lockheed Martin 如何採用 DevSecOps 技術更快建置軟體](https://www.youtube.com/watch?v=Q1OSyxYkl5w)
+ [AWS re:Invent 2023 - GitHub 如何將 AI 營運化以應用到團隊協作和生產力](https://www.youtube.com/watch?v=cOVvGaiusOI)
# OPS05-BP02 測試並驗證變更
所部署的每項變更都必須經過測試，以避免在生產環境中發生錯誤。此一最佳實務著重於各種變更 (從版本控制到成品組建) 的測試。除了應用程式碼變更之外，測試應包括基礎設施、組態、安全控制和操作程序。測試採取多種形式，從單元測試到軟體元件分析 (SCA) 都包括在內。將測試進一步納入軟體整合和交付程序中，可進一步確保成品的品質。
您的組織必須針對所有軟體成品制定測試標準。自動化測試可減少辛勞並避免手動測試錯誤。在某些情況下可能需要手動測試。開發人員必須有權存取自動化測試結果，以建立可改善軟體品質的回饋迴圈。
**預期成果：**您的軟體變更在交付前都經過測試。開發人員有權存取測試結果和驗證。您的組織具有適用於所有軟體變更的測試標準。
**常見的反模式：**
+ 您在部署新軟體變更時未進行任何測試。它無法在生產環境中執行，這會導致中斷。
+ 新的安全群組透過 AWS CloudFormation 進行部署，而未在生產前環境中測試。安全群組會讓您的客戶無法存取您的應用程式。
+ 方法被修改，但沒有單元測試。軟體部署至生產環境時失敗。
**建立此最佳實務的優勢：**降低了軟體部署的變更失敗率。軟體品質獲得改善。開發人員更能感知其程式碼的可行性。可以安心推出安全政策，以支援組織的合規性。基礎設施變更 (例如自動化擴展政策更新) 會事先經過測試，以符合流量需求。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
作為持續整合實務的一部分，對從應用程式碼到基礎設施的所有變更進行測試。發布測試結果，以便開發人員快速獲得意見回饋。您的組織具有所有變更都必須通過的測試標準。
透過 Amazon Q Developer，利用生成式 AI 的強大功能，提升開發人員生產力和程式碼品質。Amazon Q Developer 包括程式碼建議的產生 (以大型語言模型為基礎)、單元測試的生產 (包括邊界條件)，以及透過偵測和修復安全漏洞增強程式碼安全性。
**客戶範例**
在其持續整合管道中，AnyCompany Retail 對所有軟體成品執行了數種類型的測試。他們實行測試驅動型開發，所以所有軟體都有單元測試。建置成品後，它們會執行端到端測試。在第一輪測試完成後，他們會執行靜態應用程式安全性掃描，以尋找已知的漏洞。通過每個測試門時，開發人員會收到訊息。所有測試都完成後，軟體成品即儲存在成品儲存庫中。
### 實作步驟
1. 與組織中的利益相關者合作制定軟體成品的測試標準。所有成品都應該通過哪些標準測試？ 測試涵蓋範圍中是否必須包含合規性或管控要求？ 您是否需要進行程式碼品質測試？ 測試完成時，誰需要得知？
1. [AWS 部署管道參考架構](https://pipelines.devops.aws.dev/)包含可在整合管道中對軟體成品執行之測試類型的授權清單。
1. 根據您的軟體測試標準，以必要的測試檢測您的應用程式。每組測試應在十分鐘內完成。測試應執行為整合管道的一部分。
1. 使用 [Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html)，這是一種生成式 AI 工具，可協助建立單元測試案例 (包括邊界條件)、使用程式碼和註解產生函數，以及實作眾所周知的演算法。
1. 使用 [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) 來測試您的應用程式碼是否存在故障。
1. 可使用 [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) 對軟體成品執行測試。
1. [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) 可將您的軟體測試安排到管道中。
## 資源
**相關的最佳實務：**
+ [OPS05-BP01 使用版本控制](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_version_control.html)
+ [OPS05-BP06 共用設計標準](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_share_design_stds.html)
+ [OPS05-BP07 實作用於提高程式碼品質的實務](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_code_quality.html)
+ [OPS05-BP10 完全自動化整合和部署](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_auto_integ_deploy.html)
**相關文件：**
+ [採用測試驅動的開發方法](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/development-best-practices.html)
+ [使用 Amazon Q 加速您的軟體開發生命週期](https://aws.amazon.com/blogs/devops/accelerate-your-software-development-lifecycle-with-amazon-q/)
+ [Amazon Q Developer 現已正式推出，包含可重新構想開發人員體驗的新功能預覽](https://aws.amazon.com/blogs/aws/amazon-q-developer-now-generally-available-includes-new-capabilities-to-reimagine-developer-experience/)
+ [在 IDE 中使用 Amazon Q Developer 的終極速查表](https://community.aws/content/2eYoqeFRqaVnk900emsknDfzhfW/the-ultimate-cheat-sheet-for-using-amazon-q-developer-in-your-ide)
+ [左移工作負載，利用 AI 建立測試](https://community.aws/content/2gBZtC94gPzaCQRnt4P0rIYWuBx/shift-left-workload-leveraging-ai-for-test-creation)
+ [Amazon Q 開發人員中心](https://aws.amazon.com/developer/generative-ai/amazon-q/)
+ [使用 Amazon CodeWhisperer 快速建置應用程式的 10 種方式](https://aws.amazon.com/blogs/devops/10-ways-to-build-applications-faster-with-amazon-codewhisperer/)
+ [使用 Amazon CodeWhisperer 超越程式碼覆蓋範圍](https://aws.amazon.com/blogs/devops/looking-beyond-code-coverage-with-amazon-codewhisperer/)
+ [使用 Amazon CodeWhisperer 進行提示詞工程的最佳實務](https://aws.amazon.com/blogs/devops/best-practices-for-prompt-engineering-with-amazon-codewhisperer/)
+ [使用 TaskCat 和 CodePipeline 的自動化 AWS CloudFormation 測試管道](https://aws.amazon.com/blogs/devops/automated-cloudformation-testing-pipeline-with-taskcat-and-codepipeline/)
+ [使用開放原始碼 SCA、SAST 和 DAST 工具建置端對端 AWS DevSecOps CI/CD 管道](https://aws.amazon.com/blogs/devops/building-end-to-end-aws-devsecops-ci-cd-pipeline-with-open-source-sca-sast-and-dast-tools/)
+ [開始測試無伺服器應用程式](https://aws.amazon.com/blogs/compute/getting-started-with-testing-serverless-applications/)
+ [CI/CD 管道是我的發行主管](https://aws.amazon.com/builders-library/cicd-pipeline/)
+ [《在 AWS 上實行持續整合和持續交付》白皮書](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html)
**相關影片：**
+ [使用適用於軟體開發的 Amazon Q Developer 代理程式來實作 API](https://www.youtube.com/watch?v=U4XEvJUvff4)
+ [使用 JetBrains IDE 安裝、設定和使用 Amazon Q Developer (操作說明)](https://www.youtube.com/watch?v=-iQfIhTA4J0)
+ [掌握 Amazon CodeWhisperer 的藝術 - YouTube 播放清單](https://www.youtube.com/playlist?list=PLDqi6CuDzubxzL-yIqgQb9UbbceYdKhpK)
+ [AWS re:Invent 2020：可測試的基礎設施：在 AWS 上進行整合測試](https://www.youtube.com/watch?v=KJC380Juo2w)
+ [AWS Summit ANZ 2021 - 透過 CDK 和測試驅動的開發施行測試優先策略](https://www.youtube.com/watch?v=1R7G_wcyd3s)
+ [使用 AWS CDK 測試基礎設施即程式碼](https://www.youtube.com/watch?v=fWtuwGSoSOU)
**相關資源：**
+ [AWS 部署管道參考架構 - 應用程式](https://pipelines.devops.aws.dev/application-pipeline/index.html)
+ [AWS Kubernetes DevSecOps 管道](https://github.com/aws-samples/devsecops-cicd-containers)
+ [使用 AWS CodeBuild 為 GitHub 中的 Node.js 應用程式執行單元測試](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/run-unit-tests-for-a-node-js-application-from-github-by-using-aws-codebuild.html)
+ [使用 Serverspec 進行基礎設施程式碼的測試驅動開發](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/use-serverspec-for-test-driven-development-of-infrastructure-code.html)
**相關服務：**
+ [Amazon Q Developer](https://aws.amazon.com/q/developer/)
+ [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
# OPS05-BP03 使用組態管理系統
使用組態管理系統進行和追蹤組態變更。這些系統可減少由手動程序引起的錯誤，並減少部署變更的工作量。
靜態組態管理會在初始化資源時設定值，這些值預期會在資源的整個生命週期內保持一致。動態組態管理會在初始化時設定值，這些值可能或是預期會在資源的整個生命週期內保持一致。例如，您可以設定功能切換，透過組態變更啟動程式碼中的功能，或在事件期間變更日誌詳細資訊等級。
組態應以已知且一致的狀態部署。應該使用自動化檢測來持續監控跨環境和區域的資源組態。這些控制項應定義為已自動化的程式碼和管理，以確保規則在各個環境中一致套用。組態變更應透過商定的變更控制程序進行更新，並一致地套用，以遵守版本控制。應用程式組態的管理應該獨立於應用程式和基礎設施程式碼。這允許在多個環境中進行一致的部署。組態變更不會導致重建或重新部署應用程式。
**預期成果：**您會在持續整合、持續交付 (CI/CD) 管道中進行設定、驗證和部署。您會進行監控，以確認組態正確無誤。這會將終端使用者和客戶受到的任何負面影響降到最低。
**常見的反模式：**
+ 您手動更新整個機群的 Web 伺服器組態，但由於更新錯誤，導致多部伺服器無法回應。
+ 您在數小時內手動更新應用程式伺服器機群。變更期間的組態不一致會導致未預期的行為。
+ 某人已更新您的安全群組，無法再存取您的 Web 伺服器。若不知道進行了哪些變更，您就需要花大量時間來調查問題，復原時間也會跟著拉長。
+ 您可以透過 CI/CD 將生產前組態推送到生產環境中，而不需進行驗證。您讓使用者和客戶面臨使用不正確的資料和服務。
**建立此最佳實務的優勢：**採用組態管理系統可減少進行和追蹤變更的工作量，以及手動程序造成的錯誤頻率。組態管理系統提供了管控、合規和法規需求方面的保證。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
組態管理系統可用來追蹤和實作應用程式與環境組態的變更。組態管理系統也可用來減少手動程序所造成的錯誤、讓組態變更可重複且可稽核，以及減少工作量。
在 AWS 上，可以使用 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 持續監控[跨帳號和區域](https://docs.aws.amazon.com/config/latest/developerguide/aggregate-data.html)的 AWS 資源組態。它可協助您追蹤其組態歷史記錄、了解組態變更如何影響其他資源、以及針對預期或所需的組態進行稽核，方法是使用 [AWS Config 規則](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) 和 [AWS Config Conformance Packs](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html)。
對於在 Amazon EC2 執行個體、AWS Lambda、容器、行動應用程式或 IoT 裝置上執行的應用程式中的動態組態，可以使用 [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) 在整個環境中進行設定、驗證、部署和監控。
### 實作步驟
1. 確定組態擁有者。
1. 讓組態擁有者得知任何合規、管控或法規需求。
1. 確定組態項目與交付成果。
1. 組態項目是指受到 CI/CD 管線內部署影響的所有應用程式和環境組態。
1. 交付成果包括成功條件、驗證及監控對象。
1. 請根據您的業務需求和交付管道選取工具來進行組態管理。
1. 請考慮針對重大組態變更進行加權部署 (例如 Canary 部署)，以盡量減少錯誤組態造成的影響。
1. 將組態管理整合到 CI/CD 管道中。
1. 驗證所有推送的變更。
## 資源
**相關的最佳實務：**
+ [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_auto_testing_and_rollback.md)
**相關文件：**
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS 登陸區域加速器](https://aws.amazon.com/solutions/implementations/landing-zone-accelerator-on-aws/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [ 什麼是 AWS Config？](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html)
+ [ 什麼是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/)
+ [AWS CodeBuild](https://aws.amazon.com/codebuild/)
+ [AWS CodePipeline](https://aws.amazon.com/codepipeline/)
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
**相關影片：**
+ [AWS re:Invent 2022 - AWS 工作負載的主動管控與合規](https://youtu.be/PpUnH9Y52X0?si=82wff87KHXcc6nbT)
+ [AWS re:Invent 2020：使用 AWS Config 實現合規即程式碼](https://youtu.be/m8vTwvbzOfw?si=my4DP0FLq1zwKjho)
+ [使用 AWS AppConfig 管理和部署應用程式組態](https://youtu.be/ztIxMY3IIu0?si=ovYGsxWOBysyQrg0)
# OPS05-BP04 使用建置和部署管理系統
使用建置和部署管理系統。這些系統可減少由手動程序引起的錯誤，並減少部署變更的工作量。
在 AWS 中，可以使用 [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/) (例如 [AWS CodeBuild](https://aws.amazon.com/codebuild/)、[AWS CodePipeline](https://aws.amazon.com/codepipeline/) 和 [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)) 等服務來建置持續整合/持續部署 (CI/CD) 管道。
**預期成果：**您的建置和部署管理系統可支援組織的持續整合持續交付 (CI/CD) 系統，提供了使用正確組態自動化安全推展的功能。
**常見的反模式：**
+ 在開發系統中編譯程式碼之後，您將可執行檔複製到生產系統中，卻無法啟動。本機日誌檔案指出其因缺少相依性而失敗。
+ 您在開發環境中使用新功能成功建置應用程式，並提供程式碼以進行品質保證 (QA)。它未通過 QA，因為缺少靜態資產。
+ 週五，在經過一番努力之後，您成功在開發環境中手動建置應用程式，包括新編碼的功能。到了週一，您卻無法重複成功建置應用程式的步驟。
+ 您執行為新版本建立的測試。然後，您會在下週設定測試環境，並執行所有現有的整合測試，接著執行效能測試。新的程式碼具有無法接受的效能影響，必須重新開發及測試。
**建立此最佳實務的優勢：**透過提供用於管理建置和部署活動的機制，您可以減少執行重複性任務的工作量，讓團隊成員專注於高價值的創意任務，並減少手動程序導致的錯誤。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
建置和部署管理系統可用來追蹤和實作變更、減少手動程序導致的錯誤，以及減少安全部署所需的工作量。從程式碼簽入到建置、測試、部署和驗證，完全自動化整合和部署管道。此舉可縮短前置時間、降低成本、促進增加變更頻率、減少工作量，並且增進協作。
### 實作步驟
![\[圖中顯示使用 AWS CodePipeline 和相關服務的 CI/CD 管道\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/images/deployment-pipeline-tooling.png)
1. 使用版本控制系統來儲存和管理資產 (例如文件、原始程式碼和二進位檔案)。
1. 使用 CodeBuild 可編譯原始碼、執行單元測試，並產生可立即部署的成品。
1. 將 CodeDeploy 用作一項部署服務，可自動將應用程式部署至 [Amazon EC2](https://aws.amazon.com/ec2/) 執行個體、內部部署執行個體、[無伺服器 AWS Lambda 函數](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)或 [Amazon ECS](https://aws.amazon.com/ecs/)。
1. 監控您的部署。
## 資源
**相關的最佳實務：**
+ [OPS06-BP04 自動化測試和復原](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**相關文件：**
+ [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/)
+ [什麼是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS CodeBuild](https://aws.amazon.com/codebuild/)
+ [什麼是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
**相關影片：**
+ [AWS re:Invent 2022 - 適用於 DevOps on AWS 的 AWS Well-Architected 最佳實務](https://youtu.be/hfXokRAyorA)
# OPS05-BP05 執行修補程式管理
執行修補程式管理以取得功能、解決問題並保持遵循管控。自動化修補程式管理，以減少由手動程序引起的錯誤、進行擴展，並減少修補工作量。
修補程式和漏洞管理屬於您利益和風險管理活動的一部分。最好擁有不可變的基礎設施，並在已驗證的已知良好狀態下部署工作負載。如果這種方法不可行，剩下的方法就是進行修補。
[AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) 是有關規劃的生命週期事件，以及其他影響 AWS 雲端 資源運作狀態且須採取行動的事件的權威資訊來源。您應得知即將進行的變更和更新。主要的規劃生命週期事件至少會提前六個月傳送。
[Amazon EC2 Image Builder](https://aws.amazon.com/image-builder/) 提供管道來更新機器映像。作為修補程式管理的一部分，請考慮使用 [AMI 映像管道](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-image-pipeline.html)的 [Amazon Machine Images](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html ) (AMI) 或具有 [Docker 映像管道](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-container-pipeline.html)的容器映像，同時 AWS Lambda 會為[自訂執行時期和其他程式庫](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html)提供模式以移除漏洞。
應使用 [Amazon EC2 Image Builder](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) 管理適用於 Linux 或 Windows Server 映像的 [Amazon Machine Images](https://aws.amazon.com/image-builder/) 的更新。可以使用 [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) 搭配現有管道來管理 Amazon ECS 映像並管理 Amazon EKS 映像。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) 來自動化修補受管系統的流程，並使用 [Systems Manager 維護時段](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html)來排程活動。
**預期成果：**您的 AMI 和容器映像已完成修補、處於最新狀態，並準備好啟動。您可以追蹤所有已部署映像的狀態，並了解修補程式的合規狀況。您可以通報目前狀態，並設立程序來滿足合規需求。
**常見的反模式：**
+ 您必須在兩小時內套用所有新的安全修補程式，結果導致應用程式與修補程式不相容而發生多次停機。
+ 未修補的程式庫導致意外後果發生，因為有不明對象利用其中的漏洞來存取您的工作負載。
+ 您自動修補開發人員環境，而未通知開發人員。您收到來自開發人員的多次投訴，表示其環境如預期停止運作。
+ 您尚未在持續執行的執行個體上修補商用現成軟體。當軟體發生問題而您聯絡廠商時，他們會通知您不支援該版本，您必須修補至特定程度才能獲得協助。
+ 您使用的加密軟體近期發佈了修補程式，使效能獲得大幅改善。未修補的系統因未修補仍存在效能問題。
+ 收到發生零時差漏洞的通知時，需緊急修正並手動修補所有環境。
+ 您不知道維護資源所需的重大行動，例如強制性版本更新，因為您未檢閱即將進行的規劃生命週期事件和其他資訊。您錯失規劃和執行的關鍵時間，導致團隊須緊急變更，且可能造成影響或非預期的停機時間。
**建立此最佳實務的優勢：**透過建立修補程式管理程序 (包括修補準則和在各環境中散佈的方法)，您就能擴展和報告修補程度。這樣可保證修補過程安全無虞，並確保能清楚看見已知修正的狀態。如此可促進採用所需的功能、迅速消除問題，並持續遵循管控要求。實作修補程式管理系統和自動化，以減少部署修補程式的工作量，並限制手動程序引起的錯誤。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
修補系統以補救問題，獲得所需的功能，並保持符合管控政策和廠商支援需求。在不可變系統中，部署適當的修補程式集以實現所需的結果。自動化修補程式管理機制，以縮短修補時間、避免手動程序引起的錯誤，並減少修補工作量。
### 實作步驟
對於 Amazon EC2 Image Builder：
1. 使用 Amazon EC2 Image Builder 指定管道詳細資訊：
1. 建立映像管道並命名
1. 定義管道排程和時區
1. 設定任何相依性
1. 選擇配方：
1. 選取現有配方或建立新配方
1. 選取映像類型
1. 提供配方的名稱和版本
1. 選取基礎映像
1. 新增組建元件並新增至目標登錄檔
1. 選用 - 定義您的基礎設施組態。
1. 選用 - 定義組態設定。
1. 審核設定。
1. 定期維護配方乾淨度。
對於 Systems Manager Patch Manager：
1. 建立修補基準。
1. 選取修補操作方法。
1. 啟用合規報告和掃描。
## 資源
**相關的最佳實務：**
+ [OPS06-BP04 自動化測試和復原](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**相關文件：**
+ [什麼是 Amazon EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/what-is-image-builder.html)
+ [使用 Amazon EC2 Image Builder 建立映像管道](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-image-pipeline.html)
+ [建立容器映像管道](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-container-pipeline.html)
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
+ [使用 Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-console.html)
+ [使用修補程式合規報告](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-compliance-reports.html)
+ [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools)
**相關影片：**
+ [AWS 上適用於無伺服器應用程式的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE)
+ [設計時考量 Ops](https://youtu.be/uh19jfW7hw4)
**相關範例：**
+ [AWS Systems Manager Patch Manager 教學課程](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-tutorials.html)
# OPS05-BP06 共用設計標準
在團隊之間共用最佳實務，以提高認識並最大化開發工作的效益。記載它們並且隨著您的架構演進讓它們保持在最新狀態。如果您的組織中強制執行共用標準，則必須存在用於請求標準新增、變更及例外狀況的機制。如果沒有此選項，標準就會限制創新。
**預期成果：**設計標準在貴組織的團隊之間共用。它們會隨著最佳實務的演變進行記錄和保存 up-to-date。
**常見的反模式：**
+ 兩個開發團隊各自建立了使用者身分驗證服務。您的使用者必須針對要存取的系統的每一部分，維護一組單獨的憑證。
+ 每個團隊管理他們自己的基礎設施。新的合規要求會強制變更您的基礎設施，每個團隊會以不同的方式實作。
**建立此最佳實務的優勢：**以共用的標準支援來實踐最佳實務，讓開發工作量發揮最大效益。記錄和更新設計標準可讓組織 up-to-date符合最佳實務、安全和合規要求。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
在團隊之間共用現有的最佳實務、設計標準、檢查清單、操作程序以及指引和管控要求。對於請求對設計標準進行變更、新增和例外設立程序，以支援改進和創新。讓團隊得知發布的內容。擁有機制，以在新最佳實務出現時保持設計標準 up-to-date。
**客戶範例**
AnyCompany Retail 有一個跨職能架構團隊，可建立軟體架構模式。這個團隊會建置具有內建合規和管控的架構。採用這些共用標準的團隊會獲得具有內建合規和管控的優點。他們可以快速地在設計標準的基礎上建置。架構團隊每季開會一次，評估架構模式並且視需要更新。
### 實作步驟
1. 識別擁有開發和更新設計標準的跨部門團隊。這個團隊應與整個組織的利益相關者合作，共同開發設計標準、操作程序、檢查清單、指引和管控需求。記錄設計標準並且在組織內共用。
1. [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html) 可以用來建立套裝服務，代表使用基礎設施即程式碼的設計標準。您可以與所有帳戶共用套裝服務。
1. 在識別新的最佳實務時，有適當的機制來保持設計標準 up-to-date。
1. 如果設計標準是集中強制執行，設立程序來請求變更、更新和豁免。
**實作計劃的工作量：**中。開發程序來建立和共用設計標準，即可與整個組織的利益相關者協調和合作。
## 資源
**相關的最佳實務：**
+ [OPS01-BP03 評估治理要求](ops_priorities_governance_reqs.md) - 管控需求會影響設計標準。
+ [OPS01-BP04 評估合規要求](ops_priorities_compliance_reqs.md) - 合規是建立設計標準中的重要輸入。
+ [OPS07-BP02 確保對營運準備度進行一致的審查](ops_ready_to_support_const_orr.md) - 營運準備度檢查清單是在設計您的工作負載時實作設計標準的機制。
+ [OPS11-BP01 建立持續改進程序](ops_evolve_ops_process_cont_imp.md) - 更新設計標準是持續改善的一部分。
+ [OPS11-BP04 執行知識管理](ops_evolve_ops_knowledge_management.md) - 在您的知識管理實務中，記錄和共用設計標準。
**相關文件：**
+ [AWS Backup使用 自動化 AWS Service Catalog](https://aws.amazon.com/blogs/mt/automate-aws-backups-with-aws-service-catalog/)
+ [AWS Service Catalog 帳戶工廠增強型 ](https://aws.amazon.com/blogs/mt/aws-service-catalog-account-factory-enhanced/)
+ [ Expedia Group 如何使用 建置資料庫即服務 （DBaaS） 方案 AWS Service Catalog](https://aws.amazon.com/blogs/mt/how-expedia-group-built-database-as-a-service-dbaas-offering-using-aws-service-catalog/)
+ [維護使用雲端架構模式的可見性](https://aws.amazon.com/blogs/architecture/maintain-visibility-over-the-use-of-cloud-architecture-patterns/)
+ [ 簡化在 AWS Organizations 設定中共用 AWS Service Catalog 產品組合 ](https://aws.amazon.com/blogs/mt/simplify-sharing-your-aws-service-catalog-portfolios-in-an-aws-organizations-setup/)
**相關影片：**
+ [AWS Service Catalog – 入門 ](https://www.youtube.com/watch?v=A9kKy6WhqVA)
+ [AWS re：Invent 2020：像專家一樣管理您的 AWS Service Catalog 產品組合 ](https://www.youtube.com/watch?v=lVfXkWHAtR8)
**相關範例：**
+ [AWS Service Catalog 參考架構 ](https://github.com/aws-samples/aws-service-catalog-reference-architectures)
+ [AWS Service Catalog 研討會 ](https://catalog.us-east-1.prod.workshops.aws/workshops/d40750d7-a330-49be-9945-cde864610de9/en-US)
**相關服務：**
+ [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html)
# OPS05-BP07 實作用於提高程式碼品質的實務
實作相關實務以提高程式碼品質，並盡可能減少缺陷。部分範例包括測試驅動的開發、程式碼審查、標準採用和配對程式設計。將這些實務併入您的持續整合和交付程序。
**預期成果：**貴組織使用例如程式碼審核或配對程式設計的最佳實務來改善程式碼品質。開發人員和操作人員在軟體開發生命週期過程中採用程式碼品質最佳實務。
**常見的反模式：**
+ 您將程式碼遞交至應用程式的主要分支，而未進行程式碼審核。變更會自動部署至生產環境，並導致中斷。
+ 會開發一個新的應用程式，沒有進行任何單元、端到端或整合測試。無法在部署之前測試應用程式。
+ 您的團隊在生產中進行手動變更，以解決問題。變更不會經過測試或程式碼審核，而且不會在持續整合或交付程序中擷取或記錄。
**建立此最佳實務的優勢：**透過採用實務來提高程式碼品質，就能協助盡量減少生產環境中引發的問題。程式碼品質最佳實務包括配對程式設計、程式碼審核以及 AI 生產力工具的實作。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
實作實務以提高程式碼品質，在部署之前將故障降至最低。使用像是測試驅動的開發、程式碼審核和配對程式設計等實務來提高開發的品質。
透過 Amazon Q Developer，利用生成式 AI 的強大功能，提升開發人員生產力和程式碼品質。Amazon Q Developer 包括程式碼建議的產生 (以大型語言模型為基礎)、單元測試的生產 (包括邊界條件)，以及透過偵測和修復安全漏洞增強程式碼安全性。
**客戶範例**
AnyCompany Retail 採用數個實務來改善程式碼品質。它們採用了測試驅動的開發做為撰寫應用程式的標準。對於某些新功能，它們會讓開發人員在衝刺期間一起進行配對程式設計。每個提取請求都會先經過資深開發人員的程式碼審核，然後再整合和部署。
### 實作步驟
1. 在您的持續整合和交付程序中，採用像是測試驅動開發、程式碼審核和配對程式設計的程式碼品質實務。使用這些技術來改善軟體品質。
1. 使用 [Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html)，這是一種生成式 AI 工具，可協助建立單元測試案例 (包括邊界條件)、使用程式碼和註解產生函數、實作眾所周知的演算法、偵測程式碼中的安全政策違規和漏洞、偵測機密、掃描基礎設施即程式碼 (IaC)、記錄程式碼以及更快速地學習第三方程式碼程式庫。
1. [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) 可以使用機器學習針對 Java 和 Python 程式碼提供程式設計建議。
**實作計劃的工作量：**中。有許多方式可以實作此最佳實務，但是要讓整個組織採用可能會是一項挑戰。
## 資源
**相關的最佳實務：**
+ [OPS05-BP02 測試並驗證變更](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_test_val_chg.html)
+ [OPS05-BP06 共用設計標準](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_share_design_stds.html)
**相關文件：**
+ [採用測試驅動的開發方法](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/development-best-practices.html)
+ [使用 Amazon Q 加速您的軟體開發生命週期](https://aws.amazon.com/blogs/devops/accelerate-your-software-development-lifecycle-with-amazon-q/)
+ [Amazon Q Developer 現已正式推出，包含可重新構想開發人員體驗的新功能預覽](https://aws.amazon.com/blogs/aws/amazon-q-developer-now-generally-available-includes-new-capabilities-to-reimagine-developer-experience/)
+ [在 IDE 中使用 Amazon Q Developer 的終極速查表](https://community.aws/content/2eYoqeFRqaVnk900emsknDfzhfW/the-ultimate-cheat-sheet-for-using-amazon-q-developer-in-your-ide)
+ [左移工作負載，利用 AI 建立測試](https://community.aws/content/2gBZtC94gPzaCQRnt4P0rIYWuBx/shift-left-workload-leveraging-ai-for-test-creation)
+ [Amazon Q 開發人員中心](https://aws.amazon.com/developer/generative-ai/amazon-q/)
+ [使用 Amazon CodeWhisperer 快速建置應用程式的 10 種方式](https://aws.amazon.com/blogs/devops/10-ways-to-build-applications-faster-with-amazon-codewhisperer/)
+ [使用 Amazon CodeWhisperer 超越程式碼覆蓋範圍](https://aws.amazon.com/blogs/devops/looking-beyond-code-coverage-with-amazon-codewhisperer/)
+ [使用 Amazon CodeWhisperer 進行提示詞工程的最佳實務](https://aws.amazon.com/blogs/devops/best-practices-for-prompt-engineering-with-amazon-codewhisperer/)
+ [敏捷式軟體指南](https://martinfowler.com/agile.html)
+ [CI/CD 管道是我的發行主管](https://aws.amazon.com/builders-library/cicd-pipeline/)
+ [使用 Amazon CodeGuru Reviewer 自動進行程式碼審核](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/)
+ [採用測試驅動的開發方法](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/development-best-practices.html)
+ [DevFactory 如何使用 Amazon CodeGuru 建置更佳的應用程式](https://aws.amazon.com/blogs/machine-learning/how-devfactory-builds-better-applications-with-amazon-codeguru/)
+ [關於配對程式設計](https://martinfowler.com/articles/on-pair-programming.html)
+ [RENGA Inc. 使用 Amazon CodeGuru 自動進行程式碼審核](https://aws.amazon.com/blogs/machine-learning/renga-inc-automates-code-reviews-with-amazon-codeguru/)
+ [敏捷開發的藝術：測試驅動的開發](http://www.jamesshore.com/v2/books/aoad1/test_driven_development)
+ [程式碼審核為何重要 (而且確實可節省時間！)](https://www.atlassian.com/agile/software-development/code-reviews)
**相關影片：**
+ [使用適用於軟體開發的 Amazon Q Developer 代理程式來實作 API](https://www.youtube.com/watch?v=U4XEvJUvff4)
+ [使用 JetBrains IDE 安裝、設定和使用 Amazon Q Developer (操作說明)](https://www.youtube.com/watch?v=-iQfIhTA4J0)
+ [掌握 Amazon CodeWhisperer 的藝術 - YouTube 播放清單](https://www.youtube.com/playlist?list=PLDqi6CuDzubxzL-yIqgQb9UbbceYdKhpK)
+ [AWS re:Invent 2020：使用 Amazon CodeGuru 持續改善程式碼品質](https://www.youtube.com/watch?v=iX1i35H1OVw)
+ [AWS Summit ANZ 2021 - 透過 CDK 和測試驅動的開發施行測試優先策略](https://www.youtube.com/watch?v=1R7G_wcyd3s)
**相關服務：**
+ [Amazon Q Developer](https://aws.amazon.com/q/developer/)
+ [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [Amazon CodeGuru Profiler](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html)
# OPS05-BP08 使用多個環境
使用多個環境來試驗、開發和測試您的工作負載。當環境接近生產環境時提高控制層級，以確保您的工作負載在部署後依預期執行。
**預期成果：**您有多個環境可反映您的合規和管控需求。在環境中測試並推廣程式碼，以逐步進行生產。
1. 您的組織可透過建立登陸區域來執行此操作，該區域提供治理、控制、帳戶自動化、聯網、安全和營運可觀測性。使用多個環境來管理這些登陸區域功能。常見的範例是沙盒組織，可用於開發和測試 [AWS Control Tower](https://aws.amazon.com/controltower/) 型登陸區域的變更，其中包括 [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/) 和政策 (例如[服務控制政策 (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html))。這些元素全都可能對登陸區域內 AWS 帳戶 的存取和操作產生重大影響。
1. 除了這些服務之外，您的團隊還可利用 AWS 和 AWS 合作夥伴發布的解決方案，或您組織內開發的自訂解決方案來擴展登陸區域功能。AWS 所發布解決方案的範例包括 [Customizations for AWS Control Tower (CfCT)](https://aws.amazon.com/solutions/implementations/customizations-for-aws-control-tower/) 和 [AWS Control Tower Account Factory for Terraform (AFT)](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html)。
1. 在付諸實際執行之前，您的組織會在過程中透過環境針對登陸區域套用相同的測試、推廣程式碼和政策變更原則。此策略為您的應用程式和工作負載團隊提供了穩定且安全的登陸區域環境。
**常見的反模式：**
+ 您在共用開發環境中進行開發，而另一名開發人員覆寫了您的程式碼變更。
+ 對共用開發環境的限制性安全控制可防止您試驗新服務和功能。
+ 您對生產系統執行負載測試，並造成使用者停機。
+ 在生產環境中發生導致資料遺失的嚴重錯誤。在您的生產環境中，您試圖重建導致資料遺失的條件，以便了解此情況如何發生，並防止它再次發生。為防止更多資料在測試期間遺失，必須讓使用者無法使用應用程式。
+ 您正在操作多租用戶服務，且無法支援客戶對專用環境的要求。
+ 您不一定會進行測試，但要測試時，您會在生產環境中進行。
+ 您認為簡單的單一環境會覆寫環境內變更的影響範圍。
+ 您升級一項重要的登陸區域功能，但變更卻有損您的團隊為新專案或現有工作負載供應帳戶的能力。
+ 您將新的控制項套用至 AWS 帳戶，但變更卻影響工作負載團隊在其 AWS 帳戶 內部署變更的能力。
**建立此最佳實務的優勢：**當您部署多個環境時，您可以支援多個同時開發、測試和生產的環境，而不會在開發人員或使用者社群之間產生衝突。對於像是登陸區域等複雜功能，它可大幅降低變更的風險、簡化改善程序，並降低對環境進行重大更新的風險。使用登陸區域的組織自然受益於其 AWS 環境中的多個帳戶，因為具有帳戶結構、治理、網路和安全組態。經過一段時間後，隨著組織成長，登陸區域可能會進一步保護和組織您的工作負載和資源。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
使用多個環境，並且對開發人員沙盒環境實施最低限度的控制，以協助實驗。提供多個單獨的開發環境，以協助實現並行工作，進而提高開發敏捷性。在環境逐漸達到生產環境的條件時，實施更嚴格的控制，以允許開發人員創新。使用基礎設施即程式碼和組態管理系統來部署所設定控制條件與生產環境一致的環境，以確保系統在部署後依預期執行。當不使用環境時，關閉環境以避免產生與閒置資源相關的成本 (例如，在夜間和週末關閉開發系統)。進行負載測試時，部署與生產環境同等的環境，以改善有效的結果。
平台工程、聯網和安全營運等團隊通常會在擁有不同需求的組織層級管理各種功能。僅是將帳戶分隔開來並不足以提供及維護實驗、開發和測試各自所需的不同環境。在這種情況下，可建立個別的 AWS Organizations 執行個體。
## 資源
**相關文件：**
+ [ Instance Scheduler on AWS](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/)
+ [什麼是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [使用多個帳戶來組織您的 AWS 環境 - 多個組織 - 測試整體 AWS 環境的變更](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/multiple-organizations.html#test-changes-to-your-overall-aws-environment)
+ [AWS Control Tower 指南](https://catalog.workshops.aws/control-tower)
# OPS05-BP09 進行頻繁、小型、可逆的變更
頻繁、細微和可逆的變更會縮小變更的範圍和影響。與變更管理系統、組態管理系統以及建置與交付系統搭配使用時，頻繁、細微和可逆的變更可縮小變更的範圍和影響。透過回復變更，可以更有效地進行疑難排解並加快修復速度。
**常見的反模式：**
+ 您每季部署應用程式的新版本，這表示在這段變更期間，核心服務為關閉狀態。
+ 您經常對資料庫結構描述進行變更，但未在您的管理系統中追蹤變更。
+ 您執行手動就地更新，並覆寫現有的安裝和組態，但沒有明確的回復計畫。
**建立此最佳實務的優勢：**頻繁部署小型變更，可加快開發工作的速度。若變更幅度很小，就更容易了解變更是否會產生意外的後果，也更容易回復。如果變更可逆，由於復原過程較單純，因此實作變更的風險也會降低。變更程序的風險降低，而且變更失敗的影響也會降低。
**未建立此最佳實務時的曝險等級：**低
## 實作指引
透過頻繁、細微和可逆的變更來縮小變更的範圍和影響。這樣可以簡化疑難排解，有助於加速修復，並提供回復變更的選項。另外還可以提高您為企業帶來價值的速度。
## 資源
**相關的最佳實務：**
+ [OPS05-BP03 使用組態管理系統](ops_dev_integ_conf_mgmt_sys.md)
+ [OPS05-BP04 使用建置和部署管理系統](ops_dev_integ_build_mgmt_sys.md)
+ [OPS06-BP04 自動化測試和復原](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**相關文件：**
+ [ 在 上實作 Microservices AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [ 微型服務 - 可觀測性](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/observability.html)
# 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 管理主控台 就可以交付更新。有完整的變更與組態稽核記錄，可滿足管控和合規的需求。程序可在各團隊重複執行並且標準化。開發人員可全心專注於開發和程式碼推送，從而提高生產力。
**常見的反模式：**
+ 週五，您完成了為功能分支編寫新程式碼。週一，執行程式碼品質測試指令碼和每個單位測試指令碼之後，請為下一排程版本檢查程式碼。
+ 系統會指派您編寫修正程式碼，以解決影響生產環境中大量客戶的重大問題。測試修正後，您遞交程式碼和電子郵件變更管理內容，以請求核准將其部署到生產環境中。
+ 您以開發人員身分登入 AWS 管理主控台，以使用非標準方法和系統來建立新的開發環境。
**建立此最佳實務的優勢：**透過實作自動化建置和部署管理系統，您可以減少手動程序引起的錯誤，以及部署變更的工作量，協助您的團隊成員專注於提供商業價值。您在推廣至生產環境的同時，加快了交付速度。
**未建立此最佳實務時的曝險等級：**低
## 實作指引
您使用建置和部署管理系統來追蹤和實作變更，以減少由手動程序引起的錯誤，並減少工作量。從程式碼簽入到建置、測試、部署和驗證，完全自動化整合和部署管道。此舉可縮短前置時間、促進增加變更頻率、減少工作量、加快上市速度、提高生產力，並且在您推廣到生產環境時提高程式碼的安全性。
## 資源
**相關的最佳實務：**
+ [OPS05-BP03 使用組態管理系統](ops_dev_integ_conf_mgmt_sys.md)
+ [OPS05-BP04 使用建置和部署管理系統](ops_dev_integ_build_mgmt_sys.md)
**相關文件：**
+ [什麼是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [什麼是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
**相關影片：**
+ [AWS re:Invent 2022 - 適用於 DevOps on AWS 的 AWS Well-Architected 最佳實務](https://youtu.be/hfXokRAyorA)
# 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_auto_testing_and_rollback.md)
# OPS06-BP01 計畫變更失敗
計劃在部署造成非預期成果時恢復到已知的良好狀態，或者在生產環境中進行修復。擁有制定這類計畫的政策可以協助所有團隊訂立政策，從失敗變更中恢復。一些範例策略包括部署和回復步驟、變更政策、功能旗標、流量隔離和流量轉移。單一版本可能包含多個相關元件變更。策略要能提供您承受或從任何失敗元件變更中恢復的能力。
**預期成果：**您已經為失敗變更準備了詳細的恢復計畫。此外，您也縮減了發行版本的大小，如此一來，對其他工作負載元件的潛在影響將降到最低。因此，您可以縮短因變更失敗而造成的可能停機時間，並提高回復時間的彈性和效率，進而降低對業務的影響。
**常見的反模式：**
+ 您執行了部署，而您的應用程式變得不穩定，但系統中似乎有作用中使用者。您必須決定是否要復原變更並影響作用中使用者，或在知道使用者無論如何都會受到影響的情況下，等待復原變更。
+ 在進行路由變更後，您可以存取新的環境，但其中一個子網路變成無法連線。您必須決定是否要復原所有項目，或嘗試修正無法存取的子網路。當您做出該決定時，子網路仍無法連線。
+ 您的系統架構並不允許以較小版本進行更新。因此，在部署失敗期間，您無法回復這些大量變更。
+ 您未使用基礎設施即程式碼 (IaC)，並且以手動方式更新了基礎設施，從而造成不理想的組態。您無法有效追蹤和還原手動變更。
+ 由於您尚未測量部署的增加頻率，您的團隊不會想降低變更規模和改善每次變更的回復計畫，進而造成更高的風險和失敗率。
+ 請不要測量因變更失敗而導致中斷的總持續時間。您的團隊無法排定優先順序並改善其部署程序和回復計畫的效能。
**建立此最佳實務的好處：**擁有從失敗變更中復原的計畫，可最大限度地減少復原的平均時間 （MTTR），並減少您的業務影響。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
發行團隊採用的一致記錄政策和實務可讓組織規劃發生失敗變更時應採取的動作。該政策應允許在特定情況下向前修正。在任何情況下，向前修正或回復計畫都應該在部署到現場生產之前先經過詳細記錄和測試，以將回復變更所需的時間降到最低。
### 實作步驟
1. 記錄要求團隊有效計畫在特定期間內還原變更的政策。
1. 政策應指明允許向前修正的情況。
1. 要求所有參與者皆能存取記錄完善的回復計畫。
1. 指定回復需求 (例如：發現部署未經授權的變更時)。
1. 分析工作負載每個元件相關所有變更的影響程度。
1. 如果可重複的變更遵循強制執行變更政策的一致工作流程，則允許這些變更進行標準化、範本化和預先授權。
1. 縮小變更規模以減少任何變更的潛在影響，進而降低回復時間和對業務的影響。
1. 確保回復程序會將程式碼回復到已知的良好狀態，避免可能發生的意外。
1. 整合工具和工作流程，以程式設計方式執行政策。
1. 讓其他工作負載擁有者可以看到變更相關資料，以改善任何無法回復失敗變更的診斷速度。
1. 使用可見的變更資料來衡量這項實務的成效，並識別出反覆改進方式。
1. 使用監控工具來驗證部署成敗，以加速回復的決策過程。
1. 測量失敗變更期間的中斷時間，以持續修正回復計畫。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS06-BP04 自動化測試和復原](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**相關文件：**
+ [AWS Builders Library \$1 確保部署期間的復原安全 ](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [AWS 白皮書 \$1 雲端的變更管理 ](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)
**相關影片：**
+ [re:Invent 2019 \$1 Amazon 的高可用性部署方法](https://aws.amazon.com/builders-library/amazon-approach-to-high-availability-deployment/)
# OPS06-BP02 測試部署
使用與生產環境相同的部署組態、安全控制、步驟和程序，在生產前測試發行程序。驗證所有部署的步驟均按照預期完成，例如檢查檔案、組態和服務。透過功能、整合和負載測試以及任何監控 (例如運作狀態檢查) 進一步測試所有變更。透過這些測試，您可以及早發現部署問題，有機會在生產前進行規劃和問題緩解。
您可以建立暫時的平行環境來測試每項變更。使用基礎設施即程式碼 (IaC) 來自動化測試環境的部署，協助減少涉及的工作量，並確保穩定性、一致性和更快的功能交付。
**預期成果：**您的組織採用測試驅動型開發文化，其中包含測試部署。如此一來，便能確保團隊專注於交付商業價值，而非管理發行版本。團隊會及早找出部署風險，並訂定適當的緩解方案。
**常見的反模式：**
+ 使用生產版本期間，因為未經測試的部署經常會導致問題，而需要疑難排解或升級處理。
+ 您的版本包含更新現有資源的基礎設施即程式碼 (IaC)。您不確定 IaC 是否會成功執行，或對資源造成影響。
+ 您為應用程式部署一個新功能。該功能無法按照您的預期運作，且在受影響的使用者回報之前無法預見問題。
+ 您更新憑證。您不小心將憑證安裝到錯誤的元件，這些元件未被偵測並因為無法建立與網站的安全連線，而影響了網站訪客。
**建立此最佳實務的優勢：**針對部署程序的生產前階段及其帶來的變更進行廣泛測試，將部署步驟對生產的潛在負面影響降到最低。這麼做能增加產品發行期間的信心，並盡可能減少操作支援，同時不影響交付變更的速度。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
測試部署程序與測試部署所產生的變更同樣重要。您可以在生產前環境中測試部署步驟，盡可能準確反映生產環境。諸如不完整或錯誤部署步驟，或者配置錯誤等常見問題都能在生產環境之前偵測。此外，您也可以測試回復步驟。
**客戶範例**
作為持續整合和持續交付 （CI/CD） 管道的一部分， AnyCompany Retail 會執行在類似生產環境中為其客戶發佈基礎設施和軟體更新所需的定義步驟。流程包含許多預先檢查程序，可以在部署之前偵測到資源偏移 (偵測 IaC 以外所執行的資源變更)，以及驗證 IaC 啟動時所採取的動作。這個程序會驗證部署步驟，例如確認特定檔案和組態已準備就緒，或服務處於執行狀態，並在向負載平衡器重新註冊之前，正確回應本機上的運作狀態檢查。此外，所有變更都標記了許多自動化測試，例如功能、安全性、迴歸、整合和負載測試。
### 實作步驟
1. 執行安裝前檢查，將生產前環境反映到生產環境。
1. 使用[偏離偵測](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)來偵測 資源是否已在 之外變更 CloudFormation。
1. 使用[變更集](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html)來驗證堆疊更新的意圖是否符合啟動變更集時 CloudFormation 採取的動作。
1. 這會觸發 [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/approvals.html) 中的手動核准步驟，以授權生產前環境的部署。
1. 使用[AWS CodeDeploy AppSpec](https://docs.aws.amazon.com/codedeploy/latest/userguide/application-specification-files.html)檔案等部署組態來定義部署和驗證步驟。
1. 在適用的情況下，[AWS CodeDeploy 與其他 AWS 服務整合](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html)，或與[AWS CodeDeploy 合作夥伴產品和服務整合。](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html)
1. 使用 Amazon CloudWatch AWS CloudTrail、 和 Amazon SNS事件通知來[監控部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html)。
1. 執行部署後自動化測試，包括功能、安全性、迴歸、整合和負載測試。
1. 對部署問題[進行故障診斷](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html)。
1. 成功驗證前述步驟後，應該啟動手動核准工作流程，以授權部署到生產環境。
**實作計劃的工作量：**高
## 資源
**相關的最佳實務：**
+ [OPS05-BP02 測試並驗證變更](ops_dev_integ_test_val_chg.md)
**相關文件：**
+ [AWS Builders' Library \$1 自動化安全、移交部署 \$1 測試部署 ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/#Test_deployments_in_pre-production_environments)
+ [AWS 白皮書 \$1 在 上練習持續整合和持續交付 AWS](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/testing-stages-in-continuous-integration-and-continuous-delivery.html)
+ [阿波羅的故事 - Amazon 的部署引擎](https://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-engine.html)
+ [如何在運送程式碼之前在 AWS CodeDeploy 本機進行測試和偵錯](https://aws.amazon.com/blogs/devops/how-to-test-and-debug-aws-codedeploy-locally-before-you-ship-your-code/)
+ [整合網路連線測試與基礎設施部署](https://aws.amazon.com/blogs/networking-and-content-delivery/integrating-network-connectivity-testing-with-infrastructure-deployment/)
**相關影片：**
+ [re:Invent 2020 \$1在 Amazon 測試軟體和系統](https://www.youtube.com/watch?v=o1sc3cK9bMU)
**相關範例：**
+ [ 教學課程 \$1 透過驗證測試部署 和 Amazon ECS服務 ](https://docs.aws.amazon.com/codedeploy/latest/userguide/tutorial-ecs-deployment-with-hooks.html)
# OPS06-BP03 採用安全的部署策略
安全的生產部署可控制有益變更的流程，目的是將這些變更對客戶造成的任何影響降到最低。安全控制提供檢查機制，以驗證所需的結果，並限制變更引入的任何缺陷或部署失敗造成的影響範圍。安全推出可能包括諸如功能旗標、一體式、滾動式 (Canary 版本)、不可變、流量拆分和藍/綠部署等策略。
**預期成果：**您的組織使用持續整合持續交付 (CI/CD) 系統，可提供自動化安全部署的功能。團隊必須使用適當的安全推出策略。
**常見的反模式：**
+ 您一次性將失敗的變更部署至所有生產環境。因此，所有客戶都會同時受到影響。
+ 同時部署到所有系統中引入的缺陷需要緊急釋放。為所有客戶修正它需要數天的時間。
+ 管理生產發行需要多個團隊的規劃和參與。這會限制您為客戶經常更新功能的能力。
+ 您透過修改現有系統來執行可變部署。發現變更失敗之後，您必須再次修改系統以還原舊版本，這會延長回復時間。
**建立此最佳實務的優勢：**自動化部署在推出速度和持續為客戶提供有益變更之間取得了平衡。限制影響範圍可以預防損失慘重的部署失敗，並盡可能提高團隊有效回應故障的能力。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
持續交付失敗可能導致服務可用性降低和糟糕的客戶體驗。為了盡可能提高部署成功率，請在端對端發行程序中實施安全控制，盡量減少部署錯誤，而目標則是實現零部署失敗。
**客戶範例**
AnyCompany Retail 的使命是實現最小至零停機時間的部署，這表示部署期間沒有對使用者產生任何可感知的負面影響。為此，公司已建立了部署模式 (請參閱下列工作流程圖表)，例如滾動部署和藍/綠部署。所有團隊都在其 CI/CD 管道中採用一個或多個模式。
| Amazon EC2 的 CodeDeploy 工作流程 | Amazon ECS 的 CodeDeploy 工作流程 | Lambda 的 CodeDeploy 工作流程 |
| --- | --- | --- |
| ![\[Amazon EC2 的部署程序流程\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/images/deployment-process-ec2.png) | ![\[Amazon ECS 的部署程序流程\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/images/deployment-process-ecs.png) | ![\[Lambda 的部署程序流程\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/images/deployment-process-lambda.png) |
### 實作步驟
1. 推廣到生產之後，使用核准工作流程可啟動生產推出步驟的一系列動作。
1. 使用自動化部署系統，例如 [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)。AWS CodeDeploy [部署選項](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-steps.html)包括適用於 EC2/內部部署的就地部署，以及適用於 EC2/內部部署、AWS Lambda 和 Amazon ECS 的藍/綠部署 (請參閱上述工作流程圖)。
1. 在適用的情況下，[將 AWS CodeDeploy 與其他 AWS 服務整合](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html)，或者[將 AWS CodeDeploy 與合作夥伴的產品和服務整合](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html)。
1. 對 [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html) 和 [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) 等資料庫使用藍/綠部署。
1. 使用 Amazon CloudWatch、AWS CloudTrail 和 Amazon Simple Notification Service (Amazon SNS) 事件通知來[監控部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html)。
1. 執行部署後自動化測試，包括功能、安全性、迴歸、整合和任何負載測試。
1. 對部署問題[進行故障診斷](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html)。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS05-BP02 測試並驗證變更](ops_dev_integ_test_val_chg.md)
+ [OPS05-BP09 進行頻繁、小型、可逆的變更](ops_dev_integ_freq_sm_rev_chg.md)
+ [OPS05-BP10 完全自動化整合和部署](ops_dev_integ_auto_integ_deploy.md)
**相關文件：**
+ [AWS 建置者資料中心 \$1 自動化安全、無人為介入的部署 \$1 生產部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/?did=ba_card&trk=ba_card#Production_deployments)
+ [AWS 建置者資料中心 \$1 我的 CI/CD 管道是我的發行主管 \$1 安全、自動的生產發行](https://aws.amazon.com//builders-library/cicd-pipeline/#Safe.2C_automatic_production_releases)
+ [AWS 白皮書 \$1 在 AWS 上實行持續整合和持續交付 \$1 部署方法](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/deployment-methods.html)
+ [AWS CodeDeploy使用者指南](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [使用 AWS CodeDeploy 中的部署組態](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
+ [設定 API Gateway Canary 發行部署](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [Amazon ECS 部署類型](https://docs.aws.amazon.com/)
+ [Amazon Aurora 和 Amazon RDS 中的全受管藍/綠部署](https://aws.amazon.com/blogs/aws/new-fully-managed-blue-green-deployments-in-amazon-aurora-and-amazon-rds/)
+ [使用 AWS Elastic Beanstalk 的藍/綠部署](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)
**相關影片：**
+ [re:Invent 2020 \$1 無人為介入：Amazon 的自動化持續交付管道](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [re:Invent 2019 \$1 Amazon 的高可用性部署方法](https://www.youtube.com/watch?v=bCgD2bX1LI4)
**相關範例：**
+ [在 AWS CodeDeploy 中嘗試使用藍/綠部署範例](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [ 研討會 \$1 使用 AWS CDK 建置 Lambda Canary 部署的 CI/CD 管道](https://catalog.workshops.aws/cdk-cicd-for-lambda-canary-deployment/en-US)
+ [ 研討會 \$1 利用 Amazon ECS 建置您的第一個 DevOps 藍/綠管道 ](https://catalog.us-east-1.prod.workshops.aws/workshops/4b59b9fb-48b6-461c-9377-907b2e33c9df/en-US)
+ [ 研討會 \$1 利用 Amazon EKS 建置您的第一個 DevOps 藍/綠管道 ](https://catalog.us-east-1.prod.workshops.aws/workshops/4eab6682-09b2-43e5-93d4-1f58fd6cff6e/en-US)
+ [ 研討會 \$1 EKS GitOps 搭配 ArgoCD ](https://catalog.workshops.aws/eksgitops-argocd-githubactions)
+ [ 研討會 \$1 AWS 上的 CI/CD 研討會 ](https://catalog.workshops.aws/cicdonaws/en-US)
+ [ 針對容器型 Lambda 函數使用 AWS SAM 實作跨帳戶 CI/CD ](https://aws.amazon.com/blogs/compute/implementing-cross-account-cicd-with-aws-sam-for-container-based-lambda/)
# OPS06-BP04 自動化測試和復原
為了提高部署程序的速度和可靠性，請在生產前和生產環境中制定自動化測試和回復功能的策略。在部署到生產環境時自動化測試，以模擬人類與系統的互動，驗證部署的變更。自動回復以快速回復到之前已知的良好狀態。回復應該在預先定義的條件下自動啟動，例如當未達到預期成果或自動化測試失敗時。將這兩項活動的自動化可以提高部署成功率，盡可能縮短回復時間，並減少對業務的潛在影響。
**預期成果：**您的自動化測試和回復策略將整合至持續整合與持續交付 (CI/CD) 管道。您的監控能夠根據您的成功條件進行驗證，並在失敗時啟動自動回復。這會將終端使用者和客戶受到的任何負面影響降到最低。例如，當所有測試結果都達到標準時，您可以利用相同的測試案例，將程式碼提升至啟動自動迴歸測試的生產環境。若迴歸測試結果不符預期，則會在管線工作流程中啟動自動回復。
**常見的反模式：**
+ 您的系統架構並不允許以較小版本進行更新。因此，在部署失敗期間，您無法回復這些大量變更。
+ 您的部署程序包含一系列手動步驟。將變更部署到工作負載之後，即可開始部署後測試。測試之後，您會發現工作負載無法運作，且客戶中斷連線。然後您開始回復到之前的版本。所有這些手動步驟都會延遲整體系統回復，並對客戶造成長期影響。
+ 您花時間為應用程式中不常使用的功能開發自動化測試案例，因而大幅降低了自動化測試功能的投資報酬率。
+ 您的版本包含彼此獨立的應用程式、基礎設施、修補程式和組態更新。但是，您有一個 CI/CD 管道可以一次交付所有變更。一個元件故障會強迫您還原所有變更，進而使回復過程變得複雜且效率低下。
+ 您的團隊在第一個衝刺階段完成編碼，並開始衝刺兩項工作，但直到第三個衝刺階段，計畫中都不包括測試。最終，自動化測試找出第一個衝刺階段的缺漏，必須在測試第二個衝刺階段前解決，才能啟動交付項目，因此整個版本延遲，進而降低您的自動化測試效率。
+ 生產版本的自動迴歸測試案例已經完成，但您並未監控工作負載的運作狀況。由於無法查看是否已重啟服務，您不確定是否需要回復或已啟動回復。
**建立此最佳實務的優勢：**自動化測試可以提高測試流程的透明度，以及您在更短時間內顧及更多功能的能力。在生產環境中測試和驗證變更，可以立即識別出問題。改善自動化測試工具的一致性可以更精確地偵測問題。透過自動回復至舊版本，將對客戶的影響降至最低。自動化回復最終可減少業務影響，讓您對部署功能更有信心。整體而言，這些功能會減少 time-to-delivery，同時確保品質。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
自動測試已部署的環境，更快確認是否達到預期成果。當無法達成預先定義的結果時，自動還原到先前的良好狀態，以盡量縮短還原時間，並減少由手動程序引起的錯誤。將測試工具與管道工作流程整合，持續進行測試並減少手動輸入。優先處理自動化測試案例，例如減緩最高風險且需要在每次變更時經常測試的案例。此外，還可以根據測試計畫中預先定義的特定條件進行自動回復。
### 實作步驟
1. 為您的開發生命週期建立測試生命週期，定義需求規劃到測試案例開發、工具配置、自動化測試和測試案例結案等每個測試程序階段。
1. 根據您的整體測試策略建立針對特定工作負載的測試方式。
1. 在整個開發生命週期中，考慮適當的連續測試策略。
1. 根據您的業務需求和管道投資，選擇用於測試和回復的自動化工具。
1. 決定您應該分別自動化和手動執行哪些測試案例。這些內容皆可以根據受測功能的業務價值優先順序來決定。使所有團隊成員隨時接收計畫最新資訊，並確認執行手動測試的權責分配。
1. 將自動化測試功能應用於對自動化有意義的特定測試案例，例如可重複或經常執行的案例、需要重複作業的案例，或跨多個組態所需的案例。
1. 在自動化工具中定義測試自動化指令碼和成功條件，如此一來，當特定案例失敗時，可以啟動持續的工作流程自動化。
1. 定義自動回復的特定失敗條件。
1. 測試案例其中複雜度和人工互動具較高的失敗風險，因此必須排定測試自動化的優先順序，透過詳盡的測試案例開發來產生一致的結果。
1. 將您的自動化測試和回復工具整合到 CI/CD 管道。
1. 為變更制定明確的成功條件。
1. 監控觀察以偵測這些條件，並在符合特定回復條件時自動回復變更。
1. 執行不同類型的自動化生產測試，例如：
1. A/B 測試，以顯示結果比較兩個使用者測試組之間的當前版本。
1. Canary 測試讓您能在將變更發佈給所有使用者之前，先將其發佈給一部分使用者。
1. 功能旗標測試允許您從應用程式外部標記新版本的功能 (每次僅限一個)，進而使每個新功能皆能逐一進行驗證。
1. 迴歸測試，以現有的關聯元件驗證新功能。
1. 透過其他應用程式和元件，監控應用程式、交易和互動的操作面向。開發報告，以便按照工作負載顯示變更成功率，讓您得以識別出能夠進一步最佳化的自動化和工作流程部分。
1. 開發測試結果報告，協助您快速決定是否應該調用回復程序。
1. 實施策略，允許根據一個或多個測試方法導出的預定義失敗條件進行自動回復。
1. 開發自動化測試用例，以便在未來可重複的變更中重複使用。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS06-BP01 計畫變更失敗](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 測試部署](ops_mit_deploy_risks_test_val_chg.md)
**相關文件：**
+ [AWS Builders Library \$1 確保部署期間的復原安全 ](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [使用 重新部署和復原部署 AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html)
+ [ 使用 自動化部署時的 8 個最佳實務 AWS CloudFormation](https://aws.amazon.com/blogs/infrastructure-and-automation/best-practices-automating-deployments-with-aws-cloudformation/)
**相關範例：**
+ [ 使用 Selenium AWS LambdaAWS Fargate、 和 AWS 開發人員工具進行無伺服器 UI 測試 ](https://aws.amazon.com/blogs/devops/using-aws-codepipeline-aws-codebuild-and-aws-lambda-for-serverless-automated-ui-testing/)
**相關影片：**
+ [re:Invent 2020 \$1 無人為介入：Amazon 的自動化持續交付管道](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [re:Invent 2019 \$1 Amazon 的高可用性部署方法](https://www.youtube.com/watch?v=bCgD2bX1LI4)
# 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-BP06 建立生產工作負載的支援計劃](ops_ready_to_support_enable_support_plans.md)
# OPS07-BP01 確保人員能力
建立一種機制，用於驗證您有適當數量受過培訓的人員來支援工作負載。他們必須受過組成您的工作負載的平台和服務的培訓。為他們提供操作工作負載所需的知識。您必須擁有足夠受過培訓的人員，才能支援工作負載的一般操作，並且針對會發生的任何事件進行疑難排解。擁有足夠的人員，以便您可以輪替待命和休假的人員，避免倦怠。
**預期成果：**
+ 有足夠受過培訓的人員可以在工作負載可用時支援工作負載。
+ 您為人員提供組成您的工作負載的軟體和服務的培訓。
**常見的反模式：**
+ 在沒有受過培訓操作使用中平台和服務的團隊成員之情況下，部署工作負載。
+ 沒有足夠的人員可以支援待命輪替或人員休假。
**建立此最佳實務的優勢：**
+ 擁有熟練的團隊成員有助於有效支援您的工作負載。
+ 具有足夠的團隊成員，您可以支援工作負載和待命輪替，同時降低倦怠風險。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
驗證人員是否已經過充分培訓，可支援工作負載。確認擁有足夠且訓練有素的團隊成員，以妥善應對一般營運活動，包括待命輪替。
**客戶範例**
AnyCompany Retail 確保支援工作負載的團隊有適當的配備人員且訓練有素。他們有足夠的工程師可以支援待命輪替。人員會獲得工作負載建置基礎的軟體和平台的培訓，並且鼓勵他們考取認證。有足夠的人員讓員工可以休假，同時仍然支援工作負載和待命輪替。
### 實作步驟
1. 指派足夠的人員來操作和支援工作負載，包括待命職責、安全問題和生命週期事件，例如終止支援和憑證輪換任務。
1. 為您的人員提供組成您的工作負載的軟體和平台的培訓。
1. [AWS 培訓和認證](https://aws.amazon.com/training/)有一個關於 AWS 的課程庫。它們提供免費和付費的線上或面授課程。
1. [AWS 舉辦活動和網路研討會](https://aws.amazon.com/events/)，您可向 AWS 專家學習。
1. 定期執行下列工作：
+ 隨著操作條件和工作負載變更，評估團隊規模和技能。
+ 調整團隊大小和技能以符合操作要求。
+ 透過 AWS Health 驗證[處理規劃的生命週期事件](https://docs.aws.amazon.com/health/latest/ug/aws-health-planned-lifecycle-events.html)、意外的安全性和操作通知的能力和容量。
**實作計劃的工作量：**高。招聘和培訓團隊來支援工作負載需要大量的努力，但是會有重大的長期優點。
## 資源
**相關的最佳實務：**
+ [OPS11-BP04 執行知識管理](ops_evolve_ops_knowledge_management.md) - 團隊成員必須擁有操作和支援工作負載所需的資訊。知識管理是提供這項能力的關鍵。
**相關文件：**
+ [AWS 活動和研討會](https://aws.amazon.com/events/)
+ [AWS 培訓和認證](https://aws.amazon.com/training/)
# 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 Guardrails](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. 請每位利益相關者提供至少一個需求。對於第一次的反覆測試，請嘗試將項目數限制在三十個以下。
+ 《營運準備度審查 (ORR)》白皮書的[附錄 B：ORR 問題範例](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/appendix-b-example-orr-questions.html)包含您可以開始使用的範例問題。
1. 將需求集中放在試算表中。
+ 您可以在 [AWS Well-Architected Tool](https://console.aws.amazon.com/wellarchiected/) 中使用[自訂聚焦](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html)來開發 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)
+ [AWS Well-Architected Tool](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html)
# OPS07-BP03 使用執行手冊執行程序
*執行手冊*是為了達成特定成果而記錄的程序。執行手冊由一系列可供遵循以完成某項工作的步驟組成。早在航空業早期，就已使用執行手冊。在雲端操作中，我們使用執行手冊來降低風險及達到預期成果。簡言之，執行手冊就是完成一項工作的檢查清單。
執行手冊是操作工作負載的重要組成部分。從新團隊成員入職到部署重大版本，執行手冊是經過編纂的流程，無論誰使用這些執行手冊，都能提供一致的成果。應該在中央位置發佈執行手冊，並隨著流程的發展進行更新，因為更新執行手冊是變更管理流程的關鍵組成部分。它們還應該包括當發生問題時有關錯誤處理、工具、權限、異常以及向上呈報的指引。
隨著組織的成熟，開始自動化執行手冊。從簡短且經常使用的執行手冊開始。使用指令碼語言來自動化步驟或讓步驟更容易執行。當您自動化前幾個執行手冊時，將花費時間來自動化更複雜的執行手冊。隨著時間的推移，大多數執行手冊都應該以某種方式自動化。
**預期成果：**您的團隊擁有一系列用於執行工作負載任務的分步指南。執行手冊中包含預期成果、必要的工具和許可，以及錯誤處理指示。它們會集中存放 (版本控制系統)，並且經常更新。例如，執行手冊可讓您的團隊在應用程式警示、操作問題和計劃的生命週期事件期間監控、溝通和回應關鍵帳戶的 AWS Health 事件。
**常見的反模式：**
+ 依靠記憶體來完成流程的每個步驟。
+ 手動部署變更，無須檢查清單。
+ 不同的團隊成員執行相同的過程，但具有不同的步驟或成果。
+ 讓執行手冊脫離系統變更和自動化。
**建立此最佳實務的優勢：**
+ 降低手動任務的錯誤率。
+ 以一致的方式執行操作。
+ 新的團隊成員可以更快地開始執行任務。
+ 可以自動化執行手冊以減少辛勞。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
執行手冊可以根據組織的成熟度等級採用多種形式。至少，其中應包含一個循序漸進的文字文件。應明確指出預期成果。清楚記錄必要的特殊權限或工具。如果發生問題，提供有關錯誤處理和呈報的詳細指引。列出執行手冊擁有者並將其發佈在中央位置。執行手冊被記錄下來之後，透過讓團隊中的其他人執行它來進行驗證。隨著程序的發展，請根據您的變更管理流程來更新執行手冊。
隨著組織的成熟，應自動化文字執行手冊。使用 [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 等服務，可以將純文字轉換為可針對工作負載執行的自動化功能。可以執行這些自動化功能以回應事件，減少維護工作負載的操作負擔。AWSSystems Manager Automation 也提供低程式碼的[視覺化設計體驗](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-visual-designer.html)，以便更輕鬆地建立自動化執行手冊。
**客戶範例**
AnyCompany Retail 必須在軟體部署期間執行資料庫結構描述更新。雲端操作團隊與資料庫管理團隊合作，建立用於手動部署這些變更的執行手冊。執行手冊以檢查清單的形式列出流程中的每個步驟。它包括發生問題時關於錯誤處理的部分。他們在其內部 wiki 中發布該執行手冊以及其他執行手冊。雲端操作團隊計劃在未來的衝刺中自動化該執行手冊。
### 實作步驟
如果您沒有現有的文件儲存庫，版本控制儲存庫是開始建置執行手冊庫的好地方。可以使用 Markdown 來構建執行手冊。我們提供了一個執行手冊範本範例，您可以使用它來開始構建執行手冊。
```
# Runbook Title
## Runbook Info
| Runbook ID | Description | Tools Used | Special Permissions | Runbook Author | Last Updated | Escalation POC |
|-------|-------|-------|-------|-------|-------|-------|
| RUN001 | What is this runbook for? What is the desired outcome? | Tools | Permissions | Your Name | 2022-09-21 | Escalation Name |
## Steps
1. Step one
2. Step two
```
1. 如果您沒有現有的文件儲存庫或 wiki，請在版本控制系統中建立新的版本控制儲存庫。
1. 識別沒有執行手冊的流程。理想的流程是半定期執行，步驟數量少，並且具有低影響故障。
1. 在文件儲存庫中，使用範本建立新的 Markdown 草稿文件。填寫執行手冊標題和執行手冊資訊下的必填欄位。
1. 從第一個步驟開始，填寫執行手冊的「步驟」部分。
1. 將執行手冊交給團隊成員。讓他們使用執行手冊來驗證步驟。如果缺少某些內容或需要澄清，請更新執行手冊。
1. 將執行手冊發佈到您的內部文件存放區。發布後，告知您的團隊和其他利益相關者。
1. 隨著時間的推移，您將建置執行手冊的程式庫。隨著程式庫的增長，開始努力自動化執行手冊。
**實作計劃的工作量：**低。執行手冊的最低標準是循序漸進的文字指南。自動化執行手冊可以增加實作工作量。
## 資源
**相關的最佳實務：**
+ [OPS02-BP02 流程和程序已識別擁有者](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS07-BP04 使用程序手冊調查問題](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html)
+ [OPS10-BP01 使用程序進行事件、事故和問題管理](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html)
+ [OPS10-BP02 每個提醒建立一個程序](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_process_per_alert.html)
+ [OPS11-BP04 執行知識管理](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**相關文件：**
+ [使用自動化程序手冊和執行手冊實現卓越的營運](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 Automation 執行手冊來解決操作任務](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**相關影片：**
+ [AWS re:Invent 2019：執行手冊、事件報告和事件回應的 DIY 指南](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [如何在 AWS 上自動執行 IT 操作 \$1 Amazon Web Services](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [將指令碼整合到 AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**相關範例：**
+ [Well-Architected 實驗室：使用程序手冊和執行手冊將操作自動化](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
+ [AWS 部落格文章：建立雲端自動化實務以實現卓越營運：AWS Managed Services 的最佳實務](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [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)
+ [使用文件建置器建立自訂執行手冊](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
**相關服務：**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
# OPS07-BP04 使用程序手冊來調查問題
*程序手冊*是用來調查事件的逐步指南。事件發生時，我們會使用程序手冊來調查、確認影響範圍和找出根本原因。程序手冊適用於各種情況，從失敗的部署到安全性事故。在許多案例中，程序手冊可釐清根本原因，而執行手冊則用來緩解該根本原因。程序手冊是組織事件應變計劃的關鍵要素。
一個好的程序手冊有幾個關鍵功能。它循序漸進地引導使用者完成探索過程。從外到內思考，應該遵循哪些步驟來診斷事件？ 在程序手冊中明確定義程序手冊中是否需要特殊工具或更高權限。制定溝通計劃，向利益相關者通報調查進展情況，這非常關鍵。在無法確定根本原因的情況下，程序手冊應具有升級計劃。如果確定了根本原因，程序手冊應該指向說明如何解決問題的執行手冊。程序手冊應集中存放並定期維護。如果程序手冊用於特定提醒，請在提醒中為您的團隊提供指向程序手冊的指引。
隨著組織的成熟，會將您的程序手冊自動化。從涵蓋低風險事件的程序手冊開始。使用指令碼自動執行探索步驟。確認您有配套的執行手冊來減輕常見根本原因。
**預期成果：**您的組織擁有常見事件的程序手冊。程序手冊存放在中心位置，並可供您的團隊成員使用。程序手冊會經常更新。對於任何已知的根本原因，都會構建配套的執行手冊。
**常見的反模式：**
+ 調查事件沒有標準方法。
+ 團隊成員依賴肌肉記憶或機構知識來疑難排解失敗的部署。
+ 新團隊成員學習如何透過試驗和錯誤來調查問題。
+ 調查問題的最佳實務不會跨團隊共用。
**建立此最佳實務的優勢：**
+ 程序手冊可加強您減輕事故的努力。
+ 不同的團隊成員可以使用相同的程序手冊，以一致的方式識別根本原因。
+ 您可以為已知的根本原因制定執行手冊，進而縮短復原時間。
+ 程序手冊有助於團隊成員更快地開始做出貢獻。
+ 團隊可以透過可重複的程序手冊擴展其程序。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
建置和使用程序手冊的方式取決於組織的成熟度。如果您是雲端新手，請在中央文件儲存庫中以文字形式建立程序手冊。隨著組織的成熟，程序手冊可以使用 Python 之類的指令碼語言進行半自動化。這些指令碼可以在 Jupyter 筆記本內部運行，以加快發現速度。進階組織具有完全自動化的程序手冊，可解決使用執行手冊自動修復的常見問題。
列出工作負載發生的常見事件，開始建置程序手冊。為低風險並且根本原因已縮小到幾個問題的事件選擇程序手冊以開始。在您擁有更簡單案例的程序手冊之後，請轉到風險較高的案例或根本原因尚不明確的案例。
隨著組織的成熟，應自動化文字程序手冊。使用 [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) 來回應事故。此服務提供單一介面來分類事故、在發現和緩解期間通知利益相關者，並在整個事故中進行協同合作。它使用 AWS Systems Manager Automation 來加速偵測和復原。
**客戶範例**
生產事故影響了 AnyCompany Retail。隨時待命的工程師使用程序手冊來調查問題。隨著他們逐步完成這些步驟，他們會讓程序手冊中確定的關鍵利益相關者了解最新狀況。工程師將根本原因確定為後端服務中的競爭條件。使用執行手冊，工程師重新啟動了服務，使 AnyCompany Retail 重新上線。
### 實作步驟
如果您沒有現有的文件儲存庫，建議您為程序手冊庫建立版本控制儲存庫。您可以使用 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 Automation 等工具開始進行自動化，讓自動化和程序手冊保持同步。
**實作計劃的工作量：**低。您的程序手冊應該是存放在中央位置的文字文件。更成熟的組織將推進程序手冊自動化。
## 資源
**相關的最佳實務：**
+ [OPS02-BP02 流程和程序已識別擁有者](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS07-BP03 使用執行手冊執行程序](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html)
+ [OPS10-BP01 使用程序進行事件、事故和問題管理](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html)
+ [OPS10-BP02 每個提醒建立一個程序](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_process_per_alert.html)
+ [OPS11-BP04 執行知識管理](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**相關文件：**
+ [使用自動化程序手冊和執行手冊實現卓越的營運](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)
+ [使用文件建置器建立自訂執行手冊](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
**相關服務：**
+ [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 做出部署系統和變更的明智決策
為成功和失敗的工作負載變更建立程序。事前剖析是一種演練，團隊可藉此模擬失敗，制定緩解策略。使用事前剖析可預測失敗並適時建立程序。評估將變更部署到您的工作負載的優點和風險。確認所有變更都符合管控。
**預期成果：**
+ 您在將變更部署到您的工作負載時做出明智決策。
+ 變更符合管控。
**常見的反模式：**
+ 將變更部署到我們的工作負載，而沒有處理失敗部署的程序。
+ 對不符合管控要求的生產環境進行變更。
+ 部署新版本的工作負載，而未建立資源使用率的基準。
**建立此最佳實務的優勢：**
+ 您對工作負載的失敗變更已做好準備。
+ 變更您的工作負載符合管控政策。
**未建立此最佳實務時的曝險等級：**低
## 實作指引
使用事前剖析來開發失敗變更的程序。記載失敗變更的程序。確定所有變更都符合管控。評估將變更部署到您的工作負載的優點和風險。
**客戶範例**
AnyCompany Retail 定期執行事前剖析來驗證他們失敗變更的程序。他們在共用 Wiki 中記載程序並且頻繁更新。所有變更都符合管控要求。
**實作步驟**
1. 在將變更部署到您的工作負載時做出明智決策。建立及審核成功部署的準則。開發會啟動變更回復的情境或準則。權衡部署變更的優點與失敗變更的風險。
1. 確認所有變更都符合管控政策。
1. 使用事前剖析為失敗變更進行規劃並且記載緩解策略。執行桌上模擬演練來建立失敗變更的模型，並且驗證回復程序。
**實作計劃的工作量：**中。實作事前剖析的實務需要貴組織利益相關者的協調和努力
## 資源
**相關的最佳實務：**
+ [OPS01-BP03 評估治理要求](ops_priorities_governance_reqs.md) - 管控要求是判斷是否部署變更的關鍵因素。
+ [OPS06-BP01 計畫變更失敗](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) - 建立計畫來緩解失敗的部署並且使用事前剖析來進行驗證。
+ [OPS06-BP02 測試部署](ops_mit_deploy_risks_test_val_chg.md) - 每個軟體變更都應該在部署之前先適當的進行測試，以便在生產中減少缺陷。
+ [OPS07-BP01 確保人員能力](ops_ready_to_support_personnel_capability.md) - 擁有支援工作負載的足夠受過培訓的人員，對於為部署系統變更做出明智決策相當重要。
**相關文件：**
+ [Amazon Web Services：風險與合規](https://docs.aws.amazon.com/whitepapers/latest/aws-risk-and-compliance/welcome.html)
+ [AWS 共同責任模型](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [AWS 雲端 中的管控：敏捷性和安全性之間的正確平衡](https://aws.amazon.com/blogs/apn/governance-in-the-aws-cloud-the-right-balance-between-agility-and-safety/)
# OPS07-BP06 建立生產工作負載的支援計劃
針對您的生產工作負載所依賴的任何軟體和服務啟用支援。根據您的生產服務層級需求選取適當的支援等級。這些相依性的支援計劃的存在有其必要性，以便應對服務中斷或軟體問題。記錄支援計劃，以及如何要求所有服務和軟體供應商的支援。實作相關機制以確認支援的聯絡窗口是最新的。
**預期成果：**
+ 為生產工作負載所依賴的軟體和服務實作支援計劃。
+ 根據服務層級需求選擇適當的支援計劃。
+ 記錄支援計劃、支援等級，以及如何要求支援。
**常見的反模式：**
+ 您沒有主要軟體供應商的支援計劃。您的工作負載因此受到影響，且您無法加速進行修正，或及時獲得供應商提供的更新。
+ 擔任軟體供應商主要聯絡窗口的開發人員已離開公司。您無法直接聯繫供應商支援人員。您必須花時間研究及瀏覽通用聯絡系統，因此必要時的回應將更為耗時。
+ 軟體供應商發生生產中斷。目前沒有文件說明如何提出支援案例。
**建立此最佳實務的優勢：**
+ 透過適當的支援等級，您將可在必要的時間範圍內獲得回應以滿足服務層級需求。
+ 受支援的客戶可在遇到生產問題時加以呈報。
+ 軟體和服務供應商可在事件發生期間協助進行疑難排解。
**未建立此最佳實務時的曝險等級：**低
## 實作指引
針對您的生產工作負載所依賴的任何軟體和服務供應商啟用支援計劃。設定適當的支援計劃以滿足服務層級需求。對於 AWS 客戶而言，這意味著在任何有生產工作負載的帳戶上啟動 AWS Business Support 或更高等級。定期與支援供應商聯繫，取得關於支援優惠、程序和聯絡人的更新。記錄如何要求軟體和服務供應商的支援，包括如何在中斷發生時加以呈報。實作相關機制以保有最新的支援聯絡資料。
**客戶範例**
在 AnyCompany Retail，所有商業軟體和服務相依性都有支援計劃。例如，他們在所有具有生產工作負載的帳戶上啟動了 AWS Enterprise Support。任何開發人員都可在問題發生時提出支援案例。有 Wiki 頁面提供了相關資訊說明如何要求支援、應通知誰，以及加速處理案例的最佳實務為何。
**實作步驟**
1. 與組織中的利益相關者合作，識別您的工作負載所依賴的軟體和服務供應商。記錄這些相依性。
1. 確認工作負載的服務層級需求。選取相對應的支援計劃。
1. 針對商業軟體和服務，與供應商共同建立支援計劃。
1. 為所有生產帳戶訂閱 AWS Business Support 或更高等級可獲得 AWS 支援 更快的回應時間，極力建議這麼做。如果您沒有付費支援，則必須有處理問題的行動計劃，而這需要 AWS 支援 的協助。AWS 支援 提供了多種工具和技術、人員及方案，旨在主動協助您最佳化效能、降低成本和加快創新速度。此外，AWS Business Support 提供額外的權益，包括透過 API 存取 AWS Trusted Advisor 和 AWS Health，以便與您的系統進行程式設計整合，以及其他存取方法，例如 AWS 管理主控台 和 Amazon EventBridge 管道。
1. 在您的知識管理工具中記錄支援計劃。納入如何要求支援、在提出支援案例時應通知誰，以及在事件發生時如何加以呈報等資訊。任何人在得知支援程序或聯絡資料有所變更時，都可以利用 Wiki 這項機制對文件進行必要的更新。
**實作計劃的工作量：**低。大部分的軟體和服務供應商都提供選擇加入支援計劃。在您的知識管理系統上記錄並分享支援最佳實務，可確保您的團隊知道在生產問題發生時應如何因應。
## 資源
**相關的最佳實務：**
+ [OPS02-BP02 流程和程序已識別擁有者](ops_ops_model_def_proc_owners.md)
**相關文件：**
+ [AWS 支援 計劃](https://docs.aws.amazon.com/awssupport/latest/user/aws-support-plans.html)
**相關服務：**
+ [AWS 商業支援](https://aws.amazon.com/premiumsupport/plans/business/)
+ [AWS 企業支援](https://aws.amazon.com/premiumsupport/plans/enterprise/)