【摘要】随着it技术在企业的应用，许多企业已经建立了核心业务系统，企业的运作已经离不开it系统了。如何保障信息系统安全可靠的运行已成为企业最为关注的问题，而传统的运行维护管理模式已经不能适应目前环境下业务的需求。因此对it系统需要一套管理系统来支撑，这就是运行维护系统。
【关键词】运维系统 运维服务 it技术
一、背景说明
随着it技术在企业的应用，许多企业已经建立了核心业务系统，如erp、oa、数据仓库等，业务策略驱动it策略的建立，it策略支持业务策略，由此，许多企业的运作已经离不开it系统了，因此任何一个故障造成的损失，影响面是比较大，甚至影响整个企业的业务。而传统的运行维护管理模式比较被动, 即只有当系统出问题时, 才会引起注意和得到解决, 或者当业务受影响, 并被业务部门汇报投诉，才发现问题。 这种管理模式已经不能适应目前环境下业务的需求。
其次，从生命周期的角度看，无论是硬件还是软件，大致可分为规划和设计、开发和测试、实施、运营和终止等5个阶段。前面3阶段从时间的角度看，只占生命周期的20％，其余80％的时间基本上是运维服务，如果整个it的运维做得不好，那么这些花费大笔投资建立起来的系统，无法带来预期的效益，甚至于无法使用，因为使用者无法顺利使用他们。
根据gartner group调查发现，在经常出现的问题中，源自技术和产品方面的其实只占了20％，流程失误占40％，人员疏失占40％。流程失误包括变更管理没有做好、超载、没有测试等流程上的失误或不完整，人员疏失包括遗忘、训练不足、备份错误及安全疏忽等。wwW.11665.coM这就说明it运维方面的问题，更多的不是技术问题，而是来自管理方面，因此对it系统需要一套管理系统来支撑，这就是运行维护系统。
二、信息系统运行维护面临的挑战
一般信息系统架构的层次如下：
由此，我们可以看到，为了保证应用系统的可用性，不但要保证应用程序本身的正确性和健壮性，同时还要保证从网络到应用程序端到端的可用性，为此，从运行维护的角度来看，必须从整体的角度来规划，对与应用系统相关的it基础设施、支撑平台进行集中监控，并与应用系统进行关联，一旦出现故障，可以迅速定位并解决；同时定义相关的流程保证一个应用的变更不会对其他应用产生影响，对出现的问题从根源上找出原因，并进行解决，从而保证系统的高可用性。基于本人对it服务管理的理解，基于itil的框架，提出运行维护系统建立的一些想法。
三、运行维护系统的设计
那么如何设计it运行维护系统呢？主要从两方面着手，一是管理流程的设计，二是系统监控的设计。在管理流程方面，目前itil(it infrastruct library)基本上成为事实上的标准，它是最佳实践的结晶；在系统监控方面包括从it基础设施应用系统进行监控，并实现事件的关联，以实现主动的监控，实现故障的快速定位和预警，下面具体说明。
（一）运维系统的设计理念
运维系统的设计理念基于itil-it服务管理框架，itil 将it 服务管理分为：
●信息和通信基础框架管理，这部份将更侧重于技术视角。
●服务管理，包括“提供it 服务” 和“支持it ”服务两部分，关注在提供it 服务过程中，监控，管理，处理解决问题的整个过程。
●面向业务的管理，将从业务的视角来看管理，将管理it 服务与it 服务所支撑的业务关联。
1. 信息和通信基础框架管理
it 基础框架的智能管理是服务保障的基础，应该是一个可以全面管理it 基础框架中所有产品和技术的平台，并通过提供以下能力达到真正的业务价值、真正的投资回报、保障安全生产，提高服务水平。
it 基础框架的智能管理将覆盖企业it环境，提供包括广域网，局域网，主机接入网络，网络安全设备，internet 服务的全方位的it 从网络到系统，应用，业务的监控管理，以及面向it运维的事件压缩，事件相关性分析，故障诊断，根源故障分析，自动化的故障处理等一系列功能和工具。
2. 服务管理
今天，正进行着服务管理的革命。几乎所有企业的it 部门都正在向面向业务的服务提供者的转变。it部门就像一个合作伙伴一样参与到企业的业务过程，主动的提供服务职能，并向它的客户-业务部门负责。
itil 将企业的it 服务管理分为：
提供it服务，关注在提供it 服务过程中和管理行为和手段；
支持it 服务， 关注在支持it 服务过程中，处理问题，变更等的动作和流程。
（1）提供it 服务
提供it 服务包括：制定规划，为业务部门按计划和服务质量提供服务
保障提供服务的持续性。
在服务提供体系实现的主要任务是：
■服务水平管理
■可用性管理
■容量管理
■成本管理
■应急方案
（2）支持it 服务
支持it 服务包括：为达到服务目标提供相关管理信息。为实现服务目标提供相应的支撑机制。
服务支持体系实现的主要任务是：
■配置管理
■帮助台管理
■问题管理
■变更管理
■软件控制和分发管理
3. 面向业务的管理
面向业务的it 管理是从客户视角的端到端服务监控管理，它的特点是：
提供直观的监控视图，能够实时判断通信和it 基础框架故障对业务的影响；
在发生影响业务的故障时，it服务保障部门能够最快的获知问题的发生，并迅速采取行动；
根据故障对业务的影响情况，决定处理的优先级；
当业务服务发生问题时能够确定故障所在的基础框架层次；
通知相关客户服务系统或大客户，告知问题的状况和解决进展；
面向客户业务服务，提供基于web 的多种视图，包括端到端服务监控层次模型，和监控构成服务系统的各个组件；
面向业务管理的宗旨是通过全面的业务系统和it 框架系统监控，增强管理，提高管理水平，并最终保障业务的成功运行。实现it基础框架端到端的监控和与业务的关联。
（二）运维系统的设计目标
●确保it流程支撑业务流程, 整体提高业务运营的质量。
●提高用户的满意度, 提升企业的社会效益和经济效益。
●实时实现对从it的基础架构到应用系统的端到端的运行情况进行监控。
●提供从业务角度分析it基础设施（包括系统、网络、数据库、应用服务器）的能力。
●建立完善的支持服务流程和支持模式。
●建立满足服务水平要求的服务水平管理。
（三）基于itil的理念建立规范的处理流程
在itil中要建立许多管理流程，在实际应用中，我觉得至少需要建立下面几个流程：
（1）问题管理
建立并应用问题处理程序，以实现对问题诊断和确定解决问题的方案， 并将解决方案记录在配置数据库中，针对服务水平管理确定并实现内部的问题升级时间标准。
（2）资产管理
对于每天发生的事件, 问题, 变更处理, 新服务的配置, 各个组件的信息,资产管理的职责就是提供和维护这些信息, 它是与服务管理相关的最重要的任务之一。
（3）help desk管理
担当服务中与业务部门和客户的主要接触点(point-of-contac)。存储事件, 确定问题严重级别, 综合支持团队的努力, 确保及时准确地解决问题， 并提供sla统计, 证明能够达到预期的服务级别。
（4）变更管理
保证清楚的了解变更针对一个服务中任何组件的影响, 并保证对服务水平的影响最小， 变更管理包括sla文档和服务目录的变更, 以及组织变更和针对软件和硬件的变更。
（5）故障管理
故障管理的主要目标是尽可能快地恢复服务至服务级别协议（sla）要求的水准，尽可能减少故障对服务运营的不利影响，以确保最好的服务质量和可用性级别。
（四）运维系统的组成
在一般的运维系统中，需要一个大房间，在大房间中分成以下几个部分，每个部分都扮演相应的角色：
第一层：大屏幕分别显示有，基于业务的视图，基于it基础架构的视图，基于网络的视图，当故障出现时能够以特定的颜色显示出来，同时可以显示一些公司需要直观显示的数据。
第二层：服务台（help desk），主要提供：
●接受客户的请求
●提供客户使用上的问题咨询
●提供客户业务咨询
●记录并跟踪故障和客户意见
●根据知识库，尽快解决问题
●及时通知客户其请求的当前状况和最新进展
●根据服务级别协议，初步评估请求，经历解决它们或安排给一线工程师解决
●对客户的故障从提出到验证及终止的整个过程进行管理
●协调一线工程师和值班工程师
第三层：一线支持工程师
●根据提供的监控界面迅速定位问题并解决
●对于临时的解决办法，还要把故障提交给问题处理流程
●根据服务级别，在问题未能及时解决时及时把问题提交给值班经理
第四层：值班经理个人
●协调技术专家，根据服务协议的时间要求，解决问题
●协调供应商，根据维护协议要求，解决问题
（五）运维系统的功能设计
基于itil设计理念，我们把ecc的实时监控部分设计成层次架构，如下图：
1. 事件采集层
在最基本的层次上，需要从被管理的it基础设施中获取广泛的，实时的数据,能够从网络、系统和应用层中捕获、汇聚并处理大量数据的能力，我们通常称之为事件管理。
事件管理是整个面向服务管理系统的核心，在数据采集阶段（包括网络、系统和应用层）采集的信息，只有经过事件管理服务器，转变为统一的格式，再流入智能化的管理层，实现事件的相关性分析。
数据采集层是整个管理系统进行信息处理和智能化分析的基础，因此需要充分获得准确、实时、完整的管理数据。在数据采集层，应该进行原始数据的过滤、分类、分级等预处理操作，从中提炼出重要的管理信息。数据采集层获取信息的实时和准确性，以及对原始信息的预处理能力，将在很大程度上影响整个管理系统的管理能力和效率。
2.事件处理层
数据收集仅仅是实现业务和通信及it基础框架管理的基础，需求最简单的先决条件。实现真正的基础框架智能化意味着能够从整个基础框架产生的大量数据中，通过采用一系列先进的过滤，事件压缩，关联和诊断的技术进行处理，抽取管理人员需要关注的重要信息。好的基础框架监控管理系统能够将网络以至it系统的专业化知识融入在管理系统中，根据基础框架层各组成资源的特点，从原始的管理数据中智能分析系统的真实状况，判断资源实际的运行状态，分析故障发生的根源并提出解决建议，使运维人员解决问题更加准确和有效。一般包含以下功能：
（1）事件的存储
将运行维护数据与历史数据分开存储, 以确保管理的效率. 一般管理信息需要保留6个月甚至更长的数据, 以进行统计分析和存档, 而在日常运行管理中, 一般只需要查看最近一周甚至更短的信息, 一般采用运行数据与实时数据分开存储, 运行数据采用高速的内存数据库保证事件处理的实时性, 历史数据采用稳定的关系型数据库保证事件存储的可靠性和容量，这种结构使事件的处理更加合理。
（2）事件压缩
it资源事件中有很多重复事件, 尤其在系统组件不稳定时, 有可能会产生事件风暴。过多的事件会使管理员的桌面上罗列大量事件条目，管理员无法获取真正需要关注的重要事件，因此对重复事件进行合并使事件条目清晰， 帮助管理员快速找到需要处理的故障是非常重要的。重复事件压缩就是这样的一个过程: 通过将从下层数据源所报告的相似事件加以汇总,合并成一条事件,该事件的内容包含了该事件重复的次数以及发生的起止时间。
（3）事件自动化处理
可以对各类事件信息进行逻辑判断, 并做出相应的动作, 如及时删除不必要的信息、完成不同事件之间的关联、对严重事件采用明显的声音报警、自动升级警告级别如果严重事件在一段时间内没有人响应、发送邮件进行自动通知等等。
（4）可用性的计算方法
根据故障树分析fta(fault tree analysis)方法，结合可用性的计算方法，来计算服务的可用性。
组件可用率的计算方法：组件可用率 = (ast-dt)/ast*100%
ast——约定服务时间（agreed service time）
dt——在约定时间内的实际停机时间（actual downtime）
（5）可用性的评估指标
通常我们采用下面几个指标来对可用性进行评估：
①平均无故障时间(mtbf-mean time between falures)，它指的是从某次事故修复到下次事故发生之间的平均间隔时间，又称为正常运营时间（uptime），它是用来描述服务的可靠性。
②平均修复时间(mttr-mean time to repair)，它指的是事故发生到服务恢复之间的平均间隔时间，又称为停机时间（downtime），它是用来描述服务的可维护性和适用性。
3.业务关联层
业务影响分析, 基于cfia等分析法，定义事件和业务系统的关联关系, 自动找到故障所影响的业务和服务, 并根据关联结果创建新的服务事件报警。
4.呈现层
提供基于web方式的监控视图, 可以为不同的管理人员提供不同的监控窗口, 以实时监控相关的事件信息, 事件窗口可以通过分组显示不同类型、级别、源、时间段内的事件信息, 管理员可以一目了然的看到目前是否有事件发生, 级别如何, 并对事件进行一系列的处理工作。
5.报表处理层
各种监控信息存储在关系数据库中，可以利用报表工具进行信息统计分析，生成各种格式的报表。
报表应用可以与实时故障监视环境实现无缝集成，为运维提供一种长期的综合视图。报表应用帮助管理人员了解其各种基础设施在各种不同期间的行为特点，从不同设备、系统和服务的层次上对各种基础架构的长期行为特点进行查看和分析。
（六）运维系统的设计要求
1.基于itil框架设计, 结构先进
运维系统的设计要求基于itil的框架, itil的框架是最佳实践的结晶。
2.可扩展性
如果需要一个新的展示层或者事件关联，必须能够无缝扩充或集成到现有的管理框架中。为了保证随着系统架构的延伸扩展而产生的越来越多的事件信息的处理性能，在任意一个层次增加都不会影响整体框架结构。
3.集成性
集成企业现有以及未来可能要扩充的设备和管理系统。如果需要增加新的监控对象，则最多只需简单地增加一个探针，或增加一个新的关联层 。
4.集中化
已经处理的事件(重复压缩和事件关联)集中在一个地方。因此管理员可以共享整个系统的事件信息。
5.关联
因为事件关联功能在整个系统管理中是分布的，因此为一个新服务增加新的事件关联是非常容易的。
6.冗余
数据显示层和关联层的设计将考虑冗余设计，当任何一个服务器失败，数据采集层的探针将会自动切换到另一个服务器。
综上所述，运维系统的设计，主要从两个方面来实现，一是管理流程的设计，二是系统监控的设计，通过上面的描述，我们看到，系统监控的作用：当系统出现故障时通过对系统各个层面的监控以及事件的关联，能够保证快速定位故障，从而快速解决故障，使得故障对业务的影响降到最小，同时通过对系统性能的监控，进行预警，可以做到防范于未然，防范故障于萌芽状态，保证系统的可用性；而规范的管理流程，保证所有的问题在每一个阶段得到有效的处理。
