20150829  淡然

续上




2      流程详细说明

本章节的主要内容及用途如下所示：

提供了流程的指导方针，供日后相关项目中的流程设计和日常工作中使用； 提供了流程的关系图，指出了在某公司的整个服务管理体系中，本流程与其他流程的关系，即：本流程有哪些输入，同时也提供哪些输出； 提供了流程的执行框架体系，指出了本流程应该具有的一些主要活动，从而供日后实施项目的细化、归纳；                                     ITSS考试
• 提供了主要的考核指标，指出了如何对本流程进行衡量，在日后的实施项目中，应该对这些指标进行细化和实现。
  

2.1      指导原则

为了给某公司的连续性管理流程提供方向，必须定义一些指导原则。这些原则可以为所有的流程活动服务，也可以仅仅服务于某一个动作。指导原则的定义基于ITIL的最佳实践，同时根据某公司的具体情况进行调整，从而满足某公司的实际需求。

下面列出某公司连续性管理流程的指导原则：

方针 1:

连续性计划应该涵盖清晰且现实可行的恢复目标和恢复时间要求。

最佳实践：

§  恢复流程必须与业务目标一致；

§  必须明确对于灾难恢复的投资和业务的要求有直接的联系；

§  恢复所需时间与目标应与业务部门沟通且被认可；

§  在连续性计划内对于灾难应该有明确的定义，指明覆盖的工作范围（包括哪些、不包括哪些）；

§  需要明确了解在连续性计划阶段所花费的努力。

方针 2:

在某公司的信息技术部门必须开展风险管理以及开发针对风险和灾难发生的对策

最佳实践：

§  必须确保在某公司 IT运行环境的建设和运行中考虑到避免潜在灾难的措施；

§  对于任何的IT基础架构和业务需求的变更，都应该尽可能全面地考虑潜在风险。

方针3:

必须设计和开发连续性管理计划和灾难恢复计划以支持在紧急情况下关键业务功能的恢复。

最佳实践：

§  对于关键业务必须提供充分的投资用以开发主动的、预防性的灾难恢复对策；

§  所有的业务职能以及其重要性都应被明确的定义并公之于众；

§  特别重要的是，就连续性管理流程应该采取措施从而给予关键领导以信心。

方针4:

应该定期演练连续性计划。

最佳实践：

§  应该不间断的演练业务连续性计划和灾难恢复计划，包括计划的和可能不进行事先通知的；

§  演练包括涉及所有系统或者只是针对部分业务的测试；

§  演习必须有明确的目标和判断是否成功的标准；

§  应该为参与灾备的员工提供足够的培训。

方针5:

在IT基础架构变更的设计和实施过程中应该充分参照连续性管理的策略，考虑到灾难恢复的计划。

最佳实践：

§  在任何涉及IT基础架构的变更计划中都应充分考虑到连续性的因素；

§  必须为新上线的应用、系统和网络提供恢复的步骤。

方针6:

连续性管理以及容灾恢复流程和计划必须定期回顾更新。

最佳实践：

§  连续性计划的定期回顾必须被明确规定且按期执行；

§  应该由客观的第三方来回顾连续性计划，而非计划开发者本人，从而保证计划的全面性与客观性；

§  连续性计划的执行过程应该在变更管理的控制下执行；

§  必须定义并文档化对于连续性计划的修改、追踪过程和分发人员名单。

2.2      流程关系图

图3. 连续性管理流程与其他管理流程关系

§  服务级别管理

连续性管理的重点在于当灾难事件发生时IT服务的快速恢复以及相应的流程步骤和评估指标的监控，与此相关的协议、衡量标准以及成本都应该在服务级别管理流程中予以体现。

§  配置管理

配置管理为连续性计划提供配置项信息用以进行服务弱点分析，同时也为在灾难发生情况下为恢复工作的实施提供支持。

§  可用性管理

连续性管理为可用性管理提供业务影响分析(BIA, Business Impact Analysis)，反过来可用性管理提供了降低风险的措施以维护日常水平的运行(business as usual)。

§  安全管理

安全管理为连续性计划的开发提供安全规范方面的考量，同时业务连续性管理亦是全面的信息安全管理中的重要组成部分。

§  运维管理

连续性管理为运维管理提供连续性计划和容灾恢复方面的培训，当容灾演习或实际操作恢复之后运维管理应根据工作中的经验教训向连续性管理提供运行结果和改进意见。

§  变更管理

变更管理应评估基础架构和业务方面变更对于连续性计划的影响，并且对于连续性计划的变更也应该严格遵守变更管理流程。

