《IT服务连续性实现指南》 - 姚强 - 清华大学出版社 - 香港大書城

	登入帳戶　 \|　訂單查詢　 \|　購物車/收銀台(0)　\|　在線留言板　 \|　付款方式　 \|　運費計算　 \|　聯絡我們　 \|　幫助中心　\|　加入書簽
		會員登入新用戶登記

HOME

新書上架

暢銷書架

好書推介

2023年度TOP

臺灣用戶

品種：超過100萬種各類書籍/音像和精品，正品正價，放心網購，悭钱省心

服務：香港／台灣／澳門／海外

送貨：速遞／郵局／服務站

新書上架：簡體書繁體書
暢銷書架：簡體書繁體書
好書推介：簡體書繁體書

『簡體書』IT服务连续性实现指南

書城自編碼： 2795513
分類：簡體書→大陸圖書→計算機/網絡→项目管理 IT人文
作者：姚强
國際書號(ISBN)： 9787302430384
出版社：清华大学出版社
出版日期： 2016-04-01
版次： 1 印次： 1
頁數/字數： 215/360
書度/開本： 16开釘裝：平装

售價：HK$ 58.5

我要買件

** 我創建的書架 **
未登入.

新書推薦：

《纷纭万端：近代中国的思想与社会》
售價：HK$ 109.8

《中国古代文体形态研究（第四版）（中华当代学术著作辑要）》
售價：HK$ 168.0

《朋党之争与北宋政治·大学问》
售價：HK$ 99.7

《甲骨文丛书·波斯的中古时代（1040-1797年）》
售價：HK$ 88.5

《以爱为名的支配》
售價：HK$ 62.7

《台风天（大吴作品，每一种生活都有被看见的意义）》
售價：HK$ 53.8

《打好你手里的牌（斯多葛主义+现代认知疗法，提升当代人的心理韧性！）》
售價：HK$ 66.1

《新时代硬道理广东寻路高质量发展》
售價：HK$ 77.3

建議一齊購買：

HK$ 67.5
《暗影行动1：末路狂奔》

HK$ 148.5
《浪潮之巅第三版上下册》

HK$ 83.3
《MacTalk 跨越边界》

HK$ 153.6
《商业银行业务连续性管理》

HK$ 251.6
《中国资源能源与可持续发展》

HK$ 72.2
《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人士。

內容簡介：

關於作者：

姚强，华北电力学院计算机及其应用专业92届毕业生，DRII认证业务连续性专家（认证号：10180），曾服务于IBM、EMC、 SUN（ORACLE）、CENTRIN、TEAMSUN等多家知名企业，曾在中国民生银行、中国国航、中国银联、苏格兰皇家银行、广州电信等企业的IT服务连续性项目中担任首席咨询顾问，多年来以促进国内数据中心少停机、少丢数、少花钱为使命，坚守在数据中心第一线，坚定不移地致力于IT服务连续性理论及国际最佳实践的研究、引进和推广工作，开创性地建立了IT服务连续性知识体系。

