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

ISO20000:2018程序文件-服务可用性管理程序.doc

  1. 1、本文档共7页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多

文件编号: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个月的计划应当提供更为详细的信息。

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

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

文档评论(0)

158****9043 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档