SLA承诺7个9的服务可用率能上天吗？

这两天看到一篇技术文章号称把服务从5个9做到7个9的提升实战，并分享了一些技术改进措施。虽然文章中设计架构改造，流量限流容错，但是仍然让我怀疑的是这7个9的高可用有那么容易做到吗？所以梳理一番对7个9的认知，以备后用。

SLA是Service-Level Agreement的缩写，意思是服务等级协议。在云计算环境下，因为涉及环境复杂，清晰的定义服务等级可以保障投入产出比，提高利润率。SLA包含的内容涉及服务类型、服务质量和客户付款等等，从用户的角度来说，比较关心的就是服务质量。一般服务触及的质量指标就是基础服务可用率能达到几个9。

对于几个9的解读很容易让人懵逼，为了方便查阅，有现成的在线查询页面可供查阅（https://uptime.is/99.99999），标蓝色的部分是参数，浏览页面后显示如下：

对于7个9的可用率，一年只有3.2秒的故障时间。在成本一定的情况下其实现难度可想而知。从服务层级上来看，IaaS最难达到，PaaS次之，SaaS最容易实现，其道理显而易见，大量的服务指标依赖底层的高可用保障。所以，我在翻阅Google Cloud Engine的SLA发现，也只有3个9的服务承诺。3个9成为云服务厂商服务企业客户的黄金切割线。

有了3个9作为基础之上，通过在SLA中明确例外情况，可以间接保障可用率的达成，有点像保险合同中的不可抗力量免责之说。如：

故障：硬件、通信、软件和性能监视器。

处于服务提供商直接控制之外的网络问题。

服务拒绝：客户疏忽或有意的行为；不可抗力；战争，罢工，通信不可用；无法获得 SLA 的规定所需的物资和设备。

定期维护：软硬件升级和备份。

在以上例外情况之下，再次计算几个9的可用率。如此设计，可以保证承诺的严谨性。:-)

除了可用率之外，还有专业用户关注的指标：RTO、RPO和性能。万万不能写入SLA，不然7个9的可用率会更难达到。因为可用不代表完全使用，一套系统通过合理的架构设计，非关键性服务可以降级或熔断处理。比如，2018 年春晚直播期间「淘宝崩溃事件」就是里程碑的事件，在经历过双十一的打磨架构之上，容量规划过后仍然没有挡住春节那一刻的新注册用户洪流。说崩溃就崩溃，无法适用于SLA的规则，需要作为重大活动事项来处理。

所以，合理的设计SLA规则，并在成本一定的情况下才能计算出几个9的可用率。不是简单的计算下故障点的故障时间就说达到了几个9，那样算的化日后迟早会吃亏。