IT运维管理流程介绍.doc

IT运维管理流程介绍
ITIL框架
流程分类
流程名称
流程描述及分类
服务支持
事故管理
故障处理
事故发生后，第一时间及时的恢复服务、上报各级主管及相关人员，有些在规定时间不能解决或没有解决方案时，就需要将事故的处理任务交给更有经验和有权限的支持人员。并协调资源快速的解决。
性能事故处理
对系统性能问题的事故进行及时处理。
事故自动恢复
当事故发生后，自动重起进行恢复。
事故手工申报
事故发生后，第一时间及时的恢复服务、上报各级主管及相关人员，并协调资源快速的解决。
事故解决升级
由于现场技术能力有限无法解决的事故或在规定时间无法提出行之有效的解决方案时，需将事故进行升级处理，交给更有经验和有权限的支持人员，请求协助。
事故跟踪升级
若事故不能在指定时间内完成，可以马上升级。
事故报告
当事故发生时，在分析和调查后，提出相应的报告。
事故紧急启动方案
事故发生了一段时间，紧急联系厂家或者相关合作伙伴来解决问题。
故障处理预演
对故障进行模拟式的处理。
问题管理
问题记录
建立问题记录流程，将自己已解决或未解决的问题及故障登记出来，供大家参考或分析解决。
问题关闭
关闭问题
问题跟踪
协调各方资源，对问题进行详细的跟踪分析，并确保问题解决。
配置管理
配置审计
对所有配置项进行账目式的核对。
配置信息登记
记录和维护IT系统配置情况，包括配置，配置项，版本、规格、数量等等。
配置报告
定期报告所有受控配置项的当前状态及其变更更轨迹。
变更管理
主机与操作系统配置变更发现
主机系统、网络、软件、配套环境等方面的操作或变更。
网络配置变更发现
应用配置变更发现
口令变更发现
自动发现口令被修改，通知IT服务经理。
口令手工变更
系统口令需要定期维护更改、VPN口令申请。
用户信息变更
人员信息维护-人员注册注销、调动。
系统需求变更
牵涉到能力管理。
发布管理
Delta上线流程
补丁，升级。
Full Release上线
全新应用经过开发，测试、上线。
系统版本管理
对版本进行增，删，改。
系统推广
系统上线后进行推广培训。
服务交付
可用性管理
可用性改进
对系统、服务或资源进行可用性的提出改进方案。
可用性报告
形成系统或资源可用性的报告。
能力管理
能力预测报告
对系统、服务或资源进行评估预测。
能力评估报告
对系统、服务或资源进行评估预测。
能力改进与优化
对系统进行调优、程序修改等。
服务水平管理
服务满意度调查
针对服务水平，对客户进行满意度调查。
服务水平改进
根据调查和评估的结果对服务水进行改进。
服务水平评估报告
对服务水平进行评估。
自动化
例常报告
维护周报
自动触发维护周报。
维护月报
自动触发维护月报。
维护年度总结
自动触发维护年度总结报告。
例常检查
每日检查
自动触发每天检查的提醒。
每周检查
每周一触发检查提醒。
系统健康检查
系统健康检查报告、系统全面检查。
重大节日前检查
在重大节日到来前作提醒检查。
提醒
重要事件提醒
及时对系统中存在的隐患进行提醒。
口令过期提醒
对系统口令过期进行提醒。
断电提醒
在断电前作提醒工作。
例常杀毒提醒
对每周或定期进行杀毒工作进行提醒。
维护工作
维护例常会议通知
对例常会议的维护工作发放通知。
维护例常培训通知
对例常培训的维护工作发放通知。
维护任务指派
定期定时的分发指派任务。
节假日值班安排
对节假日的值班情况进行安排。
维护例常值班计划
对日常的值班计划进行维护。
运维自动化
自动杀毒
定期定时地进行杀毒工作。
杀毒跟踪
对杀毒的情况进行跟踪，检测并记录杀毒的信息，及可以时之有效跟踪病毒情况。
自动数据备份
对系统数据进行自动备份。
自动数据管理
fileserver，数据增，删，改。
FTP服务维护
对FTP服务进行维护支持。
Web Server维护
对Web Server服务进行维护支持。
J2EE应用服务器维护
对J2EE应用服务器进行维护支持。
数据库维护
对数据库进行维护。
Lotus Domino维护
对Lotus Domino进行维护。
DNS维护
对DNS进行维护支持。
代理服务器维护
对代理服务器进行维护支持。
域管理器维护
对域管理器进行维护支持。

