20150717    淡然

续上

2.3.1.    确定可用性需求

物理流程图和说明

说明：

序号	管理活动	描述	输入/触发条件	输出
3.1.1.1	理解业务需求	包括以下内容： 1）从连续性管理流程中来获取关键业务清单，该清单必须经由业务部门确认。 2） 参考关键业务清单，针对每个服务、每类客户，理解其业务目标。 3 ）同时，根据业务目标，确定可用性方面的业务需求，具体包括： ¨         关键业务的定义 ¨         服务中断的定义 ¨         中断对业务的影响 ¨         服务时间的定义 ¨         不同时间宕机影响的比较等	触发条件： ¨         SLA回顾会议 输入： ¨         关键业务清单	¨         确认的关键业务清单 ¨         可用性方面的业务需求
3.1.1.2	编制可用性需求	包括： 1）根据业务需求，确认相应的可用性需求，包括：可用性、可靠性、可维护性等。 2）当关键业务是由第三方提供的，需要确定相应的可服务性指标。 3）签订的SLA中定义了最终的可用性需求。 4）对于可用性需求的修改，也应进行相应的控制。		可用性需求 ITSS培训
3.1.1.3	需求的验证	可用性需求的验证及确认是一个循环的过程，要经过服务级别管理与可用性管理多次的协商。 应该包括如下方面： 1）最终的可用性需求必须与服务级别协议相一致。 2）需要对需求进行可行性分析，来确认其是否可以实现。 3）结合服务级别管理，对SLA中的可用性需求进行分解，确定相应的操作级别协议（OLA）及支持合同（Underpin Contract）。从根本上保证可用性需求可以被满足。		验证的可用性需求

2.3.2.    定义系统框架

物理流程图和说明

序号	管理活动	描述	输入/触发条件	输出
3.1.2.1	确定主要配置项	对于每个关键业务，需要确定其主要配置项。根据IT可用性管理模型，应该包括以下部件： ¨         平台，包括机房环境、电源、IT支持人员、其他辅助部件等。 ¨         IT关键部件：包括主机、系统软件、应用软件等。 ¨         网络：包括连接各个IT关键部件的各种网络设备：路由器、交换机、端口、网线等。 ¨         数据：指支持业务运行的数据的可用性，包括数据的完整性、可用性及安全性等。 ¨         应用：指支持业务正常运转的各种业务系统。。 此时，可以从需求说明书中了解系统的需求。		主要的配置项
3.1.2.2	定义配置项之间的关系	将主要配置项进行分解，同时确定各个配置项之间的关系，例如：父子关系、依赖关系、与或关系等等。		配置项关系图
3.1.2.3	对配置项管理功能的审查	为了保证配置项的可用性，此时必须对所有配置项的管理功能进行审查，主要包括以下内容： 1）审查的要点包括： ¨         是否对监控对象进行定义 ¨         是否明确了相应的监控方法 ¨         是否定义监控的阀值 2）监控内容应包括如下方面： ¨         可用性的监控及数据收集 ¨         可靠性的监控及数据收集 ¨         响应时间的监控 ¨         常见错误恢复时间的监控 3） 在进行审查的时候，也需要对相应的供应商进行能力审查，以确保可用性需求得到满足。 4） 需要结合安全管理，审查配置项的配置，以确保安全得到满足。	输入： ¨         运维计划 ¨         与供应商签订的运维级别协议(OLA) ¨         安全规范	完善配置项的管理功能。
3.1.2.4	生成关键业务的系统框架	根据配置项清单及配置项关系图，生成关键业务的系统框架。 系统框架可以使用图、表格、文档等形式来进行描述，主要包括： ¨         每个服务是由那些配置项所组成的 ¨         配置项之间的关系 ¨         配置项的监控、管理功能的描述 ¨         其他说明	输入： ¨         配置项清单 ¨         配置项关系图	系统框架 ITSS认证

2.3.3.    差距分析

物理流程图和说明

说明：

