谈谈云服务和 SLA

云服务在宣传时往往会强调：永远在线、永远可用、永不丢失。但是我们心里都明白，现实离这个差远了。GitHub 在过去 30 天累计宕机 5 次，这已经是非常严重的事故了。既然如此，我们应该信赖云计算以及其他 PaaS、SaaS 业务么？如何衡量一个云服务的可靠程度？

我们为什么需要云计算、云服务？

使用云服务的优势我们都已经耳熟能详：成本低、迅速获得能力等等。但是很多人也会质疑云服务的稳定性，安全性，隐私性。所以在谈可用性之前，先谈谈这三个方面。

稳定性

云服务中断的原因有很多：底层硬件基础设施故障（比如卡车倒车撞断电线杆，导致 UCloud 北京三区机房三路市电全部断电，服务中断超过 14 个小时）、合作伙伴服务故障、新功能上线导致宕机（比如 Cloudflare 的 WAF 敏捷上线导致所有 Web 业务 502），还有硬盘满了、DDoS 攻击等。但是，你自己购买硬件、或者基于 IaaS 部署，稳定性一定远远低于使用云计算服务 —— 云服务面临的上述问题你一个都跑不了，但是云服务厂商的体量比你更大、投入比你更多、冗余度比你更高、有专业的运维团队 7x24 随时救火。总之，云服务厂商的投入远远超过个人或者一般公司的投入。重要的是，稳定性是一个长期指标，在绝大多数情况下，使用云服务的稳定性都是高于自己搭建服务的。

安全性

首先，不存在 100% 安全。不论是黑客攻击、误操作还是故障和「不可抗力因素」都会导致数据丢失，因此所有重要数据必须异地备份。我们常说的「两地三中心」乃至「三地五中心」都是这个道理，因为机房或者你家一把火全烧了也是有可能的。

每次和人辩论是否需要使用云计算时我都会举一个例子：给你 1 万根金条，你会放在自己家里还是去银行租一个保险柜放起来？云计算厂商雇佣了一大帮人每天研究这个问题、投入了一堆硬件资源来做多重备份。因此，你自己部署服务器所获得安全性都不太可能比云服务厂商的高。

隐私性

IaaS、PaaS 业务应该很少会有人拿隐私性说事了，被关注最多的还是 SaaS 的隐私性。的确，SaaS 厂商如果想要看你数据，完全是可以看的。但是，这有一个动机问题：厂商没有动机去主动看用户的数据，他们最多只会看汇总的统计数据。比如在 GitHub，某些部门的员工可以查看每个用户有几个仓库、每天 push 几次，但是他们没有理由去看 push 的是什么。这不仅和业务无关、也浪费宝贵的时间。这些员工本身也签署了保密协议，如果个人的行为导致公司的信用损失，对于员工来说也会面临更严重的风险。

SaaS 的隐私问题就好比去酒店开房，酒店毫无疑问可以打开被房卡锁上的门、甚至可以在房间里装摄像头。但是除非特殊利益关系，知名的 酒店和宾馆从来不会这么做 —— 这是一个真实存在但是却不需要担心的问题。

讲讲 SLA（可用性）

正如不存在 100% 的安全一样。谈 SLA、谈可用性，首先必须承认服务一定会有不可用的时候，只是不可用的程度和时长而已。一个东西是不是高可用，直接问他 SLA 有几个 9 就好了：

云计算业务除非保证 3 个 9 才能被称为「基本可用」。做不到，这个产品就是玩具。而从 3 个 9 迈向 4 个 9，意味着你的服务每年只有不到一小时的时间是不可用的。

以前 YouTube 和 Google 搜索业务的可用度大概是 5 个 9，这其实是一个非常可怕的概念，因为 包含了一切可能发生的事故。「不可抗力」？扯淡去吧。地震、洪水、台风、火山喷发、太阳射线击穿主板、数据中心倒塌、外星人入侵地球，都要在 5 分钟之内恢复服务。同样的，亚马逊声称 AWS S3 冷存储的可用度高达 7 个 9，这也是非常吓人的数字。

相比之下，国内的数据中心都是按照 2 个 9 设计的，一年 3 天不可用，你可以给春节 1 天、元旦 1 天、国庆 1 天，用来机动。这不可用就是不可用，求爷爷告奶奶照样不能用。国内某搜索引擎在北京王府井楼上的搜索业务集群，也只是按照 3 个 9 设计的。

冗余度

N + 2

