陶宏健¹

摘 要 信息系统运行保障定级是信息系统应用项目运行保障工作的基础。合理定级是影响项目运行绩效的重要因素。本文探讨定级过程中充分利用近年应急管理、等级保护方面的工作成果，克服禀赋效应，合理调整各种影响运行保障因素的纳什平衡点的思路。

关键词 运行保障； 应用项目管理；定级；禀赋效应

 Thoughts on Rating of Operation Guarantee of Customs Information System

TAO Hong-Jian¹

Abstract The rating of operation guarantee of the information system is the basis of safeguarding the operation of information system application project. Reasonable rating is an important factor that affects project performance. This paper discusses some ideas of making full use of the achievement of emergency management and graded protection in recent years in the process of rating, overcoming the endowment effect, and rationally adjusting the Nash equilibrium point of various factors that affect the operation guarantee.

Keywords operation guarantee；application project management；rating；endowment effect

信息化系统是当前海关日常工作的基础保障，大量日常工作对应大批信息化应用项目。随着海关业务改革的不断推进，一些新开发的信息化项目不断上线投入运行。与此同时随着日常工作对信息化系统依赖的增强，信息化项目的运行保障需求日益提高，信息化系统运行稳定性更与现场业务直接相关。信息化系统故障已成为可能引发突发事件的常见因素之一。

为合理利用有限财政资金和人力，给信息化项目提供适度运行保障，分级保障是基本方法。

1  分级保障目的

一个信息化应用项目的开发，一般由现场业务、企业、用户的需要或落实国家政策的需要形成开发需求。开发人员、现场使用人员都希望项目上线得到充分的运行保障，最好是连续运行无故障、性能优越资源保障无限制、支持人员全天在现场，以便更好地服务社会，取得更高的成绩评价。但是经验和常识告诉我们，人类建造的系统没故障无瑕疵基本是不可能的。财务知识告诉我们，保障投入会有边际递减效应，超过合理保障程度后，要满足进一步的保障要求会大幅增加付出的人力财力代价，过犹不及。同时，运维队伍的经验积累和运维基础环境建设与完善，需要从运行实践中获得反馈，其工作落后于项目开发速度，难以超前。

平衡项目使用与运维两方面的制约因素，以一组条件将项目保障需求及对应保障条件分级，是实现适度保障有效且必要的办法。划分等级是方法，适度保障是目的。面对大量运行中的应用项目，分出有限运行保障等级，可有效提高运维规范化程度和整体效率。

2  相关的标准和政策

运行保障分等级实施，相关的政策、标准和制度有不少。早在2013年国务院办公厅就印发了《突发事件应急预案管理办法》（国办发〔2013〕101号）^[1]。文中要求各级机构对突发事件要有侧重不同的处置预案，要有机关部门和基层各自的应急预案，要有现场工作方案；预案要结合实际资源进行风险评估，依评估结果制定预案；预案要分层分类制定，分级响应。按照这一文件要求，海关系统从总署到基层现场都已经制定了业务突发事件和信息系统专项突发事件的应急预案。我们给信息系统确定保障分级要从业务现场、隶属关区、直属关区到全国的各层级保障资源考虑，通过风险评估给出各级运行保障适度要求。署级全国项目运行保障级别的确定要考虑业务现场实际保障资源和风险等级，运行保障的组织指挥机制、运行监控、信息报告、应急处置与变通降级处置或转人工等措施、队伍保障及调动程序等内容，还包括应急处理后的恢复方案，比如人工放行的后处理。

在信息系统方面，国家1999年推出GB17859，给出信息系统安全保护等级分级准则^[2]，在2007年推出了等级保护系列标准，2020年4月在原有基础上，结合近年来实践经验和理论进展推出了《信息安全技术网络安全等级保护定级指南》（GB/T22240-2020），对信息系统运维保护从保护对象和保护范围方面给出了分级要求^[3]，信息系统保障级别要从系统服务对象以及当保障不足时可能给服务对象造成的损害考虑。

