【IT168 专稿】在浏览即将召开的云计算会议时，我注意到一些会议致力于与云供应商就合同以及SLA进行磋商。阅读相关的会议介绍，不禁会得出一个结论，那就是小心地制定SLA是成功使用云计算的基础。

　　这些会议详细地描述了他们将如何通过如下云计算话题为参会者提供帮助：

　　· 定义正常运行时间，可用性以及性能

　　· 在制定SLA时的谈判技巧

　　· SLA中包括哪些因素：虚拟机可用性，响应时间，网络延迟，等等

　　· 就违反SLA的处罚进行谈判

　　看完一系列有关SLA话题的描述后，难免使人想到如下事实：SLA和增加可用性无关;SLA的目的是为事故之后的法律争论提供基础。

　　然而，并没有任何一个会议挑明了这一点。会议描述看起来像是建议聪明的SLA谈判应该以某种方法确保应用对运行中断具有免疫力。但事实并非如此。

　　实际情况是所有的基础设施都会面临这样或那样的运行中断。尽管对云供应商的能力进行仔细的评估可能能够选择更加强壮的云供应商，而且支付更多的费用可能能确保更快地获得响应或是能够更快地与专门的响应团队进行沟通，但是这些措施对运行中断都不具备免疫力。无论你花多少时间制定SLA协议，都不能保证100%的运行时间。

　　如此说来，为什么人们对SLA如此痴迷?

　　首先，SLA为人们提供了控制意识。坐在房间里，坚决要求特殊的待遇，取消一个合同并使用另一种说法取代现有的表述都会使人们感觉好像是他们在维护自己的支配权。而且这种感觉很棒。但是不要认为你正在从根本上改变云供应商所提供的合同。我在一名律师主讲的SLA会议中了解了这一情况。在花费90分钟对合同进行细微的调整后，他总结说：“当然，你不能过多地改变标准的合同，因为合同是用来减少云供应商的责任。你所讨论的无非就是你将得到多少服务信用。”

　　人们迷恋SLA的另一个原因就是SLA为运行中断之后的争论提供了基础。事前精明可能意味着在事后获得更多的补偿。但是需要铭记在心的就是：无论你如何争辩，都不可能获得有关运行中断所导致的业务损失的全部补偿。

　　再次重申：SLA补偿仅限于抵消服务成本而不是服务中断而导致的损失，而且服务成本通常只占因服务中断而导致的损失的很小一部分。

　　在最大的外包公司之一工作的一名前雇员和我分享了一个例子：他们非常大的零售商客户的网站在黑色星期五宕机了。应用中断了6个小时，导致的收入损失高达5千万美元。你猜该外包公司给零售商的补偿有多少?六小时的服务信用，只有大概300美元。

　　这个故事传递的信息是什么呢?那就是正确地看待有关SLA的讨论。如果你的应用不可用，那么并不能获得全部的损失。

　　投入过多的精力对SLA进行争辩最糟糕的事情就是这可能会使你不能全心关注更加重要的问题：如何确保正常运行时间。如果你在泰坦尼克号上，而且泰坦尼克号撞上了冰山并开始下沉，花费时间讨论你躺椅的位置及情况并不能解决任何问题。

　　最为重要的问题就是你将如何考虑应用服务运行中断以及你有什么选择能够改进正常运行时间?

　　切入点就是将伏尔泰的观察铭记于心：“最好是良好的敌人。”粗略地翻译一下就是完美是优秀的大敌。应用在云计算当中，这一忠告可以看作是“当云供应商的数据中心宣称能够提供远远低于可接受的正常运行时间时，切记不要采纳该云供应商因为他不可能保证99.999%的正常运行时间。”

　　如果采用云计算明显提升了正常运行时间，那么采用云计算就是正确的选择。如果对自己计算环境正常运行时间的可用性没有准确得统计数据，那么一个明显的信号就是迁移到云供应商是朝正确的方向迈出的一步。迁移至云供应商可能并不完美，但是这大大好于甚至不能追踪正常运行时间的环境。请相信我，有太多太多的IT组织无非就是为了保证应用的正常运行时间。

　　你可以采取如下措施改进应用的正常运行时间：

　　1. 设计应用架构应对资源故障。为改进应用的正常运行时间，可能你可以采取的最为有效的措施就是设计应用架构以使在其单个资源发生故障时(例如，服务器故障)能够持续运行。即使服务器运行中断导致了虚拟机中断，应用服务器的冗余保证了应用能够持续运行。同样的，拥有可复制的数据库服务器意味着如果一台服务器宕机，应用并不会陷入停顿。使用应用管理框架，启动新实例取代发生故障的实例确保了在发生运行中断时冗余拓扑能够继续运行。

　　2. 设计拓扑应对基础设施故障。尽管明智的设计在应用的硬件元素发生故障时能够保护应用的可用性，但是如果应用环境发生故障，该设计并不能提供任何帮助。如果承载应用运行的数据中心发生故障，那么使用冗余的应用设计也是枉然。在这种情况之下的解决方案就是实现应用的跨区域分布，这样即使应用的一部分由于云供应商大规模的运行中断而变得不可用，该应用仍能够继续运转。当然，这将使应用的设计更加复杂，但是它在更大程度上提供了停机保护。

　　3. 设计应用部署应对云供应商故障。当然，云供应商所有的基础设施宕机也是有可能的。即使发生这种情况的可能性是相当小的，但也是有可能的。例如，云供应商的整个网络基础设施云发生故障，或者云供应商可能突然关闭。这可能有些牵强附会，但是在过去在线服务都曾发生过上述情况。解决方案就是在多个云供应商之间扩展应用架构。尽管众多供应商声称这样做极具挑战因为不同云供应商的语义各不相同，这使设计能够合并不同功能的应用变得很困难。然而，进行充分的规划和详细的设计后，在多个云供应商之间扩展应用架构也是可能的。

　　从上述讨论可以明显地看出，更高级别的正常运行时间肯定需要增加技术复杂度级别，而技术复杂度级别更高意味着要增加投资规模。

　　做出给定的应用是否需要某一级别投资的决定是一项风险评估工作。当然这应该是一项明确的风险评估训练，需要在业务投资比率，投资以及技术操作复杂性之间进行权衡。该工作并不轻松，而且很可能并没有很简单的答案。然而，和扩大、但却无用的SLA合同争辩相比，这样做更有可能获得可以接受的结果。

　　原文出处：http://www.computerworld.com/s/article/9221644/Cloud_Computing_and_the_Truth_About_SLAs