可以定期或不定期的进行本活动，来对现在的可用性情况进行分析，找出差距、风险及单点故障，提出改进措施，从而提高可用性水平。

序号	管理活动	描述	输入/触发条件	输出
3.1.3.1	差距、风险分析	包括： ¨         根据现在的可用性数据，找出与服务级别协议之间的差距。 ¨         进行可用性的风险分析，找出当前服务的薄弱点，从而确定出相应的风险。	触发： ¨         3.1.1.3：验证需求 ¨         定期或不定期的改进活动。	¨         确定的可用性差距 ¨         确定的风险
3.1.3.2	确认单点故障	可以借助可用性分析工具（例如CFIA、FTA）等来分析IT中的单点故障。		单点故障
3.1.3.3	应对措施的制定	对于已经确定的差距、风险、单点故障，必须进行一定的分析，从而制定应对措施。	¨         确定的可用性差距 ¨         确定的风险 ¨         单点故障	应对措施
3.1.3.4	Build/Buy分析	通过对应对措施的分析，来决定是由内部人员实现，还是通过立项，由外部人员协助完成。 此时需要进行应对措施的性价比分析。		决定
3.1.3.5	计划内宕机时间的协商	对于每个关键配置项，需要和业务部门协商“计划内的宕机时间段”，以便进行维护。 如果一个配置项和几个不同的服务相关，需要分别和各个服务的不同使用者一块协商来决定。		决定的“计划内宕机时间”
3.1.3.6	生成可用性计划、提交RFC	编写完成《可用性计划》以指导应对措施的实施。 如果需要实施应对措施，必须提交RFC，通过变更管理流程来完成个。		可用性计划 RFC

2.3.4.    可用性回顾

物理流程图和说明

说明：

可以定期或不定期的进行本活动，来对过去一段时间内的运行情况进行评估，找出运行当中的薄弱点，提出改进措施，从而提高可用性水平。

序号	管理活动	描述	输入/触发条件	输出
3.1.3.1	定义可用性衡量模型	包括： 1） 根据IT可用性管理模型，定义数据采集的对象、间隔、方法等，包括： ¨         平台，包括机房环境、电源、IT支持人员、其他辅助部件等。 ¨         IT关键部件：包括主机、系统软件、应用软件等 ¨         网络：包括连接各个IT关键部件的各种网络设备：路由器、交换机、端口、网线等 ¨         数据：指支持业务运行的数据的可用性，包括数据的完整性、可用性及安全性等 ¨         应用：指支持业务正常运转的各种业务系统。 2） 同时，也应该从用户的角度去衡量每一个服务端到端的可用性指标。 3） 该模型定义完成之后，可用性管理员或运维部门进行日常的数据采集工作。	输入： ¨         关键业务系统框架。 ¨         可用性需求	可用性数据源。
3.1.4.2	趋势分析	根据问题及突发事件报告，进行趋势分析，来找出潜在的薄弱点，从而进行可用性的提高。 需要与问题管理流程相结合。	输入： ¨                   突发事件报告(来自于热线支持与突发事件流程) ¨                   问题报告（来自于问题管理流程）	确认影响可用性的要素
3.1.4.3	突发事件的生命周期分析	对重大的突发事件进行详细的分析，从而确定一些改进方向，来提高服务的可用性。事件的生命周期包括： ¨         事件响应时间 ¨         事件解决时间 ¨         事件发生的平均间隔时间	输入： ¨         详细的突发事件数据
3.1.4.4	“服务中断”的分析	1） 对于重大的服务中断，需要进行“服务中断分析”，包括： ¨         识别服务中断的原因 ¨         评估IT支持人员对事件的处理效率 ¨         生成报告来说明主要的发现和推荐措施 ¨         递交RFC来进行改进。 2） 分析的内容包括： ¨         服务故障的数据 ¨         服务性能的数据 3） 所有的数据来源于运维部门。	输入： ¨                   故障、性能数据（来自于运维管理流程）	ITSS考试

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

本帖关键字：ITSS

