高人高贴，拜读了！

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

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

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

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

汗

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

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

QUOTE:

---

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

---

终于露面了啊

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

QUOTE:

---

原帖由 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只是一个模块，还需要从全局去考虑，这后续的工作仍是不少的。
     谢谢各位的交流

我很同意楼主关于CI颗粒度的观点，就是运维的触角可以伸多远，你的CI颗粒度就要走多远，但我想更引伸一步，你的运维触角能伸多远，你的CI颗粒度最多也就走到那里，如果是刚开始做，不推荐走到那里，而是往回退一两个层级。比如你可以管到交换机的模块，那么你可以只收集交换机以及上面端口的信息，至于端口是在哪个模块上的，可以作为下一步的考虑，但这时有个关键的问题出现，就是你一定要留有一定的关系空间，以备今后使用，这里说的关系空间不一定是要在数据库中留出数据表或字段，而是要考虑如果在已有的两个CI关系中间插入第三个CI，那么系统如何能在影响最小的情况下实现，这个是相当关键的，事先考虑好维护量，或者开发出CI关系维护工具，批量的将CI关系打散并加以重组。
昨天只看了楼主的主帖，今天看了“ 神秘电波”的回复，觉得他太过理想化了，严重怀疑是某些曲高和寡的咨询或者看了国外的一些资料就往这里一粘，显示多么的先进。至少我没有看到国内现在有完全自动化或者自动化程度很高的CMDB，并且和变更等其他流程能够自动化的关联，确实，HP，MO等几个厂商有类似的自动发现的工具，但这种工具还只是停留在抓取标准的商业软件以及硬件配置上，对于企业自行研发的系统还是无能为力的，上面说的是服务器，对于网络设备就更是如此，是的，这些软件可以把物理的拓扑图抓取出来，但网络的连接不是光有物理拓扑图就足够的了，网络的连接和交换机、路由器上的配置是很有关系的，路由器和三层交换机如何路由数据，交换机上的Vlan是如何配置的，这些东西据我所知还是不能自动发现的，为什么CMDB如此复杂，为什么说从业务的视角整理IT架构如此复杂，都是因为前期需要大量的人力物力去收集，后期需要大量的日常工作量去维护。当然如果真正的重视起来，建立一个相对完整并且可以为业务提供依据的CMDB是完全可以做到的。不能否认，工具的自动发现以及自动维护是大势所趋，但现在的技术还不能够达到理想的程度，所以，要想干好，只能死磕！