20150803  淡然

目  录

[  /a/67.html#_Toc308166165]1.   概述[/url]

[  /a/67.html#_Toc308166166]1.1              目标[/url]

[  /a/67.html#_Toc308166167]1.2              范围[/url]

[  /a/67.html#_Toc308166168]1.3              术语定义表[/url]

                                                                                                        ITSS考试

[  /a/67.html#_Toc308166169]2.   角色和职责[/url]

[  /a/67.html#_Toc308166170]3.   相关要素定义[/url]

[  /a/67.html#_Toc308166171]3.1              业务影响度[/url]

[  /a/67.html#_Toc308166172]3.2              RPO、RTO和DOO[/url]

[  /a/67.html#_Toc308166173]3.3              风险级别[/url]

[  /a/67.html#_Toc308166174]4.   管理策略[/url]

[  /a/67.html#_Toc308166175]4.1              业务影响分析策略[/url]

[  /a/67.html#_Toc308166176]4.2              风险分析策略[/url]

[  /a/67.html#_Toc308166177]4.3              连续性管理计划策略[/url]

[  /a/67.html#_Toc308166178]5.   流程描述[/url]

[  /a/67.html#_Toc308166179]5.1              输入[/url]

[  /a/67.html#_Toc308166180]5.2              输出[/url]

[  /a/67.html#_Toc308166181]5.3              流程描述[/url]

[  /a/67.html#_Toc308166182]6.   流程质量控制[/url]

[  /a/67.html#_Toc308166183]7.   附件和表单[/url]

[  /a/67.html#_Toc308166184]8.   相关文件[/url]

1. 概述

1.1    目标

确保在灾难发生后，IT基础设施和IT服务能在规定的时间内得到恢复，从而支持公司业务连续性的要求。

1.2    范围

流程类型	描述
适用范围	某证券股份有限公司信息技术中心运营中心。
管理范围	1. 识别业务对IT服务的连续性要求； 2. 识别、评估及管理IT基础设施和IT服务所面临的风险、威胁及其对业务的影响； 3. 编制并测试、演练应急预案。

图表 1 范围

1.3    术语定义表

名词	定义
恢复时间目标(RTO) Recovery Time Objective	即灾难发生后，信息系统或业务功能从停顿到必须恢复的时间要求。
恢复点目标(RPO) Recovery Point Objective	即灾难发生后，系统和数据必须恢复到的时间点要求。
运行性能降低预期（DOO）Degraded Operations Objective	即灾难发生后，与灾难发生前相比运行处理能力的降低情况。

图表 2 术语定义表

2. 角色和职责[td]

角色	职责
运营中心 管理层	1.   负责本流程的审批； 2.   负责管理报告的审阅； 3.   负责对演练方案的审批。
连续性 经理	1.   负责本流程的推广、监督和改进，包括： 1)   负责本流程及附件文档的更新维护； 2)   设定本流程的绩效指标并衡量指标完成情况； 3)   回顾流程执行情况，编制连续性管理流程报告，反映存在的问题，提出改进建议，并制定改进计划。 2.   负责组织进行业务影响分析和风险分析； 3.   负责组织制定连续性策略； 4.   负责组织制定连续性管理计划； 5.   负责对连续性管理计划进行回顾。
连续性 管理员	1.   负责设计制定相应的应急预案； 2.   负责制定应急预案演练方案； 3.   负责对应急预案进行演练； 4.   负责通知相关方进行应急演练； 5.   负责对应急演练过程进行回顾。

图表 3 角色和职责

3. 相关要素定义

3.1    业务影响度

1）  业务影响度用于确定服务对业务所产生的影响，业务影响度分为五级，包括高、较高、中、较低、低五个级别。

2）  业务影响度的参考值由监管要求、业务系统两个因素决定，服务负责人根据参考值最终确定准确的业务影响度。业务影响度参考值的计算方法：

业务影响度得分=求整（（监管要求得分*20%+系统分类得分*80%）*5/4.6），具体如下表所述：

业务影响度 参考值	高	较高	中	较低	低
得分	5	4	3	2	1

图表 4 业务影响度参考值

a)        监管要求得分：

得分	监管要求
3	等级保护级别为3的或证监会明确要求中断时间在15分钟以上需要上报的系统。
2	等级保护级别为2的或证监会明确要求中断时间在2小时以上需要上报的系统。
1	等级保护级别为1的或证监会无明确要求的系统。                            ITSS认证

图表 5 监管机构要求

b)   系统分类得分：

得分	系统分类
5	实时交易系统，指直接向服务对象提供实时交易服务，实时性要求高，若中断将导致直接经济损失和重大社会影响的系统。包括集中交易、网上交易、电话委托、手机炒股等。
4	实时业务运作系统，指间接向服务对象提供交易服务，或关键业务运作依赖的系统。该系统若较长时间中断（大于30分钟）后将影响交易、资金划转，或导致正常业务停顿，直接或间接影响交易，可能产生较大社会影响。包括三方存管、基金等系统。
3	业务管理系统，指用于公司业务日常管理的系统。该系统若长时间中断（大于4小时）将影响业务管理，但不影响交易，不会产生外部影响。包括经纪人管理、营销系统等。
2	办公及后台管理系统，指公司日常非业务直接相关的管理系统和办公类系统。该系统若长时间中断（大于4小时）将影响使用部门的业务管理，但不影响交易，不会产生外部影响。包括投行、研究所、OA等。
1	其他辅助系统，指公司日常公司所需的辅助支持系统。该系统若长时间中断（大于4小时）将影响使用部门的日常管理，但可采取其他替代手段解决，不会产生外部影响。包括即时通讯系统、移动办公系统等。

图表 6 系统分类

3.2    RPO、RTO和DOO

业务影响度	RPO(恢复点目标)	RTO（恢复时间目标）	DOO（运行性能降低预期）
高	<1分钟	<15分钟	<20%
较高	<2小时	<30分钟	<20%
中	<4小时	<8小时	<50%
较低	<24小时	<24小时	<50%
低	<24小时	<48小时	<50%

图表 7 RPO\RTO\DOO

3.3    风险级别

风险的定级由相关信息安全风险评估工作确定。

4. 管理策略

根据业务影响度分析（BIA）和风险分析（RA）的结果，制定适合于某证券的连续性策略。连续性策略包括对应急预案的规划，以及连续性管理计划的要求。

4.1    业务影响分析策略

1)   业务影响度分析针对《服务目录》中的有系统支撑的服务，没有系统支撑的服务可以不做业务影响度分析。

2)   业务连续性经理每年组织相关人员进行业务影响度分析工作。

3)   新或变更的服务上线前，应对其进行业务影响分析和风险分析，根据分析的结果，回顾连续性策略并根据需要对连续性策略进行修订，之后根据连续性策略的要求制定新或变更服务的连续性管理计划。

4.2    风险分析策略

业务连续性经理每年组织相关人员对服务的连续性风险进行分析，该项工作可与信息安全风险评估结合开展。

4.3    连续性管理计划策略

1)  连续性管理计划包括应急预案规划、培训计划、应急预案回顾计划。

2) 应急预案的制定：

应为有系统支撑且业务影响度为中（及以上）且对某证券外部提供的服务制定应急预案，应对风险评估中识别出的高风险。

3)  应定期对应急预案涉及到的人员进行培训。

4)  应急预案的回顾：

a)   应急预案应进行主动回顾，主动回顾的形式有桌面推演、测试环境演练、生产环境演练：

l  桌面推演：桌面推演的参与者以走查的形式对应急预案排演而不实际进行恢复操作，桌面推演是最基本和最经济的；

l  测试环境演练：测试环境演练是在测试环境下对应急预案进行演练，相应的人员，包括供应商均采用应急预案中的人员；

l  生产环境演练：生产环境演练是在生产环境下对应急预案进行演练，相应的人员，包括供应商均采用应急预案中的人员。

b)   有系统支撑且业务影响度为高的服务应至少每年进行两次主动回顾，且回顾的方式只能采取生产环境演练。

c)   有系统支撑且业务影响度为较高或者中的服务应进行至少每年一次主动回顾，回顾方式不限。

d)   被动回顾由变更管理流程触发。

e)   当发生重大变更，包括应急预案中的人员发生变动时，应急预案应被重新回顾。

f)   回顾中如果发现预案存在问题，应通过变更管理流程预案进行修订。

5. 流程描述

5.1    输入

编号	输入项	来源	周期
1.	IT服务连续性要求	监管机构	发生时
2.	对IT服务连续性有影响的变更	变更管理流程	发生时

图表 8 输入

5.2    输出

编号	输出项	去向	周期
1.	业务影响度分析和风险评估报告	流程内部	发生时
2.	连续性管理计划	流程内部	每年
3.	演练报告	流程内部	发生时
4.	连续性管理报告	服务报告流程	每年

图表 9 输出

5.3    流程描述

图表 10 流程图

[td]

步骤	输入	步骤描述	输出
1.  收集连续性需求	监管要求； 业务需求；	连续性经理收集连续性需求，包括： 1.   由项目发起的新（或变更）服务的连续性需求； 2.   监管机构对业务连续性的要求； 3.   业务部门对业务连续性的需求。	业务连续性需求
2.  组织业务影响度分析和风险分析	收集到的连续性需求	连续性经理组织各系统管理员： 1.   根据现状和业务特点，分析IT服务中断对业务的影响程度; 2.   识别和分析IT服务中断的风险因素，分析风险发生的可能性和影响； 3.   根据各系统的业务影响程度确定其RTO、RPO及DOO。	《业务影响分析和风险评估报告》
3.  制定连续性策略	《业务影响分析和风险评估报告》	连续性经理每年根据IT系统对业务的影响程度以及IT系统面临的风险，制定连续性策略： 1.  明确连续性要求； 2.  明确连续性管理计划的范围； 3.  连续性策略设计和维护的原则； 4.  其他有关连续性管理的策略。	连续性策略
4.  制定/修订连续性管理计划	连续性策略	1.   连续性经理组织各职能部门制定连续性管理计划，包括： a)   应急预案规划 b)   培训计划 c)   预案回顾计划 2.   发生重大变更时，要修订连续性管理计划。	《连续性管理计划》
5.  审批连续性管理计划	《连续性管理计划》	1.  连续性管理计划由运营中心管理层进行审批； 2.  运营中心管理层根据连续性管理计划涉及的范围判断是否需要上级领导审批； 3.  审批通过的进入步骤6。	审批通过的《连续性管理计划》
6.  设计应急预案	《连续性管理计划》	1.  连续性管理员根据连续性管理计划中对应急预案的规划制定应急预案； 2.  应急预案包括灾难发生后的应急处置方式和恢复步骤； 3.  应急预案作为事件管理流程的输入，供事件处理时参考使用； 4.  新制定的应急预案应进行回顾，若采用演练的方式进行回顾，则进入步骤7；若采用其他方式进行回顾，则进入步骤11.	《应急预案》
7.  制定演练方案	《应急预案》	1.   连续性管理员制定职责范围内的演练方案； 2.   演练方案包括演练环境的准备、演练时间、演练人员等； 3.   跨部门的演练方案由连续性经理组织制定。	《演练报告》的演练方案部分
8.  审批演练方案	《演练报告》的演练方案部分	1.   连续性经理对各专业制定的演练方案进行审核； 2.   运营中心管理层对演练方案进行审批，并根据演练影响的范围判断是否需要其他部门或上级领导和单位进行审批; 3.   审批通过后，可按照演练方案执行演练； 4.   审批部通过的，由连续性管理员对演练方案进行修改。	审批意见
9.  通知相关方	《演练报告》的演练方案部分	通知演练相关方人员进行演练。	《演练报告》
10.执行演练	《演练报告》的演练方案部分	1.   连续性管理员按照审批通过的演练方案执行演练； 2.   涉及多个部门配合演练的，由连续性经理负责组织方案的演练; 3.   演练完成后应形成演练报告，并报连续性经理和运营中心管理层。	《演练报告》
11.回顾连续性管理计划	变更情况报告	1.  业务影响度三级及以上的系统至少每年对连续性管理计划进行两次回顾； 2.  采用评审方式进行回顾的，应形成会议纪要； 3.  回顾过程中若对测试环境和生产环境造成影响，应按照变更发布管理流程执行； 4.  采用演练方式进行回顾的，演练前按照步骤8制定演练方案，演练后形成《演练报告》； 5.  连续性经理每年对连续性管理流程的执行情况进行总体回顾，形成《连续性管理报告》。	《演练报告》 《连续性管理报告》
12.连续性管理计划回顾	《连续性管理计划》 《演练报告》	连续性经理根据培训结果、演练结果，更新《连续性管理计划》。	回顾后的《连续性管理计划》

