第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.*t1:chsdate>  获取企业层面和业务条线的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.*t1:chsdate>  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.*t1:chsdate> 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事件应急响应行动完成时间

	重大IT事件应急响应行*体完成时间
企业层面指标	重大IT事件预警响应的完成时间
	*重大IT事件后果的完成时间
	评估重大IT事件企业影响和社会影响的完成时间
	决策重大IT事件重大恢复事项的完成时间
	决策危机攻关事项的完成时间
IT条线指标	IT事件预警的完成时间
	IT损害控制的完成时间
	IT损害评估的完成时间
	决策IT恢复事项的完成时间
业务条线指标	业务运营中断事件预警的完成时间
	启用应急业务流程的完成时间
	评估业务影响的完成时间
	决策业务恢复事项的完成时间

4．定义IT应急响应行动所需要的资源及资源获取方式
IT应急响应行动通常需要的资源及资源获取方式如表5-5所示意。
表5-5  IT应急响应行动需要的资源及资源获取方式

IT应急响应资源类别		IT应急响应资源示例	获 取 方 式
IT应急响应 设施	IT事件预警设施	<、火、气、电的预警设施等	自建
	IT损害控制设施	机房防火灭火设施、机房紧急降温设施、机房防洪泄洪设施、人员疏散设施等	自建
	IT损害评估设施	IT故障快速定位系统	自建
	应急通信工具	短台、RTX、工单管理系统、自动通知系统、电话会议系统、卫星电话等	自建
	应急场地设施	ECC、避难所	自建、租赁、共享
IT应急响应 预案	部门级应急响应预案	I*体应急预案	自建、*
	先期处置专项预案	机房消防应急预案、机房异常高温应急预案、机房防洪应急预案、生产系统关闭及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．编写《高可用恢复策略报告》