§  性能与容量管理

性能与容量管理应该为连续性计划准备和维护在容灾切换过程中需要的系统性能和处理能力。

2.3      流程执行框架

本章节所提供的活动需求，主要是根据最佳实践，同时结合某公司的具体情况，对本流程的活动进行高层描述，并对主要活动进行罗列，解释等等，相关ITSP项目在进行问题管理流程的具体设计时，应该考虑这些活动，并且在功能上加以实现和扩展。

本章节将通过表格的形式表达，每一个活动都包含以下内容：

§  编号：唯一流程活动编号

§  管理活动：管理活动简述

§  描述：流程活动的具体描述                                           ITSS认证

§  输入/输出：流程活动的输入和输出交付物

图4. 连续性管理流程总览

[td]

编号	管理活动	描述	输入/输出
3.3.1	风险评估和灾难避免措施	风险分析通过发现某公司所面对的威胁且定义这些威胁发生的可能性，从而确定某公司所面临的潜在风险和弱点，并回顾避免灾难发生的回避措施。在这个阶段，主要的管理活动包括： -    发现潜在威胁 -    评估各类威胁的可能性 -    评估当前的灾害处理措施 -    评估当前的风险控制机制 -    判断如果缺乏有效管理而对于某公司所带来的影响 -    分析有效的控制管理对于某公司所带来的效益。	输出：《风险评估报告》
3.3.2	业务影响分析	业务影响分析（Business Impact Analysis）通过分析关键的业务流程以及关键业务流程的中断给某公司所带来的损失和潜在损害，从而了解某公司对于灾难发生或者某些服务中断的容忍能力。业务影响分析的主要活动包括： -    定义BIA所使用的方法和流程 -    确定需要调研的业务功能和分类 -    设计用于调研的调研表 -    分析所采集的信息并验证 分析获得结论并提交《业务影响分析报告》。	输出：《业务影响分析报告》
3.3.3	决定容灾和备份选择	基于关键业务功能恢复的需要，决定容灾和备份选择，特别的，不同的恢复策略并非互相排斥，而是根据灾难或服务中断的类型而决定。其主要的活动包括： -    确定用于关键业务功能恢复的可选容灾和备份策略； -    确定在不同场景下的容灾和备份策略选择； -    确定对于不同关键业务功能的容灾和备份策略； -    采取提高业务功能强健性的措施(Counter Measure,例如，通过同时选用两家以上的电信运营商，从而降低当电信运营商服务中断所带来的风险)。	输入：《风险评估报告》、《业务影响分析报告》 输出：容灾和备份策略
3.3.4	确定连续性管理和灾难恢复团队	定义灾难恢复实施组织的结构、功能、角色和责任、成员、恢复步骤，从而确保当灾难发生时，能够迅速召集相关人员有条不紊地按照既定步骤恢复业务及系统。需要注意的是，鉴于灾难和服务中断的情况和原因种类的多样性，需要针对不同的情况定义对各团队与人员角色的职责。其主要活动包括： -    定义灾难恢复团队的组织结构 -    定义灾难恢复团队不同角色的职责和技能要求 -    定义灾难恢复团队领导人、备选人以及其他组成人员。	输出：《连续性及灾难恢复组织架构》
3.3.5	设计和开发灾难恢复计划	结合企业的恢复策略和目标，定义灾难级别及判断标准，设计和开发灾难识别、灾难通知、灾难判断、恢复处理通知、灾难升级上报、各平台恢复（主机系统、数据库、网络、应用）、修复后回归正常、灾难恢复测试具体步骤。其主要活动包括： -    确定制定灾难恢复计划的方法和文档结构 -    定义升级上报机制 -    结合CPIC的重要业务目标和原则，编制灾难恢复计划 -    定义详细的恢复(Recovery)步骤 -    定义恢复到常态(Restoration)步骤以及接受标准(Acceptance Criteria)。	输出：《灾难恢复计划》(DRP, Disaster Recovery Plan)
3.3.6	设计和开发关键业务的应急和替代方案	当灾难发生后，会经历“灾难发生->恢复->修复->正常”四个时间点，通常而言恢复不是一切正常(business-as-usual)，而是进入维持状态，所以从灾难发生到彻底恢复正常处理期间，为了保证关键业务服务的连续性，需要设计和开发一些有别于正常业务处理流程的变通方案和步骤。该活动也包含设计和开发“业务及系统彻底恢复到正常状态后的”一些善后处理具体步骤。其主要活动包括： -    确认需要应急和替代方案的业务服务； -    针对不同业务服务选择容灾和备份策略(backup options)； -    开发替代方案细节； -    开发将替代方案恢复到正常生产状态的步骤。	输出：《关键业务的应急方案与步骤》，建议作为《灾难恢复计划》的一部分。
3.3.7	连续性与灾难恢复计划之演习	为了检验连续性及灾难恢复计划的有效性，以及灾难发生时相关人员能够有条不紊地处理，必须进行预告/即席演练。 连续性管理经理负责演练的申请。主要活动包括： -    连续性与灾难恢复演习预案设计； -    设计演习场景； -    计划和安排演习的时间； -    准备评估演习效果的方法； -    开展演习活动； -    总结并分发演习过程中的经验教训。	输出：《演习预案》、 《演习报告》
3.3.8	连续性与灾难恢复计划维护	连续性管理的工作内容应该定期回顾，从而可以反映某公司 IT运行的最更新的状况。建议的回顾周期为至少每半年一次或者在IT系统发生重大变更之后。主要的连续性管理交付物和培训材料的变更也应遵循变更管理流程。	输出：《连续性及灾难恢复组织架构》、《灾难恢复计划》、培训计划和培训材料、变更申请

