关于水利运维保障平台建设与应用的思考

唐 燕，丁 宁，杨春生，曾 焱

（1.水利部水利信息中心， 北京 100053；2.北京金水信息技术有限公司，北京 100053；3.黑龙江省哈尔滨水文局，黑龙江 哈尔滨 150010）

0 引言

随着水利信息化建设的迅猛发展，IT 规模和应用也随之庞大起来，IT 资源越来越多，硬件不可避免的损坏和软件缺陷都将导致信息系统故障的发生；一些重要应用系统性能的下降，也会导致应用系统无法正常使用，业务连续性难以得到保障，这些都说明信息系统的建设只是完成了功能，功效的发挥还需要后期的运行维护管理来实现。这给信息系统运维部门带来了许多新的考验：1）应用系统的规模越来越大，也越来越复杂，必然会使维护人员的数量增加，维护的难度加大；2）随着 IT 技术的不断更新，对维护人员的素质要求也越来越高；3）随着应用范围的不断扩大，应用的深度不断增加，应用部门对维护质量的要求也越来越高。

随着运维工作猛增，在维护技术方面也暴露了以下一些问题：1）监控监视不全面，存在盲区；2）预测预警机制不健全，难以事先发现隐患；3）维护操作缺乏监督、管理，工作疏漏、误操作难以避免，且不易发现，缺乏应急处置机制，突发事件不能及时处置，造成很大影响，还缺乏分析评估手段；4）维护人员业绩无法量化考核，缺少展示工作绩效的数据，导致价值无法体现，得不到领导认可，工作热情低，成就感差；5）变更随意性大，变更前的风险评估和应对措施不够，造成风险难以控制；6）资产管理混乱，配置不清，日常维护工作缺乏规范，对人的依赖程度过高；7）故障处理流程不规范，存在故障漏报、跟踪处理不及时的情况；8）缺少运行维护数据资料，难以为系统和服务的优化提供支持，缺少知识积累手段，缺乏信息共享。

针对存在的问题，面对信息化给运维带来的新挑战，水利部水利信息中心学习先进的运维理念，建设了水利运维保障平台，将先进的运维管理理念应用到实际运维工作中，提高了信息系统运行维护工作效率，提升了运行维护保障水平。

1 水利运维保障平台基本架构

从 2004年起，水利部水利信息中心就开始进行水利信息系统运行保障平台的研究与应用。运行保障平台是信息系统运行保障工作的技术支撑平台，为运行保障工作涉及的监控监视、预测预警、维护操作、应急处置、安全管理等各项工作提供技术手段和管理工具。

目前，水利运维保障平台已经进行了三期的建设，平台集集中监控、风险预警、服务管理、运行评估、安全管理、自动化管理及应急管理等功能于一体，具体架构如图1所示。

图1 水利运维保障平台框架

1.1 集中监控

负责采集策略的定制和下发、数据汇集和综合展现。整合采集监控层各监控工具采集的数据，综合监视各系统的运行状况（包括信息系统基础设施及应用系统状况），进行统一的数据分析和显示，实现对水利信息系统中网络和主机设备、数据库、中间件等资源的统一管理。

1.2 风险预警

负责预警指标制定、风险监控和分析及预警发布。主要实现对信息系统运行过程中可能发生的故障进行预警，提醒运行保障人员进行处理，及时消除故障隐患，以避免发生较大的信息系统事故。

1.3 服务管理

负责流程、表单、流程引擎的制定，以及流程监控等。主要完成信息系统运行保障工作的管理，将信息系统运行保障工作中人、流程、技术有机结合起来，建立1套先进的、科学的运行保障综合服务台。

1.4 运行评估

负责完成应用系统业务效率、性能、故障统计的分析和绩效考核。主要对信息系统运行状况及保障工作进行总结评估，以提高信息系统运行效率和稳定性，提高运行保障水平。

1.5 安全管理

负责对各类设备、管理工具的统一认证和集中授权。为了实现集中管理，需要解决各设备、系统的统一认证和集中授权，以避免因帐号管理不善引起信息系统的安全问题。

