水利信息系统应急预案编制方法研究

唐 燕，卢 通，丁 宁

（1. 水利部水利信息中心，北京 100053;

2. 北京金水燕禹科技有限公司，北京 100089；

3. 北京金水信息技术有限公司，北京 100053）

水利信息系统应急预案编制方法研究

唐 燕1，卢 通2，丁 宁3

（1. 水利部水利信息中心，北京 100053;

2. 北京金水燕禹科技有限公司，北京 100089；

3. 北京金水信息技术有限公司，北京 100053）

以水利电子政务综合办公系统应急预案的编制为例，从应急组织与职责的确定、故障等级的制定、应急处置及演练等方面阐述水利信息系统应急预案编制的过程，提出应急预案的编制应避免过于复杂，要保持预案的完整性及严谨性，科学制定演练计划，并与运维相结合，以期发生紧急情况时，尽可能将损失降到最低。

水利信息系统；综合办公系统；应急预案；编制；研究

随着水利信息化规模的迅猛发展，信息系统在水利行业起着至关重要的作用，一旦信息系统出现问题，轻则影响正常工作，重则对社会公众的利益造成损害，甚至还影响到人民生命财产的安全。水利各业务部门在重视信息系统运维的同时，也越来越重视应急情况的处理，为此，各个单位都已或正在编制针对信息系统的应急预案，力求发生紧急情况时，尽可能地将损失降到最低。

1 应急预案编制的准备

1.1 应急组织与职责确定

水利信息系统的应急组织大致分为以下几个组别：

1）应急领导组。负责应急管理体系、管理办法和预案的评审和确定；负责应急预案启动和终止命令的下达和授权；负责应急实施过程中的决策和授权；负责对故障处置或演练后预案变更的最终评审和确认。

2）应急指挥组。根据应急领导组的授权，负责现场指挥，协调各应急小组工作；负责应急处置情况、故障升级等相关信息的确认；负责向应急领导组汇报应急处置的进展情况；负责在应急过程中，策略的调整和应急指挥；负责组织并协调应急现场的各种资源（含第三方）。

3）应急实施组。负责故障的分析，为现场应急指挥组提供应急预案实施的参考建议；负责按照现场应急指挥组的指令，严格执行相应的应急处置方案；负责将现场故障处理情况向应急指挥组及时汇报和更新；在实施应急措施过程中，协调其他专业组为应急提供技术支持；故障解决后总结、归纳应急工作的经验和教训，完善相关应急预案；负责制定、修改、优化应急预案中应急场景的具体处置方案；负责组织应急预案的检查和评审工作。

4）应急沟通组。负责准备应急现场的故障初始、进展、升级、解决等相关报告；负责故障处理时间控制，以衡量是否需要更新报告或升级处理；负责按应急指挥组指令，及时将应急情况汇报给管理层和业务层；负责应急处置后，给应急指挥组和实施组汇总所有沟通报告；参加应急演练，并提出相应的改进建议。

5）应急保障组。负责应急过程中的后勤保障，包括安排会议室、应急提示牌、电话、视频会议、网络、交通、食宿等；根据应急指挥组的授权，负责现场联络各应急小组和召集三方资源；参加应急演练，并提出相应的改进建议。

需根据应急组织机构确定相应的人员，每组至少有 2 人互为备份，将每个人按照组别、角色、姓名、座机、手机、邮箱、应急后备等信息填表，并下发到该信息系统相关的人员手中。

1.2 现状评估

评估的目的是发现水利信息系统目前现状的优势和劣势，现状可依次分成以下 4个方面：1）最好的情况是健全的实践现状，近乎全面的方案；2）较好的是可接受的实践现状，但须进行某些改进；3）稍差的是不完善的实践现状或可能缺少功能，可能对可用性产生负面影响，建议进行改进；4）较差的实践现状或缺少重要功能，可能严重影响可用性，建议进行改进。在计划方面也分成 4个方面，依次是，健全的计划，可能行之有效，而且涉及到所需的大部分领域；可接受的计划，但难于实施，缺少某些功能或资源不充分；计划可能较差，有可能无效，或缺少重要的功能；计划可能很差，没有明确存在的问题，缺少问题或问题无效。

