Some useful tools

I am just cleaning up my bookmarks. Some of them could not be deleted. I'd like to list here.

This is a netflow monitor tool, you can capture, graph and store data.




Founded in 1992, the Distributed Management Task Force, Inc. (DMTF) is the industry organization leading the development of management standards and integration technology for enterprise and Internet environments.

Social Networking Meets Business, Concursive have CRM, online communitie, collaboration tools.

CMDB实施的几种误区

上面是ITIL v3的定义，CMDB的定义和v2没有变化。可以看出CMDB是一个存储配置记录的数据库，非常多的用户一拍脑门“不就是一个数据库么！我们也可以自己开发一个的。”。这样的情况下，IT组织的不同部门都可能会各自立门户，开发自己的配置管理信息库；例如：资产管理、终端分发和管理、机房管理等等。数据重复、数据不一致、配置信息不对称；无法得到跨部门和系统的报告。所以V3提出了CMS系统，它是CMDB系统的下一代管理系统。CMS系统需要 具有对现有信息资料的兼容性，CMS的建立不能忘记过去；一定要集成已有配置信息。
错误一：配置信息是一个独立的配置管理系统，由专人负责数据的更新和维护，手工的管理和维护所有数据。

错误二：最配置管理就是要做的细，我要管理到机房中的每一根网线，CI的属性需要设计的非常多，越细致越好。

错误三：我们自己有开发人员，我们有CMDB的需求，那就开始做吧，先看法着看看，不就是一个数据的增删改查么！！

配置管理或者说CMDB的建设可以说是目前，国内ITIL用户共同的瓶颈。ITIL项目中实施最多的三个流程是：Incident Management、Problem Management 和 Change Management。已经实施完毕以上三个流程的用户问的最多的一个问题是：一个故障单、问题单或者变更单一定要和CI想关联么？在解决处理的时候寻找目标CI或者根源CI是必须的么？

如果ITIL是一种公共语言的话，那么Incident Management、Problem Management 和 Change Management等所有流程都是句式或者时态。而CI则是主语或者宾语，您觉得没有主语或者缺少宾语的句子，会传递怎么的信息呢？

Stop to build CMDB for your IT - CMS是怎样炼成的？

ITIL在国内的实施也有8年之久，就我看过和做过的项目中：service desk是最多实施的工具，它包括IM/PM；还有Change Management；用户们还可能会常常认为，Release Management可以和变更流程可以混在一起搞。服务台一般先上，有的变更流程先上，服务台的共同特点还有PM一般形同虚设。就我所见所闻的项目和用 户来说，CMDB没有那家能建的好用的好；CMDB的建设的缺失似乎成了所有ITIL用户的通病，应该也是想重点突破的瓶颈。

ITIL v3发布后，CMDB成了CMS中的一个数据库；而且，CMS中包括不止像CMDB这样的配置信息数据库，其实任何保存配置信息的数据库都算在CMS系统 内。既然是一个系统，所以它就不光包含数据还包含一套配套工具集合，通过这套工具，维护和使用配置信息。CMS为其他所有ITIL流程提供基础的配置信 息。它的结构如下图所示：

配置管理系统

如果说上面这幅图比较还是比较抽象的话，那么请见下图：

CMS is a set of tools based on all configuration data

从上图中我们看到，CMS系统一共可以分为四层。上三层是核心CMDB数据库和相关配套工具，最低层Data层则是是所有配置信息的基础来源。从 ITIL v3的角度来说，只建设一个集中的CMDB数据库来存储所有的CI信息是不够的，CMS系统中必须能够包含和处理所有企业已有的各个系统中的配置数据。换 言之，CMDB建设的局限性在于，它只是配置信息数据化，或者说电子化的第一步。

当前依然有很多企业雄心勃勃的上马CMDB项目，不过切记在规划时，一定先好好阅读一下ITIL v3中和CMS相关的内容，适当调整项目的目标和预期总是好的，也可以规避一些项目风险。

