【Azure】微软 Azure 云中的 SLA 解析：什么是 SLA、影响 SLA 的因素有哪些、如何进行计算 SLA

回眸笑倾城分享新手 2024-01-26 17:01:26

文章目录

三、影响SLA的因素+ 四、如果发生服务中断 (服务级别协议问题)如何理赔+ 五、关于微软 Azure 云中 SLA 的几个重要的总结（重要）+ 文末总结

前言

本文将讨论微软 Azure 云中的服务级别协议（SLA）。在当今数字化时代，云计算已成为许多企业和组织不可或缺的一部分。SLA 是云服务提供商与客户之间的合同，它定义了云服务的可用性和性能指标，以确保客户在使用云服务时能够得到稳定、可靠的体验。通过本文的阅读，读者将能够更好地理解微软 Azure云中的 SLA，并为选择合适的云服务提供商提供有价值的参考。无论是企业还是个人用户，在使用云服务时都应该对 SLA 有清晰的认识，以确保其业务的顺利进行。

一、什么是 SLA

SLA：服务级别协议（英语：service-level agreement，缩写SLA）也称服务等级协议、服务水平协议，是服务提供商与客户之间定义的正式承诺（摘自：[维基百科定义]）。SLA的概念，对互联网公司来说就是网站服务可用性的一个保证。

这里注意定义中所说的服务等级，SLA通过计算服务的正常运行时间百分比来定义该级别，例如：服务 X 的 SLA 为99.99%，这意味着该服务每年可能会停机 52 分 35 秒，Y 服务的 SLA 为95%，这意味着该服务可能会下降 18 天 6 小时17 分 27 秒。因此，在获得所需服务之前，检查 SLA 是至关重要的。

对于SLA这里要提两个重要的词

Uptime（Uptime Percentage） : 运行时间（主要性能承诺通常侧重于运行时间，或者是产品或服务成功运行的时间百分比。一些 SLA 也侧重于其他因素，包括延迟或服务必须响应请求的速度。）+ Downtime : 故障时间（服务不可用的持续时间）

下表是关于 SLA 百分比与故障时间的对比表，可以更好的了解一般厂商所给的 99.9%，99.99% 和 99.999% 的区别：
SLA 百分比每周停机时间每月停机时间每年停机时间991.68 小时7.2 小时3.65 天99.910.1 分钟43.2 分钟8.76 小时99.955 分钟21.6 分钟4.38 小时99.991.01 分钟4.32 分钟52.56 分钟99.9996 秒25.9 秒5.26 分钟

在上表中这些数量是累计的，这意味着多个不同服务中断的持续时间会合并或加在一起。可以看出 SLA 都是百分之99以上，但是在年区间内，停机的时间差异巨大，想想如果在企业中一年有3天服务不可用的影响会有多大。估计运维同学已经哭晕在厕所，并且想好了离职申请怎么写。

对于上表的计算时间，这里提供一个链接可以进行计算（可能会失效，如果失效可以评论留言给博主）：

https://www.slatools.com/sla-uptime-calculator+ https://uptime.is/

二、微软 Azure 云中的 SLA

在 Azure 云中各种服务都有自己的 SLA 服务级别，比如在 App Service 中，Azure 保证运行在云中的应用99.95%的时间是可用的，但请注意，无论是免费层还是共享层，都不会为应用提供 SLA。比如在Azure SQL中，Azure 的 Azure SQL 有很多层，每一层都有自己的 SLA。最低 SLA 为99.95%。

这里不一一举例具体的每个Azure服务的SLA，详细可以参照官方链接（在哪里可以访问 Azure 服务的 SLA）： https://azure.microsoft.com/en-us/support/legal/sla/summary/

注意：在Azure中，付费的Azure服务的正常运行时间至少为 99.9%。

2.1 Azure 中的 Uptime Percentage

云服务正常运行时间百分比(月)的计算方法为：对于给定的Microsoft Azure订阅，在一个计费月内，最大可用分钟减去停机时间除以最大可用分钟。月正常运行时间百分比用以下公式表示:

Monthly Uptime % = (Maximum Available Minutes - Downtime) / Maximum Available Minutes x 100 每月正常运行时间% = (最大可用分钟 - 停机时间) / 最大可用分钟 x 100

2.1.1 Azure 中的复合 SLA

复合SLA为将不同的服务产品之间的SLA组合在一起时，最后得到的SLA被称为Composite SLA(复合SLA)。云厂商提供多种不同的云服务，当各个云服务串行或者并行在一起时，复合SLA就出现了，举例来说

（一）串行SLA

在此示例中，存在三种可能的故障模式：

应用程序服务不可用+ Azure SQL 不可用+ 两者都不可用

因此，此“系统”的总体可用性必定低于99.95％。其可用性的计算方法为：

串行系统可用性 = 组件1的可用性 x 组件2的可用性
            = 99.95% × 99.95% 
            = 0.9995 x 0.9995
            = 0.99900025
            ≈ 99.9%

（二）并行SLA

如下图，我们先只计算蓝色虚线框内的SLA

并行可用性的计算方法为：

并行系统可用性 = 100% - (组件1不可用率 x 组件2不可用率)
            = 100% - (0.05% x 0.05%)
            = 1 - (0.0005 x 0.0005)
            = 1 - 0.00000025
            = 0.99999975
            ≈ 99.9999%

（三）混合的SLA

如下图，web1和web2是并行的SLA，他们又和Load Balancer 组成了串行的SLA，这样整体的SLA计算方式为，先计算并行的SLA结果，之后再和串行的SLA相乘。

混合系统的可用性 = 串行系统可用性 x 并行系统可用性
              = 99.99% x ( 100% - (0.05% x 0.05%) )= 99.98%
              = 99.99% x 99.9999%
              = 0.9999 x 0.999999
              = 0.99989901
              ≈ 99.98%

三、影响SLA的因素

根据上述的SLA计算过程，我们不难想到提高SLA和降低SLA的情况
降低SLA的因素提高SLA的因素增加多的服务添加多层服务使用免费/预览服务增加可用性区域不同的服务(例如根据需求选择不同的数据库类型)不同的服务层级(根据不同的SKU，更高的服务层级SLA一般更高 ) 个人觉得不一定要过于追求超高的SLA，需要根据企业自身情况来衡量在Azure中的定价服务，以及自己的产品架构。但是自身产品的SLA一定要确定，因为这影响着自己产品的服务。