1 开诚公布
CMDB作为配置管理数据库，有太多的事例证明其最终被沦为鸡肋，部分小伙伴对其也不置可否:
- 开源CMDB，大概率很难推广，其真正意义上的应用场景很难发挥出来；
- 一个单纯的CMDB，主要面向的是运维；
- CMDB折腾了三年，啥问题都没解决；
- 计划做CMDB 快三年了，一直不知道该怎么下手；
- CMDB给运维更大的负担就是天天对数据，因为数据不准；
- CMDB是运维基础，自动化必须依赖起来，打好基础，上层才能便捷，高效，稳定；
- 想法很美好，现实很残酷，老板投入了好多钱，发现并没有解决问题，还带来新的问题；
- CMDB需要规范、流程将其规范化管理起来，总得允许一些小瑕疵；
从以上可以看出大家对CMDB建设有疑惑、质疑、反思、认可，这些声音总是不绝于耳。
2 CMDB的几点看法
虽然大家都知道CMDB是干嘛的，但其实很多企业或个人在使用CMDB过程都经历过兴奋期、过渡期、瓶颈期，CMDB最终是否变为花瓶，我们不得而知。但是从我们对CMDB的实践应用并推广的过程体会来看，可适当总结为以下几点:
- 引导：非常重要的一点，CMDB发起人能够宣贯CMDB的价值理念、引导团队；
- 规划：CMDB的管理能力能够覆盖到基础设施、操作系统、进程、业务关联分组等多个维度，但是过多的纳管势必会分散团队的注意力，从而带来负担。对于这点，使用人员还是要有所舍弃，”鱼和熊掌“不能兼得！
- 落地：管控范围一旦确定，我们就需要进行实际的落地，实现真正的纳管。如：网络设备、物理机、虚拟机等，当然这些还要依靠CMDB自身的自动收集能力。
- 流程：当基础设施纳管起来后，我们的重心就来到了持续更新上，例如：生命周期。生命周期包括设备、业务两个维度，这个需要不同团队的密切配合，才能保证最新的就是我们想要的，实现这点就需要团队的流程规范的支持。
再来思考下，做到以上几点后，CMDB就到终章了吗？虽然之前我也这样想过，将CMDB限制在运维内部使用即可，因为只有运维才会关注基础设施的生命周期管理。直到我们基础架构应用通过CMDB API将业务关联分组集成到各基础组件系统中，我才意识到CMDB真正发挥的作用是”资产流动“，即CMDB纳管的资源在各个业务支撑系统中流转，为其提供数据支撑。由于涉及为业务提供一定程度的数据支持，因此这将倒逼我们必须将CMDB管理好，最终形成一个闭环。
3 语重心长
为了帮助你在CMDB建设过程中更好的选型，我们也站在了巨人的肩膀下借鉴了一部分观点，现在来分享下！
3.1 传统CMDB建设失败教训
- 传统CMDB建设由数据中心发起，面向资产管理，面向运维，缺乏业务视角；
- 传统CMDB消费场景单薄，仅面向ITIL服务，数据/开放性接口不足；
- 过于关注CI广度和深度，模型不标准，模型拓展难；
- 技术架构落后，常使用关系型数据库带来能力限制；
3.2 新一代面向应用的CMDB
- 面向应用，按业务、集群、应用分层管理
- 可视化的业务拓扑
- 自定义配置模型（CI）管理
- 资源自动发现，保证数据一致性
- 全面的API服务
- 为自动化运维和DevOps提供数据支撑
因此当我们在讨论一款CMDB时，应该更多的关注它的功能是否符合当下的运维需求，注意是”运维需求“！
其实大家在冷静思考下，在接触过的含CMDB商业产品中，一般在云管、监控、运维等几个领域，如果让我选择的话，我肯定是选运维领域的产品，因为更了解运维的痛点。
4 CMDB支撑的部分场景参考
如果我们仅依赖CMDB做基础的管理，那肯定是不够的，我们应该更多的去关注CMDB的驱动能力，如以下运维场景:
- CMDB事件推送网关，测试、准生产、生产各环境与堡垒机、监控联动（运维支撑）
- 应用相关流水线，应用自动上线、应用发版、应用启停、屏蔽/恢复监控（运维支撑）
- 网关，接入新路由（架构支撑）
- 消息系统，接入新channel（架构支撑）
5 小结
其实本次想详细介绍下关于CMDB驱动资产自动化纳管的一个应用场景，但是结合小伙伴们的讨论及自己的一些实践体会就情不自禁的延深了下。总之，勇敢地去尝试，总比畏首畏尾要好得多！
来源于木讷大叔爱运维，作者三页
