IT运维流程库历史主题 · 只读
← 返回目录

可用性流程需求和差异分析----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）及支持合同（UnderpinContract）。从根本上保证可用性需求可以被满足。
验证的可用性需求

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考试

待续：

本帖关键字：ITSS