从云厂商宕机史谈预案建设_软件工程_焦振清



 写点什么

世界上没有百分之百的安全，安全事故的发生在所难免，IT 领域更是如此，因此当发生安全事故时，是否有预案来解决就变得尤为关键了。本文将从云厂商宕机史讲起，谈谈预案能力的建设。

云厂商宕机史

限于故障信息的披露涉及到很多环节，因此本文只从网络上摘选一些信息进行罗列，同时，各类故障的占比，也要辛苦大家自己来慢慢挖掘了。

AWS 十年宕机史

2018 年十大云宕机

预案执行优先级

当发生服务故障后，应该立即执行哪些预案，预案执行的先后顺序是什么，主要是看预案执行的效果，基于以下因素，不同业务自行决定预案的执行顺序

概率优先

首先需要考虑故障概率最高的三类场景是什么，那对应的预案，就应该优先执行，毕竟能解决大部分的故障场景

生效时间

在明确了故障概率最高的三类场景后，就需要评估这三类场景的预案的生效时间了。举例来说，对于某业务来讲，可能最常见的问题之一就是容量问题，但扩容至少需要 10-15min 才能生效（假设无法继续优化），那么扩容预案就不适合作为最优先的预案，因为 10-15min 直接就打破了季度 SLA99.99%的要求，你得另想办法

是否有损

预案执行的目的是止损，如果预案的执行会带来用户体验的下降或者是导致部分用户无法使用，那就不应该作为优先考虑的预案，而应该优先考虑那些概率较高且不会对用户体验造成影响的，就算预案执行后没效果，起码不会对业务产生负面的影响。对于服务已经故障一段时间，常规预案手段无济于事的场景，这时候，预案之间比的是谁带来的损失更小，至少不能比现在更差

复杂度

不同的预案，复杂度不同，对业务的影响也不同。举例来讲，切流量是相对简单的操作，仅需要修改下 DNS 解析结果即可，但如果需要重启线上所有的服务器，那不同的服务，操作要求不同，数据类服务贸然重启，可能就会导致数据完整性问题

操作的幂等性

操作的幂等性是需要考虑的风险点，同样是下发十次任务，进行流量切换的后果和服务器重启的后果截然不同，流量切换是满足幂等性的，你要求将流量从 A 切往 B 机房，无论执行多少次，都不会有什么区别。而如果是重启服务器呢，那执行十次可就是重启十次啊

通过上述的评估标准，每个团队都要建立起适合于自己业务的预案三板斧，并建立常态的预案演练机制，确保预案的有效性，且三板斧要能够拦截 80%的常规故障

预案七连击

切流量

流量切换完全符合我们上述提出的五大要素，因网络和机房故障需要切流量的场景足够频繁，生效时间基本在 5min 内，大部分时候不会引起服务质量的下降，复杂度较低，满足操作幂等性的要求，因此非常多的团队都将切流量作为第一预案，一旦出现故障，先切流量试试看，从概率上看，大概有 40-60%的可能性，是能够搞定问题的。

对于外网服务来讲，因为要接入多地域多运营商的线路，因此切流量基本就是标配，无需赘述。而对于公司内部的基础架构来讲，很多人则会觉得作为内部平台，我没办法切流量。这个观点我不能完全认同，其实对于大部分基础服务来讲，通过同城双活或者异地双活的部署，是可以做到流量切换的。这里，我提供 Google Borgmon 的一个架构图，Global Borgmon 部署了两套，而 Datacenter Borgmon 则是每个机房一套，这个思路非常值得做基础服务的同学借鉴。

最后，切流量这个动作，是较为容易标准化的。在 BATJ 里，基本都实现了自动化，在公有云厂商里，也作为 DNS 的标配功能进行提供，在这里也建议，大家也应该尽量让切流量动作自动化，从而达成更高的 SLA 目标。后面，笔者也会专门写一篇文章介绍下切流量的具体事宜。

降级

降级和切流量相比，就复杂多了，主要是降级目前还很难做到标准化，虽然有 lstio 这类工具，能够将部分业务场景的降级标准化，但 lstio 们本身也是刚刚起步，普及率较低，短期内指望不上。再者，在降级方面，lstio 主要是解决容器化后微服务之间的问题，如果涉及到第三方服务、开源软件以及未容器化的服务，可能也很难奏效。

既然短期内无法实现标准化，那结果可想而知，必然是”百花齐放“。大家以不同的方式来实现降级操作，因此时效性，复杂度，操作的幂等性这类要求，就需要具体问题具体分析了。

考虑到降级的复杂度，需要专门写文章进行详细解释，因此在本文中，就简要介绍下。关于降级，大牛讲的非常好，先分级后降级，个人觉得，这是降级的关键所在。想想，一锅粥的状态下，怎么降级，降什么，根本无从谈起，因此势必要做到先分级，然后才能谈降级。最后，把大牛当年写的 PPT 中关于降级的一页截图出来，便于大家理解先分级后降级的具体思路。

限流

限流，也叫做流控，常见的是通过接入层对异常流量（包括攻击流量，爬虫流量，扫描流量等）进行封禁，隔离，限速等操作，从而确保服务整体的可用性。

