5.3 实现不间断的信息技术服务

发布时间：2009年05月21日点击数： 作者： 来源：ITGOV中国IT治理研究中心

【字体：小 大】 【收藏】 【打印文章】

摘要:
过去，IT风险管理常被忽略或仅仅作为一个单纯的技术问题，但是，现在它已经成为组织治理的问题，是一个涉及到政府部门、监管机构、外部审计、技术服务提供商、董事会与管理层及所有利益相关者的问题。SOX法案更是通过内部控制有效性声明和严厉惩罚将法律与IT风险问题绑定。鉴于此，谨向上述人士推荐此书，相信本书的出版对于推动IT风险管理领域的发展有着非常积极的意义。

5.3  实现不间断的信息技术服务
信息技术服务连续性主要考虑以下因素：
●      制定预算，花费适当。
●      信息技术服务连续性方法同机构的风险内容相匹配。
●      必要的能力设计。
●      得到共同管理者的认同。
●      管理和衡量效能。
5.3.1  制定预算
同服务连续性密切相关又让人持续痛苦的问题是：到底要花多少钱？正常的预算应该是多少？我们怎样调整它？对于任何诸如保障行为之类的开销，总会存在另外的、更有吸引力的选择，这些选择或许也可以保证机构销售和利润。因此，我们需要以某种方式把大家都认可的优先级明确下来。机构提供服务是很重要的事情。但是如果某个功能缺乏广泛认同，那么就有必要从机构的角度对这个功能进行评估。
在一个机构里，有些服务是绝对需要的—— 那么这些服务的恢复时间必须以分钟计，甚至为了达到这个目标就干脆直接提供实时镜像的双系统运作。这种情形大概很容易取得一致认同(或者为了满足公司监管的要求)。这类服务不存在定义和协议上的挑战，因为及时提供这些服务是必须的。但是如果服务提供者是通过一套外包合同来承担责任，那么就会产生特殊的困难。因为在通常的合同里，服务供应商都会引用“不可抗力”条款。这个条款允许出现意外，包括国际性合约在内都是如此(比如电讯行业的坦布蕾协定)。因此在“灾难恢复”的情形下，并不能指望服务提供者做灾难恢复。
监管机构也越来越多地介入业务和信息技术服务的连续性事务中。马来西亚的央行—— Bank Negara Malaysia
(BNM)规定所有的银行都必须制订业务连续性计划。计划必须交给BNM。每次测试也都必须报告BNM。执行计划得到的结论也需要报告BNM—— 包括效能评估—— 并且规定业务连续性计划每年至少测试一次。一旦监管机构提出了要求，那么就会迫使机构逐步的跟随。从历史上看，随着机构实施所谓“良好管制”，放松对某些权限的控制和监管将会从“过去的美好时光”过渡到“过去的艰困岁月”。例如，2004年4月美国证券与交易委员会引入了一套规则，要求每个NASD和NYSE的成员都必须制定业务连续性计划，建立紧急事件或者重大业务停顿情况下的恢复流程。(NYSE规则
446)
从信息技术服务连续性上看，有4个支配因素决定着行动级别：
●      机构的风险内容；
●      在系统和机构里设计了多大的故障忍耐力和恢复能力；
●      机构具有什么样的风险偏好，风险是否是一个关乎机构全体职员共同承担的问题；
●      机构在这个领域设置的绩效考核机制，以及参照这种机制所取得的收获。
5.3.2  风险内容
每一个机构都面对着自身独特的风险内容。这些内容由这个行业范围的一般因素和机构内部由驱动规划执行而造就的独特的风险级别组合而成(表5-6)。
比如，环境因素清楚地显示零售银行行业同交通运输业相比将面临着更大的信息技术服务中断的威胁。
表5-6  环境或行业范围的风险内容因素      
表5-7所列出的诸多因素在不同行业有着很大的区别。因为基于互联网的系统有较高的风险敞口，也面临着相对较高的风险威胁。
表5-7  同机构相关的风险因素

