学习资料： ITIL培训基地专家讲堂直播 300期视频回放

IT运维04：服务级别

服务级别管理是对IT运维服务的级别进行定义、记录和管理。

定义服务级别可以确定关键服务目标及其度量值，可以用于需方周期性考核的关键指标，也可以用于供方的评估机制，从而及时发现并解决组织存在的问题，是标准化建设的必经之路。

从运维管理角度出发，提取合同中与服务级别相关的信息如下：

[color=rgba(0, 0, 0, 0.9)]（一）识别干系人

需方干系人包括：1）主要管理人员    负责与供方对接运维相关事宜，制定运维实施过程中的一系列规则（需方制度），对运维服务提出更加精细的要求，对运维服务提出评价，是供方的主要汇报对象。

[color=rgba(0, 0, 0, 0.9)]2）系统管理人员

    负责供方IT资产的管理，监督运维实施，对运维人员的技能、专业程度进行评价。

[color=rgba(0, 0, 0, 0.9)]3）提出需求人员

[color=rgba(0, 0, 0, 0.9)]    提出用户需求或者事件需求，对需求响应结果进行确认，对运维人员的态度、仪容进行评价。

[color=rgba(0, 0, 0, 0.9)]供方干系人包括：

[color=rgba(0, 0, 0, 0.9)]1）运维服务经理

    负责与供方对接需求，响应供方提出的改进要求，监督运维团队落实并提升运维服务标准。

[color=rgba(0, 0, 0, 0.9)]2）服务台

    作为供方的对外服务窗口，负责对需方提出的需求进行响应、处理和反馈。

[color=rgba(0, 0, 0, 0.9)]3）运维人员

[color=rgba(0, 0, 0, 0.9)]    负责运维服务实施工作。

[color=rgba(0, 0, 0, 0.9)]第三方供应商：

[color=rgba(0, 0, 0, 0.9)]1）服务经理

[color=rgba(0, 0, 0, 0.9)]2）技术人员

（二）服务与子服务

[color=rgba(0, 0, 0, 0.9)]

    前期通过对服务目录的整理，我们已知了服务内容有哪些，这一环节，我们需要将服务、子服务及服务类型整理出来，用于对应服务目标的度量值，也可以用于区分需方的服务范围，例如↓↓

（三）定义服务级别

    服务级别协议（SLA）可以根据客户的需求来确定，也可以根据供方组织提供的服务来确定。

    我们可以把SLA理解为关键服务目标的集合，通过对事件的影响范围进行分析，确定服务优先级，对不同优先级的服务约定响应时限和解决时限。

以主机设备的故障分级为例：

1）重大故障

    优先级：非常高。

    级别定义：设备故障导致业务中断8小时以上；核心业务受到入侵，危及重要数据，系统文件及门户网站页面被非法窜改，容易引发入侵扩散。

    响应时限：立即启动应急预案，5分钟内完成通报；30分钟内提出问题分析及解决方案。

    解决时限：2小时之内完成设备的故障处理，恢复设备正常运行状态。

2）严重故障

    优先级：高。

   级别定义：设备故障导致业务中断1-8小时；核心业务受到入侵，未危及重要数据。    响应时限：10分钟内完成通报。    解决时限：4小时之内完成设备的故障处理，恢复设备正常运行状态。3）一般故障

    优先级：中、低。

    级别定义：设备故障导致业务中断4小时以下；存在高危端口或系统漏洞，但无重大后果。    响应时限：30分钟内完成通报。

    解决时限：4小时之内完成设备的故障处理，恢复设备正常运行状态。

确定解决时限应该考虑：

1）关键设备的影响范围2）备品备件情况3）供应商情况4）售后维修响应情况

5）需配合的单位情况

为服务分配SLA

如下图，主机设备维护服务对应SLA：2440

SLT2440对应SLT：5分钟响应、10分钟响应、30分钟响应、2小时解决、4小时解决（高）、4小时解决（中、低）。↓↓（四）确定交付模式    交付模式可以确定运维团队和客户组织的服务关系，通过对客户组织进行识别，判断哪些客户组织会提出需求（创建工单），不同的客户组织是否需要不同的运维团队提供服务，通俗来讲就是客户提出需求，由哪些运维人员负责解决。↓↓ 定义交付模式的同时，要求运维团队定义角色，例如由谁来负责分配工单、谁来负责牵头解决技术问题等。↓↓交付模式可以这样↓↓

（五）结语

    服务级别管理的内容不仅限于本文（所以标题没有管理两个字），至少没有包括SLA的监控、对SLA的评估考核以及下一服务周期的优化，监控、考核、优化是SLA存在的真正意义，漂亮的SLA指标和流于形式的工作回顾对组织运维服务标准化没有任何好处，我们应该真实、真实、再真实！

    持续改进ing。

