过去，IT风险管理常被忽略或仅仅作为一个单纯的技术问题，但是，现在它已经成为组织治理的问题，是一个涉及到政府部门、监管机构、外部审计、技术服务提供商、董事会与管理层及所有利益相关者的问题。SOX法案更是通过内部控制有效性声明和严厉惩罚将法律与IT风险问题绑定。鉴于此，谨向上述人士推荐此书，相信本书的出版对于推动IT风险管理领域的发展有着非常积极的意义。
5.1 影响业务的信息技术服务失效
Mitroff和Alpaslan(2003)研究了财富500强中具有“危机倾向”的公司，看看其中有多少公司做好了“危机准备”。所谓“危机准备”是指这个公司能承受一些灾难，可以使自己的业务坚持较长时间，也具有较好的声誉。这种公司只是少数 —— 从统计上说你的公司可能并不在此列。怎么区别一个企业是不是“危机准备”的呢？首要条件是为可能遇到的问题作出规划；第二是制定计划来应对过去未曾遇到过的问题；第三是发展一种策略来降低未来可能遭受的风险的冲击。这些能力将会展现一个学习型企业的特质以及正视“异常危机”的韧性和勇气—— 尽管危机本身并不是我们所期望的。
Watkins和Bazerman(2003)指出：迫近危机的提示常常会出现在我们所有人的周围，但我们总是视而不见。幸运的是，在一切都变得太迟之前，有几种方法可以让我们认识到危险。业务领导人的对危机的发现模式应该是：全面审视可能出现威胁的环境(本书的第10章将会讨论)，找出所有可能发生的危机，按优先次序排列，最可能发生并且可能造成最大影响的问题优先应对，优先得到劳动力的投入。
5.1.1 服务效能
由于“信息技术服务”模型一直把注意力集中在基础设施、应用和系统等方面，因此很多信息技术功能都没有被这个模型采纳。信息技术服务也很少能完整地映射到系统和设施上面。这意味着某种系统失效对服务的影响可能是未知的。操作员的职责只是照看设备(基础设施)和系统，而不是提供信息技术服务。一个系统可能提供多种服务，但这些服务未必具有同样的优先级或重要性，因此操作员不可能对它们进行区分。
在信息技术服务连续性计划中关键的一环是定义每种服务的最大可容忍停顿(Maximum Tolerable Outage,MTO)。其含义是指某种服务中断超过多长时间就要公告为危机或灾难状态。实际上，机构不可能等待MTO消耗完再采取措施，而是在这个时间段内尽可能采取措施恢复提供正常服务。
业务连续性管理一般是首席运营官或者其他高级运营职员的责任。通过考察业务流程可以找出哪些信息技术服务是优先的，哪些服务是业务运营所必需的。在这个过程中，也能同时定义出每种业务流程的MTO。
5.1.2 完善的规划准则
信息技术服务风险有关的很多工作都反映在规划层面。在理论上讲，所有对基础服务构成威胁的风险都要被识别、评估和管理。但是，这种做法需要进行评估的风险数量巨大，影响所及要跨越很多种服务。因此找到一种替代的方法可能更有效。对单一的威胁或者一组威胁可以用一种情境来应对。所有可选情境集中起来就构成了一个情境集合。这个集合就可以应对所有重大威胁。而采用规划1应对威胁1这种一对一的方式会导致规划数量巨大，而且需要针对每种情境需要设计一组规划，因而这是一种并不现实的方法。
对连续性规划而言，“故障忍耐力(Resilience)”是最重要的指标之一。其含义是指某种服务要容忍某种程度的停顿而且服务自身还要持续维持在特定的目标效能之上。要想达到故障忍耐力的要求可以通过多种手段如投入冗余资源、选择容错设备等。故障忍耐力并不能够在危机响应过程中自然而然地产生。它是要通过规划来建构的。因此，我们有必要为每种服务设立特定的优先级。一旦服务能力减弱，那些优先级较高的服务仍希望能得到保障。也就是说，服务也需要按照预定的优先级来排队。另外的一个理论指标是建构故障恢复能力—— 当危机发生后恢复服务的能力。
大部分故障恢复能力是以设备的精心选择和用心保障为基础的。但是具体的行动也同等重要。设计一系列的测试情境，通过让职员参与依次展开的情境测试来提高应对危机的实际响应能力。重置的资源、品质过硬的设备以及完善的后备设施是保障基础设施的有效手段。我们可以基于费用和风险平衡的原则做出选择。但是，如果员工缺乏训练，又没有正规的测试，那么这些投入能发挥的作用就会很少。
5.1.3 危机与灾难
灾难恢复规划(DRP)是用来应对这样一种情形出现，即在一个可接受的时间内，预先定义的业务连续性要求得不到满足。例如，假设一个企业的关键业务服务的MTO定在两小时，现在出现了在两小时内都不能恢复提供服务的情况，那么灾难恢复行动团队就要被召集起来。显然，重大的灾难，如火灾、水灾和道路事故等应变都应该是每个机构DRP的组成部分。同样，一旦类似警察占领之类紧急服务的情况出现，机构管理者就不能采取任何行动，甚至都不能进入建筑。一旦紧急服务结束，业务连续性规划就应该投入运作，按照预定的优先级使业务在尽可能短的时间里恢复至全功能的运作。
有些机构对于“紧急”、“危机”、“灾难”这类术语都有其确切而又独特的解释，但有些机构又未必会这么做。“危机”一般被定义为对机构的财务稳定或者对个人生活会造成巨大影响的事件，要求管理层做出即时、正式和公开的反应。通常，这类的所谓公开的反应还伴随着公共关系(PR)和市场团队的参与，即使危机是因为机构的信息技术、财务、产品质量或者职员的行为不当等事件引起的。紧急事件涉及公共的应急反应服务以及可能出现的外部机构澄清。一旦由于信息技术服务失效而导致重大的公共信誉破坏或者股东损失，那么PR、CEO和董事会都可能要参与其中。
5.1.4 对信息资产的影响
在信息资产管理和信息技术服务交付之间有着天然的联系。所有类型的信息技术服务交付都需要使用信息资产，可能是数据库，也可能是系统和应用。同信息技术服务一样，信息资产也要满足安全性、完整性、可用性以及合规性的要求。某些业务用户可能会在提出服务交付需求的同时，也要求对信息资产提供保护，因此可以说信息资产安全是业务取得成功的基础。
在正常情况下，失去连接不会造成信息资产的损坏。但是，信息资产正是由于可用才体现出价值。失去连接则意味着资产的可用性的丧失。
5.1.5 管理系统失效
在通常情况下，服务失效在系统级(即技术层面—— 译注)是能侦测到的。服务支援(Helpdesk)操作员也可能会得到一个来自客户的呼叫，抱怨系统宕机了。但是由这个系统所提供的服务一旦中断，服务支援(Helpdesk)操作员可能是看不见的，因此还需要借助一个系统级的过程。每一次失效都要当作事故来看待。如果机构想要及时了解当前的服务效能级别，长时间、持续地改进事故管理，那么就有必要建立规范的事故记录、跟踪、管理和监控机制。唯一的例外是在生命遭受威胁、极其危险的情况出现时才允许对事故情况做事后记录。
由于历史的原因，信息技术职员或多或少会参与有关信息技术服务连续性方面的工作，因为本质上他们就是那些并不怎么可靠的服务的提供者。现在信息技术硬件变得日益可靠，压力现在已经集中到了信息技术安装的复杂性以及机构内部对这些服务的依赖性上面。
重大事故都有一套对应的恢复方法。这些方法应该是事先设计、事先计划和事先认可的。有关的员工应该接受恢复操作的适当训练并保留完整的事故记录。在大型的装置中，如果发生的事故超出了事先定义的标准演练的范畴，那么事故就应该迅速地转交到专家团队手里，让他们来研究、引入特殊的机制来找出解决办法。
所有已界定的事故都应该对应着一个事故级别。这个级别用来建立不同类型的沟通渠道，设置相异的优先级。事故提示将会直接通过信息技术的服务支援(Helpdesk)系统通知机构的所有有关成员。信息技术职员自身也会发出更多的事故警示。
级别较高的重要服务应该纳入业务连续性规划或者危机管理规划中。信息技术职员需要了解随时都可能执行的应变计划、联系人和需要采取哪些紧急行动。由于机构内部其他部门的原因引致业务连续性失效时，则可能会对本地信息技术设施提出更高的要求。这种情况在规划里面显然是难以体现的。
重大事故的焦点在于恢复—— 要找出事故的最原始起因，使我们不得不等待足够资源来确定事故的优先级并开始着手事故处置。
5.1.6 复杂的情境
实际生活中无数的事情会出错。哪怕我们汇编了一套本机构详尽的构件、设施、系统和工具的“清洗清单”，到了最后除了这张非常之长的清单之外我们还是会面对各种不同的失败。究其原因是这种编制清单的办法对于训练或规划来说并不总是那么有效。比较简单的方法是研究四五个可能会同时发生的情境的完整案例。在训练设置上，职员团队需要了解所有的情境来确定他们需要采取哪些行动。这些行动又可以同时与那些不协调的、不知道是不是包括在应急规划里的措施进行比对分析。
考虑到影响不同的业务部门、不同的业务机制，各种情境的分布可能会很极端，从很小到巨大都会存在。作为危机管理团队的成员，业务连续性团队和信息技术连续性团队可以为测试过程创建更多的新情境。即便如此，我们也不能期望实际发生的灾难同我们预备的所有情境相匹配。但我们至少可以针对这种交互型的要求，根据影响的不同做相应的准备。
京ICP备06004481号 Copyright 2002 - 2006 ITGov.org.cn, All Rights Reserved