那限流的顺序是不是应该放在降级之前而不应该是降级之后呢？主要是如下考量，限流的功能常态是开启的，因此一旦出现服务故障，那就意味着当前的限流策略被击穿了，所以你只能快速降级尝试缓解故障，如果在限流策略被击穿后，立即研究限流被击穿的原因，再重新上线新的限流策略，恐怕 SLA99.99%无论如何是保不住了的。

限流大致可以分为三个阶段，分别如下

第一阶段，通过单机上 nginx 的防攻击模块进行限流，因为是单机行为，因此阈值设定无法做到非常精确

第二阶段，通过类似于 nginx+lua+redis 的方式，实现集群模式的限流功能，因为可以拿到全局数据，因此阈值设置可以较为精细，效果上也会有明显提升

第三阶段，公司整体使用 GTC/GTM 类产品，实现全局的流量精细化管理，同时也会将接入层的功能进行扩展，在接入和转发上，也会增加 SSL 卸载和加速，IPV6 的支持已经灰度等功能，在安全和防攻击上，则会引入 WAF 等功能，也会将全局流量调度纳入其中，进而形成完整的产品体系，同时，因为涵盖了接入的方方面面，因此其数据分析也变得极为有价值和意义

目前，GTC/GTM 类产品，各大公有云厂商均有提供，并且支持私有化部署，并且可以集成对 DNS 的管理，大家可以多研究研究。

暂停变更

在出现较大故障后，如果预案三板斧（切流量，降级，限流）的执行没有取得预期的效果，那么这时候，就需要立即暂停变更了，避免问题更加复杂。

这里的暂停变更，不是简单意义的停止上线操作，应该是广义的变更，如网络，IDC，服务器，操作系统，基础设施等等相关的变更。不同的公司有不同的方式，自动化程度高的公司，可能直接在控制台上点击一个全局暂停操作，那么大部分的自动化变更操作都可以暂停，这时候，你甚至都无法未经许可在线上执行任何命令，自动化程度低一点的公司呢，靠吼也是管用的，毕竟人员数量有限，喊一嗓子，大家也都听到了。

回滚

线上故障的主要来源之一就是变更，之所以回滚没有放在首要位置有如下原因：

回滚的耗时较长，上线遵循灰度发布，回滚虽然没有这么严苛，但是也不能直接全并发回滚，全并发回滚就意味着在回滚期间，这个服务是完全不可用的。毕竟很多时候的故障，可能没有这么严重，如果这样操作，就违反了是否有损中不要更差的要求
变更操作定位难，因为变更导致了全局故障，潜台词就是他已经通过了灰度发布实现了全量发布。这就意味着，时间已经过去了很久，那么在此期间，必然也会有很多其他上线，因此你很难定位是哪个上线导致的，经验之一是，大家会默认回滚一定时间内的所有上线，但对于有前后依赖的一些变更，其实也很麻烦，只是说，从是否有损的角度看，它不会比现在更差而已。

综上述，回滚虽然是重要的止损手段，但是限于定位难度和耗时，很难作为快速有效的手段

重启

重启预案更多的适合于部分实例异常的场景，对于大规模故障场景下，往往不是首选。同样的，重启也面临回滚同样的问题，生效期间服务不可用。

但也不能就此忽视了重启的价值，我们的生活经验告诉我们，什么设备有问题了，重启一下说不定就能好。因此，在没有办法的时候，试试重启，也许柳暗花明呢。

扩容

在传统运维的思路里面，扩容是不会作为应急预案的，主要还是因为耗时较长，而且也面临是否有资源的问题。随着技术的进步，虚拟化以及 Docker 的出现，一定程度改善了这个情况。但扩容的生效时间，也会在 3-10min 左右，部分服务还需要预热一下才行，因此，还是没有限流或者降级来的及时一些。

预案三板斧

综上述，切流量，降级和限流就成为了一般业务常用的三板斧，而回滚，重启，扩容和暂停变更，则是一些辅助手段。需要大家结合自己的实际情况来制定适合自己的三板斧。

预案能力建设

完备性

衡量一个业务预案是否完备，有如下几种方法可供参考：

有没有预案三板斧
三板斧能不能覆盖 80%的过往故障场景
最近一个季度，执行过哪些有效的预案
故障的平均恢复时间是多久

下图是一个电商业务的预案列表供大家参考

自动化

自动化的预案解决如下问题：

人员依赖，一旦将预案脚本化，自动化之后，只需要维护相关的脚本内容即可，给出明确的执行条件，那么应急响应的工作就可以移交给专门的团队负责
执行质量，手工执行的预案，依赖于人员的经验和理解不同，可能会出现千人千面的惨剧，而无法真正的发挥预案的价值
知识沉淀，自动化后的预案，都是具备实操性的，因此可以在横向进行分享和交流，从而更好的促进整体的能力提升，也更容易孵化出横向的平台
时效性，自动化后也能够大幅提升预案执行的时效性，手工操作预案，往往需要有个人电脑开机，VPN 登录，管理系统登录，页面操作/命令行操作等步骤，而自动化后，或者不需要人工干预自动执行，至少，也是在移动设备直接操作的。