复杂的云服务SLA如何管理

[db:作者]

云服务级别协议（SLA）的定义通常是服务提供商和消费者签署的一份合同。云服务提供商和消费者约定合同条款，比如服务级别质量应该如何，要是质量低于提供商保证的级别，提供商如何赔偿。
比如说，平台即服务（PaaS）提供商和PaaS消费者在SLA中约定：平台在99.999%的时间里可供PaaS开发人员使用。双方约定，如果平台无法使用，提供商就要为平台停运支付一笔费用；这笔罚款并不适用于计划维护、硬件故障或天灾。




SLA的扩展定义
国际行业协会电信管理论坛（TM Forum）扩展了SLA的传统定义，加入了提供其他类型服务的有关方的预期要求。发起方与接收方之间可能存在的一些关系如下：

服务提供商与最终用户

服务提供商与厂商

服务提供商与企业

企业与最终用户

网络提供商与云服务提供商（网络访问提供商）

厂商与网络提供商、服务提供商或企业

内容提供商与内容聚合商或广告商
并非所有有关方都基于云；比如说，厂商可能是内部型的，也可能是基于云的。
复杂的SLA关系
不妨看一下SLA关系以及每种关系如何变得更复杂。
场景1：一家云PaaS提供商开始订有三份SLA（并非同时签订），这是它分别与PaaS开发人员、厂商和企业签订的。如果该提供商为另外的厂商提供服务，就需要与它们签订新的SLA。每份SLA随带一系列不同的起始和结束服务日期。反过来，每家厂商与服务网络提供商签订SLA。不是所有厂商都与同样的网络服务提供商合作。
场景2：一家云提供商与网络提供商和厂商在SLA中约定了相关条款。如果提供商从新的厂商获得服务，它就需要与每一家厂商签订SLA。每份SLA随带一系列不同的SLA参数。
场景3：一家企业从几家提供商和厂商获得服务。每家厂商为与该厂商签订SLA保障服务级别的网络服务提供商和云提供商提供服务。
SLA参数场景
不是所有的SLA都有同样类型的参数。不妨看一下SLA参数场景。
场景1：一家服务提供商从10家厂商获得服务，就性能、交付和成本等参数，约定了每家厂商的SLA。每个参数的值对每份SLA来说各不一样。
场景2：SLA并不关心软件即服务（SaaS）应用程序是在专有的基础设施即服务（IaaS）上运行，还是在协同运行的IaaS上运行；如果服务提供商破产，客户可能无法将应用程序转移到另一个专有的IaaS。
场景3：SLA增添了无线射频识别事件（RFID）这个参数。可以记录并监测以确保符合SLA的事件包括如下：

事件的实际观察是否成功；

箱子何时装到托盘上；以及

仓库中产品的库存量是否处于最佳数量。

场景4：SLA增添了感测温度的物联网设备这个参数。这些设备可用来测量、记录及监控仓库或供应链卡车中冷藏柜里面易腐食品的温度。符合SLA确保温度在可接受的范围之内，确保万一主冷藏柜出现故障，备用冷藏柜立马可以投入使用。
管理多份SLA
你可能早已被一大堆SLA文档搞得晕头转向，所有有关方对每份SLA抱有不同的期望。一份SLA将服务可用性这个参数设为99.999%，而一些SLA可能设为99.99%和99.9%。
想处理多份SLA，你应该任命一名SLA经理，负责监管各有关方之间不断变化的SLA关系。该经理需要明白，每份协议会有一系列不同的参数。