1、服务级别管理是一个连接 IT 服务提供商和使用服务的客户双方的流程。服务级别管理流程具有多个目标： 整合提供 IT 服务所需的各种要素； 生成清晰地描述服务项目中各种要素的文档； 以一种客户能够理解并涉及到的术语对所要提供的服务进行描述； 整合 IT 战略和业务需求； 以一种可控的方式改进 IT 服务提供。 服务级别管理在 IT 服务管理流程中扮演了一个中心角色，它与其它服务支持和服务提供流程都有密切的联系。服务级别管理充当了 IT 部门与客户之间沟通的一座桥梁，因为它为在不陷入技术细节的情况下讨论客户需求提供 了机会。随后 IT 部门才在组织内将这些业务需求转化成具体的技术说明和活动。客户无
2、需关心技术的程度是服务级别管理成功程度的一个良好的评价指标。 服务级别管理需要与客户展开有效和丰富的合作，因为定义适当的服务级别需要客户的参与和努力。如果客户（业务）对其身边的问题不是很熟悉，则这是首先需要解决的问题。图 10.1显示了服务级别管理流程的工作流图。它显示了大致平行的两部分流程：上面一部分流程是关于协议的制定，而下面一部分是关于如何确保这些协议得到切实的履行。 1、服务级别管理活动 服务级别管理包括下列活动： 识别 识别客户的需求（关系管理）以及在 IT 部门内进行宣传。了解业务流程和客户的需求。 定义 提供给客户以满足其需求的服务。这些服务在服务级别需求和服务说明书中进行定义。
3、该项活动的结果是完成一份服务质量计划。 签约 签订协议和合同，即与客户就需要的服务级别、相关的服务成本进行谈判协商，并将协议结果定义在服务级别协议（ SLA）中。签订运营级别协议（ OLA）和支持合同（ UC）以支持服务级别协议。撰写或修订说明可向客户提供的服务项目的服务目录。 监控 监控服务级别。 报告 撰写服务级 别报告。对照服务级别协议，定期地向客户和 IT 部门报告实际的服务级别。 评审 与客户一起审查服务以找出改进服务的机会。必要的情况下，可以制定一份服务改进方案。与客户就其对服务的经验和想法进行频繁的沟通。这可能产生的结果是新的或修订后的服务级别协议。 完全有效的服务级别管理需要引
4、入其它的服务支持和服务提供流程。所有的流程都在某种程度上支持了服务级别管理。在定义一项服务及其相关的服务级别时，应该对支持流程需要被引入的程度加以考虑。服务级别管理和其它流程的关系在下面进行介绍。 服务级别管理流程中包括的步 骤将在下文中进行详细介绍，包括流程工作流图和相应的活动。 2、识别 随着企业越来越依赖于它们的 IT 服务，对高质量服务的需求也在日益增长。一项服务被体验到的质量取决于客户的期望、对客户体验的日常管理、服务的稳定性以及成本的可接受性。因此，提供适当的质量的最好的选择就是首先探讨一下与客户相关的问题。 过去的经验表明，客户自己一般都不是很清楚他们的期望。有时候，他们只是简单
5、地假定应该提供具备某种质量特征的服务，而没有任何明确的意见。对于 IT 服务的这些假定的（含糊的）质量特征往往是造成许多纠纷的主要原因。这一点再次 说明，下面这种做法的重要性和必要性，即由服务级别经理来充分了解他们的客户，并帮助他们理清他们的想法：他们真正需要的服务和服务级别是什么？以多少成本来提供这些服务？ 客户的需求必须以一种可量化的指标进行表述，以便对 IT 服务进行设计和监控。如果没有与客户就评价指标达成一致意见，则很难验证 IT 服务是否满足了协议中的某些要求。服务级别管理在理解和定义客户的需求方面扮演了关键的角色。 在就现在或未来所要提供的 IT 服务签订 SLA的过程中，第一个步
6、骤应当是在服务级别需求中定义客户的需求。除了在流程实施的过程中需要进行一次 这样的活动以外，这项活动还应当定期进行，或者在报告和评审结果的触发下进行，也或者是在应客户的请求或为了 IT 部门的效益而进行。 3、定义 定义客户需求的范围和深度在服务级别管理中被视为是一个设计过程。按照关于质量保证的 ISO9001模型，一个设计过程应该包括下列步骤：设计、开发、生产、安装和维护。对设计过程应该进行管理以确保该过程的最终结果符合客户的需求。在设计过程中，术语 “外部 ”是指与客户的沟通，而 “内部 ”是指 IT 部门内部的技术支持。设计过程包括下面一些步骤，详细了解客户的需求，用明确的标准定义这些需
7、求，以 及开发提供服务所需要的具体的技术需求。 3.1定义外部标准 量化新的或现有的 IT 服务的第一步就是要概括性地定义或重新定义客户对服务的期望。这些期望在服务级别需求（ SLR）中进行描述并形成文档。这种描述应该针对整个客户组织。这一步骤通常被认为是服务级别管理中最困难的部分。 在开始这一步骤之前，服务级别经理必须为与客户进行会议沟通做好准备。首先应该向用户询问这样的问题： “对 IT 服务的要求是什么？ ”以及 “该项服务应该由哪些部分组成？ ”一项服务必然伴随着对部分基础架构的使用，如广域网（ WAN）。这样一项服务可以支持 一项复合服务，如访问一个完整的信息系统以及全部的支持性基础
8、架构（ WAN、LAN、工作站、应用系统等）。 在会议沟通时，应该将用户分成几个小组。服务级别经理负责制定一个关于用户小组及其需求和权限的清单。在定义服务级别需求时需要用到以下信息： 从客户角度对服务所要提供的功能进行的描述。 服务必须处于可用状态的时间和天数。 服务持续性需求。 提供服务所需要的 IT 职能部门。 在定义服务时需要考虑的当前运营方法或质量标准的参考基准。 需要修改或替换的 SLA的参考模板。 设计阶段将产生一份服务级 别需求文档，它需要由服务级别经理和客户签字确认。在IT 部门对照设计方案进行采购和实施的过程中，服务级别需求仍然可以进一步修改。此时的修改主要针对预设功能或成本
9、的实践可行性。这一类变更必须得到客户和服务级别管理双方的批准。 3.2转化成内部标准 在说明阶段，服务级别需求需要制定得详细而具体。这一阶段试图提供如下信息： 对 IT 服务及其需要的组件的清楚和详细的描述。 关于服务被实施和提供的方式的说明。 关于必要的质量控制程序的说明。 在说明阶段，建议对内部使用的文档资料和外部使用的区分开来（图 10.2）。外部使用的说明书主要是关于与客户约定的目标以及由这些目标所控制的设计过程。这些说明书是在与客户组织合作中完成的，并且形成内部使用的说明书的信息来源。 内部使用的说明书是指 IT 部门的内部目标，这些目标需要实现以满足客户的要求。一旦服务级别管理流程
10、开始运作，则将内部和外部说明书分开的作法是非常有用的。这可以确保 IT 部门无需用一些具体的技术问题来困扰其客户。从这时起，管理服务级别就是要保持内部和外部说明书的一致。通过维持对相关文档的记录、进行 版本管理和组织定期的审计，文档控制和内部评审可以有助于实现这一目标。 说明书（服务说明书）详细地描述了客户想要的服务（外部要素）以及这种需求可能会对 IT 部门产生的影响（内部因素）。说明书无需双方签字认可，当需要进行文档控制。服务目录可以基于服务说明书制定，因此，任何服务级别方面的变更需要立即反映在说明书和服务目录中。 SLA也需要进行相应的修改以符合修改后的说明书。 3.3服务质量计划 建议
11、将所有的管理信息（关键绩效指标）以及为内部和外部供应商准备的说明书融合在一个单一文档中，以提供有关每个服务管理流程对 IT 服务所作的贡献方面的综合信息。 4、签约 一旦说明阶 段完成了，意味着 IT 部门已经有效地将业务需求转换成相应的 IT 资源和资源的配置。这些 IT 资源和资源配置方面的信息然后可被用来制定或修改下列文档。 4.1服务级别协议 在确定服务级别协议结构时，建议在谈判开始前先就整个公司的一般服务项目（如网络服务）进行定义并制定一个总体性的以服务为基础的 SLA模型。 SLA应该具有一定的层次结构，就像客户的组织结构，即表现为多个层次上的框架协议。每一个层次都有其自身的详细程
12、度。最高层的协议是关于提供给整个组织的一般服务。而较低 层次的协议则是与具体客户相关的信息。 SLA的结构取决于下面一些状况： 组织的物理特性： - 规模 - 复杂程度 - 地理分布 文化方面： - 文档所使用的语言（对于国际组织） - IT 部门与客户的关系。 - 计费政策。 - 业务活动的一致性。 - 营利或非营利组织。 业务活动性质： - 一般条款和条件。 - 业务时间 58小时或 724小时。 4.2支持合同和运营级别协议 任何现有的 UC 或 OLA都必须在设计过程中得到修改。每一个相关的人员都必须清楚任何一份适用于某项特定的服务供应的 UC 或 OLA。配置管理可以帮助理清这些协议
13、与说明书的关系。 4.3服务目录 在撰写一份服务目录时，下列这些提示可能会有所帮助： 使用客户的语言。尽量避免技术术语，而使用一些符合相关业务的术语。 尽量从客户的角度看待问题，并使用这种方法来识别相关的信息。 提供一个有吸引力的规划，因为 IT 部门需要使用该文档来向其客户全面地战时自己。 确保该文档可以到达大部分潜在的利益相关者，例如在企业内部网站上进行发布或分发装载该文档的 CD盘片。 监控 服务级别管理只有在服务级别被事先明确地定义并符合外部约定目标的情况下 才能得到有效的监控。服务级别必须从客户的角度加以测度和评价。监控也不仅限于技术方面，而应该包括流程方面的问题。例如，直到用户得到
14、服务已经恢复的通知，他们可以假定服务仍然是不可用的。 可用性管理和能力管理通常可以提供与服务级别相关的技术目标的实施情况方面的信息。有些情况下，还应当由服务支持流程特别是事故管理提供一些信息。然而，仅仅评价内部参数是不够的，因为这些信息与用户的体验是无关的。诸如响应时间、升级时间和支持等方面也应当是可量化的。只有在结合来自系统和服务管理两方面的管理信息的情况下才能获得一个全面的考察 。 报告 客户报告（服务报告）必须按照 SLA中约定的时间间隔提交。这些报告需要对约定的服务级别和实施测量到的服务级别进行比较。有关报告内容的例子包括： 在指定的时间内的可用性和宕机时间。 高峰期间的平均响应时间。
15、 高峰期间的交易速度。 在 IT 服务中出现的功能性错误的数目。 服务降级的频率和持续时间。 高峰期间的平均用户数。 成功或不成功的安全侵害企图的数目。 服务能力被利用的比例。 完成和未完结变更的数目。 提供服务所耗费的成本。 评审 服务级别必须定期进行评审。在评 审过程中，需要考虑下列几个方面： 自从上次评审以来签订的服务级别协议。 与服务有关的问题。 服务趋势的确认。 在约定的服务级别围内对服务所作的变更。 对程序所作的变更以及对所需的额外资源所作的估计。 未能提供约定的服务级别的原因。 如果 IT 服务未能满足约定的服务级别，则应该与用户协商并采取一些行动以改进服务质量，如： 制定一份服
16、务改进方案，分配额外的人员和资源。 对 SLA中定义的服务级别进行修改。 修改有关的程序。 修改运营级别协议和支持合同。 对于许多正在引进服务级 别管理的组织来说都存在这样的一个讨论，即是否应该对未能实现服务级别协议的情况进行惩罚。这确实是一个难以回答的问题，因为服务级别管理是基于 IT 部门和 IT 服务的用户两者之间的互动而进行的，并且这两者通常都在同一个组织里。 在这样一种情形下， IT 部门和用户都是为了同样的公司目标而努力，因而惩罚措施特别是财务上的惩罚是否可以增进公司的利益是值得怀疑的。因此，基于共同的利益而就需要采取的防止不能实现服务级别的措施签订协议要好得多。然而，如果 IT 服务提供商从一个外部 IT 提供商获取了某项服务，则可以采用某些惩罚措施。但是 ，在这种情况，双方签订更可能是一份具有法律约束力的合同（ UC）而不是一份 SLA。
