作者介绍曲鹏达现任职Linkedsee，从业IT十余年。 导语本文的原题目为，运维狗的2016高考作文：《论配置管理的成效控制和成本控制》。
作为一名运维从业狗，看到这个命题心中此起彼伏。总有一种介于在吐槽和赞叹之间的情愫滋生，当这种感觉达到阈值，便触发了如下的自动化处理动作：不吐不快。 当接手运维管理的第一天起，就被ITIL教育，然后走上了配置管理的不归路，也就开始面对命题中的漫画场景。 所谓心中有佛，所见皆佛。本着爱岗敬业的精神，不自觉的要从运维管理的角度去尝试理解这幅漫画。 当然现实中成效和成本永远是联系在一起的，并不能完全割裂看待。在成效和成本之间寻求平衡，成为了运维管理者永恒的命题。在配置管理这个管理范畴中，这个命题尤其凸显。 配置管理的误区毋庸置疑，配置管理（即CMDB）是提高运维管理系统有序性的核心组件，运维的诸多元素的全生命周期跟踪和控制都和CMDB息息相关。 然而，放眼望去，CMDB建设失败的案例比比皆是，请允许我讲述一二。 误区之一：盲目追求大而全很多最初接触 CMDB 建设的运维者往往对 CMDB 的建设范围头大，其中还有一部分管理者在国内早期兴起的某些以纯忽悠为主从不管落地的咨询师的布道下，代入了贪大求洋的观念，啥都想往 CMDB 里面塞。 大到项目管理，小到耗材采购，都想让 CMDB 来支撑，这样的 CMDB 建设往往步履蹒跚，最后或无疾而终，或被最终使用者打入冷宫无人问津。 想让 CMDB 来代替全部的信息管理系统，可以套用时下流行的一句话来评价：大鹏一日同风起，扶摇直上九万里。（你咋不上天呢？） 误区之二：CMDB必须全自动化在前赴后继的激进过后，曾有这样的声音出现，CMDB 要全自动化，CMDB 的信息可以被全自动化的管理，从生产、调和、加工、消费再到报废，所有的过程全部自动化调用，完美支撑企业业务。 诚然，这样的 CMDB 太美，但在全自动化的大旗下，采购预算、开发成本节节攀升，即使是在 Devops 做的很好的企业 IT 部门，也是投入 100，产出 60。 如果在当今有人来说他提供的 CMDB 可以全自动化，那一定是其系统对 CI 信息进入做了相当严格的控制。 写到这里笔者暗暗担心，读者一定会想，这家伙就是个大喷子啊，口无遮拦乱放地图炮，而且还只放炮。 为了不做放完炮就跑的自行火炮，同时作为踩过深坑浅壑的运维狗，还是要谈谈自己的看法，且做抛砖，望能引玉。 配置管理的目标用最简短的描述来说就是，信息可控。其信息管理方法的发展历史过程笔者理解可以分为原始阶段、纸质阶段、excel阶段和软件阶段。其具体内容如下图所示： 当然，以上很多都是废话，同业者都非常清楚软件化是CMDB建设走向未来的必经之路，而且也已经在这条路上了。 下面是笔者真正想聊聊的，也就是本次高考的作文题目，到底该如何在成效和成本之间找到那刚刚好的美丽。 配置管理的成功要素笔者认为，其成功要素，不外乎以下四点：确定建设范围、明确发展路径、适当模型设计、持续优化机制。
让我们来逐个看看。 第一、确定建设范围了解现状是指导建设范围的最重要标准，步子小了没意思，步子大了容易扯到蛋。 在综合考量和横向观摩各行业的需求下，资产管理是最稳健的一种起步方式，大部分信息已经具备，可以使用经济档位。 同时在较短的时间内，可以交付一个短期成果，对上对下都有所交待。 第二、明确发展路径不谋全局者，不足谋一域；不谋万世者，不足谋一时。 IT部门的使命是更好的支撑业务，因此在做顶层设计时务必考虑从长期来看对业务的支撑程度，同时做好阶段设计。 在这个互联网+大行其道，各色企业野蛮生长的年代，定义CMDB的发展路径这一难题，给运维管理者提出了很高的要求。 第三、适当模型设计有了顶层设计和发展路径就有了方法论，下一步要做的就是用合适的粒度来设计CMDB，其主要指导思想有二: 这里要多说一点，没有自动化的CMDB没有使用价值。自动化在CMDB的运营和消费中要起到这样几个作用： 然而总有一部分信息是非常难以通过自动化完全满足的，大可不必担心这部分工作，只要这部分工作量是可以被容忍的，即在总工作量在20%以下（在信息点超大规模的情况下20%也不够理想，应该在10%以下甚至更少），CMDB的质量就是说得过去的。 第四、持续优化机制罗马和CMDB都不是一天建成的，按照明确的发展路径，使用PDCA作为其指导思想进行分阶段的优化，就可以走向美化的明天。 在持续优化的过程中，风险管理是非常重要的。 在云计算爆发的今天，容器到处跑了，网络overlay了，架构微服务了，应用架构分布式了；运维管理者可能被企业业务的变化倒逼着修改CMDB的发展路标甚至是调整其模型。 但是，只要顶层设计做好，底层有足够可信的数据源，那CMDB就依然上可倚天，下可接地，矗立在运维江湖的核心。 下面以两个比较实际的落地案例来详细说CMDB的交付实践。
案例1：某银行IT系统建设项目该项目是整体管理平台的建设项目，从监控到开发到运维都有所涉及。同时该项目是为长期统一管理平台的基础。CMDB在这样的背景下就做出了定性。 由于预见到在传统行业的多部门系统协同工作下，可能出现的对于CMDB的预期不一致。我们在该项目中做的第一件事情就是识别干系人，这一块的定义是符合PMP中所定义的干系人管理的，即资源赞助人、管理人、监督人、告知人。 我们首先组建了一个以甲方高层领导和建设方高层领导为联合赞助人的虚拟Team，并开始了第一项工作： ITIL知识传递和调研访谈。 这里需要注意的是，只需对关键人员进行访谈即可，无需细化到具体基层人员，否则可能会导致项目的刚开始就进入没必要的细枝末节。（这里项目经理的作用非常明显，良好的项目经理可以很好的控制技术框架和边际成本）。 从调研阶段，我们获取了甲方的运维现状评估结果。了解到其部门的分工情况和工作流的协同方式以及对未来业务的预期。（这里为保护甲方的隐私，恕笔者不便透露详细情况）至此，我们已经正式明确了发展路径。 第二项工作，就是正式敲定建设范围了。 有人要问，怎么和在成功因素里所描述的第一和第二倒过来了？ 实际上在项目初期是有初步的建设范围和发展路径的概念设定的，但是在一个真实的项目交付中，在商业项目开始之前不可能有详细的调研，往往是项目管理的甲乙双方的技术高层碰撞出来初步结果，在调研完成后才能说真正的敲定。 在具体的项目中，我们确定的第一阶段的建设范围为基础设施监管控平台、云平台。可以说这是一个偏保守的范围设定，但是在传统行业中CMDB从无到有的建设中，这可能是一个最稳妥的选择。 下一步是模型设计，是吗？是的，不过同时我们做了另一件事，教育用户，这里的用户指的是具体要使用这个CMDB的基层工作人员。 可能还有人会问：你东西还没出来就开始教育，不早吗？其实不早，而且刚好，我们教育基层工作人员的目的一方面是要输出ITIL理念和CMDB的使用思想；更关键的另一方面，是让尽可能多的让他们参与到模型设计中来。 要知道，他们才是真正CMDB最终的消费群体。现在，是听听他们简单粗暴的需求的时候了。然而并非全盘接纳，这里需要ITIL交付的专家出马了，过滤出符合建设范围的需求。 我们这样做的效果是：大多数的最终用户对这个CMDB的粒度都感觉很舒服。 PS：别忘了做可视化部分模型的设计，这也是商业CMDB项目中非常重要的一环，这一部分的目标是一眼就看穿全局，作用我想大家都清楚，我就不多说了。
这个项目的实际乙方工时消耗在4个人力3个月左右，从甲方的成本和收益上来看都完全超越了预期，应该说是一个比较好的传统企业CMDB初建的案例，为诗和远方开了一个好头。 案例2：某互联网公司CMDB项目互联网是一个特殊群体，尤其是近年新生代的互联网公司，野蛮生长的经营模式也蔓延到了运维部门。在这个项目中，我们做了相关咨询工作，具体的落地由甲方自有团队承担。 其实互联网公司的技术环境虽然复杂，但从管理逻辑上来看比传统行业简单的多：简单、高效、多办事。 而且在该公司的IT部门，相对层级扁平，批量的90后小鲜肉儿，协同工作的方式更倾向于使用IM工具，得到IM上的授权就撸胳膊挽袖子干活了。 在这样背景下，该公司希望新建CMDB，但作为技术核心的公司，不愿意采购CMDB这种没啥技术含量的软件。（不用质疑，CMDB软件在技术难度排行榜上只是个战斗力只有5的渣渣）这也是为啥这是个咨询项目的原因。 考虑到该公司的灵活性和高效性，我们把CMDB的首期建设的范围定义“支撑自动化”。即本阶段主要考虑的是以CMDB为核心完成多系统的自动协同管理、调度、回溯等信息消费动作。 该项目的其他部分大同小异，在模型设计上还是有一个亮点的：资源性能归一化的粒度设计，将底层资源的性能根据其品牌、配置等属性的不同，进行公式化的设计，使其形成归一化的属性值，在CMDB中管理和修改，并通过API提供给上层调度系统，另外这部分信息将被集成作为设备选型指导中的重要指标。 可以看到，互联网企业和传统企业使用CMDB的方式不尽相同，但方向一致。都是以CMDB为运维管理的核心去指导其建设的。 总结作为一篇高考命题作文（运维狗的2016高考作文：《论配置管理的成效控制和成本控制》），到这里该是点题和主题升华了。笔者想用这样两句话来作为点题： 短期成效展现能让配置管理活到青春期之后，长期成本控制能让配置管理长命百岁。
致谢本文由灵犀（一站式混合IT运营专家）供稿。 本文转自微信linkedsee。
| 
转播
分享
淘帖
()