CMDB不只是一个数据库那么简单，更不可能在服务台的数据库中建立几张表就可以搞定。从企业IT管理的全局出发，按照 ITIL v3的规范，建设CMS应该是所有ITIL项目的当务之急。CMS系统决不能遗忘过去，必须有效整个现有的各个配置信息数据源，无论其以何种形式存在。它 必须是一个开放的平台，能过最大限度的和其他任何配置信息的消费者（ITIL流程，以及任何需要获取配置信息的任何应用）整合，

以上的一些是我对CMS建设的一些认识。如果要落地到项目上还不许经过一个痛苦的过程，那就是产品选型。选项的过程中可以注重一下几点：

• 可视化：配置项和之间的关系按拓扑形式展现
• 标准化：软件、硬件配置项都有完整标准的CTI信息
• 归一化：与现有各种配置管理系统核心共存同时CMS保持一份完整的户口记录，任何CI都有ID
• 集成化：CMS中的数据以图形或者裸数据等形式供其他相关消费者流程或者人员使用
• 联邦化：CMS核心数据库中不保存动态变化的配置信息（DB的最大连接数，网络设备所使用的syslog服务器地址），这些信息通过联邦管理让用户从其他相关的工具系统中查看到最新的数据。

最近可能还会接触一下CMDB的项目，其他经验总结待续。

配置管理中几个的误区(1)

配置管理的项目可以从CMDB的建设开始，也可以从配置管理的流程建设开始。我在一些配置管理的项目中发现了一些用户容易犯的错误有很多。先说说配置管理，做ITSM的项目，往往CMDB的建设，或者配置管理流程大多不会非常重视，往往作为一种辅助性的环节在项目中得到实施。例如ITSM项目一上来就做服务台，然后是变更管理流程和其他流程；在一些后续的资产管理的项目中CMDB的到重视并建设。其实配置管理流程和CMDB是ITSM项目中非常重要的一环，它建设的效果对整体效果有乘法放大的效果。CMDB的主要功能我认为有两点：

1. 提供唯一、精确的配置信息库，让所有IT团队的人都明确IT管理配置项范围，有了它所有人都起码能清楚“我管理的东西是什么有哪些？”。都说ITIL的语言是IT管理的共同语言，那么配置信息就是这个语言的主语和宾语；从这里可以看到，如果我们没有这样一个准确的配置信息库，我们彼此之间的沟通会出现多大的误解和迷惑。我在用户现场做项目的时间比较多，耳闻目睹很多沟通障碍；这些障碍不是沟通方式和技术造成的，而是大家没有能从一开始就说清楚“谈论的CI对象到底是什么”


2. 实现一定程度上的业务影响分析。往往都是有IT部门牵头做CMDB，后期也主要是IT部门用。有效的业务影响分析能力，可以彻底提高事件管理的有效性。一般用户可能会有一个集中Event Console，从这个console中事件一般是以生成的时间先后顺序查看和处理的。最差的事件管理方式就是这种“先进先出”的处理应对方式。如果你能说清楚，发生事件的对象（配置项）对业务系统的影响程度，那么你就能够做到按照这些事件的优先级别来处理；事件的优先级就是该事件对业务系统所造成的影响的严重程度。需要做到业务影响分析，就必须做业务模型梳理。每一个业务服务和业务流程也是配置项，IT的人也需要能理解业务。

下面列出一些常见错误，这些错误发生在企业做ITSM项目的前后都有可能，不过多是在实施ITSM项目之前，或者上CMDB工具之前，或者过程中。

1）目标不明确，实施结果无法衡量 Goal


所谓目标不明确，并不是说没有目标，而是说：目标定的不太合理。不合理的原因有一下几种：目标过大、目标过于模糊、过于教条、拘泥于ITIL的书本、和实际的工作联系不紧密、没有衡量和控制的方式。在一定的项目时间周期内，总结之前配置管理的问题，作出一个切实可行的配置管理数据库建立目标应该不难，主要以使用为主，不要拘泥于细节。

2）配置项信息混乱，信息结构无序 Scope