20150717    淡然

续上

2.3.1.    确定可用性需求

物理流程图和说明

说明：

序号	管理活动	描述	输入/触发条件	输出
3.1.1.1	理解业务需求	包括以下内容： 1）从连续性管理流程中来获取关键业务清单，该清单必须经由业务部门确认。 2） 参考关键业务清单，针对每个服务、每类客户，理解其业务目标。 3 ）同时，根据业务目标，确定可用性方面的业务需求，具体包括： ¨         关键业务的定义 ¨         服务中断的定义 ¨         中断对业务的影响 ¨         服务时间的定义 ¨         不同时间宕机影响的比较等	触发条件： ¨         SLA回顾会议 输入： ¨         关键业务清单	¨         确认的关键业务清单 ¨         可用性方面的业务需求
3.1.1.2	编制可用性需求	包括： 1）根据业务需求，确认相应的可用性需求，包括：可用性、可靠性、可维护性等。 2）当关键业务是由第三方提供的，需要确定相应的可服务性指标。 3）签订的SLA中定义了最终的可用性需求。 4）对于可用性需求的修改，也应进行相应的控制。		可用性需求 ITSS培训
3.1.1.3	需求的验证	可用性需求的验证及确认是一个循环的过程，要经过服务级别管理与可用性管理多次的协商。 应该包括如下方面： 1）最终的可用性需求必须与服务级别协议相一致。 2）需要对需求进行可行性分析，来确认其是否可以实现。 3）结合服务级别管理，对SLA中的可用性需求进行分解，确定相应的操作级别协议（OLA）及支持合同（Underpin Contract）。从根本上保证可用性需求可以被满足。		验证的可用性需求

2.3.2.    定义系统框架

物理流程图和说明

序号	管理活动	描述	输入/触发条件	输出
3.1.2.1	确定主要配置项	对于每个关键业务，需要确定其主要配置项。根据IT可用性管理模型，应该包括以下部件： ¨         平台，包括机房环境、电源、IT支持人员、其他辅助部件等。 ¨         IT关键部件：包括主机、系统软件、应用软件等。 ¨         网络：包括连接各个IT关键部件的各种网络设备：路由器、交换机、端口、网线等。 ¨         数据：指支持业务运行的数据的可用性，包括数据的完整性、可用性及安全性等。 ¨         应用：指支持业务正常运转的各种业务系统。。 此时，可以从需求说明书中了解系统的需求。		主要的配置项
3.1.2.2	定义配置项之间的关系	将主要配置项进行分解，同时确定各个配置项之间的关系，例如：父子关系、依赖关系、与或关系等等。		配置项关系图
3.1.2.3	对配置项管理功能的审查	为了保证配置项的可用性，此时必须对所有配置项的管理功能进行审查，主要包括以下内容： 1）审查的要点包括： ¨         是否对监控对象进行定义 ¨         是否明确了相应的监控方法 ¨         是否定义监控的阀值 2）监控内容应包括如下方面： ¨         可用性的监控及数据收集 ¨         可靠性的监控及数据收集 ¨         响应时间的监控 ¨         常见错误恢复时间的监控 3） 在进行审查的时候，也需要对相应的供应商进行能力审查，以确保可用性需求得到满足。 4） 需要结合安全管理，审查配置项的配置，以确保安全得到满足。	输入： ¨         运维计划 ¨         与供应商签订的运维级别协议(OLA) ¨         安全规范	完善配置项的管理功能。
3.1.2.4	生成关键业务的系统框架	根据配置项清单及配置项关系图，生成关键业务的系统框架。 系统框架可以使用图、表格、文档等形式来进行描述，主要包括： ¨         每个服务是由那些配置项所组成的 ¨         配置项之间的关系 ¨         配置项的监控、管理功能的描述 ¨         其他说明	输入： ¨         配置项清单 ¨         配置项关系图	系统框架 ITSS认证

2.3.3.    差距分析

物理流程图和说明

说明：