评估的内容围绕水利信息系统的方方面面，包括水利信息系统目前运行的物理环境、管理情况、日常运维情况的现状，如运维管理和业务部门是否有良好的沟通，对业务的运维管理是否有良好的基础，是否建立了运维平台，是否有良好的策略和规范，和业务相关的各个维护单位是否做到配合默契，在运维管理电子化方面，是否采用规范、统一的电子化信息平台，系统设计和配置是否采用高可靠的冗余设计，是否运用双机热备、负载均衡、冷备切换和厂家维保等方式？通过评估总结，可以看出信息系统的运维现状和行业标准的差距，在哪些方面需要改进，还有哪些薄弱环节，这些薄弱环节有可能引起信息系统的故障。

2 故障等级的确定

2.1 系统关键功能与风险的识别

2.1.1 关键功能识别

按照水利信息系统的功能进行模块分割，每模块还具有许多小的功能模块，根据信息系统的具体功能和应用范围及影响程度，识别出信息系统的关键功能，并以此判断故障的严重程度，从而进一步确定是否启动应急预案。一旦业务应用系统多个功能失效，在有限的应急资源条件下，优先恢复业务应用系统的关键功能。

以水利电子政务综合办公系统（以下简称综合办公系统）为例。目前，综合办公系统按业务需求划分为 6 大类别功能模块[1]。根据综合办公系统的行政办公类型和应用范围，及其对水利部行政办公管理的影响程度，识别出综合办公系统的关键功能，如领导办公和公文办理模块，这 2个模块一旦瘫痪，就会影响整个水利部机关的日常办公，因此属关键功能。一旦综合办公系统多个功能失效，在有限的应急资源条件下，优先恢复综合办公系统的关键功能。

2.1.2 各种风险识别

风险的识别是编制应急预案的重要环节，著名的墨菲定律指出：凡事只要有可能出错，那就一定会出错[2]。只有在全面了解各种风险的基础上，才能预测风险可能造成的危害，预防可以避免的，推迟不可避免的，从而选择处理风险的有效手段，因此首先应进行风险识别。

针对综合办公系统，对其部署的物理环境、维护人员、网络环境、数据存储环境、应用系统部署的主机情况、数据库情况，以及所使用的中间件环境等因素进行全面分析，分别对故障场景、影响范围、严重程度、发生的可能性进行综合分析，从而确定各种情况的故障等级。

在分析的过程中，图1 所示是列举的可能出现风险的各个环节。采用头脑风暴法，通过集思广益发挥团体智慧，从不同角度找出各种风险构成要素，多多益善。

图1 风险构成要素图

针对综合办公系统，在尽可能多的列举风险后，应该对列举的风险，根据一定时间内可能发生或发生的概率，将可能性分为以下 3 种情况：

1）高（可能性大）。指在一定时间内，此种风险有可能发生或发生的概率大于 35%，衡量的指标为 3年内可能发生 2 次或更多，或者最近发生过。

2）中（有可能）。指在一定时间内有可能发生或发生的概率小于 35%，衡量的指标为 3年内可能发生 1 次或由某种外部影响面难以控制，不确定是否曾经发生过。

3）低（基本不可能）。指在一定时间内有可能发生或发生的概率小于 5%，衡量的指标为没发生过或基本不可能发生。

经过分析，挑选出发生可能性为高或中的风险形成故障场景。

2.2 故障等级定义的确定

以对水利电子政务综合办公系统的分析为例说明故障等级的划分。故障影响程度和范围主要有以下几种情况：1）重大的故障。系统瘫痪、数据丢失属重大故障，这种情况往往出现在机房断电的时候，影响严重且范围大，需要立即启动应急管理。2）较大的故障。故障影响较严重且范围较大，同样需要启动应急管理，如电子政务门户系统遭到破坏的时候。3）中等级别的故障。如应用与中间件的内存溢出致死机、单主机操作系统故障等情况，这种故障影响程度属中等严重且范围不大，可以用紧急事件管理流程处理，不需要启动应急处理程序，但需要特别关注该类故障的升级。4）故障级别为较小的故障。这种故障影响不严重且范围较小，可以用事件管理流程处理[3]。

