CMDB最后的吹牛

gzmt

高人高贴，拜读了！

eric-zheng

学习了呢..虽然有些东西还不是很明白.呵呵

神秘电波

楼主的思想还停留老CMDB的概念上，大有误导之嫌。现在谈的CMDB已经到了自动采集，颗粒度和维护成本已经不是主要问题了。

附上CMDB至关重要的五个功能点：

自动采集：
        发现收集分布在整个企业中的IT信息-其中包括关于服务器、存储设备、网络、中间件、应用和数据的详细信息，为初始化和维护配置管理数据库的提供数据来源。
联邦性：
        指能够充分利用来自其他数据源的信息，对CMDB中包含的记录源属性进行存取，将多个数据源合并至一个视图中，生成连同来自CMDB和其他数据源信息在内的报告；
调和性：
        指通过对来自每个数据源的匹配字段进行对比，保证CMDB中的记录在多个数据源中没有重复现象，维持CMDB中每个配置项目数据源的完整性；自动调整流程使得初始实施、数据库管理员的手动运作和现场维护支持工作降至最低；
同步性：
        指确保CMDB中的信息能够反映联合数据源的更新情况，在联合数据源更新频率的基础上确定CMDB更新日程，按照经过批准的变更来更新 CMDB，找出未被批准的变更。
映射和可视化：
        指说明配置项之间的对等和架构关系从逻辑和物理角度以直观的视图展示，使用户不仅能理解其整个IT基础架构，还能了解IT基础架构对服务影响的情况。

chenhp

汗

破子

如果我真的误导了大家，那倒有些罪过了。
我倒没有想过什么去介绍什么前沿的理念，只是谈谈自已真正做了的东西，至于是老CMDB与新CMDB，我就不知这个概念的划分原则了。
我觉得我们的眼光与眼界可以实际一些，谈什么自动采集、联邦调和与可视化，这在全世界有几家公司的产品是可以做到的？我们是着眼于自已构建，还是用人家的产品，有多少IT服务商可以承受那种价格呢？有多少IT服务商可以在技术层面实现自动采集？说什么颗粒度与维护成本不是问题，但奇怪的是这些在国内偏偏是问题，你说的概念除了MO、REMEDY、Opsware外，还有几家可以折腾得出来？这种概念也事实很多书上都有介绍，这是基本的概念了，我并不想写东西做知识的普及，这些要看的话，书上写得好得多的，从开始走到现在，我没有觉得这些概念对我在学习或项目过程中带来多少实质性的帮助，相反，我当时最需要的是我写的这些东西，它更有利于理解与操作，我也知道配置数据自动采集，请问我3000台桌面分布各个城市，全国每一个一二级城市分布着服务器，应用系统遍布终端，加上每一个会议室的设备（包括一个话筒麦克风），你如何“自动采集”呢？我们摸索这些，到底是着眼于自行开发一个CMDB还是仅仅是学习基本的“概念”呢？
    本质一些思考，有利我们的前行，盲目追随概念，并不可取。

[ 本帖最后由 破子 于 2008-3-18 08:41 编辑 ]

sdsdsd

原帖由 破子 于 2008-3-18 08:39 发表
如果我真的误导了大家，那倒有些罪过了。
我倒没有想过什么去介绍什么前沿的理念，只是谈谈自已真正做了的东西，至于是老CMDB与新CMDB，我就不知这个概念的划分原则了。
我觉得我们的眼光与眼界可以实际一些，谈什么自动采集、联邦调和与可视化，这在全世界有几家公司的产品是可以做到的？我们是着眼于自已构建，还是用人家的产品，有多少IT服务商可以承受那种价格呢？有多少IT服务商可以在技术层面实现自动采集？说什么颗粒度与维护成本不是问题，但奇怪的是这些在国内偏偏是问题，你说的概念除了MO、REMEDY、Opsware外，还有几家可以折腾得出来？这种概念也事实很多书上都有介绍，这是基本的概念了，我并不想写东西做知识的普及，这些要看的话，书上写得好得多的，从开始走到现在，我没有觉得这些概念对我在学习或项目过程中带来多少实质性的帮助，相反，我当时最需要的是我写的这些东西，它更有利于理解与操作，我也知道配置数据自动采集，请问我3000台桌面分布各个城市，全国每一个一二级城市分布着服务器，应用系统遍布终端，加上每一个会议室的设备（包括一个话筒麦克风），你如何“自动采集”呢？我们摸索这些，到底是着眼于自行开发一个CMDB还是仅仅是学习基本的“概念”呢？
    本质一些思考，有利我们的前行，盲目追随概念，并不可取。

终于露面了啊

sexyneco

