如何改善您的 IT 支持工作流
十大变更管理最佳实践
变更管理以流程繁重、笨拙和困难而闻名，但其实并非如此。如果运行良好，IT 变更管理可以减少事件，同时还能保持流程的灵活性并最大限度减少工作中断。
那么，您如何做到这一点呢？我们整理了一份包含 10 项最佳实践的清单，以便您在组织中启动变更管理：
1. 了解您的组织的风险承受能力并相应地进行规划
在平衡风险和速度方面，变更管理中没有一刀切的解决方案。每个组织都有自己的文化、风险承受能力和法规要求需要处理，每个组织都应将这些考虑因素纳入其变更管理实践中。
了解风险包括了解企业的监管和合规义务。一旦涉及到法规，就不再是失去业务前您的系统可能面临多少停机期间的问题，也不再是修复问题需要花费多少资源的事。这就变成了一组不容商榷的规则。您需要获得某些批准，将需要分担职责。SOX 和 GDPR 等法规使某些活动不容商榷，即使这些活动稍微减慢了流程。
好消息是，这个计划不一定是静态的。选择保守方法、审批次数更多、工作流程僵化的公司始终可以随着时间的推移重新评估，调整流程的严格程度以与风险水平保持平衡。
通过使用 Jira Service Management，可以根据组织的规范来自定义审批和工作流程。使流程达到所需的灵活性或自动化程度。或许，还能对较低风险的流程进行自动化，并通过审批来保护比较错综复杂的流程。
2. 使用数据驱动的风险评估，不断调整变更管理实践
跟踪指标，尤其是变更与事件之间的关联，是改进变更实践的重要基础。数据将突出显示趋势，揭示事件中最不可能涉及的变更管理类型、团队成员和服务。这些信息可以帮助您将不同变更请求的严格性与风险相匹配。
明智的风险评估意味着更多的变更请求通常可以降级为不太严格的审批工作流程。正如 Gartner 的自适应变更管理流程所暗示的那样，组织可以努力将越来越多的正常变更归类为标准变更，然后进行预先批准和自动化。
下面，我们整理了一些使标准更改成为新常态的实用步骤。
- 查看过去几个月的变更
- 最常见的变更是什么？
- 哪些变更是“标准变更”？
- 它们会影响哪些服务？
- 哪些更改是成功的？
- 实施这些变更的平均时间是多久？
- 开发团队请求了哪些变更？
- 选择三到五个标准变更作为候选变更进行自动化
- 为服务管理软件中的标准变更构建自助服务请求类型
- 添加文本以阐明标准变更请求的目的和范围
- 捕获重要字段，例如正在变更的系统、应用或服务
- 创建自动化规则以自动批准变更、转移状态，并通过更新通知员工
- 花点时间对您的 IT 员工和开发团队展开有关这项新功能的教育和培训
- 监控未来几个月的表现
- 获得洞察信息以改进您的现有产品
- 确定其他标准变更以实现自动化
在评估了团队以往的变更管理实践，并考量了变更风险之后，将风险评估文档汇集于一处大有裨益。借助 Jira Service Management 的 Confluence 集成，团队可以参考位于变更管理计划文档中的单一数据源。除了风险评估信息外，协作者还能在此页面上添加变更计划模板。
3. 让变更管理尽可能简单
没人想要额外的工作。这就是为什么变更管理通常被认为是一件令人讨厌的事情。变更管理实践通常要求人们记录某些内容（通常是在他们不喜欢使用的工具中），然后再等待执行包含另外一两个步骤的流程。对于负责实时推送代码的开发人员来说，这些额外的任务可能感觉像是在阻碍实际工作。此时，诸如变更管理 Confluence 页面等集中式数据源便可发挥用处，通过让整个团队参与其中，从而简化文档。
这一重大挑战的答案是尽可能简化变更管理流程。尽可能将批准保持在最低限度。选择无缝集成的技术工具，这样开发人员就不必在多个系统中输入相同的信息。另外，尽可能实现自动化。Jira Service Management 提供这些功能，因此团队可以灵活地按照自己的节奏和方式来进行操作。
您的流程越简单，就越容易让团队参与进来。
4. 重新思考传统的 CAB 模型
在大多数传统 IT 组织中，变更咨询委员会 (CAB) 的任务是评估变更请求的技术和业务影响。传统的流程带来了一些挑战——发布缓慢、流程笨拙，有时还缺乏沟通和协作。这就是为什么表现最好的团队正在重新思考 CAB 模式。
我们的目标是保持这些看板为我们 IT 流程增加的价值，实现沟通并在变更需求与变更风险之间取得平衡，同时使典型的 CAB 流程更加灵活和具有战略意义。这通常意味着：
- 只要求 CAB 批准风险最大的变更（并使用经过验证的工具，如同行评审、虚拟清单和自动化来管理风险较小的变更）
- 为 CAB 分配战略，并帮助团队制定实践，通过流程效率和自动化来降低风险并减少变更管理的工作量
- 实现 CAB 虚拟化、实时化，而不必等待面对面会议来解决重大变更或处理问题
这里的关键是转向战略。新的 CAB 不是充当看门人，而是为了实现变更；不是瓶颈，而是战略资源。代码审查和深入了解技术问题仅供同行评审和最适合捕获代码错误的人员使用，CAB 可以腾出时间专注于流程、策略和支持持续交付。
5. 使用工具自动化和完善您的流程
6. 逐步部署较小的版本，以确保您的变更顺利进行
传统的发布方法是将它们捆绑在一起，然后一次性全部发布。我们大多数人现在知道的是，这种方法容易导致重大事件，并且在问题出现时更难找到问题的根源。更小、更频繁的版本可能会限制潜在事件的范围。为小部分用户累进部署金丝雀或功能标志，以便在全面部署之前测试和证明稳定性。
如果团队可以依据变更计划协调这些发布，那么整理规模较小的受控发布就变得更加轻松了。这有助于开发人员避开冲突区域或确定停工日期。借助 Jira Service Management 的变更管理功能，团队可以访问集中式时间表，获取执行这些碎片化发布所需的信息。
7. 将 ITIL 视为指导方针，而不是一成不变的规则
ITIL 有时会受到不公正的对待。有人认为它限制较多，而且已经过时了。但事实是，ITIL 可以为 IT 团队提供很多东西，包括那些坚持 DevOps 文化的团队。这里的问题不在于 ITIL 过于僵化。而在于我们接近其准则的方式。
将 ITIL 当作一系列严格的规则来对待，当然这会让人感到受限制。把它当作您的公司可以建立的一套基本准则，在您制定变更管理实践的过程中，您会觉得这更像是一种支持。
这适用于所有框架和文化方法。ITIL、精益、DevOps、敏捷开发、CD...没有框架，不管多受人喜爱，都无法一次解决所有问题。在我们应该考虑团队文化时，我们常常会寻找框架或工具来解决内部问题。
8. 优先考虑协作
从 CAB 到 DevOps 小组，领导团队都在拥抱协作、开放和实时更新。变更管理的存在是为了跨团队进行协调。变更、事件和问题会对多个团队产生连锁反应，而您的组织越复杂，这个事实就越明显。
良好的变更管理根本不可能在孤岛中发生。努力鼓励更开放协作的组织可能会改善其变更实践。
Jira Service Management 主要在于联合团队之力来更快实现目标 — 在本例中，可以更快地实施变更，避免意外事件。对于凝聚力强的高速团队，其核心思想是协作。借助配有 Confluence、集成式聊天和视频会议等工具的一个透明平台，加上可自定义的工作流，每个人都能掌握完整的背景信息，贡献自己的力量。
9. 利用混乱和弹性工程
混沌工程是最近的一种实践，重点是通过断开或关闭产品或服务的组件来测试弹性。同样，弹性工程专门解决了系统上所有可能的压力源——例如，以高用户数量或高流量推动系统。
这两种实践都是为了确定问题和为避免将来发生事件而需要进行的变更。这种先发制人的方法为变更管理团队带来了很多价值，并大大节省了事件管理团队的时间、预算和警报疲劳。
10. 选择开发团队熟悉和接受的工具
良好的变更管理流程应内置于开发人员使用的工具中和工具之间。要求团队学习新工具、在多个工具中输入信息或使用不熟悉且不舒服的工具往往会减慢采用速度，这会损害您向客户提供有价值的更新的能力。
在 Atlassian，我们使用 Jira Service Management 来跟踪变更。借助 Jira 平台，可以轻松地将开发团队和运维团队聚集在一起，提供从开发人员开始编码之前一直到将更改部署到生产环境的透明度和可追溯的上下文。