故障等级受故障影响范围和严重程度控制，按照综合办公系统使用人群的分布，受影响人员的范围确定故障的范围大小，可通过所受影响人员的数量给出 4 种范围大小的具体定义：全网指全局，即所有人员；较大面积即按照单位计算，介于 80% ～30% 的用户受到影响；局部即按部门计算，介于30%～1% 的用户受到影响；较小面积指 1个人或几个人受到影响，即小于 1% 的使用用户受到影响。

综合办公系统故障的严重程度依据系统关键功能是否可用和下降 2个方面确定，目前严重程度被划分为以下 4 种情况：1）非常严重，指服务功能的缺失，用户无法正常使用综合办公系统的所有关键功能，所有关键功能均不可用；2）较严重，指服务功能的缺失，用户无法使用综合办公系统的部分关键功能，部分关键功能不可用；3）一般严重，指服务能力的降低，用户感觉到综合办公系统的所有关键功能性能下降；4）轻微严重，指服务能力的降低，用户感觉到综合办公系统的部分关键功能性能下降。

依据故障的严重程度和影响范围综合考虑和确定，目前把故障等级划分为重大（I 级）、较大（Ⅱ级）、中等（Ⅲ 级）和较小（Ⅳ 级）4个级别[4]，将每种情况进行量化，根据故障对水利信息系统造成的严重程度和影响范围形成影响程度矩阵，最终确定故障等级，给故障的研判提供可靠依据，如表1 所示。

表1 故障等级划分

2.3 故障的升级

当告警/故障类的突发事件发生以后，必须对故障产生的影响程度进行初步判断，确认故障级别后，应立即按照故障升级规则，将故障事件汇报到相应领导层，对于较小的 IV 级故障，升级时间为 3 d，只对内汇报给信息系统管理员；对于中等的级别为III 的故障，升级时间为 1 d，只对内汇报给应急组组长；对于较大的 II 级故障升级时间为 4 h，对内汇报给应急领导组，对外汇报给上级领导和业务组；对于重大的 I 级故障，升级时间为 2 h，对内汇报给应急领导组，对外汇报给上级领导和业务组。

故障的处理是一个发展变化的过程，应急指挥组应每隔 30 min 对故障的严重程度和影响范围进行重新评估和更新，按照故障分级标准重新判定故障级别，更新故障处理进展情况，应急沟通组要及时和应急指挥组联系和确认，准备相应的故障情况报告，并负责对内、外及时更新故障处理情况。

另外，一旦故障发生，在应急处置的过程中，应急沟通组需要检查和计算故障持续的时间，如果该故障持续的时间累计达到定义的升级时间，经应急指挥组确认后，故障等级自动上升 1 级。

3 应急处置

3.1 应急场景的编制

水利信息系统的故障场景应急处置应从人员、物理环境、网络、存储与备份、主机和操作系统、数据库、应用中间件等多方面考虑。

应急处置关键在人，为保证应急处置及时、有效，对于关键岗位平时应做好人员储备，确保 1 项工作有 2 人操作，能编写故障场景的要事先编写故障场景及相应的故障处置预案，能细化到命令行的一定要细化到命令行。使用列表方式表示，包括故障名称、场景编号、处理预案编号、故障等级、故障类别、现象描述、验证方法、处理时间。解决步骤应写明哪些步骤由用户处理，哪些步骤由工程师处理。

故障场景应使用列表形式编号存储，编号的目的是便于故障场景的存储及发生故障时的快速查找。故障场景如表2 所示[5]29。

表2 故障场景

针对表2 所示故障场景的处理预案如下：

