2014年11月19日，德克萨斯州一家承包公司的IT部门开始收到报告，称其员工无法使用基于云计算的微软Office 365电子邮件系统。用户无法通过手机或Outlook接收电子邮件。随着时间的推移，一些用户回复了邮件，另一些则没有。当美国员工签字后，国际员工开始报告类似问题。对于一些用户来说，电子邮件会关闭24小时。
在宕机之后，IT部门的领导们聚在一起，向微软提出了一项索赔，称其违反了公司的服务水平协议(SLA)，该协议保证Office和其他微软在线服务在每个月的可用时间为99.9%。如果该服务的收费低于这个标准，则可向客户发放25%的积分。但他们从微软得到的回应让他们感到惊讶:Web访问仍然可用，所以该服务在技术上不是不可用的，因此它没有违反SLA。
“愿意、有能力、有足够知识使用这个选项的人很少，”IT部门的一名高级员工说，他要求匿名，以免破坏与微软的关系。作为回应，这家承包公司教育员工在Outlook宕机时如何使用网络邮件访问。
作为对此事的回应，微软发表了一份声明，称其努力提供“始终可用的服务”，并表示sla已经到位，为这一承诺提供财务保障。如果微软在线服务在某个月的可用时间少于95%，客户可以获得该期间的全额账单积分。
然而，本集说明了理解云sla中的所有术语和条件的必要性。企业协议可能很复杂，所以在评估Microsoft Office 365 (SaaS产品)和Microsoft Azure(包括IaaS和PaaS组件)的sla时，这里有10件事需要注意。许多技巧也适用于其他云平台，如AWS，但它们是专门针对微软云服务的。请参阅微软Azure IaaS SLA正常运行时间保证列表在这里；在线服务SLA在这里。
- 阅读了合同和所有支持文件
这似乎是显而易见的，但许多人并不真正阅读合同，就像他们浏览最终用户许可协议一样。“我遇到过很多人，他们快速浏览完幻灯片，然后签了合同，”保罗·德格鲁特(Paul DeGroot)说，他是Pica Communications的顾问，为客户提供微软授权方面的咨询。分析合同内容后，如有不明白之处，应寻求帮助。理解SLA的关键是阅读它。
Pica Communications顾问Paul degrot说
合同可能会令人困惑。DeGroot说，有时相关信息在支持文件中。SLA参数可以在文档的一节中概述，但合同可能受制于其他文献中定义的术语。确保阅读整个合同，包括任何证明文件。
- SLA违反必须报告
有些供应商会在服务中断时自动给客户授信，而有些则不会。客户必须报告他们认为违反SLA的任何中断。DeGroot遇到过这样的情况:客户经历了多天的停电，并确信他们的账单将简单地反映出该事件，并计入信用额度。但如果你不记录和报告它，你就没有任何方法证明你经历过停机。如果您有问题，记录它，立即通知您的提供商，并就违反SLA提出索赔。
微软要求客户在事件发生后的月底之前向客户支持部门提交SLA违反声明。(例如，如果事故发生在2月中旬，客户必须在3月底之前报告。)索赔要求必须包括:事件的详细描述;事件的持续时间;受影响的用户或站点数量;描述你为补救情况所做的努力。
- 正常运行时间为99.9%的SLA仍然允许每年8小时的停机时间
微软的许多服务都保证99.9%的正常运行时间(3 - 9)。听起来不错。但是，在一年99.9%的时间里，仍然允许每年8小时45分钟的停机时间，而不违反SLA。如果有一天你的工作量有8个小时不在，你会有什么感觉?这个正常运行时间的计算器可以帮助用户根据SLA正常运行时间保证，预测他们应该从提供商处获得多少停机时间。
- 每个服务都可以有自己的SLA
每个服务都可以有自己的SLA正常运行时间保证。例如，微软Azure虚拟机有99.95%的正常运行时间保证(如果部署在两个可用性集;SQL数据库的正常运行时间保证为99.9%。大多数微软在线SaaS产品也有99.9%的正常运行时间保证。但是99.9%的正常运行时间允许在不违反SLA的情况下，一个月内出现多达43分钟的停机时间。
正如微软专家博主特洛伊·亨特所说指出，这些停机事件不必同时发生，提供商的SLA才能保持完整。例如，如果您有一个依赖于Azure VMs、SQL数据库和Azure存储的系统，那么在每月的第一天，Azure VM可能会宕机21分钟，从而降低您的工作负载。第二天，Azure SQL可能会继续宕机42分钟，导致应用程序宕机。这两者仍然在SLA的条款之内。关于这一点，博主Brent Stineman探究了更多如何在这里计算跨多个服务的聚合sla。
- 为了启用SLA，可能需要跨多个实例部署vm
云计算的咒语之一就是为失败做好准备。事实上，包括微软和AWS在内的一些云服务要求客户在构建系统时做好未能满足SLA条款的准备。例如，AWS要求虚拟机部署在多个可用区域(AWS云中的不同数据中心)，并且虚拟机的两个副本必须不可用，才能违反SLA。2020欧洲杯预赛微软使用术语可用性集而不是可用性区域，但其思想是相同的。客户必须注意最佳实践体系结构，以确保其系统符合SLA的条款。
- 迁移到健康的VM可能会导致停机，这可能不会违反SLA
要记住的一件事是，如果您将系统架构为容错并将故障转移到另一个VM或Availability Set，那么该操作本身可能会导致问题，例如重新启动。如果您的系统因为没有设置为处理迁移到新vm集而宕机，那么该故障不是提供商的错误，也不会被视为违反SLA。Netflix的Simian Army Chaos Monkey和Chaos Gorilla等工具可以帮助AWS客户测试他们的系统对宕机的容忍度。
- 服务真的不可用吗和是你的供应商的错吗?
在上面这家德克萨斯公司的例子中，IT员工认为宕机是微软的错，事实的确如此。但该服务并不是真的不可用，因为网络访问仍然是一个选项，所以它不计入SLA。所以如果你的应用宕机了，这真的是你的供应商的错吗?是否所有接入点都无法提供服务?类似地，有时云服务宕机，但这不是供应商的错。该公司表示，如果微软的SLA被破坏，服务必须因为“在微软控制范围内的情况”而中断。当出现中断时，检查是否有什么原因导致了中断。例如，你到云的网络连接好吗?客户必须证明他们的供应商是错误的，并且服务确实宕机了，以便为SLA违反获得赔偿。确定您的提供商是否已中断的一个有用工具是服务运行状况指示板，微软和AWS会在其中报告哪些服务不可用。
- 服务条款可以改变
云计算是一个快速发展的行业，供应商提供的产品可能会发生变化。当产品发生变化时，sla也会发生变化。通常，SLA会概述提供商是否必须通知客户服务或SLA的更改，或者客户是否应该为服务中断做好准备。但是，不同的提供商和不同的服务是否会通知客户变更可能会有所不同。如果对服务的突然更改会影响您的工作负载，请检查以确保您的提供商将通知您此类更改。
咨询公司Directions on Microsoft的研究副总裁唐纳德•雷塔拉克(Donald Retallack)指出，微软将通知客户其核心产品的“颠覆性变化”。微软将“破坏性变更”定义为:“要求客户或管理员采取行动以避免对在线服务的正常操作造成重大影响的变更。”例如，微软承诺在其Dynamics CRM平台发生颠覆性变化前6个月通知客户。但其他非破坏性的变化也可以在微软不通知客户的情况下发生。
- 计划的停机时间并不总是计算在SLA中
服务因意外原因宕机是一回事，但有时云服务宕机可能是因为服务提供商宕机。例如，Verizon就有一个“几乎”48小时计划停机今年早些时候。这样的中断可能意味着服务宕机，但它不会计入SLA。客户可以要求供应商确保他们将被告知任何计划的停机时间。
- SLA可能不附带“预览”或测试服务
许多供应商提供免费的服务层或其他处于预览阶段的产品。通常，这些免费和预览服务不在sla的覆盖范围内。所以，您可以随意使用它们，但在依赖它们实现关键功能之前，请确保您了解术语和使用它们的风险。