2.4      流程主要考核指标

定义考核指标应考虑的因素

可以从以下几个方面来考虑：

o    所有的考核指标必须具有“可测量性”，即所有的考核指标的数据都是可以采集到的，当然，推荐采用自动化的工具进行收集及显示。

o    考核指标可以用来反映流程的执行进度，即做了多少工作。

o    考核指标可以用来反映流程的执行质量，即所完成工作的效果如何。

建议的考核指标

连续性管理中在容灾恢复过程中的重要的考核指标包括：

o    RPO（Recovery Point Object），其中RPO代表了当灾难发生时允许丢失的数据量；

o    RTO（Recovery Time Object），而RTO则代表了系统恢复的时间（包括针对不同的情况和对象，例如应用、数据中心、网络等等）。

其他重要指标包括，可以按定期进行统计，例如按照每天、每季、每月、每年等：

o    运行业务系统中与连续性管理相关的告警数量；                                    ITSS培训

o    在指定时间间隔内的服务中断的次数与时间以及对于业务带来的影响。

待续http://ITIL-foundation.cn/thread-52350-1-1.html

本帖关键字：ITSS

20150829  淡然

续上




2      流程详细说明

本章节的主要内容及用途如下所示：

提供了流程的指导方针，供日后相关项目中的流程设计和日常工作中使用； 提供了流程的关系图，指出了在某公司的整个服务管理体系中，本流程与其他流程的关系，即：本流程有哪些输入，同时也提供哪些输出； 提供了流程的执行框架体系，指出了本流程应该具有的一些主要活动，从而供日后实施项目的细化、归纳；                                     ITSS考试
• 提供了主要的考核指标，指出了如何对本流程进行衡量，在日后的实施项目中，应该对这些指标进行细化和实现。
  

2.1      指导原则

为了给某公司的连续性管理流程提供方向，必须定义一些指导原则。这些原则可以为所有的流程活动服务，也可以仅仅服务于某一个动作。指导原则的定义基于ITIL的最佳实践，同时根据某公司的具体情况进行调整，从而满足某公司的实际需求。

下面列出某公司连续性管理流程的指导原则：

方针 1:

连续性计划应该涵盖清晰且现实可行的恢复目标和恢复时间要求。

最佳实践：

§  恢复流程必须与业务目标一致；

§  必须明确对于灾难恢复的投资和业务的要求有直接的联系；

§  恢复所需时间与目标应与业务部门沟通且被认可；

§  在连续性计划内对于灾难应该有明确的定义，指明覆盖的工作范围（包括哪些、不包括哪些）；

§  需要明确了解在连续性计划阶段所花费的努力。

方针 2:

在某公司的信息技术部门必须开展风险管理以及开发针对风险和灾难发生的对策

最佳实践：

§  必须确保在某公司 IT运行环境的建设和运行中考虑到避免潜在灾难的措施；

§  对于任何的IT基础架构和业务需求的变更，都应该尽可能全面地考虑潜在风险。

方针3:

必须设计和开发连续性管理计划和灾难恢复计划以支持在紧急情况下关键业务功能的恢复。

最佳实践：

§  对于关键业务必须提供充分的投资用以开发主动的、预防性的灾难恢复对策；

§  所有的业务职能以及其重要性都应被明确的定义并公之于众；

§  特别重要的是，就连续性管理流程应该采取措施从而给予关键领导以信心。

方针4:

应该定期演练连续性计划。

