服务级别协议是指提供服务的企业与客户之间就服务的品质、水准、性能等方面所达成的双方共同认可的协议或契约。

服务级别协议是指提供服务的企业与客户之间就服务的品质、水准、性能等方面所达成的双方共同认可的协议或契约。

典型的服务级别协议包括下列内容：

参与各方对所提供服务及协议有效期限的规定； 服务提供期间的时间规定，包括测试、维护和升级； 对用户数量、地点以及/或提供的相应硬件的服务的规定； 对故障报告流程的说明，包括故障升级到更高水平支持的条件。应包括对故障报告期望的应答时间的规定； 对变更请求流程的说明。可能包括完成例行的变更请求的期望时间； 对服务级别目标的规定； 与服务相关的收费规定； 用户责任的规定(用户培训、确保正确的桌面配置、没有不必要的软件、没有妨碍变更管理流程等)； 对解决与服务相关的不同意见的流程说明。

服务级别协议体系：服务级别管理的“导航图”。

为了明确业务部门和IT服务部门各自的责任，服务级别管理人员需要针对双方已达成共识的服务级别需求，签订服务级别协议。同时，为保证完全履行服务级别协议，IT服务部门还需要分别与内、外部供应商签完运作级别协议（Operation Level Agreement）和支持合同（Underpinning Contract）。这三份协议构成了支持服务级别管理流程运作的服务级别协议体系，是明确各方主体权利和责任的书面依据。因而也构成了服务级别管理流程顺利运作的“导航图”。这三份协议之间的结构关系可用【图1】表示。

服务级别协议，是IT服务部门与客户就服务提供与支持过程中，关键服务目标及双方的责任等问题协商一致后所达成的协议。服务级别协议应当使用业务部门和IT服务部门都理解的语言，而不宜采用技术化的语言。这样可以便于业务部门和IT服务部门之间的沟通，减少双方之间的摩擦，同时也有利于后期的评审与修改。

运作级别协议，是指IT服务部门和组织内部某个具体的IT职能部门或岗位，就某个具体的IT服务项目（如邮件系统的可用性、传真服务的可用性等）的服务提供和支持所达成的协议。IT服务部门作为一个整体与业务部门签订服务级别协议后，为了保证能够达到约定的服务级别目标，需要将客户的业务需求转化成具体的服务项目，并针对这些服务项目和相应的内部IT职能部门或岗位签订运作级别协议。

支持合同，则是指IT服务部门与外部供应商，就某一特定服务项目的提供与支持所签订的协议。如IT服务部门为了达到服务级别协议中所确定的有关通信系统的可用性级别目标，往往需要租用外部供应商的通信线路和设备等。此时，为了保证通信服务的稳定性和可靠性，IT服务部门需要与外部供应商签订相应的支持合同。

需要说明的是，服务级别协议和运作级别协议通常只是IT服务部门内部以及业务部门之间明确各自责任和服务目标的一个书面说明，而不属于正式的法律合同，而支持合同则通常是IT服务部门与外部供应商之间签订的具有法律约束力的正式合同。

在建立服务目录后，必须设计最合理的服务级别协议构架，以确保覆盖所有的服务和所有的IT系统的用户。构建SLA的方法有三种主要方法：

基于服务

制定的每一个服务级别协议针对一个服务，除非不同的用户对同一个服务有各不相同的特殊要求。在这种情况下，同一个服务级别协议下需要设立不同的指标体系。签署服务级别协议的时候，需要考虑到用户范围，让不同的用户范围代表签署。或者可以采取分开签署不同的协议来加以避免一些不必要的麻烦。

基于用户

确保一个服务级别协议只针对内部一个单独的用户群后，那么这个协议将包括用户使用的所有服务，能够包含所有的服务和所有的用户。

从用户的角度来说，他们可能会倾向这种协议，其所有的需求都被包含在同一份文件里。一般只要一次签字就可以了，这种比较简单，但是对服务级别管理项目推动小组来说，可能工作量会有所增加。

