变更管理技术应用解析

申请免费试用、咨询电话：400-8352-114

俗话说，“变化即是永恒”。希腊哲人赫拉克利特用著名的“人不能两次踏进同一条河流”的哲学命题表达了世上万物都处于永恒变化中的深刻道理。当这一放之四海皆准的法则被放置在IT应用的狭义范畴时，人类驾驭变化的本能让变更管理从此诞生。

变化: 永不退场

总有一些IT技术和产品最终走向没落，即便它们是曾经的王者。但IT的变化却像一位不知疲倦的舞者，永远不会退场。

相信每一位IT管理者都很清楚变化对高度复杂的IT意味着什么。当软硬件升级、新应用上线、服务版本更新时，企业往往无法马上看到立竿见影的成效，变化所导致的故障和问题却总会先期而至。据IDC和Gartner的报告显示，70％～80％的IT相关问题与环境的变更有着直接的关系。

面对主动管理和被动应对IT变化的选择，IT管理者迫切需要一种具有足够包容性、凌驾于变化之上的变更管理体系，但这一想法实现起来并不容易。很多时候，企业不得不采取机械的办法来保证IT系统的可用性。

某家国际知名的金融服务公司就面临着这样的问题。其拥有3万台服务器的IT环境每个月大约要进行数千次的改动。为此，他们不得不在月底或者季度末强行冻结变更，而这一做法在金融行业相当普遍。该公司的IT负责人说，“当我们冻结变更时，IT环境中出现的问题就大大减少了。但是我们不能总是用停止变更的办法来增加可用性。”

新技术的引入也会动摇相对稳定的IT管理架构，让变更管理遭遇挑战。以虚拟化为例，很多企业用自己的切身经历证实，随着虚拟化应用的深入，变更管理变得更加错综复杂。一家保险公司的IT经理表示，公司在实现了服务器的虚拟化之后，原本以为可以通过虚拟化保证可用性，变更管理的意识便有些松懈。但是后来发现虚拟化技术只能替代那些出现故障的服务器。在应用环境变得更“自由”的同时，系统的复杂性加大了，变更管理的难度也增加了。

其实，无论是IT建设的“叠加式”行为，还是引进新的产品、技术或服务，都需要通过一个严密而有效的变更管理体系来进行管理。正因如此，变更管理成为了IT服务管理框架中一个独立模块。

翰纬IT管理研究咨询中心 ITSM咨询顾问陈宏峰将变更管理形容为“大脑”，负责做出决策；而服务台相当于“嘴巴”，用来沟通、协调；发布管理就好比“双手”，用来执行变更管理发出的命令。

而站在IT支撑业务运营的高度，变更管理的价值链将超出IT运维的边界。中国工商银行信息科技部副总经理吕仲涛指出，变更应该被分为广义和狭义，广义的变更从需求变更开始，贯穿开发、测试、发布、支持、升级，直至终止的整个生命周期。而我们通常所说的变更管理指的是狭义的变更，即通过对硬件、软件、系统及应用组件变化的感知、追踪、配置、控制等具体操作来有计划地管理变更，从而带动IT服务水平的全面提升。

驾驭: 有物有则

在有序与无序交织的变化之间，我们总是能够找到游刃其间的办法。在变更管理的技术支撑体系之中，CMDB是核心中的核心。

CMDB让构想变现

“实施变更管理的难点和重点并不是工具，而是流程。”陈宏峰说，“市场上并不存在所谓典型的变更管理解决方案，我们可以找到成熟的ERP解决方案，却从没见过有BPR解决方案。”BPR是业务流程重组（Business Process Reengineering)的缩写，作为变更管理的一部分，BPR同样强调流程的重要作用，也将实现业务优化作为实施的最终目标。

