COBIT中包括以下四个域：

1．规划与组织域

该域的控制目标如下（PO是plan and organize的缩写）：

l  PO 1  制定IT战略规划

l  PO 2  确定信息体系架构

l  PO 3  确定技术方向

l  PO 4  定义IT组织与相互关系

l  PO 5  管理IT投资

l  PO 6  管理目标与方向的协调

l  PO 7  人力资源管理

l  PO 8  确保符合外部要求

l  PO 9  风险评估

l  PO 10  项目管理

l  PO 11  质量管理

 

2．建设与实施域

该域的控制目标如下（AI是acquire and implement的缩写）：

l  AI 1  确定解决方案

l  AI 2  获取并维护应用软件

l  AI 3  获取并维护技术基础设施

l  AI 4  程序开发与维护

l  AI 5  系统安装与验收

l  AI 6  变更管理

 

3．运行与支持域

该域的控制目标如下（DS是deliver and support的缩写）：

l  DS 1定义并管理服务水平

l  DS 2管理第三方服务

l  DS 3绩效管理与容量管理

l  DS 4确保持续性服务

l  DS 5确保系统安全

l  DS 6确认与分配成本

l  DS 7教育并培训客户

l  DS 8为客户提供帮助和建议

l  DS 9配置管理

l  DS 10问题管理与紧急事件管理

l  DS 11数据管理

l  DS 12设施管理

l  DS 13运营管理

 

4．监控与评价域

该域的控制目标如下（ME是monitor and evaluate的缩写）：

l  ME1  流程监控

l  ME2  评价内部控制的适当性

l  ME3  获得独立保证

l  ME4  提供独立性审计

 

关注业务连续性，主要就是要关注3．运行与支持域中的DS4确保持续性服务

DS4确保持续性服务包括：

1、定义业务连续性政策、目标和范围（全行级的BCM政策）

2、维持连续性策略（包括风险评估、业务影响分析、应用影响分析、分级等）

3、制定并执行业务连续性响应方案（即应急预案，包括应急和灾难场景及措施、应急资源）

4、运行、测试和审查BCP（即演练，包括桌面、模拟等演练）

5、审查、维持和改善连续性计划（即维护预案）

6、实施连续性计划的培训（全行推广、培训、建立业务连续性意识）

7、备份管理安排（建立备份资源、执行备份、验证）

8、进行恢复后审查（即发生灾难后的审查）

 

这基本是一个完整的业务连续性的过程，从金融行业的角度一个个来看

1、定义业务连续性政策、目标和范围（全行级的BCM政策）

      BCM政策制度

      BCM组织结构

      BCM职责分工

      BCM管理流程

      BCM管理工具

      外包管理制度

 

2、维持连续性策略（包括风险评估、业务影响分析、应用影响分析，风险评估包括业务风险、技术风险、安保风险等）

      业务影响分析是根据业务重要程度实现差异化管理，确定各业务恢复优先顺序和恢复指标（RTO RPO），明确重要业务归口管理部门、所需关键资源及对应的信息系统，识别重要业务的相互依赖关系，分析、评估各项重要业务在运营中断事件发生时可能造成的经济损失和非经济损失。

应用影响分析是通过分析业务与信息系统的对应关系、信息系统之间的依赖关系，根据业务恢复时间目标、业务恢复点目标、业务应急响应时间、业务恢复的验证时间，确定信息系统灾备等级、信息系统恢复时间目标(信息系统RTO)、信息系统恢复点目标(信息系统RPO)，明确信息系统重要程度和恢复优先级别，并识别信息系统恢复所需的必要资源。另外还有数据追补和业务替代手段（技术和业务）。

风险分析及预防应对措施，并识别残余风险。包括信息系统风险、业务风险。安保风险。基本可以按照部门进行风险识别梳理。

                              

3、制定并执行业务连续性响应方案（即应急预案，包括应急和灾难场景及措施、应急资源，分为技术和业务）

总体应急预案：总体应急预案是商业银行应对运营中断事件的总体方案，包括总体组织架构、各层级预案的定位和衔接关系及对运营中断事件的预警、报告、分析、决策、处理、恢复等处置程序。

 

业务应急预案主要包括：

      1业务RTO/RPO

      2重要资源（主备指挥场所、通讯联络清单）

      3故障灾备事件场景及事件分级（总行故障、分行故障、管理系统故障等）

      4不同等级的事件的处置策略

      5应急响应的组织结构（决策组、指挥组、执行组、评估组）及职责任务分工

      6 应急响应流程（事件发生-）事件检测-》报告-》启动应急组-》处置，包括技术手段和业务手段-》对外宣告（如果是重大事件）-》恢复）

 

