|
昨天天朝终于放开二胎政策了，男同胞们昨晚可能都很辛苦。贾斯特君最近也很憔悴：自己管的设备越来越多，有些都快叫不出名字了，设备们情绪也很大。所以贾斯特整了一套CMDB来解决这个问题。 CMDB，它全名叫配置管理数据库。通俗来说，IT系统的CMDB就是要把设备的配置，比如型号、CPU颗数、IP地址等信息都存到一个数据库里面去，要用的时候再到数据库里面查。建设CMDB第一步就是要设计其框架。贾斯特花了不少心思设计了一套从主机到存储到数据库到数通设备全链路覆盖，从物理硬件到逻辑组件全配置管理的CMDB框架系统。 在实际的建设之路上，贾斯特君披星戴月，披荆斩棘，花了一年半的时间，建起了自认为“东半球最好”的一套CMDB系统。作为温拿，贾斯特总结了几条要做好CMDB的道道，供各位看官参考。
CMDB是配置管理数据库，最关键的当然是数据。贾斯特要建设的CMDB，有上万台物理管理对象，涉及几十种CI，百万级的关系数据，这必须使用自动化采集平台。通过多种形式的接口，将从服务器、存储、数通设备同步过来的数据采集、解析、入库。任何不以自动化采集为手段的CMDB建设都是耍流氓！另一方面，自动化采集倒也没必要频繁实施，可以定期与不定期相结合，一些难以采集的非热点数据完全可以自动化和人工录入相结合。
如果不解决数据调和与展示的问题，就好比西施带着面纱，杨玉环抱着琵琶，谁看得到他们的美呢？举个简单的例子，一台服务器的型号在有些系统中可能采集到A，有些则可能是B。这种情况下，如果直接展示结果将是灾难性的。因此我们需要数据字典来进行调和。数据资产治理务求早规划、早建设。此外，前台展示界面可读性，可用性，灵活性，都是CMDB系统能否被“消费者”青睐的重要因素。
如果想把CMDB做的十全十美，从而导致需求不断蔓延，导致项目迟迟无法上线，那将是灾难性的。在CMDB的建设之路上，有时需要暴力一些！贾斯特认为当CMDB配置项覆盖采集率超过90%，属性覆盖采集率超过80%，就是时候可以让CMDB上线投产了。有时，投产过程需要行暴力施工，需要强制切断各专业自用资产及配置模型，并用CMDB基线系统替换已有应用系统的数据调用接口。
随着云计算和大数据技术的发展，CMDB将迎来更加广阔的应用场景。从告警关联到性能分析，从变更风险评估到故障影响分析，以及当下很火的大数据分析辅助运维，都有CMDB的用武之地。随着CMDB数据完整性的提高，各种应用会自己找上门来。初级的CMDB是政策驱动型，没几个领导推动是搞不起来的；但随着建设的推进，CMDB慢慢会变成价值驱动型，此时才是发挥它最大优势的时候。
CMDB不是万能的。未来，CMDB一定要处理好数据生产与消费之间的平衡，否则会不堪重负。CMDB中CI的颗粒度与当前的运维管理需求颗粒度保持一致，在实际应用中促进CMDB数据的准确性。普遍的情况是，运维管理成本在短期内会提升，但长期会下降。随着CMDB的完整性提升，成本会下降得越快。 好了，今天就先聊到这里。下次，贾斯特君有时间再来详细介绍这“惊天地泣鬼神”的CMDB建设之路，敬请期待~ |
|
|