学习资料： ITIL培训基地专家讲堂直播 300期视频回放

IT运维04：服务级别

服务级别管理是对IT运维服务的级别进行定义、记录和管理。

定义服务级别可以确定关键服务目标及其度量值，可以用于需方周期性考核的关键指标，也可以用于供方的评估机制，从而及时发现并解决组织存在的问题，是标准化建设的必经之路。

从运维管理角度出发，提取合同中与服务级别相关的信息如下：

[color=rgba(0, 0, 0, 0.9)]（一）识别干系人

需方干系人包括：1）主要管理人员    负责与供方对接运维相关事宜，制定运维实施过程中的一系列规则（需方制度），对运维服务提出更加精细的要求，对运维服务提出评价，是供方的主要汇报对象。

[color=rgba(0, 0, 0, 0.9)]2）系统管理人员

    负责供方IT资产的管理，监督运维实施，对运维人员的技能、专业程度进行评价。

[color=rgba(0, 0, 0, 0.9)]3）提出需求人员

[color=rgba(0, 0, 0, 0.9)]    提出用户需求或者事件需求，对需求响应结果进行确认，对运维人员的态度、仪容进行评价。

[color=rgba(0, 0, 0, 0.9)]供方干系人包括：

[color=rgba(0, 0, 0, 0.9)]1）运维服务经理

    负责与供方对接需求，响应供方提出的改进要求，监督运维团队落实并提升运维服务标准。

[color=rgba(0, 0, 0, 0.9)]2）服务台

    作为供方的对外服务窗口，负责对需方提出的需求进行响应、处理和反馈。

[color=rgba(0, 0, 0, 0.9)]3）运维人员

[color=rgba(0, 0, 0, 0.9)]    负责运维服务实施工作。

[color=rgba(0, 0, 0, 0.9)]第三方供应商：

[color=rgba(0, 0, 0, 0.9)]1）服务经理

[color=rgba(0, 0, 0, 0.9)]2）技术人员

（二）服务与子服务

[color=rgba(0, 0, 0, 0.9)]

    前期通过对服务目录的整理，我们已知了服务内容有哪些，这一环节，我们需要将服务、子服务及服务类型整理出来，用于对应服务目标的度量值，也可以用于区分需方的服务范围，例如↓↓

（三）定义服务级别

    服务级别协议（SLA）可以根据客户的需求来确定，也可以根据供方组织提供的服务来确定。

    我们可以把SLA理解为关键服务目标的集合，通过对事件的影响范围进行分析，确定服务优先级，对不同优先级的服务约定响应时限和解决时限。

以主机设备的故障分级为例：

1）重大故障

    优先级：非常高。

    级别定义：设备故障导致业务中断8小时以上；核心业务受到入侵，危及重要数据，系统文件及门户网站页面被非法窜改，容易引发入侵扩散。

    响应时限：立即启动应急预案，5分钟内完成通报；30分钟内提出问题分析及解决方案。

    解决时限：2小时之内完成设备的故障处理，恢复设备正常运行状态。

2）严重故障

    优先级：高。

   级别定义：设备故障导致业务中断1-8小时；核心业务受到入侵，未危及重要数据。    响应时限：10分钟内完成通报。    解决时限：4小时之内完成设备的故障处理，恢复设备正常运行状态。3）一般故障

    优先级：中、低。

    级别定义：设备故障导致业务中断4小时以下；存在高危端口或系统漏洞，但无重大后果。    响应时限：30分钟内完成通报。

    解决时限：4小时之内完成设备的故障处理，恢复设备正常运行状态。

确定解决时限应该考虑：

1）关键设备的影响范围2）备品备件情况3）供应商情况4）售后维修响应情况

5）需配合的单位情况

为服务分配SLA

如下图，主机设备维护服务对应SLA：2440

SLT2440对应SLT：5分钟响应、10分钟响应、30分钟响应、2小时解决、4小时解决（高）、4小时解决（中、低）。↓↓（四）确定交付模式    交付模式可以确定运维团队和客户组织的服务关系，通过对客户组织进行识别，判断哪些客户组织会提出需求（创建工单），不同的客户组织是否需要不同的运维团队提供服务，通俗来讲就是客户提出需求，由哪些运维人员负责解决。↓↓ 定义交付模式的同时，要求运维团队定义角色，例如由谁来负责分配工单、谁来负责牵头解决技术问题等。↓↓交付模式可以这样↓↓

（五）结语

    服务级别管理的内容不仅限于本文（所以标题没有管理两个字），至少没有包括SLA的监控、对SLA的评估考核以及下一服务周期的优化，监控、考核、优化是SLA存在的真正意义，漂亮的SLA指标和流于形式的工作回顾对组织运维服务标准化没有任何好处，我们应该真实、真实、再真实！

    持续改进ing。