信息系统应急恢复总体预案： 

总体的组织架构

不同等级的故障定义

不同等级的故障的通用应急处置流程

相关工具和表格

 

各信息系统应急预案：

1、已知（技术RTO/RPO、系统关联关系、系统、网络、软硬件结构、本地及远程备份情况）

2、应急组织架构及人员联系方式（领导小组、协调组、报告组、系统组、应用组、网络组、第三方）

3、该信息系统故障场景定义及处置方法（可以分为内部故障、外部故障、网络故障，回切。每一个故障都会有事件等级、现象描述、处置措施、处置时间、验证方法）还应该分为本地应急场景和灾难切换场景

      4、回退步骤

      5、恢复所需关键资源

    

 

4、运行、测试和审查BCP（即演练，包括桌面、模拟等演练）

演练计划：制定演练计划，定期演练、桌面演练、模拟演练、实战演练。不同等级的系统演练要求不一样。

演练方案：

（1）演练场景：楼宇灾难，需要将几个系统切换到异地灾备环境

      （2）涉及系统、部门：业务主管部门（编写测试案例，案例需要技术部门确认是否灾备环境能够做）、业务测试部门（进行测试）、技术部门（进行技术切换回切和技术验证）

      （3）场地、人员、沟通安排、选择合适的预案

      （4）风险及应对措施：操作风险、数据风险、网络风险、时间风险、系统关联性风险等

      （5）流程（协同计划）：灾难发生->技术准备（网络、服务器、数据库、存储）-> 服务器和存储就位->灾备网络就位-> 应用系统具备切换条件 -> 确认切换 -> 停止生产环境 -> 启动灾备环境 -> 网络切换（确保客户端发起的请求是传到灾备环境） –> 技术绿灯测试（单系统及关联系统测试） ->  业务按照测试案例进行业务交易测试并提交反馈 –> 通知进行回切 -> 停灾备环境->启动生产环境-》网络访问关系改变->生产环境绿灯测试并提交反馈->各系统进行各自系统生产环境验证->生产环境业务测试——》恢复营业->灾备环境恢复至生产前状态

      （6）演练总结评估：预案有效性、可用性、差距、问题总结、不足。

 

 

 

5、审查、维持和改善连续性计划（即维护预案，完整性、合理性、有效性做评估）

适当的引入外部评估

 

6、实施连续性计划的培训（全行推广、培训、建立业务连续性意识）

 

7、备份管理安排（制定实施灾备方案、建立备份资源（也许是双活等模式）、执行备份、验证）

7.1备用资源方面

备用业务和办公场所资源。

指后台中心、运营中心、重要业务场所，以及灾备指挥中心的准备情况，识别相关风险、业务影响分析、业务恢复策略、备用办公场地获取方式策略、业务和办公场所应急恢复预案、演练。

备用信息系统运行场所资源。

数据中心选址原则按重要性排序为自然地理条件、配套设施、周边环境、成本因素、政策环境、高科技人才资源环境、社会经济人文环境等七大要素。另外考虑建立多地多中心，防止楼宇级和地区及的灾难。

备用信息技术资源

      系统分级灾备情况

备用人力资源。

      人员互备情况

电力、通讯、消防、安保等资源。

      真双路外部供电等。

 

7.2 灾备方案及备份验证等

  交易线梳理、应用部署方案、网络方案、数据复制方案、应用改造方案、过渡方案等。

 

 

 

8、进行恢复后审查（即发生灾难后的审查）

暂无这方面的实践

 

 

另外多说2点

1应急的自动化和结构化：

本地和灾难应急的流程应该和自动化工具绑定到一起，，应用预案应该是在一个知识库系统中，当出现事件时，就可以自动联动到应急预案中相应的场景处置方法，一般常见的事件，可以将处置方法写成脚本自动运行。同时任何事件处理都可以更新知识库中的事件处置方法,自动生成需要的预案。应急流程应该全部集成在软件平台中。

2 灾备已经越来越和生产结合

        随着技术的发展，出现了类似于vplex\svc\extended rac\vsphere等技术，使得应用可以实现双活甚至多活，所以灾备慢慢的和技术架构、应用架构等项融合。 灾备应该是一个横跨其他架构的架构，需要全面的考虑。 一个灾备专家，也应该是一个企业架构专家。 这是现在金融企业灾备所急切缺少的。

 

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　2013.10.13