谈谈云服务和 SLA

谈谈云服务和 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 就好了:

可用性等级Uptime每年容许 Down Time每天容许 Down Time
1 个 990%36.5 天2.4 小时
2 个 999%3.65 天14 分钟
3 个 999.9%8 小时 42 分钟 36 秒1 分钟 26 秒
4 个 999.99%52 分钟 36 秒8.6 秒
5 个 999.999%5 分钟 15 秒0.86 秒
6 个 999.9999%31.5 秒8.6 毫秒

云计算业务除非保证 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 个小时进行全量恢复。

谈谈云服务和 SLA

本文作者

Sukka

发布于

2020-07-18

许可协议

CC BY-NC-SA 4.0

转载或引用本文时请遵守许可协议,注明出处、不得用于商业用途!

喜欢这篇文章?为什么不考虑打赏一下作者呢?
爱发电
评论加载中 ...