1.6 自动化管理

负责完成简单、重复性工作的自动化处置。在信息系统运行保障工作中，有很多重复性工作，这些工作技术难度低，工作量大，且易出错。建设自动化处置系统，代替人工重复性劳动，可减少人为误操作导致的故障，提高运行保障效率。

1.7 应急管理

负责完成应急预案的电子化管理，应急处置措施的自动化执行。在信息系统运行保障过程中，难免会由于设备自身故障、人为攻击或自然灾害等原因引起各种突发事件，如果这些事件的处置不及时，将会对信息系统造成重大影响[1]。

2 水利运维保障平台建设思路

2.1 做好底层监控管理

底层监控是非常重要的，只有做好底层监控，对数据进行归并分析，才可能为更高层的流程化和业务管理提供数据支持。

2.1.1 实现全方位监控

不同设备的监控重点是不同的，例如，对网络设备关注通断情况及带宽利用率；对服务器设备关注 CPU 和内存的利用率，以及磁盘空间利用率等指标，可通过点、线、面全方位监控设备的运行情况。在某一点上可通过对设备的 CPU 和内存的利用率、磁盘空间等多项指标 360°监控，全面掌握 IT 设备的整体运行情况；在某一层面上通过红绿黄信号灯面板，直观掌握 IT 资源的运行情况；对不同专业的类别指标进行排名，掌握最忙、负载最大的 IT 设备的情况，这些设备往往是最容易出现问题的，应给予重点关注。

2.1.2 加强预警、告警机制

针对不同的监控设备或业务系统制定多档次的告警阀值，通过弹出窗口、声音、颜色、闪烁等方式将不同级别的告警信息推送给前台值班人员，并通过邮件、短信等方式将重要信息及时传送给其他相关运维人员和领导，使监控不受地点和网络等条件的约束。

2.1.3 增强直观展示

目前，随着系统的日益庞大，系统变得越来越复杂，针对水利信息中心的实际情况，1个应用系统会涉及到不同的设备，不同的设备又在不同机房，在收到告警信息后，运维人员要快速准确地定位出问题的设备，因此，在实际监控界面上设计了机房实际机柜图方式。通过这种方式，运维人员可快速定位故障点，当故障发生时，相应的机房、机柜、设备会变红色并闪烁，给运维人员快速解决故障争取了宝贵的时间。

2.1.4 加强系统的健康度检查

利用各系统的关键指标总体评估健康度，例如，利用活动会话比、PGA 命中率、共享池和表空间的利用率、buffer cache 命中率等指标综合评价数据库的健康度。通过对系统的健康度检查，可使运维部门提前关注健康度较差的系统，及时优化，改善和加强系统的可用性。

2.2 重视配置项管理

配置项是管理的基础，包含硬件、软件、业务，以及邮箱、各种账号等。

2.2.1 配置项的属性

在设置过程中应和实际运维工作相结合，例如，对于服务器设备不仅应记录 CPU 数量和频率、内存数量和大小、硬盘数量和大小等本身的属性，还应记录该服务器的维护和使用人员信息、部署信息、所在位置、序列号、报修电话、开始使用日期，以及历次的维修和变更记录等。其中变更记录不仅应包含配置、底层软件的变更等信息，还应包括 IP 和物理地址的变更信息等，以便于在设备发生故障时进行处理。

2.2.2 配置项的关联

在事件、问题、变更等管理流程中增加配置项的关联。首先在流程建立阶段要关联相应的配置项，其次在流程结束时要有对配置项更新的确认环节，这样才能确保配置项信息是完整、唯一的，且是最新的。

2.2.3 配置项的生命周期管理

每类配置项都应建立自己的生命周期模型，例如服务器设备要经历购买、入库、出库、检修、停用、报废等环节，通过对设备生命周期的管理，可以看出哪些设备检修次数多、使用时间长，这些设备往往也是比较薄弱的环节，通过定期生成报告的方式通知运维人员对这些设备加以关注，同时也给设备更新提供可靠的数据支撑。