这里的“信息结构”是说CMDB的CI配置项信息查看应该是立体的有结构的很直观的数据信息。在访谈的过程中，有些用户在讨论过程中认为配置项组成的信息结构应该是网状的。其实现实中的IT基础架构组件的确是以网状的形式相关联的，这种想法非常实际。不过人们都太偏重IT了，遗忘了IT部门的最终使命“为企业交付各种业务服务”。业务服务就是CMDB数据金字塔的顶端部分。从IT部门提供的业务服务开始来梳理和建立CMDB配置库是一种“自顶向下”有效方式，是IT部门做CMDB配置管理过程中，与业务部门沟通的“翻译机”。自顶向下的方式需要业务部门的配合，或者IT部门内有精通业务的强人。通过这种方式做出了的CMDB，CI之间的构成方式，从宏观上看：屏幕的投影是树根型的，立体的看是金字塔形的，业务系统模型是树根的根部，是金字塔的顶端部分。微观上看，局部可能是网状的，或者是星型的。没有业务服务作为头部，很难说出CMDB的scope究竟是多大，很难说清楚哪些CI可能会在CMDB中出现。

3）配置信息随意堆积，纠缠于过多的CI属性 Level

每一个CI都可能具有非常多的属性，成功选择的标准是：够用就好，精简是王。很多用户都存在的误区就是“复杂比简单好，越复杂越放心”；大多数用户在项目初期的需求整理的时候都觉得，需求提的越全面，越好，越保险。这种心情是可以理解的，毕竟ITSM项目的周期和投入通常都是非常多的。不过对于配置管理来说却，万万不能有这种想法；否则，CMDB的维护和审计的工作量将非常巨大。一个信息量过载的CMDB，就是一个不可用的配置库。一个只有10个属性的CI和有50个属性的CI展现在你面前的时候；你找到你所关心的信息花的时间上看，前者是后者的1/5时间。属性一定要精简，特别是CMDB从零开始的用户。在设计的初期一定预留属性扩展的可能性。

4）疏于配置信息的准确性和实时性 update

CMDB一旦建立了之后，所有用户一定要对CMDB使用起来，要为CMDB提供反馈。最终使用配置信息的人，如果发现信息不准确，需要及时报告配置经理。配置经理需要及时维护。配置经理最重要的职责是，确保每一个大小变更实施完毕之后对要对相关CI做更新。你可以没有正规的变更流程系统去跑变更单，不过我所看到的是很多企业即使没有实施ITSM项目，其实他们手工变更单的流程跑的有板有眼，一点都不差。美中不足的是，变更后的结果没有地方更新和反馈。而CMDB就是这样一个变更结果反馈和汇集的目的地。在大家都频繁使用CMDB，并且每一个大小变更都更新CMDB的完美情况下，CMDB中的信息会随之时间的流逝，愈来愈精确，愈来愈完善。

5）拘泥于工具的功能，忽略了最终目标 Tool

