# 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/)