N + 2 的意思就是，如果一个服务需要一个实例提供服务，那么生产环境上必须由三个一模一样的实例在跑。N + 1 或许很合理，但是只能提供热备容灾。一旦新版本发布又遇到灾难就 GG 了。而且，N + 2 意味着你可以容忍三个实例中的两个都完全下线，你的业务依然都可以正常运转。

大到两地三中心、小到在三家云厂商开三台机器运行三个实例，N + 2 都应该是标配。

需要注意的是，三个实例必须完全独立互相不依赖的，如果两地三中心中有一个需要 24 小时暖机（环境设置、数据迁移、启动服务），那么这就不能叫 N + 2，顶多叫异地灾备、连热备都算不上。

请求控制

高可用依赖非常可靠的流量控制系统。这套系统按常见的维度（源 IP 和目标 IP）来调度是不够的，最好能按业务维度来调度流量。比如说按 API，甚至按用户类型，用户来源等等来调度。因为：

• Isolation：A 用户和 B 用户打在两套系统上的请求，互相同步时可能会造成冲突，需要隔离
• Quarantine：A 用户一个请求可能把整个实例的资源全部吃掉，则时候必须限制 A 用户的请求钉死在一个节点上以顾全大局
• Query-of-death：A 用户一个异常请求，实例直接死了，LB 和热备立刻换个实例，然后 A 用户重发请求，几趟下来整个集群都死了谈什么可用性？

灾难恢复

GitHub 宕机，一宕就是两三个小时的独角兽，但 Git 操作十几分钟就恢复运行；Cloudflare 全球 502，CTO 亲自出马、27 分钟实现了恢复业务和降级运行、1 小时 8 分钟完成代码回滚。这些事件，涉及到的都是灾难恢复。

15 分钟

之前我说过，云计算业务「3 个 9 才能被称之为 基本可用」。这 15 分钟就是一个非常关键的分水岭。从 2 个 9 迈向 3 个 9，看的就是这 15 分钟。如果云服务挂了，从故障开始到 15 分钟之内还没有恢复，如果不是大型灾难、基本可以认为这服务不靠谱。为什么这么说？因为 15 分钟就是人力的极限。出现问题自动化报警，SRE 团队立刻开电脑、连内网、打开 Dashboard、按照已有应对方案动手解决问题，至少需要 15 到 20 分钟。一家公司如果只靠堆运维、三班倒、7x24 值班、电脑不关机，也只能够维持三个 9 的 SLA。

除了堆人，15 分钟恢复服务的关键点是 常驻 和 热备。常驻热备灾难恢复，就是你必须同时跑至少两套一模一样的服务、生产环境爆炸、备用系统马上就可以 kick in 继续服务 —— 停电了、硬盘 被总理 拔了、光缆挖断了、渔船一锚把海缆咋砸断了，备用系统都要随时可切换、随时可上线、随时能接管。满足这三点，才能被称为「常驻热备」。而运维的任务，就是负责切换到备份系统上运行、并在事后恢复故障系统。

更进一步的，就是系统的自愈能力。故障来了，系统自动把流量打到备用实例上；数据同步出错了，系统自动从最近粒度的数据恢复出来。这些就是业务的自愈能力，架构的容灾和容错设计，灾备系统的完善。SLA 要想迈向 4 个 9，自动化运维是不可或缺的。

3 个小时

3 个小时是个虚数，但是大体来讲，如果一个灾难性故障 3 个小时修不好，大家对你的信任就归 0 了、你就告别互联网了。Cloudflare 如果持续 3 个小时 502（而不是 27 分钟），那么 Cloudflare 这家公司直接就是死了。因此 3 个小时应该被视为一个标准。不管发生什么故障，3 个小时内恢复不了服务，说明工作做得不到位、有人需要扣年终奖了。达成这一标准没有任何捷径、只有应急备案、随时演练 —— 大到整个公司每月模拟一次外星人入侵，小到三五个人每周模拟一次服务器没法重启，演练不能停。

备份系统

很多人认为备份系统挺简单，跑起来就不用管，其实不然。首先备份系统也不可能备份了你想要的数据。就算百分之百全量备份，也不是百分之百就不会丢：写到硬盘上，硬盘可能会寿命用尽；写在磁带上，磁带也会坏；写在纸上，纸也可能烂掉；就算都不坏，宇宙射线来了，数据位置就交换了，你还是访问不了。

除了备份，最重要的还是恢复。如果一个备份系统不能随时演习细粒度的回复，那就是没用的，关键时刻一定掉链子。GitLab 不小心删了全库，最后不得不用时 9 个小时进行全量恢复。