最佳实践：

§  应该不间断的演练业务连续性计划和灾难恢复计划，包括计划的和可能不进行事先通知的；

§  演练包括涉及所有系统或者只是针对部分业务的测试；

§  演习必须有明确的目标和判断是否成功的标准；

§  应该为参与灾备的员工提供足够的培训。

方针5:

在IT基础架构变更的设计和实施过程中应该充分参照连续性管理的策略，考虑到灾难恢复的计划。

最佳实践：

§  在任何涉及IT基础架构的变更计划中都应充分考虑到连续性的因素；

§  必须为新上线的应用、系统和网络提供恢复的步骤。

方针6:

连续性管理以及容灾恢复流程和计划必须定期回顾更新。

最佳实践：

§  连续性计划的定期回顾必须被明确规定且按期执行；

§  应该由客观的第三方来回顾连续性计划，而非计划开发者本人，从而保证计划的全面性与客观性；

§  连续性计划的执行过程应该在变更管理的控制下执行；

§  必须定义并文档化对于连续性计划的修改、追踪过程和分发人员名单。

2.2      流程关系图

图3. 连续性管理流程与其他管理流程关系

§  服务级别管理

连续性管理的重点在于当灾难事件发生时IT服务的快速恢复以及相应的流程步骤和评估指标的监控，与此相关的协议、衡量标准以及成本都应该在服务级别管理流程中予以体现。

§  配置管理

配置管理为连续性计划提供配置项信息用以进行服务弱点分析，同时也为在灾难发生情况下为恢复工作的实施提供支持。

§  可用性管理

连续性管理为可用性管理提供业务影响分析(BIA, Business Impact Analysis)，反过来可用性管理提供了降低风险的措施以维护日常水平的运行(business as usual)。

§  安全管理

安全管理为连续性计划的开发提供安全规范方面的考量，同时业务连续性管理亦是全面的信息安全管理中的重要组成部分。

§  运维管理

连续性管理为运维管理提供连续性计划和容灾恢复方面的培训，当容灾演习或实际操作恢复之后运维管理应根据工作中的经验教训向连续性管理提供运行结果和改进意见。

§  变更管理

变更管理应评估基础架构和业务方面变更对于连续性计划的影响，并且对于连续性计划的变更也应该严格遵守变更管理流程。

§  性能与容量管理

性能与容量管理应该为连续性计划准备和维护在容灾切换过程中需要的系统性能和处理能力。

2.3      流程执行框架

本章节所提供的活动需求，主要是根据最佳实践，同时结合某公司的具体情况，对本流程的活动进行高层描述，并对主要活动进行罗列，解释等等，相关ITSP项目在进行问题管理流程的具体设计时，应该考虑这些活动，并且在功能上加以实现和扩展。

本章节将通过表格的形式表达，每一个活动都包含以下内容：

§  编号：唯一流程活动编号

§  管理活动：管理活动简述

§  描述：流程活动的具体描述                                           ITSS认证

§  输入/输出：流程活动的输入和输出交付物

图4. 连续性管理流程总览

[td]