1）使用主机序列号报 case 到响应中心；登陆主机 MP 卡，输入用户名/密码；收集相关报错信息，登陆 MP 后执行 sl，以及进入 CM 执行 ps。

2）待响应中心确认故障部件后，派单给厂家工程师，并与客户确认备件运送地址。

3）厂家工程师操作。备件运抵客户现场，工程师给服务器断电并实施更换；备件更换完毕，给主机加电；登陆 MP 后使用 fw 命令同步 CELL 板firmware；进入 MP 卡的命令界面 CM，使用 PC-〉on 命令启动操作系统；系统启动完毕，将该节点重新加入双机集群：cmrunnode node1；厂家工程师检查系统及双机状态，命令如下，

4） 客户操作。数据库管理员启动数据库；应用负责人启动应用程序；检查数据库系统及应用是否正常；形成报告，上报有关分管部门。

故障解决验证方法：主机正常启动，数据库系统和应用可以正常启动和运行。

3.2 应急启动及关闭的条件

因为水利电子政务综合办公系统主要为水利部机关的行政办公提供服务，所以目前设定恢复时间目标 RTO（Recovery Time Objective）和恢复点目标RPO（Recovery Point Objective）均为 1d。

综合办公系统应急预案启动的条件需要同时满足以下 3个条件：

1）故障等级为 I 或 II 级（包括低级别的故障因为没有按时解决而升至 II 或 I 级的故障）；

2）根据实际具体情况，应急领导组再次确认了故障等级为 I 或 II 级；

3）应急领导组下达应急预案启动指令和授权。

综合办公系统应急预案关闭的条件需要同时满足以下 5个条件：

1）应急实施组已经在技术层面解决了故障，而且从用户感知方面，应急指挥组再次确认系统功能已经恢复；

2）形成故障处置综合报告，并已完成相应的善后处置，综合报告包含应急故障处置报告、预案改进计划（基于实际情况）和技术善后处置（基于实际情况）；

3）应急故障处置报告已发送给上级领导和业务组；

4）预案改进计划（基于实际情况，如果有）完成并通过审批；

5）技术善后处置（基于实际情况，如果有）已经触发了问题管理流程。

3.3 应急处置的流程

水利电子政务综合办公系统应急处理流程包括以下 3 部分流程：

1）应急前期流程。包括在服务台进行事件记录和分类，对主动或被动检测到的事件进行登记和记录，对接收到的事件进行分类并转发，对故障进行排查、诊断、分析、定位，定位故障后，根据故障的严重程度和影响范围确定故障等级（利用故障诊断和定级报告模板），完成故障定级报告，如果符合应急启动条件，由应急领导组立即启动应急预案，授权应急指挥组现场指挥应急处置。

2）应急处置流程。包括并行的应急技术处置和信息沟通 2个子流程，由应急指挥组统一协调、指挥。同时，在应急过程中，应急保障组要保障应急所需的环境，帮助应急指挥组协调应急相关的人员、设备、物资等。

应急技术处置流程主要是在应急指挥组授权和确认后，应急实施组负责协调和执行故障解决的具体技术处置步骤。在此流程中调用应急处置场景，如场景不能覆盖，应急时采取其他有效措施。

应急信息沟通流程主要是在应急指挥组的授权和确认后，应急沟通组负责向领导层和业务部门发布故障的初始、进展、升级和故障解决情况报告，确保信息中心对内、外沟通的一致性和连续性。在这个流程中，应充分使用模板（包括故障诊断和定级及情况报告模板），以达到快速、准确的要求。

3）应急后期流程。包括应急实施组汇总所有的故障诊断和定级、情况和现场技术处置等报告，并上报到应急指挥组共同讨论，形成最终的故障处置综合报告。应急领导组审核和确认故障处置综合报告后，应急故障处置报告会发给上级领导和业务组，如果有相应的技术善后处置和预案改进计划，需要在完成相应的善后处理之后，应急预案才被应急领导组正式授权关闭。

4 应急演练与预案的改进

4.1 应急预案的演练计划与方案