我看到的最多的工具是MS Excel，也有使用自开发系统的，可有自开发系统最终丁不住在转向商业工具的 :( 无论何种工具，假如在一个正确的事实和使用的策略下，我觉得都是可以获得CMDB建设的成功的。一个好的工具还是有必要的。在选择一个成品工具或者开发一个CMDB工具时，需要考虑工具的几个方面。工具应该参考或者借鉴某种国际标准，这里的标准是指某种通用模型标准 Common Data Model (CDM)，例如DTMF的 Common Information Model (CIM),或者WMI等。好的工具需要能和其他ITSM流程紧密结合，特别是事件管理、问题管理和配置管理者三个流程。如果这三个流程是建立在某种工具平台之上的，那么CMDB的信息最好能无缝的整合的流程的处理过程中。

GLPI --IT资源生命周期管理

GLPI是一个法国的开源项目，之所会了解到这个项目，是由于OCSNG的原因。当我安装并使用了一下它之后立刻产生了以下问题：1）它仅仅是一个对现有设备Inventory的工具，对新设备的采购和计划无法实现。2）它仅仅是一个技术工具，能提供CMDB相关的配置信息数据，相关的流程如何实现：计划，采购，使用，变更和报废。

没想到在安装试用了GLPI之后着一切都疑问都散去了。那就先讲讲安装过程。环境准备，我的测是环境如下：Dell Inspiron 600M笔记本（70GB HD, 1GB RAM），由于硬件资源实在有限，所以我喜欢使用VMWare作为测试环境。在VMWere中安装SuSE 10.1，最小安装；安装apache,perl,php,mysql和其它相关的包，由于Yast的包管理实在好用，所以为整个安装过程带来了很多方便。如果您也想测试的这个软件系统的话，最简单的方式则是：找一个物理的机器做SuSE 10.1的全安装，这样的安装过程绝对不会有找不到那些依赖组建的问题。软件安装：OCSNG / GLPI的安装模式都是相同的基本相似的比较简单；再次就不多话了；我猜您可能会碰到的问题有：GLPI的登陆用户名和密码的问题。所有可以利用的相关文档里好像没用提到这个信息，昏！可能是我的运气不好，的确没找到，不过最终被我猜到：）[登录密码在安装向导的导数第二个页面上]

OCSNG需要安装Agent，Agent会在目标设备上做清单扫描，上传Inventory信息；它的三层结构可能会是企业级用户的好消息，它还能方便的通过Windows 域的组策略部署代理，也就是说只要用户登陆域，代理就能顺利安装部署。OCSNG趋向做全面的客户端管理：inventory、license管理等方面。

从上面的GPLI的screenshot可以看出和一个笔记本电脑相关的一切。先讲讲它的来由，GPLI解决的是OCSNG的上层问题：计划，购买，部署，跟踪，变更，维护，退休。它管理的是所有业务和流程层面的东西。GPLI的数据来自OSCNG的数据库，它能自动从OSCNG中定期更新inventory信息。截屏中的电脑是我在我的笔记本上安装了OSCNG后，做的首次扫描后的结果，在GPLI中配置了和OSCNG的集成后，它就变成了一个GPLI中的管理数据。可以看到，和一个电脑资产相关的所有硬件信息，软件信息，help desk请求，文档，链接，注释和变更历史记录等。GPLI中有对外的HelpDesk模块，这能方便最终用户对设备维护的请求。

GPLI和OSCNG很好的结合可能做到“IT资源生命周期管理”，参考文档：http://glpi-project.org/wiki/doku.php?id=en:cyclevie

如果对把它们所实现的功能和ITIL框架对应一下，或许IT服务财务管理，能力管理，配置管理和发布管理等流程能与之能有某些联系。

OCSNG － IT资产管理软件

最近在网上又发现了一个不错的开源软件，这就是OCSNG资产管理软件。他能提供非常好的Inventory功能，发现并、更新计算机系统上的软硬件清单信息。下面是从他们的网站上找到特色介绍的信息：

• Relevant inventory 资产清单管理.


• Powerfull deployment system 强大的部署系统，代理程序软件部署方便宜用。.


• Web Administration Console 基于Web的管理控制界面.


• Multiple operating systems support,多操作系统支持 Microsoft Windows, Linux, *BSD, Sun Solaris, IBM AIX, HP-UX, MacOS X.


• Lightweight bandwith usage: 轻量网络带宽使用，Windows系统的全部清单信息大约5 KB .


• High performance: 高性能，1 000 000 电脑每天做清单扫描，使用的服务器是bi-Xeon 3 GHz /4 GB RAM.


• 3-Tier architecture 三层架构设计，支持http/https/xml等协议河标准.


• 基于有名的开源产品实现， Apache web 服务器, MySQL 数据库服务器, PHP 和 PERL 脚本语言.


• Web service 提供 SOAP 接口的Web服务访问.


• Plugins support 通过API提供插件支持.

Used with a IT and Asset Management Software such as open source tool GLPI, you will have a powerfull inventory and asset management software with automatic updates of computer configuration, license management, help desk and more.

根据ITIL的定义，CMDB是配置管理的主要数据库；其它相关的流程也非常依赖配置数据库；CMDB不一定是一个物理的数据库，它可以是一套数据库的集合。OCSNG能为CMDB提供有效的数据信息。