专家指出，良好的变更管理取决于该系统的自动化水平，其中变更管理流程自动化的实现最为关键。而在流程自动化方面，ITIL读本已经做出了明确的规定。ITIL为6个主要IT业务流程（即配置、事件、问题、变更、服务/帮助台和版本管理）设计了旨在提升IT运维效率的最佳实践。而自动化的变更管理流程包含了全部6个主要流程元素。比方说，用户不能在没有预先了解变更将给环境造成什么影响的情况下进行变更，除非已经知道环境中有哪些元素以及它们之间的依存关系，否则就不能进行变更。这就是配置管理，ITIL为配置管理做出的规定是使用配置管理数据库（即CMDB）。

另外，很多变更是为了修补现实环境中存在的问题，因此与事件、问题管理或与帮助台系统连接的流程和工具尤为关键。一旦变更得到批准，就可以将其连接在一个自动的版本发布管理系统上，确保它的部署得到控制、测试和可审计。而在这一过程之中，CMDB就是汇集和支配变更与配置管理信息流转的基础部件。

对用户而言，要实现变更自动化没有CMDB是不行的，因为自动化管理需要一幅显示IT环境详细信息的地图。而CMDB就是一个记录环境中每个配置项的巨型数据库，小到路由器的端口信息，大到企业的生产型应用，它都会一一记录在案。

而CMDB中还记录着IT资产等其他方面的配置信息，它同时为IT服务管理的其他模块提供数据库支持。因此，将CMDB理解为自动化变更管理的技术实现基础是比较准确的。一旦CMDB部署到位，企业就可以着手进行变更管理流程其他部分的自动化。同时，每次变更都可以利用CMDB的应用映射特性进行分析，确保负责支持受变更影响的每个项目的管理人员了解情况，并参与变更批准的过程。

在实际操作的过程中，用户切记不要过于依赖CMDB，变更管理的实施应该是自上而下的，这与ERP十分相似，技术体系的建立只是管理量化的表象，在其背后是IT管理模式和风格的调整。

信息保鲜术

虽然很多专家和资深用户都表示变更管理的难点不在工具，但是要找到得心应手的工具并不容易。吕仲涛所在的中国工商银行是目前被业内认为比较符合ITIL中变更管理本意，且执行得比较到位的企业之一。在谈到变更管理时，吕仲涛认为，如何在统一视图中提取变更信息，并保证CMDB中信息的“新鲜”是项目实施的难点。

目前，市场上有一些能够提供自动发现配置项，并自动建立应用依存关系映射图的CMDB软件。这些软件出自BMC、CA、HP、IBM、美科利(Mercury)、Symantec等厂商。

不过，不同的工具管理的广度和方法是不同的。对于变更的感知，有基于代理或无代理两种发现方式。专家建议，基于代理的系统一般能够采集更为详细的诊断信息，是针对关键基础设施的不错选择。但是，在对于应用水平有限又计划添加设备的企业，代理方式就失去了优势。

还有一种说法是采用混合方式，即一些发现通过代理完成，其他的用无代理方式完成，这是相对折中的选择。混合法的典型代表是IBM的CCMDB（变更与配置管理数据库），它利用Collation的无代理发现，并将这类数据与从不同的企业监测系统（这些是基于代理的）采集到的信息组合在一起。这样一来，用户就可以在从基础设施关键组件中得到更详细信息的同时，确保所有组件都被发现。不过，无代理拥趸说，完全无代理的系统是最好的，因为它省去了在不同设备上安装代理的操作。

从CMDB及应用映射技术的发展走势上看，端到端的变更管理能力最终会来自大型软件厂商，比如BMC、CA、HP、IBM。现在，这些公司已经将相关技术（有些是通过收购获得的）集成到自己的产品线中。

BMC中国区技术服务部经理谢磊表示，BMC Remedy的变更与配置管理模块能够自动化大部分的变更管理流程，但通常企业仍需要用手工的方式来管理一些非标准的变更；在配置项的发现方面，即将于8月推出的Marimba产品将提供对桌面平台变更动作的侦测能力。

