

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

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

**Topics**
+ [REL08-BP01 將執行手冊用於部署等標準活動](rel_tracking_change_management_planned_changemgmt.md)
+ [REL08-BP02 將功能測試整合為部署的一部分](rel_tracking_change_management_functional_testing.md)
+ [REL08-BP03 將彈性測試整合為部署的一部分](rel_tracking_change_management_resiliency_testing.md)
+ [REL08-BP04 使用不可變基礎設施進行部署](rel_tracking_change_management_immutable_infrastructure.md)
+ [REL08-BP05 使用自動化部署變更](rel_tracking_change_management_automated_changemgmt.md)

# REL08-BP01 將執行手冊用於部署等標準活動
<a name="rel_tracking_change_management_planned_changemgmt"></a>

 執行手冊是實現特定成果的預定義程序。使用執行手冊執行手動或自動進行的標準活動。範例包括部署工作負載、修補工作負載或進行 DNS 修改。 

 例如，實施程序 [以確保部署期間的回復安全性](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)。確保您可以回復部署，且不會對客戶造成任何中斷，這對於打造可靠的服務而言至為關鍵。 

 對於執行手冊程序，從有效的手動流程開始，以程式碼實作並在適當時將其觸發為自動執行。 

 即使是高度自動化的複雜工作負載， [執行手冊仍然適用於執行演練日](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays) 或滿足嚴格的報告和稽核要求。 

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

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

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

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