为提高对突发事件的应急响应水平，水利信息系统应用组应定期或不定期组织该系统应急预案的演练，检验预案中各环节之间的通信、协调、指挥等是否符合快速和高效的要求。通过演练，进一步明确应急响应各岗位责任，对预案中存在的问题和不足及时补充、完善。

水利信息系统应用组每年要拟订年度应急演练计划，在一年中按计划实施应急演练工作。应急演练计划应包括：演练预案的名称、责任部门、责任人、配合部门、演练类型、演练事件，以及相应的演练编写人、审核人和批准人等。综合办公系统应急预案的演练计划表如表3 所示[5]43。

表3 综合办公系统预案演练计划

演练前，水利信息系统应用组应牵头制订详细的应急演练方案，应包括：演练目的、组织、方式、场景、时间和地点、步骤、过程、总结等。

4.2 应急预案的演练执行与总结

演练执行的形式可根据具体情况选择桌面、功能或全面演练，具体如下：

1）桌面演练。通常在室内，利用流程图、计算机模拟、会议等辅助手段，按照水利信息系统预案讨论和推演应急决策和应急状况下应采取的现场处置行动。

2）功能演练。针对水利信息系统的应急预案的专项（特定场景、职能部门等）而组织的实际演练活动。

3）全面演练。针对水利信息系统的应急预案的多项（多个特定场景、职能部门等）而展开的实际演练活动。

演练期间，各工作小组应做好技术和后勤配合工作。对于每次演练，都要对整个执行过程做具体的记录。演练后，水利信息系统应用组应牵头总结经验，修改完善演练方案，对涉及的应急预案部分，也要进行修订完善。

4.3 应急预案的评审与修订

水利信息系统应用组负责对该系统应急预案文档进行初步审阅和审批，应急领导组负责对预案文档进行最终审阅和审批。在单位的发展战略、组织机构、业务规模、信息系统升级和变更（尤其是重大变更）、内外部信息系统运行环境等发生变化的情况下，要及时对信息系统所面临的风险进行重新评估和审计，如果可能的话，应由外部机构承担。发现的问题能够被报告出来，并据此采取改进行动，对预案文档进行必要的修订和更新。

水利信息系统应用组每年至少应组织 1 次信息系统应急预案文档的复审和修订，进行例行的风险分析和评估。通过对应急预案预先设定的关键性能指标（KPI）来衡量应急预案的实施效果，具体如下：

KPI 预案故障场景覆盖率 = 被用到的预案故障场景数量/总故障数量/年×100%；

KPI 预案故障场景解决率 = 用预案故障场景成功解决故障的数量/被用到的故障场景数量/年× 100%。注意：所涉及的数量统计仅针对信息系统的故障/告警类突发事件。

4.4 应急预案的变更与回收

水利信息系统应用组负责文档的保管和分发及版本控制，信息系统应用组和各应急相关小组应保留 1 份最新的应急预案，各应急小组成员每人手中应保留 1 份最新的预案及相关的技术操作手册。应急预案文档在使用过程中发生变更是很常见的现象，对于发生变更的预案文档，需要通过版本的控制和管理，对形成的预案文档及时进行归档保存。

预案文档发生变更时，需要做到以下几点：文档有清晰的变更记录；在文档发生变更时，需通知相关人员，避免新的文档产生后还使用旧的文档；应急预案每次修订后，原分发的旧版本应该销毁。

5 结语

水利信息系统应急预案在编制过程中可能会存在以下几方面的问题：

1）过于复杂。水利信息系统的应急预案面对突发事件，一些单位编制的应急预案内容非常完善，动辄几十页，甚至上百页，这些应急预案理论性太强，安全事件的定级、预案启动、应急处置等环节定义不准确，缺乏可操作性，没有明确的流程，在环节的处理上各相关应急工作人员职责不清，无法迅速对照应急预案定位应采取的措施，作为应急处置人员，面对厚厚的预案，当发生安全事件时，往往会手足无措[6]。