图表 11 流程描述

6. 流程质量控制

连续性经理按照PDCA持续改进的方法对本流程改进，连续性经理对本流程及其执行情况进行回顾，分析流程执行的效果。在回顾中识别出的改进事项按照服务改进流程的要求进行跟踪，或以其他可审计的方式记录改进情况。                    ITSS培训

7. 相关文件

无

本帖关键字：ITSS

20150803  淡然

目  录

[  /a/67.html#_Toc308166165]1.   概述[/url]

[  /a/67.html#_Toc308166166]1.1              目标[/url]

[  /a/67.html#_Toc308166167]1.2              范围[/url]

[  /a/67.html#_Toc308166168]1.3              术语定义表[/url]

                                                                                                        ITSS考试

[  /a/67.html#_Toc308166169]2.   角色和职责[/url]

[  /a/67.html#_Toc308166170]3.   相关要素定义[/url]

[  /a/67.html#_Toc308166171]3.1              业务影响度[/url]

[  /a/67.html#_Toc308166172]3.2              RPO、RTO和DOO[/url]

[  /a/67.html#_Toc308166173]3.3              风险级别[/url]

[  /a/67.html#_Toc308166174]4.   管理策略[/url]

[  /a/67.html#_Toc308166175]4.1              业务影响分析策略[/url]

[  /a/67.html#_Toc308166176]4.2              风险分析策略[/url]

[  /a/67.html#_Toc308166177]4.3              连续性管理计划策略[/url]

[  /a/67.html#_Toc308166178]5.   流程描述[/url]

[  /a/67.html#_Toc308166179]5.1              输入[/url]

[  /a/67.html#_Toc308166180]5.2              输出[/url]

[  /a/67.html#_Toc308166181]5.3              流程描述[/url]

[  /a/67.html#_Toc308166182]6.   流程质量控制[/url]

[  /a/67.html#_Toc308166183]7.   附件和表单[/url]

[  /a/67.html#_Toc308166184]8.   相关文件[/url]

1. 概述

1.1    目标

确保在灾难发生后，IT基础设施和IT服务能在规定的时间内得到恢复，从而支持公司业务连续性的要求。

1.2    范围

流程类型	描述
适用范围	某证券股份有限公司信息技术中心运营中心。
管理范围	1. 识别业务对IT服务的连续性要求； 2. 识别、评估及管理IT基础设施和IT服务所面临的风险、威胁及其对业务的影响； 3. 编制并测试、演练应急预案。

图表 1 范围

1.3    术语定义表

名词	定义
恢复时间目标(RTO) Recovery Time Objective	即灾难发生后，信息系统或业务功能从停顿到必须恢复的时间要求。
恢复点目标(RPO) Recovery Point Objective	即灾难发生后，系统和数据必须恢复到的时间点要求。
运行性能降低预期（DOO）Degraded Operations Objective	即灾难发生后，与灾难发生前相比运行处理能力的降低情况。

图表 2 术语定义表

2. 角色和职责[td]

角色	职责
运营中心 管理层	1.   负责本流程的审批； 2.   负责管理报告的审阅； 3.   负责对演练方案的审批。
连续性 经理	1.   负责本流程的推广、监督和改进，包括： 1)   负责本流程及附件文档的更新维护； 2)   设定本流程的绩效指标并衡量指标完成情况； 3)   回顾流程执行情况，编制连续性管理流程报告，反映存在的问题，提出改进建议，并制定改进计划。 2.   负责组织进行业务影响分析和风险分析； 3.   负责组织制定连续性策略； 4.   负责组织制定连续性管理计划； 5.   负责对连续性管理计划进行回顾。
连续性 管理员	1.   负责设计制定相应的应急预案； 2.   负责制定应急预案演练方案； 3.   负责对应急预案进行演练； 4.   负责通知相关方进行应急演练； 5.   负责对应急演练过程进行回顾。

图表 3 角色和职责

3. 相关要素定义

3.1    业务影响度

1）  业务影响度用于确定服务对业务所产生的影响，业务影响度分为五级，包括高、较高、中、较低、低五个级别。

2）  业务影响度的参考值由监管要求、业务系统两个因素决定，服务负责人根据参考值最终确定准确的业务影响度。业务影响度参考值的计算方法：

业务影响度得分=求整（（监管要求得分*20%+系统分类得分*80%）*5/4.6），具体如下表所述：

业务影响度 参考值	高	较高	中	较低	低
得分	5	4	3	2	1

图表 4 业务影响度参考值

a)        监管要求得分：

得分	监管要求
3	等级保护级别为3的或证监会明确要求中断时间在15分钟以上需要上报的系统。
2	等级保护级别为2的或证监会明确要求中断时间在2小时以上需要上报的系统。
1	等级保护级别为1的或证监会无明确要求的系统。                            ITSS认证

图表 5 监管机构要求

b)   系统分类得分：

得分	系统分类
5	实时交易系统，指直接向服务对象提供实时交易服务，实时性要求高，若中断将导致直接经济损失和重大社会影响的系统。包括集中交易、网上交易、电话委托、手机炒股等。
4	实时业务运作系统，指间接向服务对象提供交易服务，或关键业务运作依赖的系统。该系统若较长时间中断（大于30分钟）后将影响交易、资金划转，或导致正常业务停顿，直接或间接影响交易，可能产生较大社会影响。包括三方存管、基金等系统。
3	业务管理系统，指用于公司业务日常管理的系统。该系统若长时间中断（大于4小时）将影响业务管理，但不影响交易，不会产生外部影响。包括经纪人管理、营销系统等。
2	办公及后台管理系统，指公司日常非业务直接相关的管理系统和办公类系统。该系统若长时间中断（大于4小时）将影响使用部门的业务管理，但不影响交易，不会产生外部影响。包括投行、研究所、OA等。
1	其他辅助系统，指公司日常公司所需的辅助支持系统。该系统若长时间中断（大于4小时）将影响使用部门的日常管理，但可采取其他替代手段解决，不会产生外部影响。包括即时通讯系统、移动办公系统等。

图表 6 系统分类

3.2    RPO、RTO和DOO

业务影响度	RPO(恢复点目标)	RTO（恢复时间目标）	DOO（运行性能降低预期）
高	<1分钟	<15分钟	<20%
较高	<2小时	<30分钟	<20%
中	<4小时	<8小时	<50%
较低	<24小时	<24小时	<50%
低	<24小时	<48小时	<50%

图表 7 RPO\RTO\DOO

3.3    风险级别

风险的定级由相关信息安全风险评估工作确定。

4. 管理策略

根据业务影响度分析（BIA）和风险分析（RA）的结果，制定适合于某证券的连续性策略。连续性策略包括对应急预案的规划，以及连续性管理计划的要求。

4.1    业务影响分析策略

1)   业务影响度分析针对《服务目录》中的有系统支撑的服务，没有系统支撑的服务可以不做业务影响度分析。

2)   业务连续性经理每年组织相关人员进行业务影响度分析工作。

3)   新或变更的服务上线前，应对其进行业务影响分析和风险分析，根据分析的结果，回顾连续性策略并根据需要对连续性策略进行修订，之后根据连续性策略的要求制定新或变更服务的连续性管理计划。

4.2    风险分析策略

业务连续性经理每年组织相关人员对服务的连续性风险进行分析，该项工作可与信息安全风险评估结合开展。

4.3    连续性管理计划策略

1)  连续性管理计划包括应急预案规划、培训计划、应急预案回顾计划。

2) 应急预案的制定：

应为有系统支撑且业务影响度为中（及以上）且对某证券外部提供的服务制定应急预案，应对风险评估中识别出的高风险。

3)  应定期对应急预案涉及到的人员进行培训。

4)  应急预案的回顾：

a)   应急预案应进行主动回顾，主动回顾的形式有桌面推演、测试环境演练、生产环境演练：

l  桌面推演：桌面推演的参与者以走查的形式对应急预案排演而不实际进行恢复操作，桌面推演是最基本和最经济的；

l  测试环境演练：测试环境演练是在测试环境下对应急预案进行演练，相应的人员，包括供应商均采用应急预案中的人员；

l  生产环境演练：生产环境演练是在生产环境下对应急预案进行演练，相应的人员，包括供应商均采用应急预案中的人员。

b)   有系统支撑且业务影响度为高的服务应至少每年进行两次主动回顾，且回顾的方式只能采取生产环境演练。

c)   有系统支撑且业务影响度为较高或者中的服务应进行至少每年一次主动回顾，回顾方式不限。

d)   被动回顾由变更管理流程触发。

e)   当发生重大变更，包括应急预案中的人员发生变动时，应急预案应被重新回顾。

f)   回顾中如果发现预案存在问题，应通过变更管理流程预案进行修订。

5. 流程描述

5.1    输入

编号	输入项	来源	周期
1.	IT服务连续性要求	监管机构	发生时
2.	对IT服务连续性有影响的变更	变更管理流程	发生时

图表 8 输入

5.2    输出

编号	输出项	去向	周期
1.	业务影响度分析和风险评估报告	流程内部	发生时
2.	连续性管理计划	流程内部	每年
3.	演练报告	流程内部	发生时
4.	连续性管理报告	服务报告流程	每年

图表 9 输出

5.3    流程描述

图表 10 流程图

[td]

步骤	输入	步骤描述	输出
1.  收集连续性需求	监管要求； 业务需求；	连续性经理收集连续性需求，包括： 1.   由项目发起的新（或变更）服务的连续性需求； 2.   监管机构对业务连续性的要求； 3.   业务部门对业务连续性的需求。	业务连续性需求
2.  组织业务影响度分析和风险分析	收集到的连续性需求	连续性经理组织各系统管理员： 1.   根据现状和业务特点，分析IT服务中断对业务的影响程度; 2.   识别和分析IT服务中断的风险因素，分析风险发生的可能性和影响； 3.   根据各系统的业务影响程度确定其RTO、RPO及DOO。	《业务影响分析和风险评估报告》
3.  制定连续性策略	《业务影响分析和风险评估报告》	连续性经理每年根据IT系统对业务的影响程度以及IT系统面临的风险，制定连续性策略： 1.  明确连续性要求； 2.  明确连续性管理计划的范围； 3.  连续性策略设计和维护的原则； 4.  其他有关连续性管理的策略。	连续性策略
4.  制定/修订连续性管理计划	连续性策略	1.   连续性经理组织各职能部门制定连续性管理计划，包括： a)   应急预案规划 b)   培训计划 c)   预案回顾计划 2.   发生重大变更时，要修订连续性管理计划。	《连续性管理计划》
5.  审批连续性管理计划	《连续性管理计划》	1.  连续性管理计划由运营中心管理层进行审批； 2.  运营中心管理层根据连续性管理计划涉及的范围判断是否需要上级领导审批； 3.  审批通过的进入步骤6。	审批通过的《连续性管理计划》
6.  设计应急预案	《连续性管理计划》	1.  连续性管理员根据连续性管理计划中对应急预案的规划制定应急预案； 2.  应急预案包括灾难发生后的应急处置方式和恢复步骤； 3.  应急预案作为事件管理流程的输入，供事件处理时参考使用； 4.  新制定的应急预案应进行回顾，若采用演练的方式进行回顾，则进入步骤7；若采用其他方式进行回顾，则进入步骤11.	《应急预案》
7.  制定演练方案	《应急预案》	1.   连续性管理员制定职责范围内的演练方案； 2.   演练方案包括演练环境的准备、演练时间、演练人员等； 3.   跨部门的演练方案由连续性经理组织制定。	《演练报告》的演练方案部分
8.  审批演练方案	《演练报告》的演练方案部分	1.   连续性经理对各专业制定的演练方案进行审核； 2.   运营中心管理层对演练方案进行审批，并根据演练影响的范围判断是否需要其他部门或上级领导和单位进行审批; 3.   审批通过后，可按照演练方案执行演练； 4.   审批部通过的，由连续性管理员对演练方案进行修改。	审批意见
9.  通知相关方	《演练报告》的演练方案部分	通知演练相关方人员进行演练。	《演练报告》
10.执行演练	《演练报告》的演练方案部分	1.   连续性管理员按照审批通过的演练方案执行演练； 2.   涉及多个部门配合演练的，由连续性经理负责组织方案的演练; 3.   演练完成后应形成演练报告，并报连续性经理和运营中心管理层。	《演练报告》
11.回顾连续性管理计划	变更情况报告	1.  业务影响度三级及以上的系统至少每年对连续性管理计划进行两次回顾； 2.  采用评审方式进行回顾的，应形成会议纪要； 3.  回顾过程中若对测试环境和生产环境造成影响，应按照变更发布管理流程执行； 4.  采用演练方式进行回顾的，演练前按照步骤8制定演练方案，演练后形成《演练报告》； 5.  连续性经理每年对连续性管理流程的执行情况进行总体回顾，形成《连续性管理报告》。	《演练报告》 《连续性管理报告》
12.连续性管理计划回顾	《连续性管理计划》 《演练报告》	连续性经理根据培训结果、演练结果，更新《连续性管理计划》。	回顾后的《连续性管理计划》

图表 11 流程描述

6. 流程质量控制

连续性经理按照PDCA持续改进的方法对本流程改进，连续性经理对本流程及其执行情况进行回顾，分析流程执行的效果。在回顾中识别出的改进事项按照服务改进流程的要求进行跟踪，或以其他可审计的方式记录改进情况。                    ITSS培训

7. 相关文件

无

本帖关键字：ITSS