ITIL也玩“太极拳”

近期看到一篇老外写的发布管理的培训材料，其中把发布管理比喻成中国太极图中的“阴”，把变 更管理比喻成“阳”，觉得还挺有意思。之所以这么比喻是因为，他认为“发布”是被动的，接受的，有女性阴柔的一面；而“变更”是主动的，强势的，有阳刚的 一面。它们组合在一起形成了两个理想的平衡作用力，来控制IT服务管理中的风险。坦白说，我并不完全认同这种比喻的观点，可能老外并不完全理解中国文化中 “阴”“阳”的寓意，但这个老外无疑是ITIL领域的专家，因为他深刻了解到“变更”和“发布”之间的互相作用力，如何通过两个流程的配合和互相牵制来控 制企业信息系统的运营风险。

在和很多同行交流的过程中，大家似乎对于“发布管理”和“变更管理”在IT服务管理领域的作用和意义有些疑惑。“既然有了变更管理，已经可以控制风险了，
为什么还要需要发布管理？”“发布管理的定位和意义与变更管理有什么不同？”，“版本要发布之前需要考虑哪些因素？”，“发布管理的策略应该怎么来定？”
“发布管理应该研发队伍负责，还是运维管理团队负责？”等。

这些都是非常好的问题，也是IT运维管理（E8.ITSM）到达了一定的成熟度的团队，才会开始思考这些问题。下面我来和大家分享一下我对这两个流程的理解，供大家参考。

变更管理是
一个总体的管控流程，它控制和管理所有硬件，软件，环境，人员，流程，配置，文档的风险管控流程。只要是投入生产的系统发生任何变化都需要这个流程中的核
心审核小组CAB（Change Approval
Board）批复才能进行实施。CAB主要审核的焦点就是这个变更可能对我生产系统带来的风险和为此变更所付出的成本（国内很多企业的变更管理不太审核成
本）。变更管理对于变更可以根据其对生产系统的影响分成若干级别：包括重大变更，较大变更，一般变更，日常变更，紧急变更。每一类变更参与审核的人员，也
就是CAB的人员是不同的。重大变更需要CIO甚至CEO来决定，日常变更可以不通过CAB审核，直接做好变更记录即可。
   
发布管理是对软件，硬件上线相关的一系列活动进行组织和管理，包括发布策略的制定，发布计划的制定，发布内容的测试方案设计，通过测试的标准，发布失败的
应急方案，产品发布说明书，发布前用户的培训等等。也就是一个产品从研发完计划上生产前这个阶段的管理都属于发布管理的范畴。
一个发布可能是一个变更，也有可能是一组变更构成。例如：一个企业的ERP系统，其发布频率为1年4次，每次的发布可能会包括100多个维护类的变更。这
种发布的管控通过变更流程是无法管理的。

发布管理和变更管理的组织架构可能在企业里都是虚拟的，发布管理和变更管理的经理通常是固定的，其成员组成有可能是根据项目的不同灵活组建的。发布管理小
组成员通常是所发布项目的核心成员，第三方测试团队组成，运维管理人员组成。变更小组的成员，通常由变更相关的技术经理，业务经理组成，还包括可用性管
理，容量管理，服务级别管理，事件管理的经理等等，用来审核这个变更可能带来的影响或者说是风险。

所以，大家可以发现变更和发布是紧密相关的两个流程，都是控制系统上线风险的核心管理流程，缺一不可，互相补充。所以从这个意义上来说“阴”“阳”之说，也可以用来形容吧！！（转帖）