编号	管理活动	描述	输入/输出
3.3.1	风险评估和灾难避免措施	风险分析通过发现某公司所面对的威胁且定义这些威胁发生的可能性，从而确定某公司所面临的潜在风险和弱点，并回顾避免灾难发生的回避措施。在这个阶段，主要的管理活动包括： -    发现潜在威胁 -    评估各类威胁的可能性 -    评估当前的灾害处理措施 -    评估当前的风险控制机制 -    判断如果缺乏有效管理而对于某公司所带来的影响 -    分析有效的控制管理对于某公司所带来的效益。	输出：《风险评估报告》
3.3.2	业务影响分析	业务影响分析（Business Impact Analysis）通过分析关键的业务流程以及关键业务流程的中断给某公司所带来的损失和潜在损害，从而了解某公司对于灾难发生或者某些服务中断的容忍能力。业务影响分析的主要活动包括： -    定义BIA所使用的方法和流程 -    确定需要调研的业务功能和分类 -    设计用于调研的调研表 -    分析所采集的信息并验证 分析获得结论并提交《业务影响分析报告》。	输出：《业务影响分析报告》
3.3.3	决定容灾和备份选择	基于关键业务功能恢复的需要，决定容灾和备份选择，特别的，不同的恢复策略并非互相排斥，而是根据灾难或服务中断的类型而决定。其主要的活动包括： -    确定用于关键业务功能恢复的可选容灾和备份策略； -    确定在不同场景下的容灾和备份策略选择； -    确定对于不同关键业务功能的容灾和备份策略； -    采取提高业务功能强健性的措施(Counter Measure,例如，通过同时选用两家以上的电信运营商，从而降低当电信运营商服务中断所带来的风险)。	输入：《风险评估报告》、《业务影响分析报告》 输出：容灾和备份策略
3.3.4	确定连续性管理和灾难恢复团队	定义灾难恢复实施组织的结构、功能、角色和责任、成员、恢复步骤，从而确保当灾难发生时，能够迅速召集相关人员有条不紊地按照既定步骤恢复业务及系统。需要注意的是，鉴于灾难和服务中断的情况和原因种类的多样性，需要针对不同的情况定义对各团队与人员角色的职责。其主要活动包括： -    定义灾难恢复团队的组织结构 -    定义灾难恢复团队不同角色的职责和技能要求 -    定义灾难恢复团队领导人、备选人以及其他组成人员。	输出：《连续性及灾难恢复组织架构》
3.3.5	设计和开发灾难恢复计划	结合企业的恢复策略和目标，定义灾难级别及判断标准，设计和开发灾难识别、灾难通知、灾难判断、恢复处理通知、灾难升级上报、各平台恢复（主机系统、数据库、网络、应用）、修复后回归正常、灾难恢复测试具体步骤。其主要活动包括： -    确定制定灾难恢复计划的方法和文档结构 -    定义升级上报机制 -    结合CPIC的重要业务目标和原则，编制灾难恢复计划 -    定义详细的恢复(Recovery)步骤 -    定义恢复到常态(Restoration)步骤以及接受标准(Acceptance Criteria)。	输出：《灾难恢复计划》(DRP, Disaster Recovery Plan)
3.3.6	设计和开发关键业务的应急和替代方案	当灾难发生后，会经历“灾难发生->恢复->修复->正常”四个时间点，通常而言恢复不是一切正常(business-as-usual)，而是进入维持状态，所以从灾难发生到彻底恢复正常处理期间，为了保证关键业务服务的连续性，需要设计和开发一些有别于正常业务处理流程的变通方案和步骤。该活动也包含设计和开发“业务及系统彻底恢复到正常状态后的”一些善后处理具体步骤。其主要活动包括： -    确认需要应急和替代方案的业务服务； -    针对不同业务服务选择容灾和备份策略(backup options)； -    开发替代方案细节； -    开发将替代方案恢复到正常生产状态的步骤。	输出：《关键业务的应急方案与步骤》，建议作为《灾难恢复计划》的一部分。
3.3.7	连续性与灾难恢复计划之演习	为了检验连续性及灾难恢复计划的有效性，以及灾难发生时相关人员能够有条不紊地处理，必须进行预告/即席演练。 连续性管理经理负责演练的申请。主要活动包括： -    连续性与灾难恢复演习预案设计； -    设计演习场景； -    计划和安排演习的时间； -    准备评估演习效果的方法； -    开展演习活动； -    总结并分发演习过程中的经验教训。	输出：《演习预案》、 《演习报告》
3.3.8	连续性与灾难恢复计划维护	连续性管理的工作内容应该定期回顾，从而可以反映某公司 IT运行的最更新的状况。建议的回顾周期为至少每半年一次或者在IT系统发生重大变更之后。主要的连续性管理交付物和培训材料的变更也应遵循变更管理流程。	输出：《连续性及灾难恢复组织架构》、《灾难恢复计划》、培训计划和培训材料、变更申请

2.4      流程主要考核指标

定义考核指标应考虑的因素

可以从以下几个方面来考虑：

o    所有的考核指标必须具有“可测量性”，即所有的考核指标的数据都是可以采集到的，当然，推荐采用自动化的工具进行收集及显示。

o    考核指标可以用来反映流程的执行进度，即做了多少工作。

o    考核指标可以用来反映流程的执行质量，即所完成工作的效果如何。

建议的考核指标

连续性管理中在容灾恢复过程中的重要的考核指标包括：

o    RPO（Recovery Point Object），其中RPO代表了当灾难发生时允许丢失的数据量；

o    RTO（Recovery Time Object），而RTO则代表了系统恢复的时间（包括针对不同的情况和对象，例如应用、数据中心、网络等等）。

其他重要指标包括，可以按定期进行统计，例如按照每天、每季、每月、每年等：

o    运行业务系统中与连续性管理相关的告警数量；                                    ITSS培训

o    在指定时间间隔内的服务中断的次数与时间以及对于业务带来的影响。

待续http://ITIL-foundation.cn/thread-52350-1-1.html

本帖关键字：ITSS