2.2.4 配置项和知识库的关联

配置项的操作说明、维修记录、各种相关的更新升级记录等都应该进入知识库，同知识库进行关联，一方面在处理设备问题时可以借鉴；另一方面从知识库方面出发，可以查看相关问题在哪些设备出现过，便于运维人员借鉴查询。

2.3 注重流程管理

运维系统一般都包含许多流程，如事件处理、变更流程等。对于那些运维人员在10人以下的单位，应尽量减少流程的数量和步骤，归并一些环节。在人员允许或已有一定基础的条件下，可以适当调整流程。

2.3.1 事件管理流程

在运维系统中最常用的是事件管理流程，10人以下的运维部门，可将日常事件流程和服务请求流程合并，将流程中的角色进行合并，并充分考虑转派及协同处理。根据水利信息中心的实际情况，在事件流程中设计了热线、一线、二线、厂商等几个角色，其中一线人员主要负责完成桌面级的、客户端的事件处理工作；二线人员负责完成数据库、中间件、主机、存储、安全和网络等的管理工作。处理时，首先由热线进行受理，然后分派到一线或二线，一线处理不了的问题可以转二线，热线、一线、二线均可以转厂商直接处理，例如，在巡检过程中遇到硬盘故障直接报修更换的问题就是由厂商完成的，事件管理流程如图2所示。

图2 事件管理流程

2.3.2 服务请求流程

在10人以上的运维部门，可以考虑将普通的事件处理流程和各种服务请求流程分开。普通事件流程包括机器无法打开、上网、查杀病毒等，由一线工程师直接处理；服务请求流程包括申请入网、服务器上架、应用系统上线、数据库表空间和端口开放及用户权限申请等，主要涉及到资源、权限的分配，以及安全的设置等，偏重由二线工程师处理，这样可避免初级服务请求的直接处理，将二线工程师从繁琐的事物中解脱出来，保证对关键应用和紧急故障的处理，充分发挥各种技术人员的能力，克服高能低用情况的发生。

2.3.3 变更管理流程

变更管理对于任何部门来说都是非常重要的，建设运维保障平台中要避免变更的随意性。日常维护中的变更事项非常多，分为常规和重大变更 2类。常规变更包括权限、客户端 IP 地址等变更，只要具体负责领导签字即可进行；重大变更包括机房变动、新项目上马等涉及到多个应用系统的停机和变动，必须经过上级审批，评估授权，并成立变更委员会，制定详细的变更计划，经认真评审通过后才能执行。

2.4 加强技术和管理的结合

在正确定位运维工作重要性的同时，需要从单纯的技术思维转向管理思维。仅仅靠购买监控和ITSM（IT 服务管理）软件是解决不了问题的，需要综合人、流程、技术等多方面的因素，建立综合运维管理体系。软件只是技术手段，还必须确保管理措施、维护人员和经费。为此制定了《水利信息系统运行维护规范》行业标准，标准包括运行管理办法、维护规程、应急响应预案、维护定额等一整套运行保障办法及规范，以此加强运行保障工作制度。需根据运行维护工作内容，依据分工协作、相互配合的原则，对运维一线、二线人员进行合理分工，同时保证相互配合，才能充分发挥各组的技术优势。通过购买原厂服务，充分利用第三方资源，对一些关键设备、业务在关键时段解决应急问题，进行专业巡检服务，将故障隐患扼杀在初期。同时还制定了《水利信息系统运行维护定额标准》，给信息系统的运维提供可靠的资金保障[2]。

2.5 促进运维和业务的结合

IT 运维管理的发展趋势是 IT 与业务的完全融合，运维服务的最终目标是“业务不中断，数据不丢失”，一切管理都是为了能够让业务部门更加高效的运转，提高生产效率，为企业创造更多收益，因此运维管理必须围绕业务价值这个核心，以业务为核心的 IT 运维管理是追求的最终目标，也是信息化高度发达的体现。在 IT 规模和人员配备达到一定水平时再实施流程化的 IT 服务管理，最终达到 BSM（以业务为重点的 IT 服务管理）的目标。

