标签: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