十年过去了，但不变的不仅仅是情怀还有管理思想，ITIL在当今流行的DevOps中还在发挥着效果，那么看下，什么是变更？在ITIL原文中变更是指一切对服务以及CI配置项的改变，包括增加、删除、修改。那么在DevOps下是否适用呢？

正确的理解是适用！因为DevOps中的变更虽然进行了自动化，但也需要引入ITIL中的变更，因为DevOps没有必要自己再造一个已经有国际标准ISO/IEC20000，已经有最佳实践ITIL成熟多年的体系，那么就是引用。

在ITIL中变更管理将变更分为三大类，分别是标准变更（Standard change）、紧急变更（Emergency change）、正常变更（Normal change）

标准变更（Standard change）：是指那些经过预授权的变更，主要针对那些低风险、经常发生，并且是有预先定义好的处理步骤的的变更。一般情况下包括每月固定更新的税表或网站样式变更等内容。

其特点在于不需要再次经过领导审计，因为在变更部署前已经提前完成了审批。并且变更部署活动可以完全是自动进行的，但需要注意的是需要留下审计及跟踪的记录。在DevOps中也一样遵从ISO20000及ITIL的标准，只不就是进行了自动，智能化目前看标准变更也在逐步实现。

紧急变更（Emergency change）：是指那些要尽可能快地去实施的变更，比如解决一个重大故障，或打一个紧急的安全补丁。在紧急情况下，变更必须立即投入生产环境。一般情况下安全紧急安全补丁或紧急恢复服务。其特点是必须尽快解决的潜在高风险变更。这些变更通常需要尽快得到高级管理层的批准，在执行完成技术活动后，应立即进行记录归档工作。DevOps的践的关键目标是简化常规变更流程，使其也能适用于紧急变更。

所以在DevOps中紧急变更想要应对紧急，并不是大家认为的只是紧急的变更来了就可以应对，这就需要提前进行紧急变更的预防管理。

这里需要应急管理、连续性管理（BCM）、IT灾备管理（ITSCM）、安全事件响应（ISMS）等多个流程的提前定义才能做好紧急变更的处理工作，这个工作在ITIL高级课程 RCV中进行了很好的说明与描述。有空来听北京老李讲ITIL高级课成为ITIL专家：）

北京老李：首批ITIL Expert讲师

正常变更（Normal change）：是指那些除了标准变更和紧急变更之外的所有其它服务变更。其特点是需要更高的领导进行评审或者在既定的审批组织CAB和ECAB进行批准。其中CAB是指变更顾问委员会，ECAB是指紧急变更顾问委员会。

在最新的敏捷的道路上，很多组织的变更都是由于领导出差、评估不能及时完成，所以造成了评估的时间上的延误。

我们在2012年在IT管理项目中就注意到了这一点，我们是通过移动办公平台，IOS、安卓等新应用的开发解决这一问题。能够实现立即审批，随手审批、一键审批，并且随着应用了BMC  BladeLogic等自动化的产品，加快IT的交付频率。

那么对于变更我们是如何解决专业化的快速评估的呢？我们在银行率先实现了变更的标准化评审工作，随着自动化产品BMC  BladeLogic的应用，一起同步推进管理与技术的问题。

在新的DevOps体系下，需要从管理与技术层面解决变更的效率，这个问题在大规模代码部署的情况下尤其突出。

一般情况下我们都认为只有技术加快才能解决软件交付的问题，其实这是一个伪命题，因为技术动作的不标准化，还来的快速交付的后果就是上线死的快，上线BUG多。

今天很多单位都已经进行了云了，传统企业也从竖井式管理上升到云管理，这种情况下更是需要管理的标准化与技术的标准化。

曾经有人说过没有写过代码的工程师就不是好司机，在此老李想说，没有管理支撑的技术实现就不是好DevOps。

在越大的组织下，需是需要IT管理，IT管理成为他们的管理抓手，你可以想像一下，大规模部署可能包含成百上千（甚至数百万）行代码，由数百个开发人员在几个月内需要快速地进行交付，那么这更需要各技术专业的协合配合。

变更管理在DevOps下仍然发挥着他在云下管理的控制权及组织权，只要CABle建设得当，这依然是一个建设高效组织的必经之路。因为无论是在云下，还是传统IT管理，都不能离开组织的“闸门”。

在云下，现在更多的强调的是自动化，智能化。但随着AIOps的流行，你会发现，前提依然是需要一个标准化的规则与策略。

每个组织都希望“一口吃个胖子”。但管理的成熟度告诉我们这根本就是不可能的。

企业管理的AI成功之路，就是标准化=》模板化=》自动化=》策略化=》智能化，但在此的前提是服务化。

所以变更管理在新的DevOps需要有一个更加清晰的变更请求单（RFC）的定义，因为它里面定义了执行RFC的决策所需要信息，它是智能化的基础。