目录
第1章 IT服务剖析 1
1.1 IT服务 1
1.2 业务 3
1.3 IT资源 6
1.3.1 IT资源框架 6
1.3.2 应用系统 7
1.3.3 IT基础设施 10
1.3.4 IT资源的属性 10
1.3.5 IT资源属性与IT服务属性的映射关系 11
1.4 IT流程 12
1.5 IT组织 13
第2章 IT事件剖析 16
2.1 IT事件定义 16
2.2 IT事件前因 16
2.2.1 IT威胁源 17
2.2.2 IT威胁源消减措施 18
2.3 IT事件类别 19
2.4 IT事件后果 20
2.4.1 IT损害 20
2.4.2 IT事件影响 21
2.5 IT事件级别 23
2.6 IT服务连续性的意义 24
第3章 IT事件应对过程 26
3.1 IT事件闭环应对过程 26
3.2 IT事件防范 27
3.3 IT事件监测预测 27
3.4 IT事件应急处置 28
3.4.1 重大IT事件应急处置案例 28
3.4.2 IT事件应急处置行动框架 35
3.4.3 IT事件预警与预警响应 35
3.4.4 IT事件先期处置 39
3.4.5 IT事件后果评估 41
3.4.6 IT事件恢复决策 46
3.4.7 IT事件恢复 48
3.4.8 重大IT事件应急保障 52
3.5 重续运行 52
第4章 IT事件应急处置机制 55
4.1 IT应急处置机制 55
4.1.1 IT应急响应机制 56
4.1.2 高可用恢复机制 58
4.1.3 灾难恢复机制 61
4.2 企业层面IT事件应急处置机制 68
4.3 业务条线IT事件应急处置机制 71
第5章 IT应急处置机制开发过程 74
5.1 IT应急处置机制开发活动框架 74
5.2 风险分析 75
5.3 业务影响分析 77
5.3.1 获取企业层面和业务条线的BIA结果 78
5.3.2 IT关联性分析 78
5.3.3 应用系统影响分析 79
5.3.4 定义重要信息系统 80
5.3.5 定义重要信息系统的启停顺序 80
5.3.6 定义信息系统灾难RTO 81
5.3.7 定义信息系统灾难RPO 81
5.4 IT应急处置策略开发 82
5.4.1 IT应急响应策略开发 83
5.4.2 高可用恢复策略开发 85
5.4.3 灾难恢复策略开发 86
5.5 灾备中心选址 94
5.5.1 确定候选城市 94
5.5.2 初步筛选候选城市 94
5.5.3 比对并确定异地灾备中心所在城市 95
5.5.4 确定灾备中心的具体地址 96
5.6 IT应急处置资源设计 97
5.6.1 关键技术POC 98
5.6.2 生产环境改造设计 98
5.6.3 高可用备份系统设计 100
5.6.4 灾备系统设计 103
5.6.5 自动化灾备指挥与切换平台设计 115
5.6.6 IT应急指挥中心设计 116
5.7 IT应急处置资源实施 116
5.8 IT应急预案开发 118
5.8.1 IT总体应急预案开发 118
5.8.2 IT先期处置预案开发 120
5.8.3 高可用恢复手册开发 120
5.8.4 灾难恢复预案开发 121
5.8.5 其他条线的IT事件应急预案开发 122
5.9 应急演练 123
5.9.1 高可用备份系统切换演练 123
5.9.2 灾备演练 124
第6章 IT服务连续性管理过程 130
6.1 IT服务连续性管理活动框架 130
6.2 IT应急处置机制开发项目管理 131
6.2.1 管理活动 132
6.2.2 管理过程 137
6.2.3 管理角色与职责 138
6.3 IT应急处置资源运维管理 139
6.3.1 管理活动 139
6.3.2 管理过程 142
6.3.3 管理角色与职责 143
6.4 IT应急处置资源风险管理 143
6.4.1 管理活动 143
6.4.2 管理过程 150
6.4.3 管理角色与职责 152
6.5 IT应急处置机制就绪管理 152
6.5.1 管理活动 153
6.5.2 管理过程 156
6.5.3 管理角色与职责 158
6.6 IT应急处置机制持续更新管理 159
6.6.1 管理活动 159
6.6.2 管理过程 161
6.6.3 管理角色与职责 162
6.7 IT服务连续性绩效管理 162
6.7.1 管理活动 163
6.7.2 管理过程 170
6.7.3 管理角色与职责 171
6.8 IT服务连续性内部控制 172
6.8.1 管理活动 172
6.8.2 管理过程 175
6.8.3 管理角色与职责 177
第7章 IT服务连续性管理体系 178
7.1 IT服务连续性管理体系框架 178
7.2 IT服务连续性管理体系的边界环境 179
7.2.1 企业业务连续性管理体系 180
7.2.2 IT服务连续性内部审计机制 183
7.2.3 IT服务连续性法规 184
7.2.4 IT服务连续性SLA 185
7.2.5 IT服务连续性管理规范 185
7.3 IT服务连续性管理体系成熟度模型 186
第8章 IT服务连续性内审的关键审核事项 189
8.1 IT应急处置机制开发审计 189
8.1.1 IT应急响应机制开发审计 189
8.1.2 高可用恢复机制开发审计 191
8.1.3 灾难恢复机制开发审计 192
8.2 IT应急处置机制开发项目项目管理审计 198
8.3 IT应急处置资源运维管理审计 200
8.4 IT应急处置资源风险管理审计 201
8.5 IT应急处置机制就绪管理审计 202
8.6 IT应急响应与恢复行动审计 203
8.7 IT应急处置机制持续更新管理审计 203
8.8 IT服务连续性绩效管理审计 204
8.9 IT服务连续性内控审计 205
附录A 高可用风险检查列表库 207

