云计算应用开发实践：服务级别管理

在前面提交票单的时候，读者也许注意到了，在票单提交页面还有服务目录和服务级别协议（SLA）的下拉列表框，本节将介绍它们的作用。

服务级别协议是用户与服务提供者之间通过签订协议的方式来明确定义具体的服务内容与要求。

我国正在制订相关的信息技术服务质量标准评价体系，现在该体系正处在审核阶段，希望尽早实施。在该体系正式发布之前，对于用户而言，特别是依赖于IT服务的企业用户，仍然需要一个合理的服务级别管理标准。原因有两个方面，对于依赖于IT基础设施的客户而言，IT服务的成功与否直接关系到其业务是否能正常开展。在涉及企业业务利益时，与服务提供商的关系将显得苍白。而对于服务提供商来说，也需要一个标准来界定什么是该做的什么是不该做的，从而更好地控制成本。客户与服务提供商之间发生业务纠纷时，往往服务提供商会说自己干了多少工作，给客户服务完全是赔钱。而客户一般不管提供商付出了多少，只关心业务在某段时间发生的故障对自己的影响。所以说一个合理的标准是讨论责任归属和合理控制服务成本的关键。

IT服务中一个非常重要的概念就是SLA，围绕着SLA设计了一整套管理体系，它的作用主要集中在“协议”二字上，它表示服务提供者与客户就某项服务提出的量化指标，它具有法律效力，可以看成合同的一部分。这里我们首先要解释一个名词“服务目录”。

1.服务目录

当我们要提供IT服务给用户时，首先需要与用户协商的是服务的具体内容，这就是服务目录。

对于云计算服务提供平台而言，我们所提供的就是各种云计算服务，比如虚拟主机服务、VPS服务、大规模计算服务（使用Symphony DE或者Hadoop搭建计算环境）、大数据量存储服务，等等。只有清楚了解所要提供的服务，才能为每一项服务需要达到的服务级别与用户协商达成一致，并提供具体报价，因为服务级别与服务成本是成正比的。在OTRS中，可以通过“系统管理”→“服务”→“增加服务”实现，如图10-15所示。

图10-15 增加服务

在服务目录中除了名称、类型这类基本信息外，还有Criticality（重要性），我们可以通过该服务所影响的用户业务来确定服务的重要性。服务的具体内容决定了SLA约束的服务范围，在服务目录之外的内容将不受SLA的限制，具体的报价是不考虑这些额外服务内容的。

OTRS对于服务目录的定义仍然不够详细，这将不利于后期维护、阅读与理解。实际的服务目录要将具体所涉及的计算资源包含在内，要细化到用户到底使用哪些种类的计算资源。由于OTRS的开源特性，在实际使用中我们可以根据需要进行修改。最终目的都是为了便于查阅，在出现问题时有参考依据。

2.创建SLA

现在可以看一下如何在OTRS中创建SLA。单击“系统管理”→“服务级别协议”→“增加协议”，如图10-16所示。

首先选择SLA类型，这里以恢复时间为例来作介绍。选择刚刚创建的VPS服务作为SLA的服务。

图10-16 创建SLA

接下来有个“日历”下拉列表。这就牵扯到SLA中一个重要概念——服务日历。它决定了SLA约束的时间范围，即该服务协议为客户提供的服务时间范围，是7×24（7×24小时是指每周7天每天24小时提供支持服务）还是5×8（5×8小时是指每周5天每天8小时提供支持服务），是否扣除一个法定假期等细节。不同的日历意味着人力与管理成本的差异，在报价结算时要考虑这些细节和时间因素。

在SLA的创建页面中，有很多可供选择的日历。可以通过“系统管理”→“系统配置”→Framework→Core：：Time：：Calendar来进行设置，如图10-17所示。(www.xing528.com)

图10-17 更改服务日历

在服务日历中可以去除节假日或定义工作时间，如图10-18所示。

图10-18 设置日历

设置完服务日历之后，在创建SLA的页面中，可以看到很多时间配置。这些时间配置规定了在多长时间给用户反馈。这在SLA中称为解决时间，它是指当发生某种事件时，完成处理的时间要求，如图10-19所示，页面中分别定义了恢复服务10%，50%以及90%的具体要求，正是这些细致的配置将成本、人员安排、设备配置等因素紧密地结合在一起。

图10-19 创建SLA

3.SLA测量

在实际使用中我们还需要根据服务的具体执行情况，计算SLA是否正确执行。这引出了SLA中的另一个概念——可用性。

具体到我们的例子，用户可以通过检查提交票单的方式来查看服务方是否按照SLA的标准提供了适当的服务。通常的公式是

可用率=（服务日历总时间-停机时间）/服务日历总时间

根据票单上的记录可以计算可用率。而通过可用率就可以看出SLA的实际执行情况。

在实际操作中，一般用户与服务提供商所计算的可用率经常不一样。问题还是出现在细节上。比如某段停机时间是由用户的不当操作造成的，用户往往将其也作为停机时间。但事实上这种时间时应当是由用户自己承担的。服务提供商这时就要将历史票单拿出来跟用户说明情况。

对于云计算而言，由于服务常常需要大量的计算机，并且服务是跨不同区域的。某一个地区的停机对全局的影响都是有限的，但对某个地区的影响确有可能是巨大的。这时就可能需要两个级别的可用性计算，一个是全局可用性，另一个是局部可用性。计算可用性不但对用户有好处，服务提供者也可以清楚地认识到当前服务中所存在的问题，并根据发现的问题持续改进。

在计算可用性的实践中，我们还会碰到很多问题，比如停机这个概念。计算机停机并不一定就是彻底不能用，有可能是其中的某一个功能软件出现了问题。在具体的实践中，要结合票单的优先级来对停机时间进行加权处理。对于严重错误，需要计算所有时间，而对于非严重性错误，比如软件无法更新则可以计算10%的时间或者根本不用计算这部分的停机时间，即把事件的等级与可用性影响关联。

随着用户业务的扩大，中国的企业可能有越来越多的跨地区甚至跨国业务，也就免不了与各地区的服务提供商打交道，服务级别管理协议是业务顺利运行的有力保障。