企业信息一把抓，配置管理数据库CMDB到底怎么用才不头疼

（引用来源：知乎专栏文章《CMDB：从入门到放弃的常见坑点》） 很多公司上CMDB，一开始都雄心勃勃，觉得这下终于能把家底摸清了，IT部门牵头，买软件或者自己开发，然后发个通知让各个业务部门来填信息，结果呢？大家要么随便填填应付了事，要么抱怨太麻烦根本不想动，最后数据库是建起来了，里面的数据却是一团乱麻，过不了几个月就没人维护了，彻底成了“僵尸系统”，用的时候发现数据不准，不敢用；不用的话，之前的投入又白费了,这才是最让人头疼的地方。

（引用来源：某IT管理社区资深顾问分享） 问题就出在用法上，CMDB不是一个简单的资产登记表，你不能把它当成一个“终点”，项目上线把信息录进去就完事了，它应该是一个“枢纽”，是公司IT运营动态流动的核心，想用得不头疼，关键就一句话：别让人去记着更新，要让工具自动更新，并且让数据能真正用起来。

具体怎么做呢？在刚开始建设的时候，千万别追求“大而全”。（引用来源：Gartner报告观点）别一上来就想把服务器有多少个CPU核心、某个软件许可证哪天到期这种细枝末节都塞进去，你先抓住最核心的、大家最关心的“活”的数据，什么是“活”的数据？就是那些经常变化、并且一旦变化会对其他系统产生影响的信息，一台服务器上跑了哪几个重要的业务应用？这个应用归哪个业务部门管？当前的负责人是谁？这些关系才是CMDB的价值所在，如果只记录服务器买了多少钱、放在哪个机柜，那它就是个死档案,价值不大。

（引用来源：实践案例，某互联网公司运维团队经验） 自动化是让CMDB“活”下去的生命线，最怕的就是靠人工手动录入和更新，今天某位程序员部署了一个新服务，他忙得要死，根本想不起来也不愿意去CMDB里点几下，久而久之，数据就不准了，必须打通CMDB和你公司现有的各种工具链，用自动化工具（如Ansible, Terraform）创建服务器时，就应该自动把新服务器的信息注册到CMDB里；用持续集成/持续部署（CI/CD）平台发布新版本应用时，应该自动更新CMDB里这个应用对应的版本号；甚至可以用自动发现工具，定期扫描网络，发现新设备或者配置变化，然后与CMDB中的数据做对比，发现差异并提示更新，能不动手就别动手,让流程驱动数据的变更。

（引用来源：《ITIL 4 Foundation》核心思想） 一定要让CMDB的数据产生价值，让大家“用”起来。（引用来源：内部推广心得）人们只会维护对自己有用的东西，如果CMDB只对IT部门的后台人员有用，那业务部门的同事当然没动力配合，你要把CMDB变成解决问题的“百宝箱”，举个例子，当监控系统报警说某个应用响应慢，工程师第一反应应该是去CMDB里查：这个应用依赖哪些服务器和数据库？这些资源的负责人是谁？能立刻找到联系人，快速拉群处理，再比如，公司要做安全漏洞扫描，可以从CMDB里一键导出所有运行着某个版本操作系统的服务器列表，精准打击，而不是全网扫描影响业务，财务部门想做成本分摊，也可以从CMDB里拉出各个业务部门所占用的IT资源清单，当各个团队发现，CMDB能实实在在地提高他们的工作效率、减少扯皮时，他们自然就会关心数据的准确性,甚至会主动要求维护。

（引用来源：多位企业CIO访谈总结） 文化和流程要跟上，要明确每个数据字段的“主人”，业务应用的负责人应该是业务部门指定的，IP地址分配的责任人可能是网络工程师，光有工具不行，还得有制度，规定数据变更的流程，确保任何变化都能反馈到CMDB中，要定期做“数据健康度”检查，表扬维护得好的团队,对数据质量差的领域进行整改。

想让CMDB不头疼，就得转变思维：别把它当静态仓库，而是动态枢纽；起步要小，聚焦核心关系和动态数据；全力推进自动化采集，减少人工干预；最重要的是，创造各种使用场景，让数据流动起来，让每个相关的人都能从准确的CMDB中受益，当CMDB从一项额外的“任务”变成了工作中离不开的“帮手”时,头疼的问题自然就解决了。