由于机构本身的风险内容具有特殊性，因此那种“香草计划”或书架上的业务连续性计划就不是一个可行的方案。如果它们干脆就来自于一本食谱，那么这种计划对业务停顿而言就根本不具有任何实际意义。
5.3.3  能力设计
使机构具备一定的故障忍耐力和独特的恢复策略总比亡羊补牢来得节省—— 尽管只是在设计时达到目标，看上去还是一个怪异规划。很多院校在校园里依赖于互联网协议，依赖于冷战条件下具有足够好的故障忍耐力这个假设。不过互联网协议对本地校园里面发生的网络中断而言确实是足够好了。
机构一旦把很高的故障忍耐力定义为机构的目标之一，那么很自然地就应该把这种故障忍耐力设计到他们的系统里。那么怎么样才能达到这个级别呢？这是一个事关技术技能和技巧的问题，而不是一个为在机构内的优先级和预算打嘴战的问题。当然，系统也可能是“过工程化”的，但是它们面临的风险仍然没有改变。
5.3.4  认同与偏好
获得了整个机构认同的业务服务连续性计划就能够成为机构的一项特殊目标，发挥重要的示范带头作用。对一些机构来说，它具备的故障忍耐力就像一枚荣誉证章，所有员工都会为之感到骄傲。而另外的一些机构可能为了能够得到供应商或订约人的认可，被迫要达到一定的故障忍耐力和恢复力级别。认证是个很缓慢的过程，包括类似于在英国、中国香港和新加坡广泛采用ISO17799标准。英国的信息技术IL规范也把信息技术服务连续性问题作为核心。这个规范将作为国际性的BS15000标准向外公布实施。
澳大利亚国家审计署最近对主要机构的业务连续性和应急管理进行了评价(ANAO，2003a)，他们依照自己良好实践指引(ANAO，2000)、COB信息技术、ISO17799和信息技术IL服务管理指南对信息技术给相关机构造成的影响进行了评估。在同时进行的另外一项评估中(ANAO，2003b)，审计署建议各机构考虑引用《应急管理澳大利亚》(EMA，2002)和业务连续性协会(www.thebci.org)的“相关指引”。幸运的是大部分建议都是一致的，都要求对连续性计划和灾难恢复计划进行规范的测试、持续的演练。
正如调查和报告显示的，遗憾的是很多的机构并没有为业务连续性和灾难恢复做出规划。也有很多的机构虽然有规划，但缺乏测试和演练。
多少测试才算多呢？大部分的机构对试图进行的测试和有关信息技术服务连续性的训练存在一些实践上的限制。对计划进行重复的演练存在困难，操作代价高昂。演练的过程还会产生很多复杂的能力方面的信息。比如，这次的演练是失败了吗？效果“低于预期”的演练有用吗？效果“低于预期”的演练能看到具体成果吗？每次测试都必须成功吗？等等。
另外一种问题是关于机构的风险偏好。有些机构把所有用于减少风险方面的费用都看成浪费—— 就像一个人把目的地挂在飞机机翼前面一样。但是大部分的机构还是希望在完全承担某种风险还是减低某种风险之间的中间地带具备某种权衡的能力。
5.3.5  效能指标
我们已经多次讨论过两个关键的效能指标：故障忍耐力和灾难恢复力。在我们更深入地探讨这些问题之前，还要引入第三个难以捉摸但还有些价值的指标。那就是“即时利益”的可能性—— 它可能在服务连续性的设计和规划期间获得。在很多机构里，在讨论哪些是关键流程过程中会出现一些错误的有关重要性方面的假设，就像信息技术部门选择系统时偏重于供应商的选择一样。但更偏颇的问题是在试图确定一项服务的恢复机制时，出现的一种偏重工程化的倾向。企图依赖技术造就一套更有效率、更有弹性的服务。从服务连续性的视角出发也许会有新观点和评价方法来交付服务和保障服务。显然，为这些偶然所得设置目标是毫无用处的，虽然这种成果可以记录在案。
对忍耐和恢复这两方面的认知类似于对我们自身健康和安全感受的关注—— 你是否准备把所有的金钱都用来检查你面临的风险因素；保证你摄取足够的维生素；使你具备那种“绕着办公室跑”就有了对抗感冒的抵抗力？你上次患感冒或者嗓子感染多长时间恢复的？你确实是被那些小东西击倒的吗？复原确实会给人的身体带来进步。
故障忍耐是指这样的一种期望或可能性，服务在交付过程中不会被意外事件中断。有关“故障忍耐”的效能目标也可以定义得很明确。比如即使把带宽降低了50％都不会使在线客户的响应时间的明显增加；或者损失一条数据通讯渠道不会耽误电子邮件在指定的时间内寄出。系统能承受多少次的点击仍能使服务保持在可接受的级别？某些方面的忍耐力指标可以直接通过测试获得。但仍有一些指标只能通过质量评估获得。但故障忍耐力只能通过我们自身直接的努力而获得！
恢复力则取决于具体的事件。出现的事件可能会完全处在我们研究过的所有情境之外，仅仅在团队的思维中出现过。机构可以小心翼翼地在它的系统中去掉所有的单点失效，但是难以抵御恐怖分子在多个节点同时实施的恐怖攻击。而恢复则可能要花费数月的时间，需要完整地重建硬件层，更新原始设备—— 前提是要假定以前的数据和软件配置是分开存放的。
事实上，大部分的机构都能够承受小规模的、适度的意外事件和服务中断的冲击。恢复统计数据也证实了这一点。但这种统计只是记录了一般的情况。如果一套服务级别协议极易达到，同时又没有强制性，那么因为技术意外或者错误功能对业务服务产生的影响就可能没有被及时记录下来。网管人员只知道在90分钟内网络能力下降到只有原来的20％。他并不知道在这种情况下客户等待响应时间之漫长，也无法感知机构职员在关键时刻无法访问外部信息库的痛苦。
所以故障忍耐力和灾难恢复力都是我们的目标，都要做出效能度量。机构可以评估其当前的成果，设置新的目标，然后朝这个方向去努力—— 一路上的“即时利益”不会丢失。