2.6 做到运维管理体系的平滑过渡

IT 运维管理平台的核心思想是 ITIL（信息技术基础构架库），要将 ITIL 变成一种文化，全员参与，培训先行；在实施过程中要重管理、效果；要结合现有管理成熟度，推广过程中要考虑与现行管理制度的兼容性，做到管理的科学性和艺术性相结合。在开始建设 IT 运维管理平台时，并没有马上引入绩效考核制度，也没有实施 SLM（服务级别管理），变更、事件流程都是最简单的，直到运维人员已适应流程管理，并在工作中主动应用运维管理平台时，才逐渐引入绩效考核制度，并将服务请求从事件管理流程中剥离，把更为复杂的变更加入变更流程，做到管理体系的平滑过渡。

3 水利运维保障平台建设过程中重点问题及解决方案

在水利运维保障平台的建设过程中，要弄清楚运维人员关心什么？运维保障平台对运维工作到底有什么帮助？在建设过程中也会遇到一些问题，该如何解决，都要认真探讨。

3.1 运维平台要解决哪个层次的问题

在运维保障平台的建设过程中到底要解决什么层次的问题，是基础设施管理，还是流程化的 IT管理，还是高级的业务服务管理，不同阶段都需要有不同的解决方案。在一期建设过程中，首先建设了监控和配置项管理模块，实现了对基础设施的管理，建设了服务台和简单的事件管理流程，实现了初步的流程化管理；在二期建设中，建设了服务请求管理，丰富了变更管理，强化了流程管理；在三期建设中，建设了对业务的监控与管理，加强了各种报表功能，在前期数据积累的基础上为领导决策提供可靠的数据支撑。

3.2 运维产品的选择问题

目前，市场上的运维产品很多，功能也很全，一些运维产品在实施过程中对管理人员的技术及管理流程都有较高的要求，这对于运维部门人数在10人以下的单位来说，显然是用不起来的，没有足够的人员进行角色分配，流程无法运转，到最后根本无法解决实际运维问题，或者运维系统虽然用起来了，但并不能提供运维人员所关心的重点数据，无法反映业务运行状况等。有些单位将运维系统软件采购回来，安装后就再没有使用，形同虚设的 IT 运维管理最终是没有成效的。

典型的运维产品应包括事件、问题、变更、配置、知识库、服务级别、可用性、容量等管理模块，以及服务台模块，应根据实际情况建设，不能原封照搬，也不能盲目上马。要使运维保障平台充分发挥效益，需要综合人、流程、技术等多方面的因素，在许多环节上需要通过管理手段实现，而不仅仅是靠1套 ITSM 系统软件就能彻底解决的。在水利运维保障平台实施与应用过程中，在多个流程中设置了配置项的变更环节，并通过管理手段强化配置项的唯一性、完整性，通过实际人员配备情况设置具体流程，这些都要求运维产品具有足够的灵活性，并可根据运维实际情况进行定制。

3.3 运维软件的更新问题

很多单位认为购买运维软件后，实施起来就行了。实际上 IT 系统和业务应用是逐步发展变化的，架构的调整，规模的扩大等对运维管理软件、管理人员的管理水平都提出更高更新的要求，因此，运维软件需要不断更新升级，IT 运维是1个持续化建设过程[3]。还有一些单位在建设过程中喜欢大而全，什么都需要，却忽视了运维人员的承受能力，不但不能对运维起到辅助作用，反而增加了许多流程环节，使简单的事情变复杂了，增加了运维人员的工作量。水利信息中心根据运维部门的实际人员和资金的情况，设置了服务台，以及事件、配置项、变更、报表及知识库等管理，通过几期的建设，陆续建设了服务级别、业务的可用性、容量及配置项的生命周期等的管理。

3.4 如何真正提高运维水平的问题