很佩服楼主公司的魄力，能负担起那么多桌面机的维护量，如果没有自动化工具支持的情况下，很多时候是不会把桌面机作为CI的，楼主说得没错，看似桌面机的维护量平摊到每个工程师头上其实并不算什么，但首先现在的工程师并没有楼主那样的管理意识，他们认为维护CMDB的工作不是自己分内的事儿，还有，即使工程师有这样的意识去主动维护，工程师忙起来很有可能忘记更新某些CI，一个月，一个人忘记两三个不算什么，但所有人都忘记这么多，长此以往CMDB中桌面机的CI信息就是不完全真实的了。楼主在实施ITSM的时候有意识从工程师的角度看待问题是很值得称赞的，很多咨询顾问是不能做到这点的，但有时还是有些理想化，这也是现在国内没有特别成功的ITSM实施案例的原因之一。还是说桌面机，要想做到信息准确，一定要从流程和工具两方面加以限制。比如流程方面，把更新CI信息作为完成一份桌面机维护工单的必须步骤，如果不做这个步骤，就无法关闭这份工单，这样至少可以限制工程师一定要去做这一步操作，但更新的是否正确、规范，就是下一个要说的东西去审计，那就是工具，现在市场上有很多自动搜索客户端配置的工具，这些工具可以用来作为审计CMDB信息的参考。这样从流程和工具两方面去规范工程师的行为，会更加有说服力。

sdsdsd

原帖由 sexyneco 于 2008-3-18 15:48 发表
很佩服楼主公司的魄力，能负担起那么多桌面机的维护量，如果没有自动化工具支持的情况下，很多时候是不会把桌面机作为CI的，楼主说得没错，看似桌面机的维护量平摊到每个工程师头上其实并不算什么，但首先现在的工程师并没有楼主那样的管理意识，他们认为维护CMDB的工作不是自己分内的事儿，还有，即使工程师有这样的意识去主动维护，工程师忙起来很有可能忘记更新某些CI，一个月，一个人忘记两三个不算什么，但所有人都忘记这么多，长此以往CMDB中桌面机的CI信息就是不完全真实的了。楼主在实施ITSM的时候有意识从工程师的角度看待问题是很值得称赞的，很多咨询顾问是不能做到这点的，但有时还是有些理想化，这也是现在国内没有特别成功的ITSM实施案例的原因之一。还是说桌面机，要想做到信息准确，一定要从流程和工具两方面加以限制。比如流程方面，把更新CI信息作为完成一份桌面机维护工单的必须步骤，如果不做这个步骤，就无法关闭这份工单，这样至少可以限制工程师一定要去做这一步操作，但更新的是否正确、规范，就是下一个要说的东西去审计，那就是工具，现在市场上有很多自动搜索客户端配置的工具，这些工具可以用来作为审计CMDB信息的参考。这样从流程和工具两方面去规范工程师的行为，会更加有说服力。

潜水的高手还不少嘛

破子

近段时间忙着准备ISO20000的第二次外审，上来得少了些。
关于sexyneco说的这关于桌面运维这一点，观点我是认同的，目前我们也把数千台机器导入到CMDB当中了，也确实碰到一些困难，也就是你说的这种情况，精力所限，没有在这一块的实施投入特别多的时间，就我们公司的情况，如果下一些力气，是完全可以做得好的，因为每天我们在监控事件量，十几个桌面工程师，一般一天的单量在30-40左右，一般而言的事件处理，其实不会影响配置信息，因为我们的桌面标准，机器装什么软件是有规定的，出了故障重装或恢复，配置仍然没变，除非说更换操作系统就需要变化了，然后就是更换硬件，这就需要维护配置信息了，真正分析每一天的CMDB维护量是非常有限的，如果我腾出时间决心整理，做不定期的CMDB审计与处罚，加上硬件的更换必须根据CMDB的信息发放，这样是完全可以控制数据精度的，我们不光是把一台电脑建成一个CI，把这个电脑上的CPU也建成了一个CI（这当时更多是为了日后事件的定位与运维分析），现在回头想来，也可能是过了，也可能不是，主要是桌面的配置信息对我们整体的基础架构影响不大，所以一直没有太多的力气去做。我也一直在说，真正维护CMDB时，如果你真正分析实际的业务量与变更量，其实答案是显而易见的，当然这种情况可能不是放绪四海的。
     CMDB的建设过程，花去不少脑力，现在算是上了，但问题亦不少，跟我之前的预期有一些差距，这里面也有一些象sexyneco说的人员意识问题，也有其它的一些问题，我们的平台CMDB只是一个模块，还需要从全局去考虑，这后续的工作仍是不少的。
     谢谢各位的交流

vecentli

本帖有2点比较好：

1：流程和工具保证信息准确。
要想做到信息准确，一定要从流程和工具两方面加以限制。比如流程方面，把更新CI信息作为完成一份桌面机维护工单的必须步骤，如果不做这个步骤，就无法关闭这份工单，这样至少可以限制工程师一定要去做这一步操作，但更新的是否正确、规范，就是下一个要说的东西去审计，那就是工具，现在市场上有很多自动搜索客户端配置的工具，这些工具可以用来作为审计CMDB信息的参考。这样从流程和工具两方面去规范工程师的行为，会更加有说服力。

2：CI颗粒度和运维的能力相符合。
关于CI颗粒度的观点，就是运维的触角可以伸多远，你的CI颗粒度就要走多远，但我想更引伸一步，你的运维触角能伸多远，你的CI颗粒度最多也就走到那里，如果是刚开始做，不推荐走到那里，而是往回退一两个层级。

[ 本帖最后由 vecentli 于 2008-3-19 10:39 编辑 ]