与在内部环境相比，云端变更管理可能更复杂。当企业部署云环境时，他们将需要管理大量的服务-而让这一挑战加剧的是，开发人员需要轻松快速地跨不同区域部署和更新应用程序。

但是，云变更管理并不是不可能实现的事情。通过适当的计划，企业可以制定流程，以自动化他们如何使用这些服务，并结合迭代部署模型与基础架构即代码等技术。除变更管理的技术方面外，企业还考虑其员工的协调以确保每个人理解相同。

超越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组可以确保组中的实例数量是恒定的，即使可用性区域中出现故障也是如此。