2）缺乏完整性。一些单位编制的应急预案内容过于简单，不够完整。这些应急预案往往只关注关键环节，而忽视其他环节。主要表现在只注重分级、分类及应急处置环节的编写，对于安全事件的报告、安全等级研判、决策指挥、信息发布及通报、应急响应报告、应急预案演练、应急预案的评估、应急预案的修订等方面内容涉及太少，有些环节甚至不作任何描述。

3）应急与运维的关系不明确。一些单位有很强大的运行维护部门，大事小事都由运维部门单方面解决，当事件发生时，由于缺乏研判过程，有的应急事件被当成普通事件，忽略了应急事件中的通报、信息发布等重要环节；有的普通事件又被当成应急事件处理，把本来很简单的事情复杂化，造成人员和经费的浪费。

为避免上述问题，应该做到以下几点：

1）力求实用，可操作。首先是人员组织的设置要到位，人员信息完整，确保应急发生时有相应的人员快速进入处置；其次是明确应急启动和关闭的条件，条件不能含糊不清；三是故障场景具体实用，描述清晰，处置命令明确；四是事件升级的条件都要具体，该升级必须升级；五是演练计划不虚设。

2）力求内容完整。首先是基础资料的完整，细化到主机人员的联系方式，网络备用设备的存放地址，信息系统相关设备的位置、型号，操作系统的版本号，每块网卡的序列号等；其次是应急处置方案的完整，应急处置方案的完整性直接关系到应急事件的处置，在实际工作中应很好地保存，必要时便于查看，也可以和运维知识库相关联；再次是应急处置过程中各种报告的模板，便于快速形成报告。

3）力求量化，便于研判。在事件发生时，运维人员能通过具体的量化值判断是否是应急事件，能够通过受影响的范围和受害程度迅速定级，从而启动相应的应急流程。

总之，在编制水利信息系统应急预案的过程中应重视应急预案的严谨性，科学制定演练计划，不断完善，并与运维相结合，将信息系统应急处置场景纳入运维知识库，与运维系统充分融合。

参考文献：

[1] 水利部水利信息中心. 水利电子政务建设基本技术要求（水文[2010]189 号）[S]. 北京，中华人民共和国水利部，2010: 11-28.

[2] 崔全会，黄受安，李规正，等. 简论安全管理的警示职能——墨菲定律的启示[J]. 中国安全科学学报，1999 (4): 18-20.

[3] 付静，詹全忠，唐燕，等.《水利网络与信息安全事件应急预案》解析[J]. 中国水利，2008 (19): 13-15.

[4] 全国信息安全标准化委员会. 信息安全技术信息安全事件分类分级指南 [S]. 北京：中国标准出版社，2007: 5-6.

[5] 水利部水利信息中心. 综合办公系统应急预案[M]. 北京：中华人民共和国水利部，2012.

[6] 褚英国，陈正奎. 关于网络与信息安全应急预案的研究与实践[OL]. [2014-01-08]. http://www.docin.com/p-753168173. html.

Study on Preparation of Emergency Plans for Water Resources Information System

TANG Yan1, LU Tong2, DING Ning3
(1. Information center, the Ministry of Water Resources, Beijing 100053, China;
2. Beijing Jinshui Yan Yu Technology Co. Ltd, Beijing 100089, China;
3. Beijing Jinshui Information Technology Co., Ltd., Beijing 100053, China)

With the compilation of emergency response plan for integrated office system of water resources e-government as an example, from confirmation of emergency organization and responsibility, formulation of the fault classification, emergency disposal and exercise and other aspects of water resources information system emergency planning process, the article suggests emergency plan should avoid over complex, keep integrity and rigor of the plan, scientifically make exercise plans, and combine with the operation and maintenance. So that when emergencies happen, it will minimize the loss as far as possible.

water resources information system; integrated office system; emergency plan; development; research

TN39

A

1674-9405(2014)01-0047-07

2014-01-10

唐 燕（1964－），女，天津人，高级工程师，从事水利信息化建设与运维管理工作。