多层次服务级别管理

在服务级别协议初步稳定实施一段时间后，可以根据需要选择采用多层次SLA结构。比如类似以下三层结构：

1.公司层面：包含适合所有用户的大类服务级别管理问题。适用于比较稳定的服务，系统不会频繁更迭和升级。

2.用户层面：包含所有与个别用户群体有关的服务级别管理问题，不管这个用户组使用什么样的服务。

3.服务层面：针对中国移动通信内部某个特殊用户群体，以及与这个用户群体相关的某个特殊服务。

服务级别协议定义了开发人员和客户之间正式理解和沟通的基础。Simon Jackson探讨了为什么项目需要一个服务级别协议。

服务级别协议（Service Level Agreement，SLA）用来管理服务的表现。尽管它可能还不能成为开发项目的一个常见部分，但是SLA可以用来提高开发过程的质量，减少项目失败的风险，加强与客户之间的关系。SLA体现的是专业性——发表和依赖可接受的标准表明公司了解其业务和客户。本文将探讨软件开发里的服务级别协议：为什么需要用它，以及创建这样一个协议的诀窍。

什么是服务级别协议

SLA Information Zone的Web网站将SLA描述为“定义两者之间关系的文档”。SLA为开发过程的要素设定了基准，这被认为对于保持开发小组和客户之间的关系十分重要。

尽管不是一个正式的合同，但是SLA能够被用作是正式交易的一部分。合同与SLA之间的不同之处在于文本的目的和严谨性。合同是为了将关系正式化，并具备法律效力；而SLA用来改善关系，并不具有法律效力。但是，如果无法实现SLA的条款，那么你将伤害或者破坏这种关系，这与不履行合同的后果一样。

为什么要实施服务级别协议？

软件开发在交付方面的名声并不好。Standish集团公司2003年的CHAOS报告显示，在要求和预算进行开发碰到困难时，超过一半的IT项目都会遭到“质疑”。

项目失败的原因各式各样，但是各种研究都表明标准对于项目的成功至关重要，例如用户的参与和清晰明了的要求就是这样的标准。SLA是将这些原理从书本里拿出来放到实际项目里进行实践的工具。

同样重要的还有加强与客户之间的关系。编写SLA要求对专业软件开发的理解和对客户的真正责任。你清楚自己的要求，并坚持这一点，给客户以理由相信你的能力和知识。

为什么应该囊括服务级别协议？

项目成功的主要因素包括：选择项目、客户的参与、正式的项目管理和要求管理。

根据项目的大小、计划安排和风险，你还希望考虑软件开发的最佳做法，比如质量保证和单元测试。

加入客户认为重要的内容也很重要。你可能并不总是同意，但是如果必须的话，提问、倾听和协商是很重要的。

要记住，SLA定义的是关系；它以协议和理解为基础。通过获取用户的投入，你是在加强关系，改进整个过程。

选择项目方法

一开始，选择一个适合项目的项目方法似乎是不可理喻的。从本能上讲，我们在寻找一个真正的途径，也就是有效地实现项目成功的完美方法。听够了任何过程布道者的花言巧语，你也会开始相信。唠唠叨叨的挑剔之语总是存在，但是——如果他们的过程这么好，那么那么多其他的过程是怎么来的呢？

忽略伪宗教者的言论而把注意力放在客户和项目上很重要。每个客户和每个项目都不相同——没有哪个方法是万能药。

替代方法有很多，所以你应该选择一种适应你具体要求的方法。敏捷软件开发方法的先锋Scott Ambler 在他的文章《One Size Fits None》里指出，“做到这一点要求对项目的了解，以及对各种方法的优势和劣势的了解”。

SLA必须申明所选择的项目方法以及相关的特性和性能标准。客户可能不是非常关心选择的是哪种方法，但是他们会关心它会如何影响项目。