《海关信息系统运维服务保障等级定级规范》（HS/T42-2014）要求信息系统开发及投入运行时应给出运行保障等级，针对不同保障等级要求，采用不同技术保障手段。运行保障等级直接影响后续运行保障投入绩效。海关行标结合海关信息系统（简称项目）实时性要求、业务敏感度和业务依赖度三个因素，将运行保障等级分为五级。项目的业务敏感度取决于项目用户规模、级别和业务种类，是项目应用范围的衡量。项目的业务依赖度是指项目提供的功能应急替代难度。在项目上线投运前，希望提出业务需求的人员和开发运维技术人员共同给出项目实时性要求、业务敏感度和业务依赖度描述，以确定项目保障级别。^[4]

国际上，作为IT系统运维最佳实践ITIL，汇集总结全球数十年成功的信息系统运维工作经验，其重要内容之一是推荐开展服务级别管理，从业务需求、使用方和系统运行维护各方的人员、流程、技术、资源等方面，综合制定服务级别协议（SLA：Service Level Agreements）。SLA不仅可以是商务性文件，对公益社会服务、非盈利组织的信息系统运维和行政指令运维任务的执行同样有效。SLA在运行过程中既维持一个阶段的稳定（比如一年），又不断评估完善调整，是提高信息系统用户满意度同时提高运维资金使用绩效的有效手段，其中定级和适时级别调整是关键。^[5]

3  当前存在的问题

信息系统运维服务保障等级定级工作，多年来对信息系统运行维护，对海关业务工作稳定高效运作发挥了重要作用。但在实际工作中也存在需要探讨、研究和思考的问题。

一是初始定级偏高。例如，某关大型自动化装卸码头堆场，出口卡口设计正常响应速度是正常货柜车到达卡口，希望秒级抬杆放行。习惯上由此会将相关的各项应用项目认定实时性强、业务敏感、业务依赖度高，因而要求7×24模式连续运行保障。业务需求人员也会争取项目保障级别尽可能定到最高级。事后偶然到现场调研，了解到该码头大部分岗位很少7×24 模式连续工作，长期现场带班的同志给出工作经验是卡口平时故障停顿15-30分钟，不会造成港区大范围混乱，卡口部门一般自己就能妥善应急处理。该现场设备系统多为单系统，冗余程度不高，现场人员基本是下班回家。对于这样的现场应用情况，上线时提出的保障级别明显偏高。每日8小时连续运行保障，意味着8小时外可以有大量时间进行中断业务的运行维护。这与全年不停机连续运行，只能进行在线维护的要求差别巨大。另一案例，某司局一应用项目上线时，从项目的应用意义和作用考虑，业务需求人员提出一级运维保障定级意见，后对相关现场应急方案中的风险后果评估、报告协调措施和人员准备状况进行了研究讨论，下调为三级保障。就平均水平看，目前项目保障定级偏高的倾向普遍存在。

图1  海关信息系统运维服务保障等级定级逻辑

Fig.1  Ranking logic of operation and maintenance service level of customs information system

二是目前运行定级标准量化不够。现行应用项目服务保障级别定级实时性要求、业务敏感度和业务依赖度三项要素，原则性明确，但导出实时性、业务依赖度的依据与现实风险分析关系不明，易受经办个人认识影响，导致定级不当。

4  影响保障等级定级的深层因素

信息系统运维服务保障等级的定级要素在行标中描述了计算方法，但业务方和技术承办单位在确定要素级别时，难以避免其局限性。

首先，业务方和技术承办单位人员对产生该项目业务需求的政策法规相对熟悉，或者对该项目的特定业务场景熟悉，对项目建设具体工作有很多直接认识，因而对项目成果有较强的认同，进而直觉认为项目的业务敏感度和业务依赖度是很高的。投入大量精力的项目对应的工作从具体工作人员角度看是比较重要的。同时，相关部门也希望开发出的项目能取得良好的效益，为此申请相对高的保障级别，以便保障项目取得较好的运行效果。

