团队如何共享变更管理角色和职责

变更管理者/协调员

变更管理者（有时也称为变更协调员）通常负责管理 IT 变更的所有方面。他们确定变更请求的优先级，评估其影响，并接受或拒绝更改。他们还记录变更管理流程和变更计划。重要的是，他们准备、组织和担任 CAB 会议的主席。变更管理者的成功通常取决于他们是否符合时间和预算目标。

变更权威人士/批准者

变更权威人士是指决定是否授权变更的人员。有时是一个人，例如经理或高管。有时候是变更顾问委员会的一群人。有时候是同行评审员。根据 ITIL 4，“在高速组织中，分散变更批准是常见做法，这使同行评审成为高绩效的首要预测指标。”

变更管理者通常会与变更权威人士密切合作，以批准变更并在组织内向前推进。在某些情况下，特别是在小型组织中，变更管理者就是变更权威人士，有权在不增加人员或团队的情况下做出这些决策。

企业利益相关者

企业利益相关者通常会参与变更管理，并可能进入授权流程。鉴于软件服务对大多数企业至关重要，这种情况越来越普遍。

例如，如果某项变更影响了财务团队的付款跟踪软件与销售团队的 CRM 之间的连接，则财务和销售团队的利益相关者可能需要参与 CAB 会议以及就变更做出的最终决策。

工程师/开发人员

开发团队通常会提交更改以供批准，并根据需要记录案例。变更获得批准后，在采用“谁构建，谁运行”方法的公司中，这些团队部署变更并对其进行监控，并经常对与变更相关的任何事件或问题做出响应。在其他情况下，负责更改引起的任何事件的事件管理团队可能与实施变更的开发人员分开。

服务台支持人员

服务台支持人员可以对变更可能导致的事件和常见服务问题提供独特的前线视角。

运营经理

由于运营经理负责保持系统的日常运行，因此他们会考虑风险和依赖关系。

客户关系经理

为了代表客户的声音，关系经理可以提供有关客户心态、挫折感和不断变化的需求的知识。

信息安全官和网络工程师

网络安全和云基础架构专家带来了有关威胁和漏洞的重要洞察信息。

什么是 CAB？

变更咨询委员会 (CAB) 召集负责上述职责的人员，这些小组的任务是评估每个变更请求的风险并批准（或不批准）这些变更请求。通常，CAB 会定期举行会议，审查所有拟议的未来变更，并根据需要邀请专家与他们一起解释、评估变更或为变更辩护。传统 CAB 被称为控制变更版本的看门人。

出于这个原因，再加上繁琐的会议、长时间的变更请求待办事项列表以及与工作本身的距离，CAB 常常被人轻视。幸运的是，许多 CAB 正在不断发展，以更好地实现敏捷的软件交付，承担着更具战略意义的咨询角色。CAB 正在转变为顾问，负责监控变更趋势，推荐能够解决这些趋势的实践，并寻求更好地使团队能够为客户创造价值并降低风险的方法。

CAB 的挑战

围绕糟糕会议的陈词滥调也适用于 CAB。公平来说，我们可以说他们浪费时间，因为他们成就不够，涉及太多随机的人，并且“本来可以采用电子邮件形式”。部分原因是传统的 CAB 的责任负担过重。

我们用一个航空比喻来说明这个挑战。我们可以将 CAB 想象成机场的控制塔。那个控制塔有一项工作——告诉飞机什么时候可以降落。它永远不会负责评估飞机在结构上是否安全或飞行员是否有资质，因为这些因素已经得到美国联邦航空局和其他机构的确认。

同时，太多的 CAB 召集了各种利益相关者，他们的任务是就各种不同的变化做出广泛的安全决策。而且，这种情况通常发生在周末，因为疲惫的人们渴望在周末离开。CAB 根本不是为了成功而设置的。

此外，CAB 通常主要关心的是变更导致事件的风险。这当然很重要，但他们也必须权衡拖延有价值的变更的风险。行动太慢可能会伤害客户，而在竞争激烈的软件即服务世界中，组织就会陷入困境。

可以提升和关注 CAB 的角色。有了正确的做法，许多变更就可以实现自动化。这样，CAB 就可以成为重要的顾问，跟踪趋势，并与团队合作探讨如何实现更快的变革，从而使客户受益。

如何将您的 CAB 定位为战略顾问