定义了网站可用性指标，如何获取网站的可用值? 监控工具该粉墨登场了。
多数网站都会倾向于利用开源软件自行搭建监控平台。笔者一向认为，即使网站有一台服务器，也应该搭建监控工具，这是保障网站能持续改进的基石。常见的开源监控工具有Nagios（www.nagios.org）、monit（ 是开源的主机、网络、服务监控程序，从这个描述能看出，Nagios 的设计目标是很庞大的。依赖其强大的扩展性，通过分布式监控模式，管理上千台甚至更多的服务器也不在话下。而对于大型集群环境，Ganglia (http://ganglia.info/) 是个不错的选择。
另外商业化运作的比较好的开源监控工具或框架还有 Zenoss ( ( ( OpenNMS(http://opennms.org/) 等。这几个的定位都是"企业级"监控平台。当然，功能的确不比 Nagios 差，也有的弥补了 Nagios 的一些不足之处(比如 Zenoss 增强了对 Windows 服务器的监控能力)。但出于种种原因，在国内的流行程度并不广泛。

(图2: Nagios 分布监控示意图
图片来源:
如果要满足日趋灵活的 Web 监控需要就不得不提 Nagios 灵活的插件机制，最简单只需要几行 Shell 代码就能实现基本的插件功能。多数情况下，脚本捕获系统日志中的特定事件，通过 NSCA Client 发送给中心监控服务器即可。灵活性是衡量监控软件的一个重要标准，从这一点说，多数传统的商业网管软件怕是都不如 Nagios 这样胜任现在日趋复杂的网站环境。
提到网管监控，必然要谈到 SNMP。跨平台或者针对专有设备的监控离不开SNMP，但有的时候 SNMP 的安全性也的确会带来严重问题。这就需要运维团队中的安全专家对监控系统机制的安全性做整体评估，或是提升运维团队的安全意识以避免在监控过程中引入更多的安全问题。
有些公司的运维团队喜欢自己写监控工具而不是利用已有的第三方开源工具。这种重复发明轮子的做法笔者认为是不可取的。这样做最明显的一个缺点是软件本身的维护成本可能会更高，而且团队人员变动的时候后续代码维护也是个潜在的问题。至于商业工具的选择，这里不作评价。
报警机制
光有监控而报警机制跟不上，不能及时把紧急情况下的信息传递给运维技术人员，那么监控形同虚设。现在报警信息发送途径主要有邮件、IM、SMS 三种(过去书籍中提到的传呼方式已是明日黄花)。
这几个途径中，邮件告警可能是最简单的，实现起来容易，一行命令即可做到，但因为邮件本身的异步属性和邮件服务器的延时问题，很难让运维人员及时得知信息。所以，如果比较严重的告警信息必须考虑其它实时性比较高的方法。至于发送到 IM，如果 IM 是支持 Jabber 的，实现起来并不难，可靠性也会有一定保障，而如果 IM 比较封闭，那么可行性就不大了，除非 IM 公司对你开放 API ，否则任何取巧的技巧来发送消息的方法其可信赖性都不强、SMS 是大家都比较倾向的一种方式，只是有很多人不知道具体如何实现，说白了也就是一层窗户纸。如果有电信服务提供商(SP) 能够提供基于 Web 的调用接口给你，那么直接利用 Wget 或是 cURL 工具模拟浏览器处理表单信息即可，几行命令即可搞定。如果不具备这样的条件，不妨考虑一下短信 Modem，现在市场上这样的短信 Modem 很多，价格不贵，大多都提供二次开发的功能，简单的写点脚本即可实现目的。至于网上有人推荐的免费短信服务，因为实时性比较差，笔者是不推荐的。天下没有免费的午餐，这样的服务往往信息发送优先级很低，而且，短信到达率很难保障。
值得一提的是，报警服务器本身也需要监控的。建议定期发送测试邮件、测试短信来验证告警功能处于正常状态。尤其是在节假日来临前更要反复确保该功能是正常可用的。
一个成熟的运维管理环境包括机房环境的管理，网络设备的管理，链路的管理，端口的管理，流量的管理，业务仿真端口的管理，各种系统服务器的管理，数据库，中间件，应用系统等软管理等等。

l 运维系统应该能够提供统一的运维平台，管理人员可以在同一页面进行作业计划、工单等方面的处理，为用户提供一个集中处理的平台而不需要到各个功能模块中去分别处理。

l 作业任务是整个运维体系中非常重要的一环，维护人员需要通过作业任务的执行对现有系统运行情况进行了解，以便为网络优化和问题处理提供更好的分析数据。同时系统提供自动化的任务功能，能够使作业中日常的工作能够自动执行，减轻运维人员的日常工作量。

居然能够让作业自动化配置与布署。控制好作业的时间周期的

- 通过Mocha ITIL最佳实践方式的4个循环阶段(Plan-Do-Check-Improve)，循序渐进的实现IT运维流程;
- 通过Mocha ITOM提供的CMDB为核心，将各配置项相互关联，通过拓扑方式展现，一目了然;
- 通过Mocha ITOM提供的流程与表单的结合，通过可视化修改与配置，更好地实施ITIL式运维计划;
- 通过不同KPI指标，规范IT运维工作量分配和绩效考核;
- 持续改进循环是所有ITIL流程的基础，通过计划-实施-检查-改进后，不断完善IT运维流程，提升IT运维效率。
由于环境十分复杂，企业会指派不同的人员维护数据中心中不同的数据。需要了解所有不同角色与数据中心设备之间的交互过程，角色之间责任重叠。企业的高层决策者需要参与整个计划的过程并做出决策。
· 数据中心的完整资产信息
数据中心中包括大量的服务器和设备，首先需要收集这些硬件资产的信息，以及这些资产之间的关系。资产之间的关系对于计划非常重要。这里举例来看一个服务器和网络之间的关系：
o 通过一个逻辑定义的 IP 地址访问服务器
o 必须在操作系统中定义一个网络接口才能定义 IP 地址
o 服务器中必须有一个物理网卡来支持操作系统中定义的网络接口
o 网卡具有特定的属性，例如 MAC 地址，用来通过物理链路和数据中心内的其他设备连接
o 网卡必须连接到交换机的一个端口上
o 交换机也拥有自己的关系，例如端口属于哪一个模块，交换机之间的连接关系
上述的资产信息需要被收集起来。图 5-9 展示了一个数据中心的例子：
·   绘制业务数据流
在将设备逻辑关系文档化后，为了确定可以实现自动化部署的部分，正确理解配置这些设备的流程非常重要。另外了解设备在业务功能上的用途也很重要。根据这些信息，我们基本可以确定数据中心的基础构架，例如路由器、交换机、数据库服务器和负载均衡器这些设备的变动比较少，而且配置方式比较特殊，因此不适合使用自动化部署。而应用服务器通常使用相同的硬件并且经常发生变动，根据我们收集的信息分析来看比较适合使用自动化部署。下图是一个业务数据流的例子：
·
·
图 5 - 10 数据中心范例的数据流
自动化部署完成后，可以在没有人工干预的情况下将一台服务器从裸机开始到操作系统部署到应用部署完成，而后还能够将这台新的应用服务器加入应用服务器群集，并开始对外提供服务。
· 了解手工部署流程
将数据中心设备当前的结构和使用情况文档化后，还要将管理数据中心的 IT 流程文档化。这样就可以将设备从抵达到进入数据中心需要进行的工作整理为一个步骤列表。这个列表包括上架和接电等手工步骤以及可以融入自动化管理平台的自动化步骤。部署流程通常是跨组织角色的，并且应该和现有的自动化技术结合组成完整的解决方案。

通过这种文档化之后，你就可以理解一个数据中心的那些部分可以使用自动化管理。每个组织在实施自动化管理时有一套独特的步骤，并且每个步骤都有不同的需求，因此这样的自动化管理平台并不是一成不变就可以解决所有问题的。针对每个用户不同的环境、不同的流程，我们都需要对这个云计算平台进行定制化。这样才能满足不同用户的需求。
· 组织结构
自动化部署涉及到很多复杂的步骤，包括物理基础架构、操作系统、网络基础架构、应用程序部署、监控、项目管理以及和其他部门的协调。一般日常的服务器部署不需要和其他部门协调就可以完成，除非存在组织上的、安全上的或其他方面的原因。
在很多组织中，架构中很多部分被认为对业务是非常关键的。例如，网络架构部门需要满足网络可用性以及变更管理和安全性问题的服务级别协议。而云计算平台通常需要改变 IT 文化，要更好的使用这个平台，就需要将组织中的每个部门都融入到其中。
· 标准化
很多组织的IT环境都是异构的，这使云计算平台的实施变得更加复杂。因此最好的方法就是数据中心的设备都使用标准的硬件配置，使硬件类型最少化。例如针对应用程序服务器层，使用统一的硬件平台可以减少对每台服务器的手动配置的工作量。
· 和当前的自动化流程整合
很多组织都已经在 IT 基础构架的不同层次使用了自动化部署，例如启动服务器、软件分发包、系统管理软件和用来运行日常任务的定制化脚本等技术。但是这些自动化技术都是针对于某一个子系统或者局部的，在部署整个系统的过程中还是需要很多的人工介入来完成。云计算平台并不会完全替代现有的这些技术，而是依赖于这些自动化技术和流程来实现更高层次的、全局性的自动化管理。
· 结束语
在本文中，我们从当前 IT 的发展现状出发，结合 IBM 2008 全球 CEO 调查结果，分析了全球企业所面临和急待解决的问题，讨论了相应的应对方法 --- 建设全新企业级数据中心 （NEDC） 的必要性，并介绍了 NEDC 的概念，特征及其发展阶段。在明确了 IT 优化在 NEDC 建设过程中所起到的作用之后，我们分别针对进行 IT 优化需要采用的四个架构模式 --- “物理整合”、“虚拟化”、“灵活的 IT ”和“将 IT 作为服务”，从技术上进行了深入浅出的探讨。
我们介绍这些概念和方法之目的在于帮助读者了解如何通过对 IT 资源的优化，迈进全新企业级数据中心的发展历程。这些通用的方法适用于不同的企业环境，但是由于每个企业的环境和起点不同，企业需要根据自身的情况，设计和规划各自的发展计划，制定符合企业现状和发展方向的蓝图，通过 IT 优化实现高效、环保、坚实可靠、迅速响应业务需求并推动业务发展的全新的数据中心

[转载]Mocha BSM基础架构管理——灵活的网络拓扑展现 (2010-05-27 20:48)
分类： 网上眼界
原文地址：
业务需求与挑战
    企业的网络拓扑结构与设备时常变化，人工往往难以维护网络拓扑。尤其对于上千台设备的大型网络来说情况更为复杂。
    当用户网络设备大量增加后，网络结构异常复杂，用户的网络拓扑很难在一个屏幕上展现或者很难找到要查阅的网络拓扑。
    由于有些网络存在某些租用的线路，拓扑生成发现不到这些节点之前的实际链路。除此之外，企业的外部设备，或与企业网络关联的第三方网络由于防火墙等因素影响，也可能无法发现。
    网络管理成本随网络设备的更替与增多而过快增长。

关键功能与亮点
自动发现与生成拓扑

自动发现
    第二层和第三层网络设备，网络协议（TCP/IP、Ethernet、FDDI、ATM、帧中继、令牌环等），设备包含信息（如网卡、接口、IP和 MAC），设备之间的物理和逻辑关系、设备连接信息（如电缆、中继、网络连接和VLAN）。
 • 网络设备状态、链路状态、接口状态监控与报警n
 •n 支持创建资源组
 • 编辑拓扑n
自定义拓扑

 • 简单而强大的绘图工具n
        使用基本的线、图形、文本、插图、背景色、背景图（地图）等简单工具，就能够绘制出当前各种类型的拓扑与设备的监控图。以下图形都可快速的画出：
 •n 与实际资源关联
        自定义拓扑不仅可以是静态图，也可以是具有实际设备状态、链路状态、接口状态的动态图。
 •n 图库管理
        考虑到编辑拓扑时需要用到各种图标、背景，除了系统提供的默认图库外，用户也可以上传图片。
导入、导出拓扑
    可将自动拓扑、自定义拓扑导出为XML文件，在需要时导入XML文件，恢复拓扑。
权限控制
    网络拓扑管理员可分配用户对自动拓扑和自定义拓扑的编辑权限、浏览权限。
网络设备管理

    在对网络设备的可用性监控以红、黄、绿、灰状态灯展示的同时，也对网络设备的接口信息，包括操作状态、管理状态、接口发送/接收速率等具体指标也进行实时的监测。管理员可以一目了然地看到发生故障的接口及当前接口的性能。
网络维护工具
    系统中还提供了MIB、Telnet、搜索、设备定位、导航等专业的网络维护手段。

我们给客户带来什么
提高维护工作效率
    在网络拓扑可视化管理中，用户只需输入核心交换机的IP地址，系统将自动发现企业的整个网络拓扑，以生动的图形展现出来，并能够立刻开始监控所有已发现网络资源的状态和链路的状态，并定时自动更新。使网络管理员能够快速的掌握企业最新的、客观的网络结构与资源状况。
一人即可轻松管理大量网络资源
    为使网络的展现和管理更适用，支持网络资源组功能。管理员可以对拓扑图的节点进行分区域，组或网段的管理，比如按照不同地区，组或网段将设备划分到不同资源组中。同时，对不同资源组可控制浏览权限。
协助网络管理员监控各种特性的网络
    网络管理员能够根据实际情况对自动拓扑进行编辑，也可以完全脱离自动拓扑，随心所欲的绘制各种类型的拓扑监控图，并与实际设备、链路、接口关联。
可视化监控，一目了然的监控
    可视化监控提供一目了然的监控，降低对管理员的要求，并且降低了管理员的学习门槛。无需掌握复杂的路由器、交换机等设备的维护命令，只需点击鼠标与查看，即可获取设备信息。
开源IT资产管理
IT Asset Management 缩写为ITAM，它是IT管理和IT治理的重要内容。IT资产主要指组织所拥有的，能为其发挥价值的硬件、软件和信息资产等。通常企业在采购IT软硬件后，要建立资产台账，也有IT资产采购、维修、报废的流程。这是IT管理的基础信息。高效地管理IT资产的全生命周期已经不是可有可无的了，而是至关重要的。它能优化IT资产成本，降低安全和法规遵从风险。通常IT资产管理包括：硬件资产清单管理、软件资产管理、采购管理、财务管理、结算、合同管理，线缆管理等方面。资产清单数据往往是IT服务管理流程的基础数据。
资产管理系统的缺失所伴随的问题可能是：
· 资产闲置：资产重复购买，缺乏对IT资产综合管理的意识和方法，也缺乏相应的分析和手段
· 大宗资产报废：IT系统没有用起来就被当废品买到了垃圾站，IT资产的采购、利用率、维护、报废等会接都缺乏对IT资产的价值意识，IT资产的报废造成的浪费巨大
· Excel手工管理：资产与实际环境不一致，数据无法真实，靠手工盘点确保正确，更新不及时

那么如何才能让你随时掌握企业环境中都有哪些资产？正被那些用户使用？如何对资产维护和收费？如何在资产生命周期过程中对其进行合理地变更？每台机器是什么时候采购的？是什么处理器？谁在什么时间装了什么软件？机器将要（或已经）在何时报废？当企业无法掌握现有的各类资产时，要想在企业内进行资产的维护和分配，并确保每个员工都拥有开展工作所需要的工具，就变成的非常困难。要使资产在正确的时间处于正确的位置，所需要的成本也是很高的。
问题在于：财务部门的资产数据只能管理到资产的流入情况，它不适合与IT部门的共享和维护，在资产投产之后财务部门无法对这些信息作更新，随着时间的变迁，原始的资产信息和实际的IT环境也变的没有了相关性和参考性。IT部门往往手工收集和维护一部分的资产配置信息。但是根据这些有限的资产数据，很难准确掌握所有IT资产的现状，很难提前安排维护和支持计划，很难进行批量维护和变更处理。从而使IT部门承担了大量的重复劳动，被迫处理大量的突发事件，并工作在较低生产力的状态，IT员工的绩效及其他部门对IT部门的满意度都很那达成。企业往往也没有专门制定一名员工来从事IT资产管理工作，IT人员工作忙而忽略了ITAM，导致ITAM有效性下降，招致代价高昂的法规遵从问题，同时还会由于资产冗余和不必要的开支导致企业浪费资金。
这里所推荐的IT资产管理方案是：OCSNG和GLPI的组合。

它们各自介绍请参考其网站和Martin Liu的博客。
无疑：能对大量的资产信息进行跟踪无核是很有诱惑力的，但是并不是所有可知数据都值得跟踪。而这些IT资产的信息应该主要服务于：规划IT更新换代、进行预算、安装、移动、增加、变更和采购等活动上。一个有效的IT资产管理系统能为IT部门能带来如下好处：
1. 掌控现状
2. 降低风险
3. 降低成本
4. 明确责任
5. 提高绩效
IT资产管理是ITIL v3中的新增部分，它扩展了V2中的单纯的配置管理。需要通过稳定的资产和配置管理，来驱动IT服务管理流程和业务管理流程，从而来控制IT成本，降低风险，并进行高效的变更，使业务价值最大化。ITAM可以帮助企业控制IT采购和部署流程。将实际需求与合同条款和维护记录进行对比。将供应商的表现记录下来，以便以后在谈判中发挥作用。ITAM可以杜绝不必要的采购，对即将报废的设备，确定最佳淘汰日期。ITAM如果被很好执行，将提高技术投资的回报率，提高运营效率和员工工作效率
IT Delivery + IT Support
在IT管理领域里，商业软件厂商中有自称Big 4的集团：CA，HP，BMC， IBM；在开源软件项目中也好像有自称“开源Big 4”的集团，他们是Groundwork、Hyperic、Qlusters和Zenoss公司。商业厂商向用户推出自己的产品的时候，往往都会打着一些比较大的概念和幌子，说“我们是IT管理的Total Solution”；潜台词是我们的产品非常多，可以满足您所有的需求，而且只要您选择了我们，我们能保证所有的产品模块之间是无缝集成的。事实上的确如此，商业厂商凭着后台开发团队的强大，还有本地服务商的支持，在解决方案的集成性上的确没有什么问题。对于开源软件来说，由于每个软件都在各自为政的状态下独立发展，即使是彼此之间的功能有着某种衔接和集成性，在多数的情况下也往往是各自独立发展；没有考虑到彼此的组合和集成。不过换一个角度看，既然是开源软件，人家把源代码都全开放出来了，如果你想做两个开源软件的集成的话，从技术的角度上说，没有任何障碍；对比商业的闭源软件产品来说，似乎他们又在这方面有着与生俱来的优势。
开源的IT管理软件中有非常多的种类，就拿网管软件来说吧。我的blog上介绍了很多，其中很多的软件都是功能非常重复，而各有千秋的。要想组合一个纯开源的整体IT管理解决方案不是不可能的，需要的是对一些比较精华的软件系统有所了解，并且了解他们之间集成的方式和实现功能。在此基础上做出合理的组合，方能搭建出一个整体的方案。
由于现在ITIL已经成为了大家耳熟能详的“GOOD PRACTICE”，这是08年V3之后的一个转变，V3提出之后，它就以一种亲民的身份，自称自己不再是“BEST PRACTICE”了。既然是要攒一个“开源IT管理整体解决方案”，同时为了保持本方案具有一定的理论高度  选择ITIL作为理论依据当然是不会错了呵呵～～ 不好意思今天心情比较好，废话实在太多，抱歉，下面将开始方案书写了。
本方案将兼顾ITIL中的两大块：IT交付和IT支持。我所选取的是OpenNMS, Hyperic HQ 和 OTRS来分别支撑IT交付和IT支持者两个部分。OpenNMS和Hyperic HQ组合来完成网络和系统监控，它们为可用性管理、性能（容量）管理和服务水平管理提供支持和实现，注意这里说的是为这几个流程提供支持的工具，这些工具本身并不是流程工具。OTRS完成事件管理、问题管理、配置管理和服务水平管理等流程，OTRS本身是一个工单跟踪管理系统，他现在的ITSM模块以及发展到1.1的版本了，同时自称是ITIL兼容的软件。

IT Delivery
OpenNMS和Hyperic HQ的功能定位有所不同，在这里选择他们俩来作为监控网络和系统的平台由一下的一些理由。OpenNMS是agentless的监控软件，它的网络自动发现功能非常好使，而且现在能支持越来越多的网络设备，对于国内的华为等厂商的设备需要做一些定制后才能监控，否则只能看到标准的mib2的信息。最新的版本也能支持分布式的管理功能，也就是remote monitor的模块。我没有让Zenoss入选网络监控的一个重要原因是，OpenNMS是纯开源软件项目，它的所有功能都是可用的，而且它是Java程序，配置文件大多是xml文件。对支持非常大量的网络设备和端口，你需要有的是对Tomcat和Java应用的调优能力，和通过OpenNMS的邮件组来解决bug的能力。OpenNMS里面有非常好的告警事件管理功能，它本身是一个非常好的事件平台，事件升级、报警、过滤等功能都有。而且现在OpenNMS已经能和Hyperic HQ做事件集成，Hyperic HQ的报警事件能传递到OpenNMS中，这就意味着OpenNMS可以作为一个统一集成的事件管理平台，在这里对集中管理所有类型的告警事件。HQ是一种Agent based的监控软件，对于系统监控而言，很多商业厂商的软件功能都无法很好的做到单一代理的技术，当然我认为BMC的Patrol是例外，它的单一代理技术是我见到最好的。HQ的单一代理技术意味着，通过在一台服务器上部署一次代理程序后，其他的工作就都转到web console上了，在那里，你可以配置代理对各种资源的管理，它的代理能发现非常广泛的基础架构应用：Web， midtier, DB等。由于HQ是一个商业开源的软件，所以它对商业基础架构软件的平台支持的非常好，能支持目前流行的所有基础架构软件包括各种商业的操作系统、数据库、中间件；当然它对开源的软件也能够监控。监控参数很多，配置容易，有开放的接口提供功能扩展开发。从OpenNMS和HQ的各种图形上可以很好的评价和监控和各种IT服务的质量。OpenNMS中的界面中最多的就是对某个节点或者上面的某个服务可用性的计算。
OpenNMS和HQ实现和完成的功能能为IT交付中的：可用性管理、性能管理和服务水平管理提供实时的数据支持，OpenNMS作为总的事件平台，同时它还监控所有的网络设备。HQ用来监控所有重要业务服务器，那些边缘的非重要的业务服务器或者是客户端设备也可以交给OpenNMS来管理，它的无代理监控，对这些设备也能管理的不错。

IT Support
OTRS本身是一个非常不错的工单跟踪系统，它在加载了ITSM模块之后，就把ITIL的很多精髓理论做了很好的诠释和实现。对于很多大型企业用户而言可能会笑话OTRS的简陋，不过实施ITIL的过程，我觉得应该是：把当前的繁杂工作，按照ITIL的几个流程简化梳理的过程，每个流程完成比较单一而纯粹的目标；流程之间又能有一定的集成就可以了。对于OTRS的研究，我目前也处于安装和读管理员手册阶段，没时间细看。选择OTRS的一个最重要原因是，今年也开发了一个事件集成模块，它能通过这个模块与Nagios，openNMS，OpenView，Tivoli等监控产品做事件集成，也就是说告警事件能自动在OTRS中生成事件单，而OTRS的事件管理模块就负责吧入站的事件单自动化的分配给相关的技术支持人员受理解决。详情请参考Automated System Monitoring with OTRS Download这个白皮书是在OTRS.com的网站上下载的，我当初怀疑这个事件集成模块是否是开源的软件，所以在Christopher T. Kuhn 的Blog上问他了一下，他向我确认该模块是开源的，并提供了下载地址。从技术路线上来说OTRS是实现了服务台的功能，并且实现事件、问题、配置和SLA管理；从界面上看它对这些流程的支持是比较简洁的实现，你完全不能把它和商业的服务台软件来比较。不过实施ITIL的道路，我觉得应该是丰俭由人的，我相信一定会有人走简洁路线的。想想Apple的产品，它的设计无比的简洁，它简洁并不丑陋，而且还很cool，很流行。
由于这个方案攒的还是比较匆忙，而且技术上没有实际测试和验证，本文旨抛砖引玉的提出一些思路和想法，未经详细推敲，欢迎提出您的建议