內容試閱：

第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关联性分析活动框架

IT关联性分析活动

分析结果

分析业务与IT服务的映射关系

业务与IT服务映射关系表

分析IT服务与应用系统的映射关系

IT服务与应用系统映射关系表

分析应用系统与IT基础设施的映射关系

应用系统与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事件分级方法

IT事件后果

IT事件级别

一般IT事件

较大IT事件

重大IT事件

六级

五级

四级

三级

二级

一级

非重要信息系统损害

☆

☆

☆

非重要IT服务影响

☆

☆

非重要业务运营影响

小范围

☆

大范围

☆

重要信息系统损害

☆

☆

☆

重要IT服务影响

☆

☆

重要业务运营影响

小范围

☆

大范围

☆

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事件应急响应行动完成时间

总体指标

重大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应急响应
预案

部门级应急响应预案

IT总体应急预案

自建、外包

先期处置专项预案

机房消防应急预案、机房异常高温应急预案、机房防洪应急预案、生产系统关闭及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 = ServiceYearSavedTimeCost。
（5）计算高可用备份系统在其生命周期内的总体成本。计算公式为：Totalcost=高可用备份系统建设成本 ServiceYear高可用备份系统年度平均维护费用。
（6）计算高可用备份系统的成本收益率BCR。计算公式为：BCR= TotalBenefit Totalcost。
2．确定同城高可用备份策略
如果企业的灾难恢复机制采用了同城灾备中心、同城一体化网络技术和同城同步数据复制技术，则应考虑借助同城灾备系统实现重要信息系统的同城高可用备份，以应对本地HA系统整体失效的高可用风险。
实现以上策略，仅需很少的投资，但可实现同城灾备系统与同城高可用备份系统的融合，即同城灾备中心的信息系统既是同城高可用备份系统又是同城灾难备份系统。在某主IT系统及其本地高可用备份系统同时出现故障后，将此系统切换至同城灾备中心时，同城灾备中心的IT系统扮演了同城高可用备份系统的角色；在生产系统大面积失效后，将所有重要生产系统切换至同城灾备系统时，同城灾备中心的IT系统扮演了同城灾难备份系统的角色。
3．确定IT系统的高可用恢复时间指标
根据IT系统采用的本地高可用备份方式，确定IT系统的本地高可用恢复时间。根据所采用的同城高可用备份策略，确定IT系统的同城高可用恢复时间。将本地高可用恢复时间和同城高可用恢复时间中较长的一个定义为IT系统的高可用恢复时间指标。
4．定义高可用备份系统建设项目
5．编写《高可用恢复策略报告》

書城介紹　 \|　合作申請　\|　索要書目　 \|　新手入門　\|　聯絡方式　 \|　幫助中心　\|　找書說明　 \|　送貨方式　\|　付款方式	香港用户　 \|　台灣用户　\|　大陸用户　\|　海外用户

	megBook.com.hk
Copyright © 2013 - 2024 （香港）大書城有限公司　 All Rights Reserved.