客户的参与

“早发布，常发布”这个格言常常是吹嘘得多但实际做到的少。这里面所隐藏的意思是客户在项目实施过程中不应该听到任何不利的意外：比如“我们超过了预算50%”或者是“至少还需要多花两个星期”这样的话。

让客户参与进来的策略包括会议、共享的工作空间和正式的问题管理。

会议

定期的会议，最好是每周一次，但这常常不受开发人员的重视，虽然它们可能会成为项目的支柱和救星。如果运用合理的话，它们会帮助解决问题，加强关系，加深小组对客户要求的了解。但是如果运用不当，它们就会浪费时间并打击信心。

SLA必须确定会议的频率及内容才能够让会议产生效果。这些内容包括有一个固定的议程，指定一个主席、计时员、书记员，告知行动项目和分发会议记录。

对于如何组织好会议，去拜访一下你所在地的（专业）主持人。这些会议都有固定的规则；例如它们都要按时开始和结束，发言人的发言要按时间表来。这样做的结果就是，它们不会退化变成喋喋不休的个人独白。

共享的工作空间

项目会带来很多信息——文档、讨论、问题记录、联系信息表和事件。集中和共享是协调项目和保持用户参与的关键因素。

要变得真正有效果，整个项目小组就必须能够从可能的渠道获得资源——从办公室、家里或者是现场。基于Web的企业内部网是一个好的解决方案。

这是客户关系管理中最重要但是实践最少的地方。在任何项目进行的过程中，会产生很多疑问、问题和建议。捕捉、保存、优先对待和处理这些事情对于推动一个客户认定为成功的项目是极其重要的。交付了客户想要获得的内容但是仍然失败的例子还是有的。这也许是因为项目要求发生了改变，或者是因为没有在文档里完整地表述出来。听取客户的意见，一产生问题就立即着手解决，这样我们才能够将成功的机会最大化。电子邮件不是完成这项任务的好工具。我常常会看到客户关系由于对电子邮件里虚假内容而迅速恶化。应该维持单一的、集中式的问题登记，也许是在企业内部网里。技术并不是那么重要，但是所有人都应该能够看到这些问题的登记信息，并经常监视和审查。

正式的项目管理

一般来说，项目管理要求具有不同的软件开发技能。尽管如此，高级开发人员经常被要求除了领导开发之外还要管理预算、规划资源、负责人员招收、管理客户关系和其他事务。这不仅仅是不合理，这对于客户关系常常是致命的。

项目管理需要额外的代价，这包括客户有的时候不愿意开会，尤其是如果他们过去的项目管理成绩不佳。定义项目管理成果和标准的SLA将在某种程度上有助于减轻他们的忧虑。

要求管理

理解客户需要什么是交付价值的重要部分。这很复杂，因为在某些情况下，客户可能只有对他们想要什么的一个未成型的想法。在所有的情况下，他们要依赖开发小组的技术专家来给他们建议。进行要求管理的方法是软件开发方法的基础。例如，敏捷软件开发方法通常都假设客户对需要什么没有一个完整的理解。所谓的瀑布开发方法则是从一个正式和静态的且定义良好的要求开始。要求管理因此与项目方法的选择密切相关。

SLA必须推荐要求管理的方法，以及如何处理项目实施过程中要求的变化。这包括一个变化控制过程，从而对整个项目的第二次发布或者重新报价提出了功能上的要求。

软件“最佳做法”

软件开发有专门的做法；正确地使用这些做法能够提高软件质量和生产效率。这些做法包括每晚构建、功能审查、缺陷计量跟踪、代码注释、编写文档、质量保证、变更、同事评估、单元测试和用户认可度测试。

不是每个SLA都需要用到上述所有的做法；这要由项目、客户和项目小组的技术、经验和创造力来决定。不要害怕做事情的新方法——成功就是一个创新的过程。