可以定期或不定期的进行本活动，来对现在的可用性情况进行分析，找出差距、风险及单点故障，提出改进措施，从而提高可用性水平。

序号	管理活动	描述	输入/触发条件	输出
3.1.3.1	差距、风险分析	包括： ¨         根据现在的可用性数据，找出与服务级别协议之间的差距。 ¨         进行可用性的风险分析，找出当前服务的薄弱点，从而确定出相应的风险。	触发： ¨         3.1.1.3：验证需求 ¨         定期或不定期的改进活动。	¨         确定的可用性差距 ¨         确定的风险
3.1.3.2	确认单点故障	可以借助可用性分析工具（例如CFIA、FTA）等来分析IT中的单点故障。		单点故障
3.1.3.3	应对措施的制定	对于已经确定的差距、风险、单点故障，必须进行一定的分析，从而制定应对措施。	¨         确定的可用性差距 ¨         确定的风险 ¨         单点故障	应对措施
3.1.3.4	Build/Buy分析	通过对应对措施的分析，来决定是由内部人员实现，还是通过立项，由外部人员协助完成。 此时需要进行应对措施的性价比分析。		决定
3.1.3.5	计划内宕机时间的协商	对于每个关键配置项，需要和业务部门协商“计划内的宕机时间段”，以便进行维护。 如果一个配置项和几个不同的服务相关，需要分别和各个服务的不同使用者一块协商来决定。		决定的“计划内宕机时间”
3.1.3.6	生成可用性计划、提交RFC	编写完成《可用性计划》以指导应对措施的实施。 如果需要实施应对措施，必须提交RFC，通过变更管理流程来完成个。		可用性计划 RFC

2.3.4.    可用性回顾

物理流程图和说明

说明：

可以定期或不定期的进行本活动，来对过去一段时间内的运行情况进行评估，找出运行当中的薄弱点，提出改进措施，从而提高可用性水平。

序号	管理活动	描述	输入/触发条件	输出
3.1.3.1	定义可用性衡量模型	包括： 1） 根据IT可用性管理模型，定义数据采集的对象、间隔、方法等，包括： ¨         平台，包括机房环境、电源、IT支持人员、其他辅助部件等。 ¨         IT关键部件：包括主机、系统软件、应用软件等 ¨         网络：包括连接各个IT关键部件的各种网络设备：路由器、交换机、端口、网线等 ¨         数据：指支持业务运行的数据的可用性，包括数据的完整性、可用性及安全性等 ¨         应用：指支持业务正常运转的各种业务系统。 2） 同时，也应该从用户的角度去衡量每一个服务端到端的可用性指标。 3） 该模型定义完成之后，可用性管理员或运维部门进行日常的数据采集工作。	输入： ¨         关键业务系统框架。 ¨         可用性需求	可用性数据源。
3.1.4.2	趋势分析	根据问题及突发事件报告，进行趋势分析，来找出潜在的薄弱点，从而进行可用性的提高。 需要与问题管理流程相结合。	输入： ¨                   突发事件报告(来自于热线支持与突发事件流程) ¨                   问题报告（来自于问题管理流程）	确认影响可用性的要素
3.1.4.3	突发事件的生命周期分析	对重大的突发事件进行详细的分析，从而确定一些改进方向，来提高服务的可用性。事件的生命周期包括： ¨         事件响应时间 ¨         事件解决时间 ¨         事件发生的平均间隔时间	输入： ¨         详细的突发事件数据
3.1.4.4	“服务中断”的分析	1） 对于重大的服务中断，需要进行“服务中断分析”，包括： ¨         识别服务中断的原因 ¨         评估IT支持人员对事件的处理效率 ¨         生成报告来说明主要的发现和推荐措施 ¨         递交RFC来进行改进。 2） 分析的内容包括： ¨         服务故障的数据 ¨         服务性能的数据 3） 所有的数据来源于运维部门。	输入： ¨                   故障、性能数据（来自于运维管理流程）	ITSS考试

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

本帖关键字：ITSS