信息化运维朝着精细化和智能化不断发展，涉及的软硬基础设施更为复杂，支持环境的部署覆盖区域广泛多样，同时随着智能终端的广泛应用，对信息化的整体运维工作提出了更高的响应和处置要求。在信息化运维技术不断革新的同时，信息化运维的管理更加的规范和务实，其中系统化的风险管理成为了信息化运维项目成功的关键所在。     

     本部分内容介绍标准的信息化运维风险管理的基本思路和框架，重点介绍信息运维各阶段风险管理的重点注意事项。 
 
    1 风险管理的目标 

    项目风险管理的理想目标是规避所有的系统风险，消灭所有的非系统风险。同时可以把项目风险管理目标划分为四个可行的阶段性目标： 

    1.  尽早识别风险 。
    2.  尽力避免风险的发生 。
    3. 尽量降低风险的损害 。
    4. 尽责总结风险的教训 。 

     上述管理目标又被称为“四尽原则”，由于风险管理的目标难以量化验证，传统的项目风险管理一般只能强调主观因素。最终只能归结于“谋事在人成事在天”。    

    2 风险管理的基本流程

    项目风险管理需要经过：1）风险识别 2）风险评估 3)风险应对 4）风险控制  

    1）风险识别  

    风险识别是风险管理的重中之重，风险识别的方法也很多包括头脑风暴、专家意见、风险因素分析、过程跟踪分析法等等。在信息化运维项目中我们要充分运用运维项目风险分析模型（本质是 一个风险知识库），可以通过系统性的风险分析和思路启发，尽最大可能的识别各类项目风险。  
 
    2）风险评估  

    项目风险识别的信息量可能很多，需要对风险进行评估以方便管理。 
    风险分析的方法很多，有些过于感性，人为因素偏差很大，有些虽然专业但是信息收集管理工作量大，不便于实际工作中推广。
    下面推荐一种简易实用型风险综合分析法：
    风险综合值=发生几率*危害程度*验测能力，对于风险综合值进行排序按优先级机型管理 

                                    

    分级不宜过多过细，同时需要便于理解。管理是需要成本的，一个风险管理分级过多过细往往不利用初期的推广和执行。本标准采用5级分类（研究发现一般人记忆同类事物数量一般不超过7个）适合记忆和使用，即可满足一般分级管理需要同时又不至于过于复杂导致推广困难。该方法可以用科学数据依据来于说服一些客户和承建单位重视风险。

    3）风险应对

    项目风险首选应对当然是规避风险（这个通常在建设方案、招标、合同拟定阶段实施），但是在项目实施过程中碰到风险，则不得不进行应对，应对策略为：

    A）分散风险    

    把大风险化整为零各个击破
    B）转移风险     

    比如承诺函，补充协议，合同等具有法律效率的办法
    C）降低风险     

    使用额外措施来降低风险造成的损失
    D）缓解风险  

   采取缓冲手段为解决风险争取时间和条件
    E）限制风险  

   把必然降临的损失限制在局部可控范围，避免照成全局性的影响。
    F）承受风险     

    提高相关方承受风险的心理素质，同时定出风险承受底线。如果一个项目没有明确的底线，大家都抱着观望和侥幸的心理，则事情往往是越来越糟。

    3 运维风险管理的特点

    1)信息化运维项目具有极强的继承性

    A）信息化运维项目延续至今，一直由同一家或两家运维商负责，新一期运维项目往往继承了前一期运维项目的相关风险。
    B）如果是一个新信息系统第一年投入运维，则可能继承开发项目中出现的相关项目风险。
    C）信息化运维项目如果更换了之前的运维商，新运维商可能延续前任运维商相关项目风险，更有可能引入新的项目风险。
    所以做好项目背景以及上一期项目的执行情况的调查收集工作至关重要“以史为鉴“方能有备无患。

    2)信息化运维项目涉及技术的多样性 

    一个信息化系统要稳定运转，涉及到从硬件到软件，从网络、系统、数据资源的方方面面。通常一个信息系统的运维不可能依靠一家运维商全部由自己全部完成，需要各相关单位以及分包商的配合，中间涉及到责权边界界定等复杂问题。同时由于项目的复杂性，部分运维项目可能还涉及到少量需求变更和二次开发内容。

    A）技术风险评估不到位

    案例1：某运维项目涉及二次开发内容，需要做接口实现相关查询功能，由于使用的是免费外部数据源，接口是调通了，但是外部数据源数据不准确，通过与数据源提供商协调也无法解决（无相关合同约束），导致该接口虽然做好了，但是实际功能却难以支持业务使用。该接口的实现在立项时只是定了接口开发实现的业务目标，并未明确使用何种数据源（数据源谁来提供谁来保证），如使用有偿数据源则各方均无相关预算，导致建设方和承建方互相推诿责任项目陷入风险。

    B）无运维服务总集商（部门）或起技术协调能力不足

    案例1：运维项目中机房运维，数据库的性能至关重要，运维服务没有总集成概念。当出现系统瓶颈时候，应用系统运维方说是数据库的问题，数据库运维方说是硬件问题，硬件厂商最后又拿出系统硬件测试（在理想情况下做的）报告说不是他们的问题，但是各方都提不出无可辩驳的证据说服，导致问题解决陷入僵局。这是由于总集成运维商在前期系统规划时候，没有明确责任边界和相关的验证措施，或者项目缺少总集成商，由客户自行规划分包但无协调处理技术问题能力造成。一旦出现复杂技术问题往往出现“无头案”情况，各方都说自己无问题，但是系统就是有性能瓶颈。

    C）SLA（服务等级协议）无法实际落地

    案例1：SLA要求定位不合理（或太粗），比如有些运维项目涉及地域广泛但是却对实时性要求很高，对问题没有进行分类管理，市内要求统一1小时内到达现场，KFC麦当劳这种大型的公司，建立了如此多的服务点，尚且只能做到半小时要求（高峰期都要推迟）。
    SLA的要求没有细化拆分，某些运维要求没有人员、工具、车辆的保证下，很多超时服务（服务不到位），受迫于与实际情况，最终在各方妥协下也只能不了了之。最终SLA的权威受到了严重损坏，最终变为一纸空文。

    案例2：某些运维总包商，承诺某应用系统SLA的运维要求一般故障两小时内解决，但是它与分包商的合同却没有这样的要求，所有承诺只是一厢情愿愿，导致后续风险不断。

    3)信息化运维项目讲究“稳中求进“

    A)保证运维团队的稳定，重视运维团队的建设。 

    信息化运维项目大多涉及比较多的人力资源投入，保持运维团队的稳定至关重要。而一个系统从上线初始到后期，系统越来越多越来越复杂，总体财政运维经费投入却没有怎么增加，在加上运维门槛相对开发来说较低竞争激烈，一个直接影响就是运维商要不断压缩成本，人员投入的质量和数量保证越来越困难。如何保证运维一线团队的问题是一个不能不面对的实际问题，以前这个问题可能需交给运维商自己处理，建设单位只需按合同办事就行（从合同上来说的确如此）。一旦运维团队不稳定导致运维质量出现重大问题，直接的受害者还是建设单位，虽然有合同条款作为依据，但是多半都是双输的局面。
    建议建设单位要多关系运维团队建设，多采取鼓励表扬措施（出表扬信的形式），并制定相关激励制度，估计运维商奖励好的运维团队成员。
    运维管理需要有经验的人员投入和培训，不是简单的制定制度和执行。
    有经验的运维管理人员（项目经理）对于运维项目成败很重要，所有制度执行落地的需要力求精简可行，同时需要有步骤有计划的落地，并采取适当激励措施。在目前运维项目经费紧缩的大环境下，激励比一味的强压处罚能起到更好效果。

    B)要时刻保持持续改进的努力

    运维项目的质量改进通常都是循序渐进的，这跟运维项目本身的特点密切相关，运维质量的持续改进应该长期坚持。同时重视运维工具和知识库的建设，把个人能力和经验转化为团队组织能力。

    4)信息系统运维一般涉及多种安全风险

    A)硬件安全  

   硬件安全的含义是保护支撑信息系统业务活动的信息系统硬件资产免遭自然灾害、人为因素以及各种计算机犯罪行为导致的破坏。硬件安全通常包括环境安全、设备安全和介质安全。
    B)软件安全    

    软件安全包括操作系统、软 件系统等软件环境的稳定运行。
    C)数据安全
    维护系统数据的正确性，防止系统外部对系统数据的不合法的访问，保证系统数据在发生意外时能及时恢复。   

    D)操作安全
    操作安全容易被忽视，系统运维有些涉及到硬件部署，一定要注意专业操作和规范，凡是和电打交道的事情都要遵循安全操作的原则。

作者简介

蒋  耿：北京时代鼎典工程咨询有限公司监理工程师，信息系统项目管理师。具有丰富的运维项目监理经验，多次获得客户好评。