## 實作指引
<a name="implementation-guidance"></a>
+  透過在執行手冊中記錄程序，對熟知的事件做出一致且迅速的回應。 
  +  [AWS Well-Architected Framework：概念：執行手冊](https://wa.aws.amazon.com/wat.concept.runbook.en.html) 
+  使用基礎設施即程式碼的原則來定義您的基礎設施。透過使用 AWS CloudFormation (或受信任的第三方) 來定義您的基礎設施，您可以使用版本控制軟體對變更進行版本控制和追蹤。 
  +  使用 AWS CloudFormation (或受信任的第三方供應商) 來定義您的基礎設施。
    +  [什麼是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 
  +  使用良好的軟體設計原則，建立單一、解偶的範本。
    +  確定實作的許可、範本和負責方。
      + [ 使用 AWS Identity and Access Management 控制存取 ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html)
    +  使用原始檔控制 (例如 AWS CodeCommit 或受信任的第三方工具) 進行版本控制。
      +  [什麼是 AWS CodeCommit？](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) 

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

 **相關文件：** 
+  [APN 合作夥伴：可以幫助您建立自動化部署解決方案的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=devops) 
+  [AWS Marketplace：可用於自動化部署的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps) 
+  [AWS Well-Architected Framework：概念：執行手冊](https://wa.aws.amazon.com/wat.concept.runbook.en.html) 
+  [什麼是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 
+  [什麼是 AWS CodeCommit？](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) 

   **相關範例：** 
+  [使用程序手冊和執行手冊將操作自動化](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/) 

# REL08-BP02 將功能測試整合為部署的一部分
<a name="rel_tracking_change_management_functional_testing"></a>

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

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

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

## 實作指引
<a name="implementation-guidance"></a>
+  將功能測試整合為部署的一部分。功能測試會作為自動化部署的一部分執行。如果未符合成功條件，則會終止或回復管道。 
  +  在 AWS CodePipeline 中建立模型之軟體發行管道的「測試動作」期間叫用 AWS CodeBuild。此功能可讓您輕鬆針對程式碼執行各種測試，例如單元測試、靜態程式碼分析和整合測試。
    +  [AWS CodePipeline 新增對於單位的支援，以及透過 AWS CodeBuild 自訂整合測試](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/) 
  +  使用 AWS Marketplace 解決方案，在軟體交付管道中執行自動化測試。
    +  [軟體和測試自動化](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation) 

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

 **相關文件：** 
+  [AWS CodePipeline 新增對於單位的支援，以及透過 AWS CodeBuild 自訂整合測試](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/) 
+  [軟體和測試自動化](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation) 
+  [什麼是 AWS CodePipeline？](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) 

# REL08-BP03 將彈性測試整合為部署的一部分
<a name="rel_tracking_change_management_resiliency_testing"></a>

 彈性測試 (使用 [混沌工程的原則](https://principlesofchaos.org/)) 會在生產前環境中做為自動化部署管道的一部分執行。 

 這些測試會在生產前環境暫存於管道中並在其中執行。這些測試也應該在生產環境中執行，以 [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays)。 

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

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

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

 **相關文件：** 
+  [混沌工程的原則](https://principlesofchaos.org/) 
+  [什麼是 AWS Fault Injection Simulator？](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) 

 **相關範例：** 
+  [Well-Architected 實驗室：第 300 級：測試 EC2 RDS 和 S3 的彈性](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html) 

# REL08-BP04 使用不可變基礎設施進行部署
<a name="rel_tracking_change_management_immutable_infrastructure"></a>

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

 不可變基礎設施範例最常見的實作是 ***不可變的伺服器***。這表示如果伺服器需要更新或修正，則會部署新的伺服器，而非更新已在使用中的伺服器。因此，應用程式中的每個變更都會從軟體推送至程式碼儲存庫 (例如 git push) 開始，而不會透過 SSH 登入伺服器並更新軟體版本。不可變的基礎設施不允許進行變更，因此您可以確定已部署系統的狀態。不可變的基礎設施在本質上更一致、更可靠且更可預測，而且它們可簡化軟體開發和操作的許多方面。 

 在不可變的基礎設施中部署應用程式時，請使用 Canary 或藍/綠部署。 

 [https://martinfowler.com/bliki/CanaryRelease.html](https://martinfowler.com/bliki/CanaryRelease.html) 是將少量客戶導向至新版本的實務，通常會在單一服務執行個體 (Canary) 上執行。之後，您可以仔細檢查所產生的任何行為變更或錯誤。如果遇到嚴重問題，可以從 Canary 中刪除流量，然後將使用者傳送回以前的版本。如果部署成功，則您可以繼續以期望的速度進行部署，同時監控變更是否有錯誤，直到完全部署為止。AWS CodeDeploy 可以使用將支援 Canary 部署的部署組態來設定 AWS CodeDeploy。 

 [https://martinfowler.com/bliki/BlueGreenDeployment.html](https://martinfowler.com/bliki/BlueGreenDeployment.html) 與 Canary 部署類似，不同之處在於整個應用程式須並行部署。您可在兩個堆疊 (藍色和綠色) 之間交替部署。再次強調，您可以將流量傳送到新版本，且如果發現部署問題，則可以回復到舊版本。通常會一次切換所有流量，但您也可以將一小部分的流量用於每個版本，以使用 Amazon Route 53 的加權 DNS 路由功能，提高新版本的採用率。可以使用將支援藍/綠部署的部署組態來設定 AWS CodeDeploy 及 AWS Elastic Beanstalk。 

![\[圖表：顯示使用 AWS Elastic Beanstalk 和 Amazon Route 53 進行藍/綠部署\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/blue-green-deployment.png)


 不可變基礎設施的優勢： 
+  **降低組態偏移：** 透過經常從基本、已知和版本控制的組態取代伺服器，可將基礎設施 **重設為已知狀態，並避免組態偏移。** 重設為已知狀態，並避免組態偏移。 
+  **簡化部署**：部署不需要支援升級，因此會得到簡化。升級只是新的部署。 
+  **不可部分完成的可靠部署：** 部署成功完成，或是未進行任何變更。其可為部署程序賦予更多信任。 
+  **利用快速的回復及復原程序打造更安全的部署：** 前一個運作版本並未變更，因此部署變得更加安全。如果偵測到錯誤，您可以回復至該版本。 
+  **一致的測試和偵錯環境：** 所有伺服器都會使用相同的映像，因此環境之間沒有差異。一個組建會部署到多個環境中。它還能預防不一致的環境並簡化測試與偵錯。 
+  **提高可擴展性：** 伺服器使用基礎映像，具有一致性和可重複性，因此自動調整規模相當簡單。 
+  **簡化工具鏈**：您可以擺脫管理生產軟體升級的組態管理工具，因此工具鏈得到簡化。不會在伺服器上安裝額外的工具或代理程式。會對基礎映像進行變更、並對變更進行測試然後推出。 
+  **提高安全性：** 藉由拒絕對伺服器進行的所有變更，您可以停用執行個體上的 SSH 並移除金鑰。這可減少攻擊向量，從而改善組織的安全狀態。 

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

## 實作指引
<a name="implementation-guidance"></a>
+  使用不可變基礎設施進行部署。不可變基礎設施是一種模型，其中不會進行更新、安全性修補程式或組態方面的變更。 *就地* 進行更新、安全性修補程式或組態方面的變更。需要進行變更時，系統會建置新版本的架構並部署到生產環境。 
  +  [藍/綠部署概觀](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green) 
  +  [逐步部署無伺服器應用程式](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html) 
  +  [不可變基礎設施：透過不可變實現可靠性、一致性和可信度](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23) 
  +  [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html) 

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

 **相關文件：** 
+  [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html) 
+  [逐步部署無伺服器應用程式](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html) 
+  [不可變基礎設施：透過不可變實現可靠性、一致性和可信度](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23) 
+  [藍/綠部署概觀](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green) 
+  [Amazon Builders' Library：確保部署期間的回復安全](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments) 

# REL08-BP05 使用自動化部署變更
<a name="rel_tracking_change_management_automated_changemgmt"></a>

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

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

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

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

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

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

## 實作指引
<a name="implementation-guidance"></a>
+  自動化您的部署管道。部署管道讓您可以叫用自動測試、偵測異常，或者在生產部署之前的某個步驟中停止管道，或者自動回復變更。 
  +  [Amazon Builders' Library：確保部署期間的回復安全](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments) 
  +  [Amazon Builders' Library：使用持續交付加快腳步](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/) 
    +  使用 AWS CodePipeline (或受信任的第三方產品) 來定義和執行管道。
      +  設定管道以在對程式碼儲存器提交變更時啟動。
        +  [什麼是 AWS CodePipeline？](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) 
      +  使用 Amazon Simple Notification Service (Amazon SNS) 和 Amazon Simple Email Service (Amazon SES) 傳送有關管道中問題的通知，或與團隊聊天工具 (如 Amazon Chime) 整合。
        +  [什麼是 Amazon Simple Notification Service？](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 
        +  [什麼是 Amazon SES？](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html) 
        +  [什麼是 Amazon Chime？](https://docs.aws.amazon.com/chime/latest/ug/what-is-chime.html) 
        +  [使用 Webhook 自動化聊天訊息。](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html) 

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

 **相關文件：** 
+  [APN 合作夥伴：可以幫助您建立自動化部署解決方案的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=devops) 
+  [AWS Marketplace：可用於自動化部署的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps) 
+  [使用 Webhook 自動化聊天訊息。](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html) 
+  [Amazon Builders' Library：確保部署期間的回復安全](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments) 
+  [Amazon Builders' Library：使用持續交付加快腳步](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/) 
+  [什麼是 AWS CodePipeline？](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) 
+  [什麼是 CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 
+  [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 
+  [什麼是 Amazon SES？](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html) 
+  [什麼是 Amazon Simple Notification Service？](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 

 **相關影片：** 
+  [2019 年 AWS 高峰會：AWS 上的 CI/CD](https://youtu.be/tQcF6SqWCoY) 