一份云服务等级协议（Service Level Agreement，简称SLA）可以增加额外的业务保护，防止业务数据由于云资源短缺而造成的中断。本篇会让你了解到你对你的云SLA了解多少，以及你是否要采取其它步骤来保护云中的业务。

云服务中断之类的新闻近来不断。Amazon的EC2 EBS、Google的Blogger服务以及Microsoft Business Productivity Online Standard Suite（简称BPOS）的云邮件服务，都是最近大名鼎鼎的云服务供应商，不过近来都发生了服务中断。假设你用Google搜索快速检索一下“Microsoft Cloud Service Outage”，你会看到许多页的标题中都展示了一年来Microsoft为其服务中断所作的道歉。在2011年5月时就有至少3次BPOS事故发生，不过所幸的是，所有这些事故并未影响到所有的用户；据称在5月19日的服务中断中仅影响了不到1%的用户不过数小时的时间。

Microsoft不是所有云服务供应商中唯一出事故的。Amazon EC2的中断事故可能是所能找到的最早的一次事故。数以千计的EC2用户和许多著名的站点被迫中断业务，这在业内网上造成了很大影响。出于事故影响范围之大以及预计可解决时间，Amazon糟糕的公关技能并没有太好地解决这次事件，其只是承诺在今后的时间中会做得更好。

这些中断事故在目前无所不在的云计算行业中并非个例。企业级IT系统同样面临着业务中断的可能，而且这类事件对公众而言较在云上的业务中断更少为人所知。由于波及效应，云服务中断事故能容易受人瞩目，不过云服务短缺可能影响数以百计的应用以及数以千计的业务。这类问题的解决方案较其控制途径亦更为困哪。所有这些都表明：假设你计划使用云服务，你必须完全理解其能为你所做的，以及如何保护在事故发生时保护你自己的业务。

用一份云服务等级协议（SLA）保护自己的业务

如果你正在考虑应用云服务，或已经在使用了，以下信息可以帮助你从云服务协定中获取最大的收益。

理解你的云服务协定。阅读每一细项并理解该云服务协定所确保的事宜。许多服务保证99.999%的在线时间，这意味着你在一年525,600分钟中有525,594分钟又45秒里可以访问你的服务。换句话说，你每年的宕机时间可能只有5分钟又15秒。这也意味着在一天的1,440分钟内，你可能只有0.0144分钟的宕机时间（仅仅是一秒钟）。谁不能接受这种情况呢？不过一份表明99.999%在线时间的云服务协定并不意味着你的实际时间绝不会超过上述情况。你可能，不过你有权在供应商无法保证其承诺时获得相应的赔偿。

更重要的是，你需要理解服务可访问不等同于确保数据的可用性。大多数服务会有合适的数据保护机制来保护你的数据，放置物理故障，比如故障磁盘驱动器或者甚至是站点的中断。不过你可能无法保护逻辑故障，比如，错误的删除操作或者软件的漏洞。你还是需要部署一些放置逻辑故障的数据保护机制，无论是数据备份，基于时间点的拷贝或者是连续数据保护（CDP）。数据保护在云中同样具有以意义；你不能只是将这些留给云服务供应商来做。

按需制定相应的解决方案。你还是需要将资源用于构建、规划解决方案来满足你特殊的业务需要。许多人出于云的简易性为其所吸引。如果你只是依靠云服务，让其关照所有日常数据管理，容量规划，负载均衡以及调优，你数据的敏感性就无从谈起，你也无法掌握数据的保留时间、备份的频率，以及数据的性能参数和所需的恢复点目标（RPO）和恢复时间目标（RTO）。

考虑采取混合策略。有些应用或许经得起宕机时间，并对你的业务影响甚微，这类应用就非常适合于云。进行风险/回报分析。大多数数据都并不活跃或被频繁地使用，这类数据都十分适合在云上进行归档。而另一些数据对于性能要求很高，不过其并不一直需要那种性能。这种情况可以制定相应策略，将新的数据放在本地，并将老的数据放在云端，充分利用两边的优势。不过需要确保这种策略适用于该应用；将资源致力于上述工作，以充分理解RPO/RTO，数据敏感性和所需的保护策略，以及使用模式，来保证你可以游刃有余地处理云端的数据。

对于支持云计算服务的超大规模计算系统，我们并不需要太多深入的理解。云服务供应商在建立其系统时并不会过多地考虑其今后的发展，不过这并不意味着你也可以对此完全不顾。在购买、管理和维持你自有系统的过程中有很大的空间可以来降低运营成本和资本支出，你可以将这些资金投资在其它途径，帮助业务增长。不过，用户亦必须完全理解其所签署获得的服务，并且，和内部自有的IT应用一样，必须进行解决方案规划以来确保业务所需，以及为不可避免的业务中断做好准备。

更多请参考：

云计算之SLA

关注云计算中的服务等级协议（SLA）