






















这是一个创建于 542 天前的主题,其中的信息可能已经有所发展或是发生改变。
小弟刚开始接触和实施 cmdb ,有一些问题想和大佬们取取经。
cmdb 作为自动化运维的基石,它的很重要的一个价值就是“数据”,通过基本的数据支撑,为其他业务系统提供底层数据,比如监控,任务管理等等。
但是我觉得比较麻烦的一个点就是维护这个数据的准确性以及数据之间关系的准确性,目前我能想到的有几个约束点
除了这几种,各位大佬还有其他的好的手段可以保证数据更新的及时性和准确性么。因为 cmdb 不准,就意味着依赖它的很多系统数据可能都不是准确的。
3 37Y37 2024 年 12 月 18 日这个我们有建设,实际落地了,上边说的几点都有用,根据经验来看,技术约束要优于规范流程,比较好的方式是:打通全流程,申请之后自动入库,之后所有全生命周期操作都关联上 cmdb ,其次自动发现配合规则自动同步,尽量少人为介入 除此之外个人觉得最为重要的是,cmdb 的数据一定要为上层业务提供服务,强耦合,例如监控系统基础数据取自 cmdb ,成本中心数据也取自 cmdb ,发布部署数据也都来自 cmdb ,这样确保数据只有一份,并且只有保证 cmdb 数据准确才能保证上层业务不出问题,以强依赖来倒逼数据准确 我写了好几篇相关的文章,可以参考看看: https://blog.ops-coffee.cn/cloud |
4 Tsunayoshi 2024 年 12 月 18 日@37Y37 是的,我们目前是这么打算的,要把 cmdb 作为数据的中枢,然后为各类系统提供数据底座。我感觉 cmdb 只有消费才有价值,不然就是一个大的 Excel |
5 Hopetree 2024 年 12 月 18 日cmdb 的数据分为几种类型: 可以在基础数据维护好的前提下,引入 ITSM 流程来维护 CMDB 的管理类数据,但是 ITSM 的流程设计和维护成本极高,应该是将一些有必要用流程来规范的数据使用流程维护,其他数据还是让数据的负责人自行维护 |
6 Hopetree 2024 年 12 月 18 日CMDB 是需要数据治理的,就是设置一些检查规则,把不规范的数据暴露出来,然后制定数据更新规范定期维护这种不规范的数据 |
7 9136347 2024 年 12 月 18 日问个问题,你有没有能力从技术上约束整个研发的流程,就是上面 @37Y37 兄弟说的逻辑。如果做不到,就开开心心的做个 excel 吧,等数据不对的时候,再同步一次 excel 。 |
8 Tsunayoshi 2024 年 12 月 18 日@9136347 这块目前还是具备一定定制以及接入能力的,只不过目前刚上没多久,所以针对维护的一些方式还存疑,想和大家沟通沟通。 |
9 Tsunayoshi 2024 年 12 月 18 日@Hopetree 受教了,这块的确是,需要一些分析手段定期去排除不符合期望的一些资源。或者说通知出来,及时进行调整 |
10 sampeng 2024 年 12 月 18 日 via iPhone没有领导的领导支持,这事就是自嗨 |
12 Tsunayoshi 2024 年 12 月 18 日@sampeng 这块的确是,更重要的是,这玩意需要持续运营。如果说领导不理解或者不支持的话,很多时候,收益都不好说,更别提 ROI 了。本身就是一个长期的事情,好在我们的领导还是比较支持的。作为重点项目之一去做的。 |
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。