但是，因为项目运行保障级别在一定时期，在有限运行保障经费、设备和有限运行人力条件下，很大程度上是众多运行项目之间相对保障程度的一种平衡。而单一项目的业务方和技术承办单位人员一般难以了解同一运行环境下，所有项目运行的整体保障状况所受的边界限制。有争取高保障级别的愿望，在缺少直接制衡因素的情况下，产生的项目运行保障级别自然有偏高的倾向。

从这个角度考虑，当前的定级方法，在行为学方面遇到了禀赋效应（Endowment Effect）。对项目投入精力越多，评估项目价值时就越会偏离合理值而趋向更高的认定^[6]。这个禀赋效应在项目开发人员方面同样存在。定级越高，保障越强，运行稳定性越好，运行性能越好。与此同时，运维资金使用绩效会随过度保障逐步降低。各方从良好愿望出发，却未必能得到恰当的结果。现实中，信息系统运维服务保障等级的定级工作陷入了某种平衡。对业务需求提出方、开发承办人员，有高保障高成果高效果愿望；然而保障级别越高，运维人员压力越大，保障占用设备资源越多；保障级别越高，现场业务应急配套要求越高，业务协调储备资源占用越多。这个多方平衡点如何平衡，与定级策略密切相关。要消除禀赋效应，应该引入与项目需求提出、立项、开发、部署实施等过程关系较少的人员和要素，参与定级工作。

如何推动这个纳什平衡点向更合理的方向改变，是一个值得探讨的问题。

5  定级的制约因素

保障级别与后续运行中各方责任、运行保障成本、相关保障能力等要素应关联考虑。各项因素中最弱保障项决定总体保障水平。

要实现项目运行保障级别对应的业务保障结果，不仅在信息系统设施运行保障方面要配套，对应业务保障流程、业务人员工作职责也要配套。按照突发事件应急管理和等级保护要求，需对业务现场应用风险、故障及保障能力进行风险评估，要具备分级响应机制。分级响应的组织保障、协调配合责任因素应与运行保障级别配套考虑。项目运行保障，通过落实现场业务保障职责、现场应急管理责任、应急升级管理流程、现场设施条件、后台运行保障设施、后台运行人员保障责任的一系列组合来实现的，最弱项决定总体级别。在项目后台核心点，保障级别要满足所有现场中综合保障条件最高的要求。

确定高保障级别，除要核实业务现场设施是否具备条件，比如冗余能力，还要核实现场项目使用人员配备情况，比如对应岗位具有操作和简单应急处置技能的人员配备不止一名。7×24模式，5×8模式，和中午有午休的5×（4+4）模式，在实际高保障要求方面是差别很大的，比如24小时通行的公路繁忙口岸、夜间基本无业务的港口、中午午饭时间窗口可以关闭的一些特殊监管区。如果是5×（4+4）模式，项目调整可以在午间进行，实际级别比5×8模式低，其项目连续运行保障时间将下降为4小时，整体运维保障成本降明显低于5×8模式保障要求，加班维护时间会变少。

关于保障成本的考虑，ITIL中汇集了世界上很多国家政府项目的经验。其主要起源就是为合理控制政府信息化项目开支，提高财政投入效益探索IT系统运维经验，总结规律，力求以合理成本适度满足用户合理需要。在服务规划、服务交付、服务实施中合理的服务预期对社会服务成本有重要影响。

在HS/T42-2014中的表1列出了不同保障级别对应的系统维护、运行监控、技术支持的IT运行方的配套项目，但没有给出财政经费使用绩效评估的相关对应项目，作为技术标准更难直接落实分解绩效责任划分。仅从HS/T42-2014中的表1可以看出，同等功能项目保障等级的升高带来的经费负担快速加大。随着运行保障级别的升高，对应的专项突发事件分级响应预案中日常准备行政、物资和流程成本势必连带上升。等级保护方面也会产生类似连带变化。从后台到服务对象全程全网的综合成本与保障定级的关系，不可不察。建议在现行定级综合平衡要素中补充应急、等保及绩效评估等要素，使平衡更加合理。