ITIL 最早源于20世纪 80年代的英国，如何将ITIL 的框架应用于中国政府部门中，真正提高运维水平？例如，服务台作为信息部门和服务客户之间的重要联系点[4]，既可以响应系统用户的询问和请求，也可以解决用户发现的故障和产生的疑问，怎样的服务台才最有效？当运维服务比较专业时，服务台人员如果没有比较深入的项目知识，接到电话后都把电话转给一线或二线人员，由一线或二线人员再跟客户联系，久而久之许多客户都不打电话到服务台了。水利信息中心在实际的运维服务中，把一线支持人员全部纳入服务台中，实践证明这是符合实际工作需要的。

IT 运维保障平台离不开 ITSM 管理软件，但在应用时，有时却两面为难，对一线或二线的工程师来说快速把事件搞定，不使用 ITSM，不填任何信息，来得更快，没有 ITSM 时，故障一样处理。由于SLA（服务等级协议）的计算，对事件处理信息录入有比较苛刻的要求，这对一线工程师来讲是比较麻烦的，事件单关闭不及时，会引起 SLA 的计算不准，也会产生一些负面影响。因此要搞清楚，流程首先是要满足管理的需求，而不是具体业务操作的需求[4]。

专家研究和大量应用实践表明，IT 项目的生命周期中，大约80% 的时间与 IT 项目运维有关，源自技术或产品（包括硬件、软件、网络、电力失常及天灾等）方面的问题通常只占 20%，而流程失误问题占 40%，人员疏失问题占 40%[5]。

运维管理中采用 ITSM 软件，是为了固化体制与流程，让服务体制更规范、标准，把真实的运维现状反映出来，如果说在某一段时间会增加成本，那么这个成本是必须付出的。在水利运维保障平台的实施过程中，在运维的各个环节，领导要始终坚持流程化的管理，并引入人员的绩效考核，如果运维平台上无数据，再多的工作不被认可，这样，运维平台上的数据得到了丰富。

4 结语

将国际最佳实践与政府部门的实际相结合，水利信息系统在运维保障平台投入使用以后，经过三期的建设，已经初见成效，运维人员从急救大夫变为保健医生；规范了信息系统运行保障工作，降低了人为故障率；实现了信息系统的全面集中监控和预警，降低了技术故障率，实现了信息系统运行保障工作的自动化，提高了效率；建立了应急处置机制，提高了应急处置能力，减少了损失；加强了安全管理，保证信息系统安全；实现了经验积累和共享，提升了运维人员水平；大幅降低了故障率，提高了故障恢复速度；大幅提升了用户满意度。

水利运维保障平台与其他运维系统相比具有以下几点突破：

1）首次将服务请求从普通的事件管理中分离出来，使得一线、二线的工作更加具体，更好度量，给后续的统计分析奠定了良好的基础；

2）在可用性与容量管理方面进行了初步尝试，对业务的整体可用容量及可用性进行监测；

3）建立了业务服务试图，对业务的运行进行监控管理，可实时反映业务的运行情况；

4）建立了配置项的生命周期模型，实现了配置项的全流程管理。

相比传统的运维保障软件产品，水利运维保障平台在许多方面都做了深层次的探索和尝试，在绩效考核、知识库管理，以及业务的可用性、容量管理方面还需要进行更深层次的研究，继续拓展运维平台的广度和深度，为水利信息系统安全稳定的运行提供更可靠地保障。

[1] 水利部水利信息中心.水利信息系统运行保障平台研究与应用工作报告[R].北京：水利部水利信息中心，2009:5-4.

[2] 中华人民共和国水利部.水利信息系统运行维护定额标准[S]. 北京：中国水利水电出版社，2009: 25-32.

[3] 孙永杰.析中国 IT 运维现状 解企业高效管理之路[OL].[2009-10-20].http://blog.sina.com.cn/s/blog_5f7733320100fk5h.html.

[4] Jan Van Bon IT 服务管理——基于 ITIL 的全球最佳实践[M].章斌，译.北京：清华大学出版社，2006: 34-35.

[5] 候维栋.ISO2000认证与实践[M].北京：清华大学出版社，2010: 26-29.