重新定位 CAB 的第一步是消除重量级变更管理会产生积极成果的观念。《2019 年 DevOps 状况报告》的数据显示，需要 CAB 批准的流程会对软件交付性能产生负面影响，遵循这些流程的受访者表现不佳的可能性要高 2.6 倍。此外，没有证据支持正式的批准流程与较低的变更失败率有关！

出于这个原因，现代团队正在采取这些措施来改进他们的 CAB。

停止以“一刀切”的方式处理变更请求

每个变更请求都是跟踪和收集信息的机会。我们可以了解成功率、相关事件以及与之相关的因素。随着时间的推移，随着数据的应用，应该可以预先批准和自动执行越来越多的变更。只有影响最大、风险最大的变更才需要亲自批准。

使变更和版本管理更加紧密地联系在一起

传统的发布方法是将它们捆绑在一起，然后一次性全部发布。然后，CAB 需要痛苦地审查和批准大批量变更。这种方法可能导致重大事件，并且在出现问题时更难找到问题的根源。它还会降低团队为客户创造价值的速度。这也意味着变更和版本管理者可以为项目管理任务分配更少的时间。

使用渐进版本进行测试和迭代

为小部分用户累进部署金丝雀或功能标志，以便在全面部署之前测试和证明稳定性。这限制了潜在事件的范围，并在将部署推广到所有环境之前证明了部署的成功。

使用自动化和工具简化变更管理

高速团队开始重新思考以前的审批模式。与其在每周一次的面对面会议中处理冗长的变更请求待办事项列表，不如利用虚拟协作。这就像发送一封详细说明变更请求的电子邮件一样简单，这样便可在 CAB 会议之前对其进行审查。在其他情况下，Jira 工作单和 Confluence 页面等内容可以为变更审阅者提供异步协作和批准更改所需的上下文。通过使用 Jira Service Management，团队便能以这些方式进行协作，甚至还能参加视频会议或创建指定的 Slack 通道。根据团队偏爱的联系方式，它仍然位于同一个地方，所以每个人都能保持同步。

传统的 ITSM 工具使基础架构、运营和开发团队难以提出变更请求，因此希望借助自动化和现代软件来减轻手动输入变更信息的负担。如果可以自动跟踪工作，开发人员最不想做的就是在笨重的单个系统中填写工作单。而在 Jira Service Management 中，团队可以利用自动化来简化变更流程，同时最大限度降低风险并缩短停机时间。

左移并让变更管理更贴近从业人员

同行评审是经常取代或减少 CAB 批准的最常见策略之一，这种策略将识别代码中问题的责任交给了最了解守则的人员。ITIL 4 指出，“在高速组织中，分散变更批准是常见做法，这使同行评审成为高绩效的首要预测指标。”同样，《2019 年 DevOps 现状报告》建议“在开发过程中，组织应基于同行评审的批准‘左移’。”

为了遵守法规，需要仔细记录这种方法，这正是像 Bitbucket 这样的系统的用武之地，它可以自动跟踪作者和同行评审，并防止变更在没有必要流程的情况下上线。

在 Atlassian，同行评审是我们审批流程的核心部分。正如我们的 IT 风险与合规专家所说：“所有 Atlassian 代码都存储在 Bitbucket 中。当开发人员想要进行变更时，他们会将代码从 Bitbucket 签出到笔记本电脑上。当他们将其签回 Bitbucket 存储库时，系统设置为需要同行评审，而不是更新代码。只有在审核完成并获得批准后，代码才会被拉回存储库中。如果代码未获批准呢？它会与同行评审员的笔记一起发回给原始开发人员。他们修复了错误之处，并将其提交给其他同行评审。”

召集专家推动良好实践

随着组织变得越来越复杂，促进团队之间的信息流动和协调变得越来越重要。CAB 可以将注意力转移到实践改进上，而不是批准个人的变更请求。在这种范例中，他们可以寻求提供实践改进建议，实施更好的功能，并提供资源和工具以提高绩效。这扩大了 CAB 的职权范围，以应对向市场运送价值的速度太慢的风险。

即使在更传统的 IT 组织中，CAB 也可以成为提出创造性解决方案的地方。在一个案例中，一所遵守传统 ITSM 工具和实践的规避风险的大学需要弄清楚如何告知学生一项可能无法获得的重要服务。CAB 成为集思广益新沟通策略的论坛。他们决定分发糖果和海报，这场活动有效地转移了有关计划中的系统升级的请求。