点击上方“程序人生”，选择“置顶公众号”
第一时间关注程序猿（媛）身边的故事
节选自《IT 基础架构：系统运维实践》
作者：赵旻
如果要问运维团队里最重要的系统是什么，我想毫无疑问就是 CMDB 了。CMDB 一直被认为是 ITIL 服务管理的核心，位于最底层的支持系统位置上，由此可见其重要程度。
1. 用 CMDB 去衡量运维团队的能力
衡量一个运维团队的能力如何，我有一个非常简单粗暴、但又行之有效的判断依据，那就是去检阅他们的 CMDB 到底能做到什么程度。
运维团队有时会接待一些前来参观视察的领导团。通常都是在一番欢迎仪式之后，由负责人带领大家来到那些监控大屏下面，给众人展示那些交易量、成功率、运行状态等各种图表。曲线图平滑优雅，状态面板是一片绿色的海洋。总而言之，我们的交易量很高，系统运行很稳定。众位领导在绚烂的 UI 和美丽的交易数据面前频频点头，时不时还相互的耳语几句。随同而来的小秘书，一脸花痴状地望着英俊帅气的运维总监两眼出神。演讲完毕，众人纷纷都给出了满分。
然而，从技术角度上看，这些其实都是虚的。领导的视察时间都是提前选好的良辰吉日，参观的时段都是系统运行最正常的时刻。这种表演纯属面向业务，为了提升企业形象，增强投资者的信心而已。如果一个技术团队来造访，还采用这种展示方式，就显得太没有诚意了。
我以紧急故障处理为例。夜半时分，监控团队正在办公室值班。忽然间警铃大作，报告有一台 IP 地址为 192.168.0.250 的应用服务器的网络 down 掉了，其他情况暂时不明。监控同学见此情形，迅速拨打了 SE 的值班电话。
值班的 SE 接到电话后得知 192.168.0.250 远程无法登录，但监控没有提供带外管理地址。登录查询系统，输入用户名密码后，发现这个地址找不到。没办法，SE 又拿出自己做的 Excel 表格查询，终于找到了带外管理地址。登录后，经 SE 检查发现，是因为内核 crash 掉后导致的重启，重启后又由于硬件故障卡在了自检那里。于此同时，监控同学将故障也告知了负责应用运维的 PE 团队。不巧的是，当天 PE 团队的值班人员并不是负责这台服务器的 PE。他和 SE 一样，也是费了一番功夫才联系上了这台服务器的 Owner。仅仅是登录服务器和联系干系人，就花费了两个人十多分钟的时间。
监控平台的告警信息不完整。除了故障现象和业务地址以外，其他的什么都没有，还是要其他人来完成二次查询和确认的工作。那么这个责任在谁？是监控团队的问题么？我认为归根到底还是 CMDB 的问题。既然业务地址已经无法登录，为什么不提供带外管理地址呢？带外地址为什么在查询系统里面无法找到，还需要手动查询 Excel？既然知道故障主机属于某个业务，为什么没有提供业务的 Owner 呢？监控团队的工作是什么？在故障出现时，监控团队的首要任务是通知和组织干系人。这两项工作不应该再交给其他人去做了。由于监控提供的信息不完整，监控团队的作用根本就没有发挥出来，导致监控的工作是无效的。
这就是我为什么要说，评价一个运维团队的水平要看他们 CMDB 模型的能力成熟度。CMDB 是一切运维的基石。一个楼盖的好不好，首要是地基得牢靠。一辆汽车性能强不强，是由发动机、变速箱和底盘来决定的。光看表面文章没有用。根基差，上层做得再绚烂、再美丽，亦如同浮沙筑屋一般。
对于监控告警平台的要求，不是说故障出现时，能够及时发出警报这么简单，你要把所有相关的信息都发送出来才行。什么信息都没有，光喊狼来了，那是不行的。告警的意义是什么？警报发出来，不是让大家去避难的。运维团队是前线作战部队，警报发出来，就意味着战斗。既然是战斗，那就必须得弄清楚敌人的全部情况才行。
你说狼来了，让我们做好准备。可是我们都不知道狼从哪里来？有几只狼？离我们有多远？你要我如何准备？
2. CMDB 的多米诺效应
最糟糕的运维就是在没有打好基础的时候，反倒是先把上层建筑都统统搞起来了，唯独丢掉了最重要的 CMDB，用 Excel 表格来自欺欺人，后期信息缺失全靠人肉支撑。想一想，这是多么可怕的一件事！
CMDB 是运维组件多米诺骨牌当中的第一张骨牌。想想看，部署系统、配置管理、监控平台哪一个离得开 CMDB 的存在？如果 CMDB 倒下了，那么后面所有的内容都将不复存在。
然而，先盖楼、后打地基正是某些运维团队的现状。这样做的理由就是因为打地基的成本高，进度慢，所以就先拿一个东西来凑活，剩下的以后再说。反正，这种团队总是有一大堆理直气壮的理由去拒绝一个 CMDB 系统的建设。面对这样的运维态度，我们也只能呵呵了。然而，这口黑锅肯定是要有人来背的，欠下的帐迟早要还，只是可怜了那些无辜的背锅人罢了。
CMDB 是一切运维的基石
3. 是什么毁了 CMDB
大多数运维团队的问题在于根基没有打好，一系列错误的观念与行为导致有可能你使用了一个假的 CMDB 系统。
（1）偷换概念的迭代盾牌
一个项目的开始，往往就是这样类似的开场白。我们做这个项目是因为有一个某某问题的出现，为了解决这个问题，我们决定如何如何。一开始不用那么完美，先解决眼前的饥渴，剩下的东西我们可以迭代，有什么问题以后再慢慢调整优化。事实上，这种做法并不是真正的迭代，根本就是摸着石头过河。
（2）闭门造车
软件开发的过程中最忌讳的就是想当然。在构建 CMDB 的过程中，实际上是一个业务逻辑梳理的全过程。因此，CMDB 的整个架构设计应当由业务团队去构建，而不是甩给开发团队。不懂业务就没有发言权。缺少对业务的深度理解，就无法全面准确地定义配置项以及建立它们之间的关系模型。
当然，在定义配置项之前，也需要有切实可行的流程规范渗透在里面，不了解流程的前提下，去做配置项就是空谈。
（3）空口无凭
在软件项目的开发过程中，有一个非常大的问题，就是各个团队之间没有文档输出，完全靠 PM 的会议纪要去支撑。
这里面存在两种情况。
第一，缺乏需求文档。需求来源于使用方，然而使用方没有输出需求文档，变成了会议纪要和电子邮件，或者是开发自己在汇总。最后，整个系统设计完成后全部走形。
第二，开发文档不开放。开发团队对写代码这种事情很专业，但是他们对业务逻辑的理解并不那么到位。写程序的过程等同于工作交接，把人所做的工作方法「教授」给程序。程序逻辑必须和人的逻辑一致，所以很多逻辑实现是需要和业务需求方去核对的。比如提取一个信息，作为业务方会更清楚怎么做才是正确的姿势。所以，他有权力向开发了解这个功能是怎么实现的，他的意见也是最权威的。对此，开发团队却认为这样的做法「侵犯」了他们的「领空」。他们认为，我只要实现你的需求就好了，代码怎么操作是我的事情，你管不着。盲目自大导致了糟糕的错误逻辑，在产品上线后，闹出了很多笑话。业务方用着不爽，要么忍着，要么冷嘲热讽，就此还产生了一些团队之间的不愉快。
4. 如何定义你的需求
这是一个没有数据就寸步难行的信息时代。所谓无数据不服务，你很难想象一个没有数据的系统是怎么建立起来。但这又是一个信息爆炸的时代，我们一方面渴望拥有丰富的数据资源，而另一方面却又因为受到各种虚假、冗余的信息轰炸而感到身心俱疲。面对信息的获取，我们缺乏有效的筛选和控制。就像一个拾荒者，疯狂地汲取了大量的垃圾——虚假、冗余和无用的信息，反而加大了信息利用的困难程度。
我们构建一个 CMDB，需要它做什么？我们的目的是存储有价值的信息。关于价值如何去定义，我想可以根据如下这五点去衡量。
（1）关联性
提供的信息一定要和用户有关联，是用户真正希望看到的内容。
我举一个 CPU 硬件信息采集的例子。我们希望在带外管理中，能够看到 CPU 的厂商、主频、产品型号、核心数量等（例如 Intel E5 2650 v2 2.6GHz 8Core）。至于它的内部代号就属于无用信息，因为大多数用户对此并不感兴趣。
再比如说，当一台主机故障无法登录的时候，系统工程师希望看到的是带外管理地址，告警系统只给出一个业务地址是没有任何参考意义的。因为业务地址此时根本没法登录。
与自己切身利益无关的信息，就和电视广告一样的无聊。
（2）准确性
虚假数据比没有数据危害更大，它会导致决策者出现错误判断。虚假的信息往往来源于人工输入和逻辑错误。人难免犯错，如果信息源大量来自于人工输入，势必会生更多的错误内容。同样，程序在录入的时候也会出现错误，但这种情况多来自于程序设计之初的逻辑错误。具体原因有很多：不了解业务，做了错误的逻辑；考虑欠妥，没有规避特殊情况；技术水平有限，没有使用正确的方法等等。
（3）时效性
失效的数据就像一张已经过期的购物卡，即使它的面值是 100 万，也只能被丢进垃圾桶。
像开头所讲的故事一样，茜茜的数据在一开始是有效的。但由于后来部分信息没有更新，导致过期信息失去了存在的价值。我们在设计之初就应当约束所有的数据变更都要流经 CMDB，不能出现故事中所讲的那种情况。这就是时效性的要求。在某种程度上说，失效过期的数据也是一种虚假的信息。
（4）精炼性
一条信息如果不断地重复就变成了广告，所以去重也是很重要的。最典型的例子就是告警信息。没有告警信息显然是不行的，但是告警信息太多会让人失去耐心。正所谓「虱子多了不咬、债多了不愁」，过量的告警不会令人更加重视问题，反而倒逼别人想尽一切办法去屏蔽信息来源。
信息去重的方式有两种。第一是汇总。比方说，日志里有 100 次关于「too many attemps」的尝试性登录记录，正确的告警方式是发布一条关于「too many attemps」的通知，并汇总这个信息出现了 100 次。而不是连续发 100 条通知。第二是升华，进行分级处理。通告系统有恶意入侵的行为，具体的详细情形采用二级信息的方式展开：告知用户我们发现有 100 条尝试性的错误登录，有 1024 个端口扫描，有溢出攻击行为等等。
关于在 CMDB 上面去重的具体应用，我们以硬件信息为例。一般硬件信息清单的获取都是根据系统总线扫描得到的，像内存条通常会列举出每一条 DIMM 信息。在存入 CMDB 之前，可以精简为单根容量、数量和总计容量这三个内容，而不是傻傻的把底层信息原封不动地抄送进来。即便如此，在数据展示的时候也没有必要把信息全都平铺出来。人脑对信息数量的记忆是有限的。给的太多，反而让人挑花了眼，什么也记不住。
（5）独特性
信息提供切忌出现常识性内容——给的都是你不要的，说的都是你知道的。
相声泰斗马三立先生有一个著名的单口小段叫《祖传秘方》。讲的是一个人在大街上卖祖传的止痒秘方，而且是立即见效，不灵不要钱。有一个患者，花了五毛钱买了一份，回到家里打开一瞧，结果里面只有两个字——「挠挠」。身上痒了用手挠，这是人之天性，莫说是秘方，恐怕连常识性的知识都算不上。这个相声小段在抖开包袱之前做了很多的铺垫，最终这样一个结局令观众忍俊不禁。
艺术作品让人莞尔一笑，然而现实中这种结局多是令人气愤和失落的。比如，你在执行一个操作时出现了异常，想通过查询日志进行分析时，却只在日志中看到了这样一条——「操作出错，请你联系管理员」。想来这种日志不要也罢。我们在测试服务器硬件清单抓取的工作中发现，个别一些服务器产品提供的存储信息非常简陋，竟然只是告之哪些插槽上有硬盘，连容量和 SN 都看不到。这种就属于完全没有价值的信息。
赵旻《IT 基础架构：系统运维实践》作者，获得 RHCA/RHCSS/MCITP 认证，十年以上互联网金融、电信、政府等多领域背景的从业资历，曾参与中国国家电子政务多项重点工程的安全信任体系的建设工作，为中国移动、中国航空等大型企业提供技术支持。熟悉 x86 平台基础架构系统的建设、管理及运维工作，并醉心于运维产品的设计与体验。乐于在工作实践中分析问题、总结经验，具有持续优化的能力，属于主动管理型的工作者。
资深面试官，产品设计评论人，《运维前线》联合作者，现专注于管理学、产品设计、基础架构运维等领域。
推荐阅读：
本期评奖规则
在本文下方留言，用30+个字符，留言说说你想要这本书的理由是什么~
我们会从留言用户中，按照留言点赞数，抽取排名在第1、4、10、18、22名的5位幸运者，送出本书。
开奖时间：7月3日当天（以当天小编开奖时看到的名次顺序为准）