璐姐捞干货：聊聊配置管理和资产管理

今儿来一篇干货，聊聊配置管理和资产管理的区别和联系。

既然是干货，闲言碎语不要讲，直奔主题，咱们先来看看IEEE是怎么定义配置管理-Configuration Management的：

A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.

没有找到权威的翻译，而且就算翻译了还是挺抽象的，所以还是发挥一下璐姐的爱好吧，不严谨地归纳总结一下，大概意思就是，有一些东西特别重要，它要是变了，你最后交付的产品或者服务也会变，要是没把这些变更管好很可能就会出问题，要管好这些特别重要的东西的变更的手段，就是配置管理。这些“特别重要的东西”就是配置项。

我知道，其实还是不太具体，咱们举两个栗子：

☑ 比如你们是一个研发团队，正在开发一个系统，现在产品经理提出一个新需求，要增加一个功能，会有什么影响？简单说就是代码要跟着变。那么，承载“需求”的需求文档，以及随着它改变的它下游的源代码就都是我们说的“特别重要的东西”——配置项。

☑ 比如你们是一个运维团队，如果现在需要对操作系统升级，你是不是会考虑运行在它之上的数据库、中间件、业务系统可能受到什么影响？也就是说，操作系统、数据库、中间件、业务系统对运维服务而言，全都是配置项。无论使用技术手段还是行政手段，一定要把它们的变更管理好。

当然，配置项不仅仅上面提到的这些。研发管理中的配置项通常是串成串儿的，需求文档、原型、设计文档、源代码、测试用例，甚至编译器都可能是配置项，上游变，下游跟着变；运维管理中的配置项就更复杂了，基础设施、虚拟资源、应用都可能是配置项，而它们之间不是简单的上下游关系了，而是网状的，可以说是牵一发动全身，所以一个好的CMDB(Configuration Management Database)在运维管理中的重要性是不言而喻的。

在过往的咨询经历中，在客户公司看到过一种很奇怪的现象。拿研发项目为例，很多组织所谓的配置库实际上是个归档的概念，在项目完成以后，或者最多是在各个阶段结束之后，把文档和代码做个备份。更有甚者还为此建立了一套特别“缜密”的逻辑：组织级备份各个阶段完成以后的文档和代码，叫“基线库”；项目有个SVN存放文档和代码，叫“受控库”，注意我用的词是“存放”，不是“管理”，因为主要就是存，并没有什么真正的管理手段；然后说开发人员自己电脑上的就是“开发库”。于是，这就成了所谓的配置管理“三库”。我跟你港，这么干的还真不是一家两家，尤其是特别早就开始做CMMI的、做项目而不是做产品的公司。

刚才说了，配置管理到底是要管什么？管的是让变更别出错儿，也就是说，管的就是过程！只备份结果或者阶段性成果的做法最多只能算是资产管理，还有个前提是你真的把这些文档和代码当成资产。很多时候，这个资产管理管的只是一个从来没人光顾的“旧货仓库”。

这种问题在运维管理里体现得更明显。我看到过很多组织的CMDB只是一堆Excel表，里面记录着各种服务器、交换机、路由器、磁盘阵列的配置、厂商、保修期。设备越来越多，管理维护越来越困难，就开始寻求各种CMDB工具。然鹅，如果还是继续关心设备、资源、应用的基本属性，而不是它们之间的联系以及变更的影响，用了再好的CMDB工具最终也还是管理这些资产而已。

说到这儿大概能总结一小下儿了，虽然配置管理和资产管理的管理对象类似，但是它们的目的和方法是完全不一样的。通过上面说的这些，配置管理的目的应该已经明确了，为了避免变更可能带来的问题。那么该怎么做呢？跟把大象关冰箱一样，拢共分三步：

☑ 第一步，找到哪些东西变了是会对最终的交付有影响的，专业的话叫“识别配置项”。

☑第二步，在没有变更的时候，先把这些配置项管起来，该存的存好，该记的记好，该理清楚相互之间关系的理清楚，专业的话叫“建立基线”。

☑第三步，一旦有变更，根据配置项和配置项之间的关系，找到谁会受影响，然后好好儿地跟踪变更，尽量让它别出错儿，专业的话叫“管理变更”。

说起来挺简单，做起来，非一日之功。把大象关冰箱不也只是说起来简单吗，你关一个我看看！

顺便吐个槽，说说研发配置管理的“三库”！通常说的“三库”指的是开发库、受控库、产品库，早年间很流行这种说法。也有人说“三库”是开发库、受控库、基线库，我没看过特别正统的配置管理的书，不敢说绝对错，但是起码从逻辑上看这个说法就不太make sense，基线也是受控的，怎么能并列一个受控库一个基线库呢，大约是讹传。还有人说“四库”，也就是开发库、受控库、基线库、产品库，不知道是不是讹传以后的演绎。听说有的CMMI和GJB5000A的主任评估师/主任评价员至今仍然坚持物理“三库”，也是挺心疼这些老师评估的企业的。其实在我们日常的开发中，根本不用管开发库、受控库这些名字，基于自己的开发模式、发布特点、使用的配置管理工具，建立一个适合自己的分支策略，你是在主干上开发然后分支发布，还是在分支上开发合主干再发布，拉分支怎么个规矩，合主干怎么个要求，这些东西其实就是配置管理。那些配置项、基线、配置管理系统、变更管理系统、配置审计、配置状态报告神马的术语太玄幻，不用理会。

稍微扯几句跟IT行业没什么关系的配置管理，可能对你更好地理解配置管理有帮助。16年我给一家企业做过CMMI-SVC(CMMI服务模型)的咨询，这家企业是给银行做外包的，但是不是做银行的IT系统的外包，而是一些人力服务，比如咱们在银行网点常见的大堂经理。CMMI服务模型里同样有配置管理这个过程域，同样需要识别配置项。对于外包大堂经理这样一个服务产品，有哪些配置项？想象一个场景：外派给银行网点的大堂经理要穿统一制服，如果需要临时换人，男女高矮胖瘦不一样，没有合适的制服，会不会影响为客户提供的服务？所以，制服就是一个配置项，它依赖于外派人员的性别、身高、体重这些属性。有点儿意思吗？希望这个例子能对你体会怎么识别配置项有启发。

好了，叨叨了不少了，今天就先聊到这儿。希望下一篇不太远。

璐姐鸡汤：产品要为用户痛点服务