與在內部環境相比，云端變更管理可能更復雜。當企業部署云環境時，他們將需要管理大量的服務-而讓這一挑戰加劇的是，開發人員需要輕松快速地跨不同區域部署和更新應用程序。

但是，云變更管理并不是不可能實現的事情。通過適當的計劃，企業可以制定流程，以自動化他們如何使用這些服務，并結合迭代部署模型與基礎架構即代碼等技術。除變更管理的技術方面外，企業還考慮其員工的協調以確保每個人理解相同。

超越IT之外

在數據中心，IT管理員使用變更管理來控制IT資源的消耗和操作。他們通常采用規定的方法，通過服務管理框架，例如ITIL。通常會有變更咨詢委員會，負責審查請求及其潛在影響，并可能提出簡化或優化請求的方法。

Deloitte Consulting咨詢公司負責人Edward Majors表示，在云端，變更請求的最大不同之處在于速度。與在數據中心相比，云用戶可以更快地安排和部署變更到生產中。

Majors說：“由于變化如此之快，因此變更管理不再只是IT范疇。”

為了成功實現云變更管理，企業必須在受影響的群體之間保持溝通，以便員工了解變更的期望、收益和效果。

做更多計劃

借助靈活的按需IT資源，云用戶可以部署分布式、靈活擴展的工作負載，例如微服務。

云咨詢公司ServerCentral Turing Group云解決方案高級總監Josh Quint說，使用這種模型時，云端服務數量會急劇增加。因此，開發人員或IT工程師可能需要多個地方（有時甚至是找多家提供商）進行更改，而不是通過單個管理控制臺進行工作。另外，這些更改可能需要同時進行，從而使手動重新配置或配置變得不切實際。

企業應該將變更作為標準構建、集成和部署過程的一部分，這可確保一致性，即使發行版本的部署頻率越來越高。用于代碼創建、交付和部署的受控CI / CD管道還可標準化團隊之間的通信點。通過圍繞每個步驟的參數構建CI / CD管道，云團隊可記錄對云托管應用程序執行的所有變更的正確方法。

這種標準化的CI / CD流程可管理云中的所有更改，而無需門控式審查-這在內部部署中很常見。它還使云團隊能夠將自動化引入變更管理。流行的CI / CD工具（例如AWS CodePipeline、Jenkins和Azure DevOps）可在變更發布的每個階段自動化執行代碼，包括部署前的測試和審核。這些步驟會生成有關變更的信息，團隊應捕獲這些信息作為變更的文檔。

Quint說：“圍繞核心流程提供詳細的文檔和結構，這里未實現的好處是自動化所帶來的真正價值。”這些文檔會使變更請求變得更容易檢查和部署，因為它們有明確的路徑，并且可清楚地識別誰應該或不應該參與。

基于利益相關者的反饋進行迭代

當IT團隊，從仍然很常見的Waterfall開發方法，轉移到通過CI / CD管道的少量變更發布的迭代方法時，他們應該關注利益相關者的反饋。

IT咨詢公司TetraVX客戶體驗總監Sean Kendall解釋說，IT團隊可以在新的部署中進行多次測試，以便同時處理來自各個利益相關者的反饋。

在此迭代過程中要解決的一些重要問題包括：

· 用戶能否訪問該軟件？

· 是否有適當的高可用性和故障轉移？

· 我們離云提供商的數據中心有多遠，這是否會影響延遲性？

Kendall指出，基于反饋審查和調整軟件的靈活做法比任何特定工具都更重要。

基礎設施即代碼

云咨詢公司SADA云平臺主管Simon Margolis說，如果企業努力設置基礎架構即代碼，則變更管理會更容易。對于給定變更，IT資源和托管方面都是自動化，這使得更容易跟蹤、復制和操縱這些基礎結構配置。開發人員還可以在發布之前從基礎結構代碼快速啟用復制環境進行測試，但由于成本原因，這種做法在本地并不總是可行。

Margolis推薦使用HashiCorp Terraform用于基礎設施即代碼。它可在很多公共云上運行，并且很多IT工程師和開發人員都很熟悉。還有特定于給定平臺的云原生選項，例如AWS CloudFormation或Google Cloud Deployment Manager。

協調人員

計劃和跟蹤變更也很重要，企業可使用Asana、Trello或Basecamp等工作管理工具來協作、查看實時進度和更新，因為所有利益相關者都應該關注云變更。Margolis說：“你需要找到一種工具來檢查所有基本情況，并確保整個團隊都在使用該工具。”

流程圖也很有用，可確保所有人理解相同。云變更及其部署過程的可視化視圖可以幫助與工程師展開有關潛在問題的對話。

為故障做計劃

云咨詢公司Nebulaworks首席技術官Rob Hernandez說，企業在運作任何云環境時，都應該為故障做準備。這不一定需要混合或多云方法。云用戶通常可以通過跨可用區域部署以及設計實例以自動進行故障轉移和重新配置來實現彈性。

Hernandez說，跨越可用性區域的機器角色應該是默認的操作方式。這不需要比單區域配置更多的工作，并且當云提供商出現問題時，這可提供顯著優勢。

大型云供應商提供實例選項以重新部署和恢復工作，而無需人工干預。例如，在AWS中，Auto Scaling組可以確保組中的實例數量是恒定的，即使可用性區域中出現故障也是如此。

責任編輯：ct