变更管理多元化的技术延展纵深也给了专业化软件厂商充分的施展空间。以应用映射技术为例，美科利的表现就非常活跃。据美科利高级技术顾问邓嘉伟介绍，美科利提供的变更管理解决方案不仅能够管理IT运维中的变更，同时还可以感知和控制IT运维之外的部件变化，并且能够与业务面进行呼应，是跨越全生命周期的变更管理。

其中，Mercury Application Mapping（简称MAM）是一款独特的产品。它能够将环境中持续的变更与相应的业务直接生成动态映射，对应用和基础架构的变更进行管理和分析，自动发现和映射配置项间的关联，并将信息植入CMDB。据称，这种新技术已经超越了手动的、反复执行映射或CMDB维护的第一代产品。

虽然软件厂商坚持的理念各有不同，但必须承认，最好的工具是可以实现变更管理全过程的自动化，从最初的请求直至最终的批准。它应该能够对变更的部署进行跟踪，并且提供对变更效果的审计机制。

存在技术盲点

至少在现阶段，变更管理的实现技术依然不是完美的。特别是对于信息化建设起步早、遗留系统多、IT架构复杂的用户来说，变更管理在一段时间内很可能无法覆盖整个IT环境。以CMDB为例，大多数CMDB可以发现大量基于服务器的软件，并建立它们的映射关系图。但也有一些应用程序是检测不到的，特别是那些遗留应用。比如，很多商业产品在设计时并没有考虑大型机或AS/400这样的设备。

针对“主机黑洞”，一些厂商已经开始着手解决这个问题。其中，BMC在近期推出了存储发现功能，并计划在年内实现对大型机的支持。美科利也表示其最新的映射分析技术能够用来侦测大型机等设备。

当这种暂时性的技术缺憾投射到用户心中，便会被放大许多倍。很多用户因此而放弃了购买商业产品的想法，做出了自力更生的选择。中国工商银行便是其中之一。吕仲涛便坦言市场上还没有真正成熟适用的CMDB。

据他介绍，目前中国工商银行总行自行开发的资源管理库已经运行多年，今年他们的任务是将原先面向的管理配置库转为面向操作的配置库。

而这种想法在用户群中很容易产生共鸣。天津移动的IT资源管理系统虽然还没有构建CMDB，但是其网络生产管理中心系统开发室经理李永春也表示，将于近期启动的配置库建设倾向于采用自建的方法。

这种对通用产品不够信任的情绪并非无来由。其中，用户需求与实际产品的落差是主因。吕仲涛指出，与选择何种产品相比，IT架构的设计更为关键。由于架构设计的不合理，导致有些变更无法在线变更，从而不得不延长计划停机时间；有些变更计划得不错，但是从业务角度却无法实现。

谢磊则强调，对通用产品的质疑很多情况下是由某些行业的特殊性造成的。以电信业为例，其IT系统除了面向IT运维外，还需要支撑电信运营网络，这种行业特征让他们很难直接去套用标准。构建CMDB的方式取决于用户，通用产品的缺点是不够个性化，企业需要一段时间的磨合，但好处是便于知识的分享，应用风险较小。自行开发则恰好反过来。在最终的选型时，用户需要用自身情况来平衡。

实践: 兵无常势

船是人类征服江河的武器。当企业面对像江河一样奔流不息的变化时，选择什么样的船？从哪里出发？并无一定之规。

多起点，无定式

通向变更管理的地图有很多入口和很多路径。很多人将原因归结为技术的不成熟，但事实上，管理对象的多元化，以及变更分布空间的广阔，也是造成这一局面的重要原因。目前让这幅路线图马上变得清晰还不现实，不过人们已经开始用IT管理方法论和实战经验对这个问题加以总结。

陈宏峰表示，翰纬咨询“高度认可”两种ITIL的变更管理实施思路。一是从服务台、事件管理入手；二是从变更管理流程发起实施。其中第二种做法是国外咨询公司比较推崇的。同时建议企业分两步走，第一步是自动化，即将现有变更流程做较小调整后自动化；第二步是优化和重组。

