ISO20000：2018程序文件-服务可用性管理程序.docVIP

文件编号：HTPC-ITSM-B-11

文件名称：服务可用性管理程序

第PAGE1页

文档编号：HTPC-ITSM-B-11服务可用性管理程序

版本号：V1.0

服务可用性管理程序

编制：

审核：

批准：

发布日期：

实施日期：

修订履历

版本

变更履历

变更人/变更日期

审核人/审核日期

批准人/批准日期

目录

TOC\o1-2\h\z\u1目的 3

2范围 3

3职责 3

3.1可用性管理员 3

3.2可用性负责人 3

3.3部门经理： 3

4相关文件 3

5程序 4

5.1可用性需求识别和分析 4

5.2定义可用性目标 4

5.3调查服务组件的可用性 5

5.4识别可用性风险和对策 5

5.5可用性设计 5

5.6服务组件设计 6

5.7可用性需求满足测试或评审 7

5.8可用性需求满足监控 7

5.9可用性报告 7

6记录 7

1目的

提供符合预定可用性级别且成本合理的IT服务，以帮助企业实现其业务目标；确保已经取得的可用性级别能够得以评价和计量，以及在必要时进行持续改进。

2范围

本程序适用于技术服务部。

所有新增IT服务以及服务承诺：

公司开发的信息管理系统售后服务工作；

涉及到的服务组件，如服务器、信息管理系统、网络设备、硬件设备等。

3职责

3.1可用性管理员

负责可用性服务的具体实施，计划和报告的编制。

3.2可用性负责人

定义、开发并管理可用性管理流程；

确保IT服务在经过设计后，实际的服务重要性（一般、重要、紧急、重要紧急）能够符合约定的服务级别；

制定可用性计划；

撰写可用性报告,归并于IT服务报告中；

提出优化IT基础架构的改进建议。

3.3部门经理

安排人员对IT服务的风险评估报告和可用性计划的编制；

根据服务承诺，提交IT服务报告给公司主管领导。

4相关文件

《配置管理程序》

《服务报告管理程序》

5程序

5.1可用性需求识别和分析

可用性负责人根据服务级别需求识别和分析可用性需求，加入到《服务需求说明书》中，可用性需求分析包括：

对软件系统维护服务的定义；

软件系统对公司的重要性；

软件系统系统所支持的并发用户数量；

系统故障时间或服务不可用状态造成的业务影响；

故障停机时间或服务不可用状态产生的成本代价以及成本代价随时间推移相应变化的方式；

所需服务小时数；

较容易承受停机故障的次要服务时段；

专为计划内维护与升级工作设定的停机时段；

启动应急计划之前所能容许的故障停机时间。

需求识别时间：

在签订合同协议之前进行；

需考虑新的IT服务和需求对现有服务做出的变更的方面；

尽可能早的阶段确定客服部门是否能够实现这些需求以及怎样实现这些需求。

需求识别内容：

关键业务功能；

可量化的可用性需求；

非计划的IT服务中断对业务功能所产生的可量化的影响；

客户的业务正常运作时段；

有关定期维护约定的中断时间。

5.2定义可用性目标

可用性管理负责根据可用性定义的结果确定可用性目标。识别可用性管理的服务对象和组件，并提供可用性目标。

5.3调查服务组件的可用性

可用性负责人调查服务组件的使用年限、性能、已发生故障情况等内容，并把调查的结果写入到《风险评估报告》中。

5.4识别可用性风险和对策

可用性负责人员根据服务组件的调查情况识别组件的薄弱点、威胁及可能存在的风险隐患，编制《风险评估报告》。

5.5可用性设计

可用性负责人员根据《风险评估报告》进行可用性管理的方案设计，设计的原则包括：

确认那些影响系统运行和服务运行的薄弱环节。

基于适当的可用性标准的一个良好的可用性设计可以使得有可能与供应商签订有效的维护合同。设计过程中采用了一些技巧，如确认单点故障的组件故障影响度分析。

如果可用性标准不能够实现，最好的选择是确认设计是否可以进一步改进。

如果可用性需求特别难以达到，则应当考虑使用其它的容错技术、其它的服务流程（事件管理、问题管理和变更管理）或额外的服务管理资源。

5.5.1可用性计划

为有效地实施有关可用性管理活动以改进IT组件及服务的可用性，必须制定明确的《可用性计划》。

可用性计划包括运行监控、日常维护和故障恢复方案等内容。

可用性计划不仅需要关注技术方面的问题，还应对可用性管理的人员、流程、工具和技术等方面进行考虑。在可用性管理的初始阶段，可用性计划与实施通常是紧密结合进行的，但这两者却又是不同的，不能将它们混淆。

可用性计划的计划周期应当覆盖1至2年，并且对于前6个月的计划应当提供更为详细的信息。

值得注意的是，可用性计划应当和能力计划和财务预算的周期保持一致。

可用性计划一般包括以下部分：