描述
开 本: 16开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787302430384
姚强，华北电力学院计算机及其应用专业92届毕业生，DRII认证业务连续性专家（认证号：10180），曾服务于IBM、EMC、 SUN（ORACLE）、CENTRIN、TEAMSUN等多家知名企业，曾在中国民生银行、中国国航、中国银联、苏格兰皇家银行、广州电信等企业的IT服务连续性项目中担任首席咨询顾问，多年来以“促进国内数据中心少停机、少丢数、少花钱”为使命，坚守在数据中心线，坚定不移地致力于IT服务连续性理论及国际*实践的研究、引进和推广工作，开创性地建立了IT服务连续性知识体系。
前 言
在本书出版之际，感谢IBM、EMC、SUN、Centrin、Teamsun公司，他们给了我在书卷中感悟的时间，也给了我在实践中成长的机会。感谢我的家人，在无数个日子里，他们默默地奉献着，给予了我良好的写作环境。
特别感谢在我职业生涯中的关键人物——柏睿数据RapidsDB总裁刘睿民先生。
谨以此书作为礼物献给她/他们。
本书目标
本书的目标是：补好“IT服务连续性”这块短板，培养IT服务连续性领域的人才，帮助国内数据中心实现“少停机、少丢数、少花钱”的夙愿。
写作背景
作为一名长期奋战在数据中心建设前线的BC/DR（业务连续/灾难恢复）咨询顾问，我对IT服务中断事件感触颇深。在EMC工作期间，有一次我和西南某省电信公司数据中心老总一块儿用餐，他说：“在过去一年里，我们宕机了一百多次。”有一次我为SUN公司做全国巡回讲演，深圳会场到场的一位数据中心生产运营总经理告诉我：“我们前几年花了6个亿建灾备系统，但现在心里一点底儿也没有，真发生灾难时根本不敢切换。”凡此种种，举不胜举。了解数据中心运维的人士都知道，他们对IT服务连续性的无奈，正是中国数十万个数据中心的缩影。
每一次亲自经历或从媒体得知某个数据中心长时间宕机或恢复失败的事情，我都不禁扪心自问：“作为职业的BC/DR咨询顾问，不应该对此承担些责任吗？怎样为千疮百孔的IT服务连续领域提供些正能量呢？”
2007年春天，IT服务连续性概念在国内刚刚萌芽，我已踏入IT行业19个年头，从事全职BC/DR咨询工作达4年之久。之前，我有幸与美国、新加坡的DRII（国际容灾协会）专家一起工作数月之久，并获得了DRII美国总部颁发的业务连续性专家认证。这一年春天，我做了一个现在看来是不知天高地厚的决定：梳理出IT服务连续性领域的方法论和实践并呈现给社会。这个决定，让我踏上了一条充满荆棘与坎坷的、漫长的写作 之路。
写作过程
从2007年初到2015年底，本书历时8年完成。
8年间，我一直站在IT服务连续性建设的线，主导了数个大中型IT服务连续性项目的建设，经历了将DRII Practice、BCI BS25999、COBIT、ITIL、ISACA审计规范、ISO17799、TOGAF、SS507等国际实践及规范与IT服务连续性建设融会贯通的过程，经历了从感性上升到理性，再用理论指导实践的过程，经历了无数次重构和修改书稿的 过程。
8年间，我曾面对各种类型的企业和企业文化，面对各类IT人员五花八门的视角和看法（100个人对一个IT服务连续性术语会有100种理解），目睹了IT服务连续性领域的野蛮生长及种种乱象，众口难调的巨大阻力让我数次停笔。而在一次次目睹IT人员对IT服务连续性方法论与实践渴望而不可得的情景之后，我又一次次拾起自己的初衷。
8年间，我曾不断地告诫自己：“基于国际实践、符合演绎推理或归纳推理、经得起实践检验的知识是能站得住脚的，我一定要把理性的梳理结果呈现给社会”。在这个信念的支撑下，我终于走过了漫长而艰辛的写作之旅。
本书的时代特征
可喜的是，本书生逢其时。在本书出版之际，IT服务连续性相关的外部环境体现为两大特征。
首先，“业务连续性（Business Continuity，BC）”被引爆。业务连续性成了国计民生行业热门的话题之一，国内监管机构陆续颁布了多个业务连续性法规，以业务连续性为主题的论坛和会议层出不穷，业务连续性管理（BCM）逐渐成为企业董事会议上例行谈论的话题，各企业纷纷着手业务连续性管理体系建设，国计民生企业纷纷高薪设立了BCM经理职位，业务连续性领域的市场需求呈现出飞跃式扩大的趋势，业务连续性咨询服务业发展成为一个热门的行业，专门提供业务连续性咨询服务的商业机构不断涌现，业务连续性咨询顾问已成为令人羡慕的高薪职业。从主流搜索引擎搜索“BCM”或“业务连续性”，搜索结果的数量足以见证以上事实的火爆。
其次，“IT服务连续性”被业务连续性引爆。随着IT渗透到人们生活和生产的每个角落，IT服务对业务的支撑作用越来越明显，IT服务中断造成的业务影响越来越严重，IT服务的连续性引起了监管机构、媒体、社会大众的高度关注，“IT服务连续性”成了数据中心人士尽人皆知的术语。几乎所有的数据中心，尤其是银行、证券、保险、海关、税务、电信、民航、电力、铁路等国计民生行业的数据中心，毫无歧义地把“少停机，少丢数”当作一个极其重要的运营目标。为了实现以上运营目标，国内各数据中心如火如荼地开展着IT应急处置机制建设或完善活动。
本书致力于解决的问题
很多数据中心在IT应急处置机制建设方面的投资巨大，但IT系统仍然频繁宕机、系统恢复时间仍然频繁超标。“重技术、轻管理”只是表面原因，切实可行的IT服务连续性活动框架的严重缺乏，才是问题的症结所在，“巧妇难为无米之炊”才是IT人员的真实 写照。
本书致力于解决国内数据中心在IT应急处置机制建设和管理过程中普遍遇到的、迫切的以下几个问题：
数据中心的“业务”是IT服务相关的需求分析、规划设计、采购实施、交付与支持、控制改进等过程，数据中心的“业务”有其自身的鲜明的特点，当今的业务连续性方法论和实践对数据中心“业务”的连续性只能提供高层次的指导，并不能提供实现数据中心“业务”连续性所需要的详细的IT服务连续性活动框架。
缺乏整个企业范围内的“IT事件应急处置行动框架”，导致数据中心IT应急处置行动与企业其他条线的IT事件应急处置行动难以协调联动，往往衔接不畅。
缺乏系统化的“IT应急处置机制开发活动框架”，导致数据中心在IT应急处置机制建设阶段无法从实现IT服务连续性这个总体目标出发去进行IT服务连续性总体需求分析、总体规划设计，而是各自独立地开展IT应急响应机制建设、灾难恢复机制建设、高可用恢复机制建设，导致这些机制之间往往衔接不畅。
缺乏“IT服务连续性管理活动框架”，再加上IT应急处置机制的复杂性及日新月异的IT环境，导致IT应急处置机制投产后可能会随时失效或处于IT服务连续性能力不可确定的状态，终结果是IT高级管理人员对IT服务连续性能力缺乏信心，甚至巨大的IT投资付诸流水。
由于以上IT服务连续性活动框架（由IT事件应急处置行动框架、IT应急处置机制开发活动框架和IT服务连续性管理活动框架组成）的缺失，导致数据中心难以完整地、明确地定义IT服务连续性团队、角色和职责，难以体现 “谁主管谁负责”的原则，导致“人人有责，人人都不负责”，终结果是隐患不断、乱象丛生。
在IT服务连续性内审方面，由于缺乏对IT服务连续性活动框架的整体认识，IT内审人员难以全面把握关键审核事项，导致IT服务连续性治理的薄弱。
第5章 IT应急处置机制开发过程
在IT条线，IT应急处置机制从无到有，IT人员经历了怎样的开发过程呢？
本章将详细阐述“IT应急处置机制开发活动框架”，该框架以实现IT服务连续性需求为目标和导向，涵盖IT服务连续性有关的需求分析、规划设计、实施、预案开发与演练等活动，该框架的用途是为数据中心开展IT应急处置机制建设提供切实可行的、系统化的方法论，解决数据中心IT应急响应机制、灾难恢复机制、高可用恢复机制之间衔接不畅的 问题。
5.1 IT应急处置机制开发活动框架
当前，国内外普遍遵循DRII的业务连续性实践（The DRII Professional Practices for Business Continuity）开展IT应急处置机制开发活动。 DRII业务连续性实践主要阐述了业务连续性机制开发阶段所涉及的以下10项活动。
（1）Program Initiation and Management（业务连续性项目立项与管理）。
（2）Risk Evaluation and Control（风险评估与控制）。
（3）Business Impact Analysis（业务影响分析）。
（4）Business Continuity Strategies（业务连续性策略开发）。
（5）Emergency Response and Operations（应急响应预案开发）。
（6）Plan Implementation and Documentation（业务连续性预案开发）。
（7）Awareness and Training Programs（业务连续性意识培养与培训）。
（8）Business Continuity Plan Exercise， Audit and Maintenance（预案的演练、审计与维护）。
（9）Crisis Communications（危机攻关计划开发）。
（10）Coordination with External Agencies（外部协作计划开发）。
IT应急处置机制是直接支撑数据中心“业务”连续性的机制，数据中心的“业务”是IT服务相关的需求分析、规划设计、采购实施、交付与支持、控制改进等过程，数据中心的“业务”有其自身的鲜明的特点，DRII业务连续性实践对数据中心“业务”的连续性只能提供高层次的指导，并不能提供详细的IT应急处置机制开发活动框架。
本书基于DRII实践，制定IT应急处置机制开发活动框架，如图5-1所示。
在图5-1中，各个活动体现在不同的IT应急处置机制开发项目中，IT应急处置机制开发项目包括IT应急处置机制主体建设项目和后续持续更新项目，IT应急处置机制主体建设项目通常包括IT应急处置机制规划项目、IT应急响应机制建设项目、高可用恢复机制建设项目、灾难恢复机制建设项目，后续持续更新项目包括大大小小的IT应急处置机制完善项目。
图5-1 IT应急处置机制开发活动框架
下面，详细阐述IT应急处置机制开发活动框架中的各项活动。
5.2 风险分析
风险分析（Risk Analysis，RA）也叫风险评估，在本书中专指在IT应急处置机制开发项目中的风险分析活动。
RA的目的是评估IT应急处置机制需要应对的风险，包括生产系统高可用风险分析和生产系统灾难性风险分析。生产系统高可用风险分析是指分析生产系统各组件在高可用备份资源、高可用恢复手册、高可用恢复团队三方面存在的缺陷或不足，生产系统高可用风险分析结果用于确定高可用恢复机制的建设内容。生产系统灾难性风险分析是指分析可能造成生产系统灾难的威胁源，生产系统灾难性风险分析结果用于灾难恢复策略开发，例如，如果存在影响范围可波及整个城市的灾难，则需要建设异地灾备中心。
RA识别的风险在生产系统IT风险框架中的定位如图5-2所示。
识别生产系统IT风险框架中的所有IT风险，通常是数据中心IT风险管理人员的日常职责。RA活动需要基于IT风险管理人员日常的风险分析结果，完善并强化生产系统高可用风险分析工作和生产系统灾难性风险分析工作。
通常应在IT应急处置机制规划项目中开展RA活动。
国内的RA实践可谓五花八门，生产系统的安全性风险、可靠性风险、性能和容量风险、ITSM流程风险等都曾被纳入RA的范围，这些都是典型的RA误区。实际上，以上风险的评估工作是数据中心IT风险管理人员的日常职责，而不是IT应急处置机制开发项目中需要开展的RA活动。
图5-2 生产系统IT风险框架
RA活动主要包括以下任务。
（1）确定需要分析的生产系统组件。
（2）开发风险检查项列表。
（3）调查与访谈。
（4）确定可能的风险。
（5）分析风险的可能性和风险的影响。
（6）编写《RA报告》。
在RA任务中，“开发风险检查项列表”是重要的任务环节，为此，本书提供一个基本的生产系统高可用风险检查列表库（参见“附录A”）和一个生产系统灾难性风险检查项列表，如表5-1所示，供读者补充完善。
天有不测风云，在分析生产系统灾难性风险时，不可能覆盖生产系统可能面临的所有灾难性威胁源。例如，不可控的IT管理漏洞或技术漏洞、不可预知的人为或自然环境因素都可能是灾难性威胁源，但无法对它们进行评估。
表5-1 生产系统灾难性风险检查项
续表
5.3 业务影响分析
业务影响分析（Business Impact Analysis，BIA），BIA的目的是“通过分析业务之间的关系和业务中断影响，确定重要业务、业务恢复时间指标和业务恢复顺序”。
企业层面、业务条线、IT条线有不同的“业务”，企业层面的“业务”是完成企业目标和履行企业使命，企业使命包括社会使命、政治使命、企业对股东与投资者的使命、企业对员工的使命、企业对合作伙伴的使命、监管遵从等；业务条线的“业务”指的是在企业产品的设计过程、采购过程、生产过程、仓储过程、销售过程、售后服务过程等；IT条线的“业务”指的是IT服务的规划设计过程、采购实施过程、交付与支持过程、控制与改进过程等。
企业层面、业务条线和IT条线都需要根据自己的“业务”开展各自的BIA活动。企业层面BIA结果是业务条线BIA的输入，业务条线BIA结果是IT条线BIA的输入，企业层面BIA活动的滞后会严重影响业务条线的BIA活动，企业层面BIA活动或业务条线BIA活动的滞后都会严重影响IT条线的BIA活动。
1）企业层面的BIA活动针对企业层面的“业务”，代表企业的诉求，通常由企业层面的业务连续性管理组织或企业风险管理部门负责。企业层面BIA活动的主要任务包括以下几点。
（1）按照“企业目标”定义“关键业务指标”。
（2）为了避免企业生存危机，为了满足法规对业务恢复时间的要求，为了避免过渡的灾备投资，确定企业在灾难情况下可容忍的长的业务全面中断时间。
2）业务条线的BIA活动针对业务条线的“业务”，由业务条线的业务运营连续性管理团队负责，主要任务包括以下几点。
（1）获取企业层面的BIA结果。
（2）分析业务功能的行业关联性。行业关联性是指由于业务功能中断导致行业内其他机构无法开展特定业务，造成连锁反应，进而影响整个行业稳定的情景。
（3）分析业务功能之间的依赖关系，确定业务流程之间的恢复次序。
（4）分析各业务功能中断在各时间梯度对关键业务指标的影响。
（5）分析各业务功能的业务数据丢失在各时间梯度对关键业务指标的影响。
（6）分析业务数据丢失时人工补录数据的可行性，分析人工补录数据时间与业务数据丢失时间的关系。
（7）定义重要业务，即某属性不正常时会对关键业务指标造成不可接受的影响的业务。
（8）定义灾难情景下重要业务的恢复时间指标（业务灾难RTO）。
（9）定义灾难情景下重要业务的恢复时间点指标（业务灾难RPO）。
IT条线的BIA活动针对IT条线的“业务”，由IT条线的IT服务连续性管理团队负责，其目标是定义重要应用系统、定义信息系统灾难RTO、定义信息系统灾难RPO和定义重要信息系统的恢复批次与顺序。IT条线BIA活动的主要任务如下。
（1）获取企业层面、业务条线的BIA结果。
（2）IT关联性分析。
（3）应用系统中断影响分析。
（4）定义重要应用系统。
（5）定义信息系统灾难恢复时间指标（信息系统灾难RTO）。
（6）定义信息系统灾难恢复时间点指标（信息系统灾难RPO）。
（7）定义重要信息系统的恢复批次与顺序。
（8）编写《BIA报告》。
IT条线通常应在IT应急处置机制规划项目中开展BIA活动。
下面，详细阐述IT条线的BIA任务。
5.3.1 获取企业层面和业务条线的BIA结果
企业层面的BIA结果主要包括关键业务指标、企业在灾难情况下可容忍的长的业务全面中断时间。业务条线的BIA结果主要包括重要业务列表、业务灾难RTO、业务灾难RPO、业务流程之间的恢复次序。企业层面的BIA结果和业务条线的BIA结果是IT条线定义重要信息系统、定义信息系统灾难RTO、定义信息系统灾难RPO的依据。
IT条线通常在IT应急处置机制规划项目或灾难恢复机制建设项目的初期获取企业层面和业务条线的BIA结果，此时，会经常遇到以下2个问题。
（1）企业的业务连续性管理体系建设往往滞后于IT条线的IT应急处置机制建设项目，企业层面和业务层面的业务连续性管理组织往往还未设立，企业层面和业务层面从未自上而下地开展BIA活动，根本不存在企业层面或业务条线的BIA结果。
（2）业务条线往往不区分灾难事件下重要业务的恢复时间指标、非灾难事件下重要业务的恢复时间指标，只是基于以往的IT高可用恢复时的业务恢复时间定义一个非常短暂的“业务灾难RTO”。在灾难事件下，该“业务灾难RTO”根本难以实现。
面对以上问题，IT条线在执行BIA活动时只能根据企业文化选择自上而下的方式或自下而上的方式，下面将详细介绍这2种方式。
5.3.2 IT关联性分析
IT关联性分析的目的包括以下几点。
（1）通过自上而下地梳理业务、IT服务、IT应用系统、IT基础设施的映射关系，为下一步的“应用系统影响分析”提供基础信息。
（2）分析应用系统启停顺序。
（3）分析应用系统之间的物理关联关系，为定义切换单元提供基础信息。
（4）分析哪些应用系统是紧耦合应用系统，为确定生产系统布局提供基础信息。
IT系统之间的逻辑访问层次众多、数据访问关系错综复杂。为了避免过度分析，应该从IT条线BIA活动的目标出发，只开展实现这些目标必须的关联性分析活动。IT关联性分析活动框架如表5-2所示。
IT关联性分析结果通常汇总为《IT关联性分析报告》。
表5-2 IT关联性分析活动框架
5.3.3 应用系统影响分析
应用系统影响分析是指分析应用系统停止运行时和应用系统数据丢失时对关键业务指标的影响。应用系统影响分析的结果将作为定义重要应用系统、定义灾难恢复能力等级的重要基础信息。
应用系统影响分析包括以下4个步骤。
1．确定应用系统分析范围
当IT条线能够获取业务条线BIA结果时，首先基于重要业务列表、业务与IT服务映射关系表，列出支撑重要业务的IT服务。然后，基于IT服务与应用系统映射关系表，列出支撑以上IT服务的应用系统，将这些应用系统列入分析范围。
当IT条线不能够获取业务条线BIA结果时，将所有应用系统列入分析范围。
2．确定“关键业务指标”
首先从企业层面的BIA结果中获取“关键业务指标”。当IT条线不能从企业层面的BIA结果中获取“关键业务指标”时，与业务运营管理部门沟通，定义“关键业务指标”，并获得企业层面的业务连续性管理组织的认可。
3．分析应用系统停止运行时在不同时间梯度对关键业务指标的影响
分析路径如图5-3所示。首先分析应用系统停止运行对所支撑的IT服务的各个属性的影响，然后分析受影响的IT服务对所支撑的业务的各个属性的影响，后分析受影响的业务对关键业务指标的影响。
分析过程中采用的时间梯度包括应用系统通常的高可用恢复时间、紧急采购部署应用系统所花费的时间。
4．分析应用系统数据丢失在不同时间梯度对关键业务指标的影响
分析路径如图5-3所示。首先分析应用系统数据丢失时对所支撑的IT服务的各个属性的影响，然后分析受影响的IT服务对所支撑的业务的各个属性的影响，后分析受影响的业务对关键业务指标的影响。
分析过程中采用的时间梯度包括数据异步复制时数据可能丢失的时间（通常是几秒到几分钟）、磁带每日增量备份时数据的丢失时间（通常是24h）。
图5-3 应用系统影响分析路径
5.3.4 定义重要信息系统
根据5.3.3节“应用系统影响分析”的结果，将停止运行后对关键业务指标造成明显负面影响的应用系统定义为重要应用系统。
将支撑重要应用系统的网络、网络基础服务系统、信息安全系统、运行监控系统定义为重要IT基础设施。
重要信息系统包括重要应用系统和重要IT基础设施。
获得企业层面的业务连续性管理组织和业务运营管理部门对重要应用系统的共识。
5.3.5 定义重要信息系统的启停顺序
首先，根据IT关联性分析时生成的“应用系统启停顺序列表”，确定重要应用系统之间的启停顺序。
然后，根据重要信息系统之间的层次支撑关系确定重要信息系统的启停顺序，即“启动时启动网络、第二启动网络基础服务系统、第三启动信息安全系统、第四启动重要应用系统，停止时停止重要应用系统、第二停止信息安全系统、第三停止网络基础服务系统、第四停止网络”。
5.3.6 定义信息系统灾难RTO
定义信息系统灾难RTO的基本原则以下有两点。
其一，灾备的目的是避免企业生存危机和满足合规性需求，灾备相当于为企业上保险，而不是为了获取更大收益。灾难发生概率极低，启用灾备系统的概率也很低，灾备系统属于低投资低回报类资产。所以，灾备投资的原则是满足灾备目的即可，而不是尽力缩短灾难恢复时间指标。过短的灾难恢复时间指标将造成过高的灾备投资，严重违背灾备投资原则。
其二，除了自然灾害会导致灾难，不可控的IT管理或技术漏洞也会导致灾难。在这灾难下，人们应该以相同的灾备目的（即实现企业在灾难下的生存能力、满足合规性需求）去判断可以忍受的业务运营中断时间，而不应该对IT管理或技术漏洞导致的灾难提出苛刻的恢复时间要求。
定义信息系统灾难RTO可分为两种方式。如果业务条线已经规范地定义了灾难情景下业务的恢复时间指标，则IT条线可采用自上而下的方式定义信息系统的灾难RTO。如果业务条线没有定义灾难情景下业务的恢复时间指标，企业层面也没有定义灾难情况下企业可容忍的长业务全面中断时间，则IT条线只能采用自下而上的方式定义信息系统灾难RTO。下面分别介绍这两种方式下定义信息系统灾难RTO的步骤。
1．采用自上而下方式定义信息系统灾难RTO的步骤
（1）获取业务条线定义的灾难情景下各业务的恢复时间指标。
（2）确定各业务所依赖的应用系统群。
（3）确定各业务所依赖的应用系统群的灾难恢复时间指标。
这里提供一个计算公式作为参考,“某业务所依赖的应用系统的灾难恢复时间指标 = 灾难情景下该业务的恢复时间指标-该业务数据完整性检查时间-该业务功能验证时间”。
（4）根据相关法规对信息系统灾难RTO的要求、企业对信息系统灾难RTO领先性的诉求等，调整信息系统灾难RTO的值。
（5）取得业务运营管理部门、企业层面业务连续性管理组织对信息系统灾难RTO的共识。
2．采用自下而上方式定义灾难RTO的步骤
（1）向企业层面的业务连续性管理组织提请需求，促成企业层面定义“灾难情况下企业可容忍的长业务全面中断时间”。该时间减去业务数据完整性检查时间和业务验证时间，即为信息系统灾难RTO。
（2）IT条线参考相关法规对业务恢复时间指标和信息系统灾难RTO的要求，自行定义信息系统灾难RTO。
（3）取得业务运营管理部门、企业层面业务连续性管理组织对信息系统灾难RTO的共识。
5.3.7 定义信息系统灾难RPO
IT条线定义灾难RPO分为2种方式。如果业务条线已经规范地定义了灾难情景下业务的恢复时间点指标，则IT条线可采用自上而下的方式定义信息系统的灾难RPO；如果业务条线没有定义灾难情景下业务的恢复时间点指标，则IT条线只能采用自下而上的方式定义信息系统灾难RPO。下面详细介绍2种方式下定义信息系统灾难RPO的步骤。
1．采用自上而下的方式定义信息系统灾难RPO的步骤
（1）获取业务条线定义的灾难情景下业务的恢复时间指标。
（2）对于某个业务，根据“业务功能与承载其业务数据的应用系统的映射关系列表”确定承载该业务的业务数据的应用系统群。
（3）定义应用系统群的RPO，即灾难情景下该业务的恢复时间指标。
（4）根据相关法规对信息系统灾难RPO的要求、企业对信息系统灾难RPO领先性的诉求等，优化信息系统灾难RPO的值。
（5）取得业务运营管理部门、企业层面业务连续性管理组织对信息系统灾难RPO的认可。
2．自下而上定义灾难RPO的步骤
（1）对于某个业务功能，根据“业务功能与承载其业务数据的应用系统的映射关系列表”确定需要分析的应用系统。
（2）对于某个应用系统，根据“应用系统数据丢失对关键业务指标的影响”，再根据信息系统灾难RPO的定义原则“业务数据丢失时间对关键业务指标的影响必须忽略不计”，确定该信息系统灾难RPO。
（3）根据相关法规对信息系统灾难RPO的要求、企业对信息系统灾难RPO领先性的诉求等，优化信息系统灾难RPO的值。
（4）取得业务运营管理部门、企业层面业务连续性管理组织对信息系统灾难RPO的认可。
5.4 IT应急处置策略开发
IT应急处置策略开发的目的是标识IT应急处置机制的建设范围、建设指标和建设途径，为下一步的IT应急处置机制设计与实施提供高层次的需求和指引。
IT应急处置策略开发需要将《RA报告》和《BIA报告》作为输入，其开发活动框架如图5-4所示。
图5-4 IT应急处置策略开发活动框架
下面，详细阐述各项策略开发活动。
5.4.1 IT应急响应策略开发
IT应急响应策略开发的目的是标识出IT应急响应机制建设涉及的资源和主要活动，为下一步的IT应急响应机制建设立项、方案设计等活动提供高层次需求和指引。
IT应急响应策略开发过程如下所述。
1．定义IT事件级别
定义IT事件的级别需要基于以下4个因素。
（1）受到损害的IT资源的重要性级别。
（2）受到影响的IT服务的重要性级别。
（3）受到影响的业务的重要性级别和范围大小。
（4）是否存在IT人员伤害。
表5-3提供一个IT事件分级的方法，供读者参考。
表5-3 IT事件分级方法
2．定义IT应急响应团队及角色职责
详见“4.1.1 IT应急响应机制”。
3．定义IT应急响应行动完成时间指标
定义IT应急响应行动完成时间指标的原则包括以下几点。
（1）尽可能实现快速响应。
（2）在灾难发生时确保满足重要信息系统灾难RTO。
对于较大IT事件和一般IT事件，IT条线可自行设立IT应急响应行动完成时间指标，时间指标包括以下几点。
（1）IT应急响应行动总体完成时间。
（2）IT事件预警完成时间。
（3）IT损害控制完成时间。
（4）IT损害评估完成时间。
（5）决策IT恢复事项完成时间。
对于重大IT事件，需要统筹考虑企业各条线的重大IT事件应急响应行动完成时间，如表5-4所示。
表5-4 企业各条线重大IT事件应急响应行动完成时间
4．定义IT应急响应行动所需要的资源及资源获取方式
IT应急响应行动通常需要的资源及资源获取方式如表5-5所示意。
表5-5 IT应急响应行动需要的资源及资源获取方式
5．定义IT应急响应机制建设项目
IT应急响应机制建设项目包括IT应急响应设施建设项目和IT应急响应预案开发项目。在高可用恢复机制建设和灾难恢复机制建设之前，应尽量完成IT应急响应机制建设。
6．编写《IT应急响应策略开发报告》
5.4.2 高可用恢复策略开发
高可用恢复策略开发的目的是标识高可用恢复机制的建设范围，为下一步的高可用恢复机制设计与实施提供高层次的需求和指引。
高可用恢复策略开发过程如下。
1．确定本地高可用备份方式
本地高可用备份方式主要包括NULL、本地冷备、本地热备、本地双活、本地多活等。确定本地高可用备份方式的过程包括以下几点。
1）借助IT条线BIA活动中的应用系统影响分析结果，分析并确定主IT系统中断后的业务损失。
2）确定当前主IT系统在服务时段内的服务可用率。
可根据设备实际的服务可用率、专业机构统计的设备可用性指标、设备厂家标注的设备可用性指标估算。
3）确定可选的本地高可用备份系统，估算各本地高可用备份系统在生命周期内的成本。可选的本地高可用备份系统主要包括冷备系统、热备系统、双活系统和多活系统。
4）针对每种可选的本地高可用备份系统，执行成本效益分析（Cost Benefit Analysis，CBA），将成本收益率（Benefit Cost Ratio，BCR）的值且大于1的高可用备份系统作为。BCR计算过程如下。
（1）计算在单机配置下、单位时间内主IT系统停机所造成的损失。计算公式为：Cost=财务损失 非财务损失。
（2）计算采用高可用备份系统后年度平均可缩短的停机时间。计算公式为：SavedTime=可缩短的计划内停机时间 可缩短的计划外停机时间。
（3）计算高可用备份系统的服务年限ServiceYear。
（4）计算在服务年限内高可用备份系统因缩短停机时间而增加的收益。计算公式为：TotalBenefit = ServiceYear×SavedTime×Cost。
（5）计算高可用备份系统在其生命周期内的总体成本。计算公式为：Totalcost=高可用备份系统建设成本 ServiceYear×高可用备份系统年度平均维护费用。
（6）计算高可用备份系统的成本收益率BCR。计算公式为：BCR= TotalBenefit / Totalcost。
2．确定同城高可用备份策略
如果企业的灾难恢复机制采用了同城灾备中心、同城一体化网络技术和同城同步数据复制技术，则应考虑借助同城灾备系统实现重要信息系统的同城高可用备份，以应对“本地HA系统整体失效”的高可用风险。
实现以上策略，仅需很少的投资，但可实现同城灾备系统与同城高可用备份系统的融合，即“同城灾备中心的信息系统既是同城高可用备份系统又是同城灾难备份系统”。在某主IT系统及其本地高可用备份系统同时出现故障后，将此系统切换至同城灾备中心时，同城灾备中心的IT系统扮演了同城高可用备份系统的角色；在生产系统大面积失效后，将所有重要生产系统切换至同城灾备系统时，同城灾备中心的IT系统扮演了同城灾难备份系统的角色。
3．确定IT系统的高可用恢复时间指标
根据IT系统采用的本地高可用备份方式，确定IT系统的本地高可用恢复时间。根据所采用的同城高可用备份策略，确定IT系统的同城高可用恢复时间。将本地高可用恢复时间和同城高可用恢复时间中较长的一个定义为IT系统的高可用恢复时间指标。
4．定义高可用备份系统建设项目
5．编写《高可用恢复策略报告》
评论
还没有评论。