本帖最后由monicazhang于2015-7-1714:37编辑
20150717淡然
续上
2.3.1.确定可用性需求
物理流程图和说明
说明：
| | | | | | | 包括以下内容： 1）从连续性管理流程中来获取关键业务清单，该清单必须经由业务部门确认。 2）参考关键业务清单，针对每个服务、每类客户，理解其业务目标。 3）同时，根据业务目标，确定可用性方面的业务需求，具体包括： ¨关键业务的定义 ¨服务中断的定义 ¨中断对业务的影响 ¨服务时间的定义 ¨不同时间宕机影响的比较等 | | | | | 包括： 1）根据业务需求，确认相应的可用性需求，包括：可用性、可靠性、可维护性等。 2）当关键业务是由第三方提供的，需要确定相应的可服务性指标。 3）签订的SLA中定义了最终的可用性需求。 4）对于可用性需求的修改，也应进行相应的控制。 | | | | | 可用性需求的验证及确认是一个循环的过程，要经过服务级别管理与可用性管理多次的协商。 应该包括如下方面： 1）最终的可用性需求必须与服务级别协议相一致。 2）需要对需求进行可行性分析，来确认其是否可以实现。 3）结合服务级别管理，对SLA中的可用性需求进行分解，确定相应的操作级别协议（OLA）及支持合同（UnderpinContract）。从根本上保证可用性需求可以被满足。 | | |
2.3.2.定义系统框架
物理流程图和说明
| | | | | | | 对于每个关键业务，需要确定其主要配置项。根据IT可用性管理模型，应该包括以下部件： [p=22,null,left] ¨平台，包括机房环境、电源、IT支持人员、其他辅助部件等。[p=22,null,left] ¨IT关键部件：包括主机、系统软件、应用软件等。[p=22,null,left] ¨网络：包括连接各个IT关键部件的各种网络设备：路由器、交换机、端口、网线等。[p=22,null,left] ¨数据：指支持业务运行的数据的可用性，包括数据的完整性、可用性及安全性等。[p=22,null,left] ¨应用：指支持业务正常运转的各种业务系统。。[p=22,null,left] 此时，可以从需求说明书中了解系统的需求。 | | | | | 将主要配置项进行分解，同时确定各个配置项之间的关系，例如：父子关系、依赖关系、与或关系等等。 | | | | | 为了保证配置项的可用性，此时必须对所有配置项的管理功能进行审查，主要包括以下内容： 1）审查的要点包括： [p=22,null,left] ¨是否对监控对象进行定义[p=22,null,left] ¨是否明确了相应的监控方法[p=22,null,left] ¨是否定义监控的阀值[p=22,null,left] 2）监控内容应包括如下方面：[p=22,null,left] ¨可用性的监控及数据收集[p=22,null,left] ¨可靠性的监控及数据收集[p=22,null,left] ¨响应时间的监控[p=22,null,left] ¨常见错误恢复时间的监控[p=22,null,left] 3）在进行审查的时候，也需要对相应的供应商进行能力审查，以确保可用性需求得到满足。[p=22,null,left] 4）需要结合安全管理，审查配置项的配置，以确保安全得到满足。 | 输入： [p=22,null,left] ¨运维计划[p=22,null,left] ¨与供应商签订的运维级别协议(OLA)[p=22,null,left] ¨安全规范 | | | | 根据配置项清单及配置项关系图，生成关键业务的系统框架。 系统框架可以使用图、表格、文档等形式来进行描述，主要包括： [p=22,null,left] ¨每个服务是由那些配置项所组成的[p=22,null,left] ¨配置项之间的关系[p=22,null,left] ¨配置项的监控、管理功能的描述[p=22,null,left] ¨其他说明 | 输入： [p=22,null,left] ¨配置项清单[p=22,null,left] ¨配置项关系图 | |
2.3.3.差距分析
物理流程图和说明
说明：
可以定期或不定期的进行本活动，来对现在的可用性情况进行分析，找出差距、风险及单点故障，提出改进措施，从而提高可用性水平。
| | | | | | | [p=22,null,left]包括：[p=22,null,left]¨根据现在的可用性数据，找出与服务级别协议之间的差距。[p=22,null,left]¨进行可用性的风险分析，找出当前服务的薄弱点，从而确定出相应的风险。 | 触发： [p=22,null,left] ¨3.1.1.3：验证需求[p=22,null,left] ¨定期或不定期的改进活动。 | [p=22,null,left]¨确定的可用性差距[p=22,null,left]¨确定的风险 | | | 可以借助可用性分析工具（例如CFIA、FTA）等来分析IT中的单点故障。 | | | | | 对于已经确定的差距、风险、单点故障，必须进行一定的分析，从而制定应对措施。 | [p=22,null,left]¨确定的可用性差距[p=22,null,left]¨确定的风险[p=22,null,left]¨单点故障 | | | | 通过对应对措施的分析，来决定是由内部人员实现，还是通过立项，由外部人员协助完成。 此时需要进行应对措施的性价比分析。 | | | | | 对于每个关键配置项，需要和业务部门协商“计划内的宕机时间段”，以便进行维护。 如果一个配置项和几个不同的服务相关，需要分别和各个服务的不同使用者一块协商来决定。 | | | | | 编写完成《可用性计划》以指导应对措施的实施。 如果需要实施应对措施，必须提交RFC，通过变更管理流程来完成个。 | | | | | | | |
2.3.4.可用性回顾
物理流程图和说明
说明：
可以定期或不定期的进行本活动，来对过去一段时间内的运行情况进行评估，找出运行当中的薄弱点，提出改进措施，从而提高可用性水平。
| | | | | | | 包括： 1）根据IT可用性管理模型，定义数据采集的对象、间隔、方法等，包括： [p=22,null,left] ¨平台，包括机房环境、电源、IT支持人员、其他辅助部件等。[p=22,null,left] ¨IT关键部件：包括主机、系统软件、应用软件等[p=22,null,left] ¨网络：包括连接各个IT关键部件的各种网络设备：路由器、交换机、端口、网线等[p=22,null,left] ¨数据：指支持业务运行的数据的可用性，包括数据的完整性、可用性及安全性等[p=22,null,left] ¨应用：指支持业务正常运转的各种业务系统。[p=22,null,left] 2）同时，也应该从用户的角度去衡量每一个服务端到端的可用性指标。[p=22,null,left] 3）该模型定义完成之后，可用性管理员或运维部门进行日常的数据采集工作。 | 输入： [p=22,null,left] ¨关键业务系统框架。[p=22,null,left] ¨可用性需求 | [p=21,null,left]可用性数据源。 | | | 根据问题及突发事件报告，进行趋势分析，来找出潜在的薄弱点，从而进行可用性的提高。 需要与问题管理流程相结合。 | [p=21,null,left]输入：[p=22,null,left]¨突发事件报告(来自于热线支持与突发事件流程)[p=22,null,left]¨问题报告（来自于问题管理流程） | | | | 对重大的突发事件进行详细的分析，从而确定一些改进方向，来提高服务的可用性。事件的生命周期包括： [p=22,null,left] ¨事件响应时间[p=22,null,left] ¨事件解决时间[p=22,null,left] ¨事件发生的平均间隔时间 | 输入： [p=22,null,left] ¨详细的突发事件数据 | | | | 1）对于重大的服务中断，需要进行“服务中断分析”，包括： [p=22,null,left] ¨识别服务中断的原因[p=22,null,left] ¨评估IT支持人员对事件的处理效率[p=22,null,left] ¨生成报告来说明主要的发现和推荐措施[p=22,null,left] ¨递交RFC来进行改进。[p=22,null,left] 2）分析的内容包括：[p=22,null,left] ¨服务故障的数据[p=22,null,left] ¨服务性能的数据[p=22,null,left] 3）所有的数据来源于运维部门。 | 输入： [p=22,null,left] ¨故障、性能数据（来自于运维管理流程） | |
本帖关键字：ITSS
|
转播
分享
淘帖
()