容器云下的CMDB,在http://www.talkwithtrend.com/Question/426651 有相关的讨论。个人感觉devops、微服务确实对传统CMDB带来冲击。但另一方面,CMDB本身在运维环境中主数据的价值不变,抓住这个主要矛盾就可以在新场景中
容器云的CMDB管理我们也在摸索中,欢迎大家一起交流探讨。前面有个讨论贴讲到CMDB定位和价值跟传统虚拟机时代有所变化。容器环境中,docker实例是短生命周期的,封装的也较好,一致性强。仅从登记角度,个人觉得不必追求细节或
这个话题很大,其实前面很多讨论已经分析了细节。CMDB数据准确性要通过数据治理,所谓治理是一个系统性综合工作,总体可以概括以下几点:首先要提升CMDB数据战略地位,明确数据价值,凝聚共识,利用组织的力量来推动工作。二是明确
这个话题值得探讨。容器的出现,交付部署发生巨大改变,而且容器平台本身集成或标配了配置中心、监控等许多组件。容器平台本身提供了”一条龙服务“,取代了原本各种复杂林立的运维工具平台,一统江湖。从这个意义上,原来CMDB
行业里有厂商已经在实践了。可参见 http://www.talkwithtrend.com/Question/426377。另外有篇文章可参考:https://blog.csdn.net/kwame211/article/details/78410512
CMDB的管理要求当然可以纳入IT标准和制度里。比如CMDB和其他运维平台的集成关系,那些公共配置信息必须以CMDB为主配置库,中心化管理。但IT标准化不是神丹妙药,标准不是几个专家拍个脑袋就能搞定的。标准是一种共识,而且这
您指的是CMDB建模设计表结构吧。个人经验是:业务建模,看远做近,概括以下几点:1.CMDB建模同样遵循传统数据库设计原则,从业务来设计。典型模型网上其实有不少参考的,拿来剪裁即可。2.属性不是重点,反正今后可以添加,主要是把握
“如何把CMDB用起来?”个人的一点体会是:假如CMDB孤零零的立在那儿,技术再牛,数据再准也没用。CMDB的价值是依附在具体运维环境土壤中的,价值有两条腿:一是主数据库,二是工具和流程的场景。从这个意义上说,CMDB技术上可以标准
个人理解,数据表字段和表关联越来越多是正常的。CMDB是真实运维世界的虚拟映射,真实世界是复杂的,这个虚拟模型也一样,CMDB模型和需求一定是随着运维发展而演变的。为了避免技术上的变更太被动,大神们发明了面向对象、面向
无agent优点无需多说,无入侵,部署成本低,等等。但如果non-agent能搞定数据采集,这个世界早就天下大同,不需要agent了。正是因为实际现状决定了,要抓取到丰富的信息,目前只有agent方式,以高权限执行。目前了解到商业CMDB也都是
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30