对您的云计算服务进行评估并编写SLA要比为简单连接服务（如虚拟专用网VPN）制定SLA要复杂得多。为了正确评估云计算SLA，应了解云计算体验的细节以及实际上是由谁来提供它们。寻找应用程序的工作流程，因为关键应用程序问题可以毁了一个很好的SLA。此外，要确定你有一个实际可行有效的验证和补救方法。

公共云计算服务在其范围内提供了令人难以置信的灵活性和效率，但是其广度范围取决于服务成本、可用性以及性能。这提供了评估云计算SLA中常见错误和最佳实践的信息。其涵盖内容包括响应时间SLA、从网络供应商和云计算供应商处获得保证，混合云计算SLA问题等等。

遵循应用程序的工作流程

云计算服务买家对于云计算SLA的最关键错误是忘记所有应用程序都是真正的工作流程。一个通过网络连接从用户发向应用程序的请求通常是由多个组件组成的。然后，该请求会导致产生流向其他组件的工作——在云计算内的或者返回数据中心的——以及对位于云计算内外数据库的多次访问。最终，通过网络向用户返回响应结果。

如果SLA只关注于这一过程中的某一点（例如与公共云计算托管相关的一部分），那么SLA是没有用的。如果这一工作流程的任意部分中断，那么应用程序就会发生故障。如果这一流程中的任何部分发生性能问题，那么应用程序的使用体验质量就会受到影响。当其他环节只是得到笼统的保证时，那么只是针对云计算内性能或可用性的严格要求是没有任何好处的。

让所有参与者都确保SLA

评估云计算SLA的另一个问题是无法让所有相关参与者都确保SLA。云计算工作流程通常涉及三方——企业本地自有网络的员工、让员工访问云计算的网络供应商以及云计算供应商。具体可能还涉及企业的数据中心（网络与托管）和提供“云计算至数据中心”连接的另一家网络供应商。供应商通常不会撰写或接受用于处理他们所不涉及工作流程环节的SLA。你需要让他们同意成为他们为此收取一定费用的“主要承包商”或者为所涉及的每一方得到或编写一份SLA。

通常SLA中的最大问题是网络连接问题，因为在大多数情况下，除了在云计算本身内部的情况外，云计算供应商是不会提供网络服务。如果你希望严格的SLA，那么你将需要为网络服务编制一份SLA。所以，你应当首先确认你的云计算供应商是否会提供一个VPN或者他们是否能够与你所使用VPN服务的供应商进行协作。在很多情况下，你仍然需要使用互联网来实现用户的连接性，但是VPN将为你提供一个你希望获得保证的坚实网络边界。

思考混合云计算工作流程

混合云计算中的“边界交叉”也会产生SLA问题。工作流程遵循应用程序和业务逻辑确定的路径，如果这些路径在数据中心和云计算之间形成了多个可变交叉，那么就出现了性能与可用性风险。当确保性能或可用性时，你的云计算供应商是无法触及工作流程模式的移动目标的，因此应试图确保你不会在你希望公司保证的工作流程中引入明显的变量。如果你无法做到这一点，那么你将不得不撰写一份非常详细复杂的SLA来解决所有的变量，而且很多供应商根本就不会接受它。

定义云计算SLA的边界

SLA中的最后一个问题就是违规行为的检测，以及处罚和补救程序。一般而言，你或者你的云计算供应商或者其他的网络合作方都不会根据其中某一方的参数测量结果来接受一份SLA。好的SLA会在各方都同意的基础上定义一个边界测量点供独立测量使用，从而进行状态验证。你自己的SLA应确定这些点、将进行的测量以及用于确定是否违反SLA的被测条件。

通常，包交换网络和云计算服务的可用性和性能违反都是基于一个相当长的报告期的——即每周或月的停用情况。所以最好采用“停机间隔时间”这样的协议而不是简单的故障次数，因为后者无法涉及平均修复时间。响应时间SLA也是很难成文的，因为我们很难正确地测量响应时间。如果你的SLA中包括有响应时间，那么就需要花时间来让双方确定将如何对响应时间进行测量。
补救或处罚始终是一个棘手的事。很多用户认为，如果发生SLA违反（也就是通常所谓的间接伤害），那么他们就可以根据业务损失得到赔偿。这种情况是极少发生而且代价昂贵的；与其试图通过谈判来兑现这一协议，还不如花功夫想办法让你的应用程序具有更高的可用性。

用户报告说，SLA中最有用的处罚是一个自动升级条款。如果发生SLA故障，应向供应商运营中心报告这一故障。如果在规定时间没有解决这个问题，或者故障发生频率超过了某一阈值，那么就应向供应商的管理链发送这一故障通知——让更高层人员来负责检查问题并亲自与你联系讨论状态更新和补救措施。这一条款可确保高级管理人员能够关注你的问题，从而提高问题解决的概率。

对于SLA 中的经济处罚，应将处罚金额限于在中断期间服务成本以下作为基线，如果中断情况严重，那么可加上整个测量间隔服务成本。你是否有机会得到这样一个惩罚性条款将取决于你的合同规模以及你成为供应商未来客户的潜力。