如何改善您的 IT 支持工作流
IT 变更管理的演变
变更管理（也称为变更支持）是一种 IT 实践，旨在在更改关键系统和服务的同时最大限度地减少 IT 服务的中断。
变更是指添加、修改或删除任何可能对服务产生直接或间接影响的内容。
变更管理实践旨在减少事件并满足监管标准。这些实践可确保高效、及时地处理 IT 基础架构和代码的更改。无论您是要推出新服务、管理现有服务，还是要解决代码中的问题，现代变更管理方法都可以打破孤岛，提供上下文和透明度，避免瓶颈，并将风险降至最低。
风险管理是相关的 ITIL 4 实践，遵循“确保组织了解并有效处理风险”。变更和风险管理都需要跟踪和链接变更，以提供可审计的记录。利用有关先前变更及其成功率的数据的能力，组织能够以巧妙地平衡风险和速度的方式调整其实践。
以数据为依据的自适应实践力求提高效率，而传统的变更管理往往缓慢、流程繁重且负担过重。由于变更管理涉及风险和合规性、可审计性和跨团队协调方面的挑战，因此变更管理往往会变得复杂、繁琐且令人痛苦。
不过不一定是这样。将变更管理视为 ITSM 的“吃蔬菜”——并不是特别想做，但至关重要。通过正确的实践和文化，变更管理可以减少事件，减轻团队的压力，并将更多的时间花在为客户创造价值上。
定义变更管理
我们中有些人想到变更管理时，我们的定义涉及到变更的各个方面——从技术、人员和流程一直到对客户和系统的影响。为了在 ITSM 的背景下提供清晰度，ITIL 4 区分了 IT 变更管理和组织变更管理实践。
- 组织变更管理是“确保组织中的变更顺利成功实施，并通过管理变更的人为方面来实现持久收益的实践”。
然后，ITIL 4 将其以前的变更管理流程重新定义为“变更控制”实践。
- 变更控制实践确保“正确评估风险，授权继续进行变更并管理变更时间表，以最大限度地增加服务和产品成功变更的次数。”
这个新名称的选择引发了争议，许多 IT 团队拒绝与“控制”关联。对某些人来说，这是一个有毒的词，它让人想起传统变更管理因创建而臭名昭著的官僚主义、瓶颈和不必要的步骤。
Axelos 听取了反馈并做出了回应。“ITIL 4 Foundation 发布后，我们听到有些人表示，‘这种实践会被误读或误解为专注于‘控制变更’或‘控制团队’，而不是‘控制变更速度’’”
ITIL 最终转而将这种实践称为“变更支持”。新名称意味着一种对团队有帮助的实践，为他们提供推动变更的能力和自由。
归根结底，我们认为使用的术语并不是特别重要。（在本文和 Atlassian 中，我们将其称为变更管理。）重要的是方法。以健康的团队和正确的文化开始，您的组织就会走上正确的轨道，创建有效的变更管理实践。
变更管理与版本管理之间的关系
版本管理是变更管理对话中另一个非常重要的实践。根据 ITIL 4，“版本管理...是提供新的和更改的服务和功能以供使用”的目的。版本可能包括从软件功能的更改到文档和培训更新的所有内容。
过去，版本管理将变更捆绑在一起，以软件包的形式呈现给客户。传统的版本管理遵循严格的项目管理标准，可能会在向客户发布有价值的更新时造成摩擦，导致遵守敏捷开发原则的团队感到沮丧。
我们可以重新构想 DevOps 上下文的版本管理。摆脱传统的项目管理功能，版本管理应该转向集成和自动化。它首先将代码管道引入到一个安全的系统中，该系统尽可能包含自动审查，并提供跟踪和监督。这可以打破过去的孤立方法，提供一条顺畅的生产途径。版本管理可以比以往任何时候都更轻松地持续交付价值，并应用“谁构建，谁负责”的原则。
为什么 IT 变更管理很重要？
现代组织对 IT 团队有几个关键期望，并且这些期望还相互矛盾。首先，他们期望获得稳定、可靠的服务，以确保组织的工作效率并能够满足最终用户的期望。其次，IT 团队需要定期实施服务更新，以使组织能够适应不断变化的安全性、成本和业务需求。
两个期望无论哪个得不到满足，都可能导致可怕的后果。无法维持可靠的服务可能会对生产力和成本造成巨大损害。据 Gartner 称，许多组织报告说，停机期间每小时代价超过 300,000 美元。对于某些基于 Web 的服务，这个数字可能还会大幅提高。
同时，不适应未来的组织将无法跟上业务的步伐，并落后于竞争对手。部署变更的速度过慢可能会导致员工跳槽到系统更灵活的地方工作，或者您的客户将支持和资金转移到为他们提供更多价值的其他组织。
那么，您应该如何管理这些相互矛盾的需求呢？变更管理实践使您的组织能够发布更新，同时确保稳定性并降低风险。变更管理通过以下方式帮助实现变更：
- 建立管理变更流程的框架
- 确定必要变更的优先顺序，以正确分配资源
- 整合相关信息以做出更明智的决策
- 让开发人员和 IT 部门的必要利益相关者参与审批
- 整合变更测试，以避免意外事件
- 简化和改进变更流程，更快地实现价值
变更的类型
ITIL 定义了三种类型的变更。
标准变更
标准变更风险较低，通常为重复性变更，并且是预先批准的。标准变更会频繁执行，并遵循某一记录在案的、经过批准的流程。
例如，添加内存或存储是标准变更。将故障路由器更换为正常工作的相同路由器是一项标准变更。创建数据库的新实例是一项标准变更。
这些变更很常见，并且遵循某一明确定义的流程。而且，由于该流程可能已经通过了变更管理的风险评估和批准流程，因此无需在每次需要更换路由器时都再次执行该流程。
对于许多公司来说，标准变更是实现自动化的绝佳机会。一些公司报告说，多达 70% 的标准变更可以自动执行，这使他们的团队能够腾出时间专注于常规和紧急变更。
常规变更
常规变更是一种非紧急变更，但它们并没有既定的、预先批准的流程。
例如，升级到新的内容管理系统是常规变更。迁移到新数据中心是常规变更。性能改进是常规变更。它们不是标准可重复的，会涉及风险。但它们也不是紧急变更。这意味着他们可以进入一般变更管理队列进行风险评估和批准。
某些常规变更（如数据中心交换机）仍然存在高风险，可能需要风险评估并获得变更顾问委员会 (CAB) 的批准。其他变更（例如网站变更）可能风险较低，可以通过指定的变更机构或通过自动检查和同行评审在更短的时间内获得批准。
紧急变更
这些变更源于意外的错误或威胁且需要立即解决，其目的通常是为了恢复客户或员工的服务或保护系统免受威胁。
例如，实施安全补丁程序是一项紧急变更。处理服务器中断是一项紧急变更。解决重大事件是一项紧急变更。
紧急变更的紧迫性意味着需要按照更紧迫的时间线处理变更，因为冗长的审批过程所产生的风险远高于快速解决问题所牵涉的风险。
对变更进行分类的方式取决于多种因素，包括您的组织、流程和风险承受能力。我们主张放弃“一刀切”的方法，而是根据风险评估来对每项变更进行区别对待。随着的组织更多地了解以前的事件、特定系统并整合其他相关数据，应该可以将更高比例的变更指定为标准变更，并预先批准这些变更。现代变更管理应该让变更请求尽可能简单和精简。
什么是变更咨询委员会 (CAB)？
在大多数传统 IT 组织中，变更咨询委员会 (CAB) 的任务是评估风险并批准（或不批准）每项变更。通常，CAB 会定期举行会议，审查所有拟议的未来变更，根据需要邀请专家与他们一起解释、评估变更或为变更辩护。
一方面，变更咨询委员会可以帮助降低风险，并在变更对公司不起作用时发出警报。另一方面，它们也可能造成瓶颈，尤其是当他们由与所部署的变更不太接近的人员组成时。在许多企业中，变更咨询委员会 (CAB) 的审批流程既复杂又耗时，这会减慢变更流程。
许多 IT 团队正在放弃传统的 CAB 会议，或者将会议范围限制在风险最大的变更和重要的组织问题上。在这种模式下，CAB 可以成为值得信赖的顾问，负责监测趋势，就实践如何解决这些问题提供建议，并在团队和他们的需求之间进行协调。
ITIL 4 还鼓励将您的变更权限下放给业务利益相关者或同等级别。不要使用单独的委员会，而是将变更管理构建到与相关利益相关者的正常工作流程中。为避免瓶颈，请将自动化、虚拟清单和同行评审视为更灵活、更具协作性的替代方案。
变更管理流程
对于敏捷、高速的团队来说，变更管理流程正在从冗长的审核和非技术利益相关者的批准变为 IT 和开发团队之间的自动化协作流程，这种流程在提高灵活性的同时仍能平衡风险。
以下是变更管理流程的基本概述，以及一些加快交付价值的建议。
变更管理的最佳实践
正如我们之前提到的，变革管理带来的恐惧与我们中有些人对吃绿叶蔬菜的恐惧一样。我们并不想做这件事，但我们知道它非常重要。并且，我们可以采取措施使这两件事更具吸引力。
以下是现代变更管理的一些最佳实践：
- 了解您的组织的风险承受能力和监管义务
- 尽可能简化和自动化变更管理流程
- 为 CAB 提供更具战略意义的重点
- 拥抱实践，使标准变更成为新常态
- 查看 ITIL 和 DevOps 等各种框架，找到最适合您的组织的准则
- 优先考虑协作
- 使用混沌工程来降低风险
- 简化 IT 和开发人员团队的变更请求收集
- 利用变更指标和 KPI 解锁学习
- 采用 DevOps 驱动的版本管理方法
迎接变更管理的挑战
开发人员希望快速推出代码，而无需在手动文档上花费额外的时间和精力。IT 运营团队力求降低风险、维护详细的记录以供审计，并避免事件。要求开发人员在他们的流程中添加一个额外步骤，写下事情，开始和结束都要打卡，可能会让他们觉得自己无法实现工作的最终目标。要求运营团队彻底改革现有流程、取消审批检查并将更多工作留给自动化并不容易，而且可能会感觉这会带来更大的风险。
同时，风险也比以往任何时候都高。软件驱动的服务的兴起提高了客户对永不停机、高性能服务的期望和需求。在日益动态的环境中，管理服务所需的工作量不断增加。
那么，我们怎样才能克服这些挑战呢？首先要消除繁重的过程可以降低风险的神话。然后采用有助于团队协作和交付的文化、相应的实践和工具。最后，不断整合信息以证明前面步骤的价值，并继续努力改进。
想要了解 Jira Service Management 如何转变您的变更管理流程？