6  可操作的定级评估条件

通过上述分析，综合运行项目运维服务保障等级现行定级要素、专项突发事件应急预案要点和等保风险分析思想，建议在进行运维服务保障等级定级工作时，首先应对该项目的主要业务现场进行实际业务连续性要求调查，开展风险分析，用底线思维，依实际现场综合保障状况摸清保障底线。其次，要区分理想保障目标、现场影响范围和损失底线风险分析给出的现实目标。还要按照该项目信息化系统保障中断时，专项应急预案和等级保护分析中给出的业务影响，了解社会秩序影响范围，经济直接损失，分层分级报告处置策略，以及人员组织和物资保障状况。对新项目，缺少对应等级保护风险分析信息时，可更多收集对应的应急保障预案，包括管理和技术等方面。缺少现场专项应急预案基本内容的项目，进行运维服务保障等级定级，既违背制度也不能得到合适的结果。

如何判断业务影响，是过去运维工作中的难点。运用底线思维进行风险评估，建议在工作中探索新思路。

现行定级方法中，通过用户类型→业务敏感度，业务依赖度分高中低三类，实时性要求是直接报出，这个过程中缺少风险分析，数据比较原则化，缺少组织管理与流程方面相关评价。相关建议如下：

（1）进行运维服务保障等级定级前，按照国家和总署应急管理规定，要提交适用于该项目的业务突发事件和信息系统的专项突发事件的应急预案，包括主要业务现场、隶属关区、直属关区和全系统的各层级保障分类分级响应预案。最好附有制定预案时的风险评估材料。这类预案目前有较好的基础。

（2）要提交适用于该项目的等保风险评估材料，确定项目异常对应可能造成的社会秩序影响范围和经济损失。这项是业务敏感度的底线反映。项目异常时，社会秩序短时间内影响不大，造成各相关方直接经济损失可以忽略时，项目业务敏感度很弱。比如每周只有几次的业务，中断一天也不会形成社会秩序混乱，业务对经济影响可忽略，不宜简单将敏感度仅与用户类型对应。

（3）从上述应急预案和等保风险评估材料，查看该项目业务保障组织层级分级情况和相关协调部门范围，查看设备与环境技术保障情况。这些内容从另一个角度反映了业务依赖程度。项目运维服务保障等级不应该也无法实现比技术保障能力更高的等级。

（4）从上述材料中，查看该项目业务本层级响应中上报流程/响应升级流程限定的上报时间要求。这是业务实时性/连续性要求的底线。过度要求更高的实时性，会产生明显边际效应。例如不少海关的应急处置预案中^[7-9]，都提及半小时为异常情况处置升级时限，考虑到导致异常的技术故障发生到影响消除过程时序上按照正态或瑞利分布，近似估算故障中断时间在分布均值70%以内，均值控制在升级时限的70%，即10～15分钟，应是合理时间。再比如，北京海关监管作业现场突发事件应急预案，没有对应信息系统突发事件内容，则可按照突发公共事件一般要求时限来分析。

7  应用保障定级方法完善建议

在进行信息系统运维服务保障等级的定级工作时，建议进一步从以下五个方面加以考虑：（1）对于同一个应用项目/信息系统，查看总署、各关及业务现场对其重要性定位的一致性。重要性可分为普通项目、比较重要项目和重点项目。可以从项目立项/任务书中查看各级对项目重要性的描述。上一层级批准的项目重要性高于下一级自立项目。一致性越高定级越合理。系统影响度确定是建议将项目重要性纳入评估项。

图2  运维服务保障等级定因素扩展

Fig.2  Extension of rating factors of operation and maintenance service level

（2）为落实两年内国家相关政策、法规明确要求而投入运行的信息系统，重要性为高。为落实两年内省、自治区、直辖市相关政策、法规明确要求而投入运行的信息系统，重要性为较高。

