关于 CMDB 如何保证数据一致性的讨论

[Tsunayoshi]

小弟刚开始接触和实施 cmdb ，有一些问题想和大佬们取取经。

cmdb 作为自动化运维的基石，它的很重要的一个价值就是“数据”，通过基本的数据支撑，为其他业务系统提供底层数据，比如监控，任务管理等等。

但是我觉得比较麻烦的一个点就是维护这个数据的准确性以及数据之间关系的准确性，目前我能想到的有几个约束点

1. 规范，约束人的，但是这个东西严格意义上来讲，还是可能会存在疏漏
2. 流程，把操作和各类流程挂钩，通过流程+自动化的一些手段最终更新 cmdb ，不让人去更新。
3. Agent 主动上报，在主机上安装 Agent ，动态的去实时更新资源的信息。
4. 自动发现，通过自动发现手段，不管是扫，探测还是其他等手段，发现未覆盖的设备。

除了这几种，各位大佬还有其他的好的手段可以保证数据更新的及时性和准确性么。因为 cmdb 不准，就意味着依赖它的很多系统数据可能都不是准确的。

[liprais]

你是领导么，你不是还是拉倒吧，尽人事听天命

[Tsunayoshi]

@liprais 您是想表达做这个事如果没有领导支持费力不讨好么。。

[37Y37]

这个我们有建设，实际落地了，上边说的几点都有用，根据经验来看，技术约束要优于规范流程，比较好的方式是：打通全流程，申请之后自动入库，之后所有全生命周期操作都关联上 cmdb ，其次自动发现配合规则自动同步，尽量少人为介入

除此之外个人觉得最为重要的是，cmdb 的数据一定要为上层业务提供服务，强耦合，例如监控系统基础数据取自 cmdb ，成本中心数据也取自 cmdb ，发布部署数据也都来自 cmdb ，这样确保数据只有一份，并且只有保证 cmdb 数据准确才能保证上层业务不出问题，以强依赖来倒逼数据准确

我写了好几篇相关的文章，可以参考看看： https://blog.ops-coffee.cn/cloud

[Tsunayoshi]

@37Y37 是的，我们目前是这么打算的，要把 cmdb 作为数据的中枢，然后为各类系统提供数据底座。我感觉 cmdb 只有消费才有价值，不然就是一个大的 Excel

[Hopetree]

cmdb 的数据分为几种类型：
管理类：人工维护，人工更新，比如负责人、资产编号等
采集类：自动采集或上报，自动更新、比如主机信息等
关系：自动创建或人工维护，比如负责人、硬件设备的连接关系（通过采集的数据自动关联）

可以在基础数据维护好的前提下，引入 ITSM 流程来维护 CMDB 的管理类数据，但是 ITSM 的流程设计和维护成本极高，应该是将一些有必要用流程来规范的数据使用流程维护，其他数据还是让数据的负责人自行维护

[Hopetree]

CMDB 是需要数据治理的，就是设置一些检查规则，把不规范的数据暴露出来，然后制定数据更新规范定期维护这种不规范的数据

[9136347]

问个问题，你有没有能力从技术上约束整个研发的流程，就是上面 @37Y37 兄弟说的逻辑。如果做不到，就开开心心的做个 excel 吧，等数据不对的时候，再同步一次 excel 。
我司也搞了 cmdb ，但是说了半天，都停留在概念中。因为最上层的领导理解不了做这么一个东西需要的改动量。
他们都是听着这个概念 cmdb 比较牛逼，但是对这里面的工作量，和对流程的改造，没概念的。在他们眼里就是出个公告，大家要维护好 cmdb 就行......

[Tsunayoshi]

@9136347 这块目前还是具备一定定制以及接入能力的，只不过目前刚上没多久，所以针对维护的一些方式还存疑，想和大家沟通沟通。

[Tsunayoshi]

@Hopetree 受教了，这块的确是，需要一些分析手段定期去排除不符合期望的一些资源。或者说通知出来，及时进行调整

[sampeng]

没有领导的领导支持，这事就是自嗨

[forvvvv123]

@Tsunayoshi #2 如果你不是领导或者领导指定要你干这个活，你就应该现状跟着 xjb 搞，完全没必要想这些

[Tsunayoshi]

@sampeng 这块的确是，更重要的是，这玩意需要持续运营。如果说领导不理解或者不支持的话，很多时候，收益都不好说，更别提 ROI 了。本身就是一个长期的事情，好在我们的领导还是比较支持的。作为重点项目之一去做的。