由于，基本已经完成一期的功能开发，所以要继续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
原文：http://www.cnblogs.com/rexkang/p/thinking-about-cmdb-1.html