实践中的服务级别协议

就像大多数的性能测定一样，SLA应该是SMART的：具体（Specific）、可测定（Measurable）、可实现（Achievable）、现实的（Realistic）和受时间限制的（Time-bound）。我将使用一个用于功能测评的基准作为说明上述内容的实际例子。基准测试的第一部分相当简单：“我们将测评软件的功能。”

上述说法会带来一些显而易见的问题：功能测评是什么，为什么需要它？由谁来进行测评？如何进行测评？什么时候来测评？所以它肯定是不符合SMART标准的——因为它从中传达出来的信息过多。

要改进它，首先要做的就是让这个说法更加具体，申明要实现什么，为什么，以及如何实现。“功能测评用来检查软件的完整性，看它是否满足既定的要求，是否满足商业需要。这就能够保证发布的软件可以满足客户的预期。

“在进行第一次测评之前，提供商要以一小点一小点的形式将要求总结出来，接受客户的检查，并得到客户的认可。

“功能测评包括整个项目小组的一次会议——也就是说，包括开发小组和业务小组。在会议中，开发小组将陈述每个要求是如何在软件里实现的，这要用软件最新的开发版本来说明。

“客户负责确定每个功能是否已经被正确地实现。”这就要明确得多。将要求具体化还可以让开发小组检查标准是否是可实现的和现实的。

这些测定在很大程度上取决于开发小组的能力——技术、知识、经验和时间。上面这种说法仍然不能完全满足SMART的标准：它没有一个时限，也无法性能的测定提供一个基础。还需要更多的细节：

“将进行三次功能测评：第一次是在代码完成50%的时候，第二次是在完成75%的时候，而最后一次测评是在软件进入正式测试（formal testing，QA）之后。在要被解决的功能里，90%将被客户认可为被完成。”

在这种情况下，计划安排要以构建阶段里的里程碑为基础。更加具体的日期可以通过这些点提供给项目规划。我们还需要表述出一个清晰的、可测定的标准。如果做不到这一点，就可能在开发过程中，在规范或者沟通过程中出现问题。

这是项目的目标，也是一个早期预警系统。它将再次确保客户了解它们将被问到是否已经满足了项目要求，并给予他们你将向他们交付物有所值的软件的信心。使用它，你就可以表明自己知道软件开发里的常见问题——不完整或者不连贯的要求——并表明自己有决心解决这一问题。

每天都要应用服务级别协议

你当然会“得到你测定的东西”，但是SLA不仅仅是简单地用作是一种测定方法。通过设定可实现的和现实的基准，它成为了一个用来改善软件开发和增强客户管理的工具。尽管软件开发的质量在过去十年里得到了提高，但是要改进的地方还有很多；SLA就是解决问题的一种方法。

监控

轻松监控SLA的先决条件

签署SLA，会有以下形式：IaaS、PaaS和SaaS，分别是基础设施即服务、平台即服务和软件即服务。企业应该确保它们能对所有签署的SLA的进行监控。

第三方监控

审计是很重要的一步，能够确保安全，保证SLA的承诺和责任归属，保持需求合规。企业可以用第三方监控。如果企业在云中运行业务关键的应用，这项服务应该保持定期审查，确保合规，敦促厂商与SLA步调一致。

转换SLA，帮助整个业务成果

尽管云计算市场正在迅猛增长，中小企业的IT大多数都不够成熟，不足以支撑基于基础设施的SLA来帮助义务发展。企业应该选择最适合业务需求的SLA，而不是急急忙忙签署协议。

如果企业操之过急，直接选择基础设施级别的SLA，可能会由公司内部产生很多话费。比如说，某企业想要99.999%的高可用性，服务商就会提供更多冗余和灾难恢复，结果花费大幅提高。

当聚焦于节俭型业务级别SLA时，云计算SLA监控应该具有逻辑性和可行性，而不仅仅是基础设施级别的SLA。