码迷,mamicode.com
首页 > 数据库 > 详细

CMDB反思1

时间:2014-06-10 22:03:38      阅读:340      评论:0      收藏:0      [点我收藏+]

标签:style   blog   http   com   文件   数据   

由于,基本已经完成一期的功能开发,所以要继续CMDB的开发工作了。

最近看了不少CMDB相关的文章,也思考了不少,后面将所思所想(比较浅)记录一下。

发现很多内容都记录在Wiz上,抽空整理到博客中。

 

七问CMDB http://blog.vsharing.com/xqscool/A1267069.html

话说CMDB只是一个系统,而配置管理是一个流程,CMDB固然重要,但是维持它的流程更为重要。反观我司,只在CMDB建设初期的时候按照配置管理流程行事,建设快结束的时候就开始抽调配置管理流程的人力到别的流程上去,最后无论是配置管理还是别的流程都没有做好——配置管理流程几乎废掉,CMDB的数据也不再准确,到目前都还是这样
 
个人认为配置管理的实施必然包含着CMDB的实施,企业实施了其中之一,必将在规模扩大,用户更加精明的时候遇到一系列问题——比如客户要我们提供每日的PC数量以及分布区域,客户要我们提供维护的存储数量以及剩余存储空间、存储空间变化明细等等,缺少了配置管理上面的信息提供就成为了空谈。
 
以往,我们做配置管理的时候总是注重于表面信息,如服务器的型号、服务器的硬件配置等等,我们忽略了Tomcat发布的端口、配置文件的内容等这些内在的信息,导致我们只能在信息准确的前提下有限的挖掘CMDB中的信息价值。这些表面的信息虽然能够解决管理层对外提供信息的问题,但是实际上没有给运维工作带来任何价值,这是否是系统/网络管理员长期拒绝配置管理流程的原因呢?
 
云或许能够解决这些问题,因为云服务提供的及时性要求对整体的配置工作都提出了要求,这就是说一开始设计云服务的时候就需要将这些内容纳入配置管理(或许在云中不叫这个名字)。我司云服务底层是一个全新的系统,这也导致了现状,云自身运行的良好,但是不能给所谓的传统运维带来一丝影响——无法迁移的系统,无法复用的组件,云带给运维很多好处,很多梦想,但是有很多问题不能解决——这些传统运维、基础架构层面的问题才是运维工作变更的关键。
 
说到这里,我又想谈谈年龄的问题了——年龄其实不是问题,观念才是问题,但年龄会导致拒绝新事物,这就是观念问题了。

CMDB反思1,布布扣,bubuko.com

CMDB反思1

标签:style   blog   http   com   文件   数据   

原文地址:http://www.cnblogs.com/rexkang/p/thinking-about-cmdb-1.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!