吕仲涛也赞同先建立帮助台，再由事件管理上升到问题管理，进而部署变更管理的思路。同时他表示，变更管理体系的建立是一个持续的过程，系统部署前后会伴随组织结构、管理文化、工作习惯的改变，因此企业需要从一开始（比如帮助台建设阶段）就努力对管理方式进行不断地调适。

“事件→变更→配置”是邓嘉伟给出的实施顺序，他同时指出，流程管理将贯穿在这一过程之中，且变更管理不是整个流程的第一步。

谢磊指出，在从事件管理起步时，变更管理需求并不一定立刻出现。当变更的涉及面比较小的时候，不必引入复杂的流程去控制它。建议企业在需求积累到一定程度、IT准备成熟后，再启动实施进程。

谈到多入口的变更管理最终走向何方，吕仲涛认为，无论是变更管理还是其他的管理模块，与IT架构的剥离都是大方向。特别是随着SOA这样灵活架构技术的普及，架构问题将不再会困扰变更管理。

掌握要领再出发

与其他ITSM项目一样，变更管理实施前企业需要预先进行架构设计和流程调整。吕仲涛认为，好的架构设计应该能够“消化”变更，将无序的需求变更有序化，把影响业务的变更变成不影响业务的常规变更，化解变更的风险。

在选择变更管理的具体产品前，企业应该对现有变更流程做完整地梳理，并进行合理调整。在实施之前，IT部门应确保流程的高效率、可管理与可审计，避免部署过程中和项目上线后的大规模流程改动。

变更管理系统建成之后，企业同样需要制定严谨的变更执行策略，而在此期间，管理理念的转变将更进一步。吕仲涛提示说，一定要保证CMDB中的变更信息是直接从生产环境中提取的，如果没有做到同步，就会造成下一轮的变更不准确，进而引发恶性循环。同时要做好需求管理，使其从无序变成可控; 版本发布要严格控制，避免频繁升级; 维护计划要留出应急预案，使紧急补丁能够及时部署到位。

他并不完全同意“变更管理是IT部门不断迎接业务需求挑战”的说法。“其实很多变更是IT部门自身造成的，在这一过程中，IT部门不是完全被动的，只要内部计划周详，很多无谓的变更可以避免，而来自IT外部的变更也不会对管理体系造成冲击。”吕仲涛说。

编看编想

学会吃粗粮

“观众很可爱，观众能吃粗粮。”出自王朔最新的一部剧本。仔细想来，这话套用在那些计划或正在实施变更管理的用户身上倒是挺合适的。当然，有大米白面谁还吃粗粮呀，更何况这可是咱自己花钱消费。但问题是，现在变更管理应用整体上依然处在物质相对匮乏的阶段，软件厂商仍在不断改进产品，典型的解决方案尚未形成，早期用户的经验又过于分散且通用性差。而IT环境中无处不在、永不停歇的变更又必须加以管束。在IT系统成长到一定阶段后，变更管理如不能及时跟上，不仅IT运维的效率大大降低，还会制约企业业务的发展。

所以，与其等待粗粮变精，倒不如学会吃粗粮。找不到匹配的软件，就试着用现有产品取长补短，或者像中国工商银行这样自己动手。事实上，粗粮的味道不一定不好。吕仲涛就表示，虽然自行开发的CMDB一开始信息管理的颗粒度比较大，但基本的配置管理功能都可以实现。随后他们做了很多细化的工作，现在的CMDB已经基本能够满足自身的业务需要了。

更妙的是，“吃粗粮”还是锻炼企业IT部门“消化”能力的好机会。一个基本的变更管理框架，IT部门怎样根据业务需求去充实它，让它运转起来？变更流程如何依据自身情况进行调适？这都是对IT执行力的考验。其过程可谓艰苦，但对企业而言，变更管理的部署肯定是宜早不宜迟的。只有粗粮并不可怕，关键是要学会粗中取精、粗粮细做，就能品出其中的味道。（cnw-ccw）