（3）信息系统专项应急预案中列明突发事件可导致海关全系统三级以上突发事件的，同时申报等级保护三级及以上的项目，项目敏感度为高。信息系统专项应急预案中列明突发事件仅会可导致海关全系统三级以下突发事件的，同时申报等级保护二级的项目，项目敏感度为中。其余项目为低。

（4）现场有经过培训的操作人员使用应用的熟练程度能达到项目部署要求，主要应用现场不少于三人，后台对系统结构的熟悉能够独立分析系统故障、进行性能控制的维护人员不少于三人，对应业务依赖度才可定为高。现场或后台人员不足三人，业务依赖度最高定为中。项目部署环境中前后台主要设备购置超过三年、缺少配置冗余，单设备/线路利用率超过40%的，实时性要求不可定为高。

（5）核定业务敏感度时，应检查项目管理业务和技术方面明确的责任制度，明确的管理人员层级，当地对应用项目关注的用户数量和行政级别，操作运维流程详细完整。要检查各层运维工作是否落实责任制。项目突发情况需由总署司局或省、直辖市自治区层组织处理的为高；仅需直属关领导组织处理的业务敏感度应限定不高于中级；仅需隶属关或地级市以下领导协调处理的，敏感度、业务依赖度均宜限定在中级以下。

表1  运行保障级别的限制因素

Table 1  Limiting factors of operation support level

信息系统运维服务保障等级应在项目立项阶段，由业务方、技术主管部门、技术承办单位和运维方共同确定。同时，业务方和运维方应在上线前核查项目从业务现场到后台保障各层级实际保障资源和风险等级，运行保障的组织指挥机制、运行监控、信息报告、应急处置与变通降级处置或转人工等措施、队伍保障及调动程序等内容的落实实况，还包括应急处理后的恢复方案，人工处理的后处理等内容。

8  结语

信息系统运行保障合理定级，是影响信息系统运行绩效的重要基础工作，也是多种因素综合平衡的结果。探索各因素对运行绩效的影响，寻求平衡点妥善调整方法，落实《中华人民共和国突发事件应对法》，是本文探讨的目的。

【该文经社科期刊学术不端文献检测系统（SMLC）检测，总文字复制比为0.6%。】

参考文献

[1]国务院办公厅.突发 事件应急预案管理办法[DB/OL]. http://www.gov.cn/xxgk/pub/govpublic/mrlm/201311/t20131108_66546.html，2013-10-25.

 [2] GB17859-1999计算机信息系统 安全保护等级划分准则[S], 北京: 中国标准出版社, 2001.

 [3] 中国国家标准化管理委员会.GB/T22240-2020信息安全技术 网络安全等级保护定级指南[OL/S]. http://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=63B89FFF7CC97EBBBED8A403396F0F00, 2020-4-28.

 [4] HS/T42-2014海关信息系统运维服务保障等级定级规范[S]. 北京:中国海关出版社, 2014.

 [5] Office of Government Commerce  (OGC). ITIL Version 3 Service Operation[M]. London: The Stationery Office , 2007-5-31.

 [6] [美]理查德·塞勒:赢家的诅咒, 中信出版社, 2018:92-108.

 [7]北京海关:北京海关监管作业现场突发事件应急预案[DB/OL]. http://www.customs.gov.cn/beijing_customs/434756/434810/3121066/index.html, 2020-6-10.

 [8]嘉定海关：上海海关隶属嘉定海关突发公共事件应急处置预案[DB/OL]. http://gkml.customs.gov.cn/publish/portal5/tab177/module628/info1058.htm, 2010-12-27.

 [9]广州海关网络与信息系统安全应急预案[DB/OL]. http://www.customs.gov.cn/tabid/399/ctl/InfoDetail/InfoID/279496/mid/60432/Default.aspx?ContainerSrc=[G]Containers/_default/No+Container, 2010-8-2.

 （文章类别：CPST-A）