近期,Cloudflare 在更新 WAF 配置规则时,因其中一个规则包含了正则表达式,导致 Cloudflare 全球机器上的 CPU 峰值使用率达到 100%,在最糟糕的时候,流量下降了 82%,对整个互联网都产生了明显的影响。 |
近期,Cloudflare 在更新 WAF 配置规则时,因其中一个规则包含了正则表达式,导致 Cloudflare 全球机器上的 CPU 峰值使用率达到 100%,在最糟糕的时候,流量下降了 82%,对整个互联网都产生了明显的影响。
因此,变更的定义,不仅仅是狭义的上线新版本代码,也应该包含配置变更,数据变更,操作系统变更,网络变更,基础设施变更等方面。变更是运维人员的主要工作内容,同时也是导致服务故障的主要原因。据 Google SRE 统计,线上 70% 的故障都是由某种变更而触发的。
服务变更的关键点
部署清单
部署清单主要是管理部署期间的整个生命流程,通过将各个阶段的各个步骤进行罗列和长期维护,从而逐步形成针对特定变更场景的说明手册。
如果只是升级一台服务器的二进制代码,需要部署清单吗?答案是肯定的。不能把二进制代码变更等同于二进制文件替换,在替换动作之外,有很多的工作内容,仅仅是更新完毕以后,就需要考虑如下问题:
- 程序是否正常启动
日志是否存在异常信息
服务功能是否正常
服务性能是否符合预期
服务关键指标是否异常
对于多模块,多系统,多团队配合的变更操作,如果没有一份事前经过充分验证的部署清单,谁在什么时候应该做什么事情,准入条件是什么,交付标准是什么,有哪些操作禁忌和注意事项,那这种复杂变更的结果就只能靠运气了。
随着运维自动化水平的提升,部署清单并不会消失,而是在载体上有所不同,从早期的纸质上线单,到现在内置于部署系统中,实现了更好的经验传承,校验完善,流程管控,信息分享等。
灰度发布
绝大部分服务,都不应该由单个实例组成。那么,在变更的时候,就应该避免一次性升级所有实例,而应该分批次的逐步升级,并在每个批次间预留一定的时间间隔对上一批次进行观察和评估,从而决定是否继续进行升级,以此来保障变更的质量。
以 Google 为例,其灰度发布的比例,从 0.1% 开始,每 24 小时增长 10 倍推进,从 0.1%-> 1% -> 10% -> 100% (详见 Google SRE 中文版 162 页),并且灰度的初始比例一定不可以超过服务整体的冗余度。同时,在对服务进行变更操作的期间,需要将流量摘除,避免对线上产生影响,变更操作完毕后,方可引入灰度流量进行验证。
在灰度阶段,有针对性的选择灰度流量,尽可能完整的覆盖各类业务场景和用户类型,并通过流量调度形成局部热点,对服务的性能进行验证,避免全量上线可能出现的性能下降。
快速回滚
变更操作一定要有回滚预案,并能够快速回滚!日常的变更操作,只要有备份,大多数情况都可以进行回滚。那些无法进行回滚的,一般都是重大变更,这时候,等着你的基本上就是直接在线上调试并修 bug 以及超长的停机时间和大批的脏数据了。
不同公司对待回滚的态度不同,和其背后的专业能力有很大关系,因此不能盲从。如果对所有的回滚事件不加甄别的进行追责,那么导致的后果就是对于非核心故障,研发坚决不进行回滚操作导致带伤上阵,或者说将回滚美其名曰快速迭代。
功能开关
比回滚更高效的方案是功能开关,在发现新功能上线有问题后,可以通过功能开关立即关闭该功能,从而起到更快速的止损效果。可以想象一个场景,一次上线后,发现 10 个功能里面有 1 个功能异常,且引发了部分脏数据,因为还需要确保其余 9 个功能正常,因此不能全并发回滚,只能按照预置的并发度进行回滚,那么回滚耗时就会较长,这时候,如果有功能开关,那情况就大不一样了。
线下测试
既然线上有了变更保障能力,那为啥还要在线下费劲搞集成测试呢,直接在线上测不就行了吗?我们假设这个观点是正确的,那么所有未经测试的代码全部推送到线上开始灰度,在灰度阶段去发现各种问题,然后回滚,修复后继续上线。但灰度的流量,也是真实的用户,怎么能够拿用户的真实流量做这样的事情呢。因此,线下测试还是非常重要的环节,通过线下测试,将 80% 以上的基本问题拦截在线下环节,在灰度环节,更多的去解决线下环境无法覆盖的场景。
效果检查
服务变更后,需要有一系列的基于部署清单管理的效果检查的内容,例如前面提到的程序是否正常启动,功能是否正常,性能是否正常,以及本次调整的内容是否符合预期,通过对变更的效果进行验证,才能最终确认本次变更是否正确。同时,针对服务相关的全局核心指标的监控,在变更期间,既不应该出现异常,更不能被随意屏蔽掉。
时间窗口
早期,Facebook 的交付工程团队,会在每个工作日进行一次非关键性更新,而重大更新则每周进行一次,通常在周二下午进行。这里就体现了时间窗口的概念,时间窗口主要是用来降低变更导致的影响,常见的时间窗口有如下建议:
- 尽量避免节前做变更,即使是 BAT 和运营商,对于全年重要的节假日,往往会提前数周停止业务的非必要性变更,或者是将自动流程转为审批流程
尽量避免在业务每天的高峰期做变更,例如很多网络切割都是选择凌晨进行操作,就是避免对业务产生影响
尽量避免在下班前尤其是周五下班前做变更,提前通告并全员值守的除外
隔离
如果服务是分组部署(多 AZ 部署、多 Region 部署),且分组间能够做到尽量避免服务间的交互和基础设施共享,那么在变更中,就需要利用该特性,对分组进行逐一升级和观察,避免问题发生扩散,在出现问题的时候,通过流量调度即可快速摘掉流量止损。
通告
任何的变更,都需要事前进行通告,告知相关的上下游团队,变更时间,变更内容,可能的影响,应急联系人等,并在变更期间的各个阶段,进行通告。同时,也应该将变更信息录入到统一的系统中,便于相关上下游订阅。
服务变更的优秀实践
蓝绿部署
本文以蓝绿部署为基础,介绍服务变更的优秀实践
服务变更如何做到高可用?
截图简要说明:将系统按照 AZ 的维度,独立部署了 4 组,分别是 AZ1、AZ2、Z3 和 AZ4,这四组完全一致,基于隔离的思路,四个分组间,尽量避免了服务间的交互和基础设施共享。
考虑到线上环境的复杂度,以及天然存在一定的冗余度,因此每次仅升级一个 AZ 分组。在第一个分组 AZ1 的时候,会进行较为详细的验证,除去常规的自动化检查外,还会有测试人员的手工效果检查,以此确保变更的质量。其余 AZ 因为变更内容一致,因此不会有测试人员的接入,仅保留自动化检查。
如果变更存在问题,因选择的 AZ1 是明确小于冗余度的,因此仅需要摘除流量后,再进行回滚,部分时候,如果研发要求短暂保留现场,也可以满足其要求。
服务变更如何做到高可用?
部署系统
部署系统应该将变更的关键点内嵌到部署系统中,不断完善,让其成为变更流程无法逾越的环节,从而更好的保证变更质量。一个部署系统在做好单机部署工作的同时,也应该满足如下业务侧的需求:
- 提供部署清单功能,并具备自动化的检查能力,阶段性进展通告的能力
提供版本管理功能,常规变更(二进制代码和配置)必须全部基于版本库进行
提供快速回滚功能,能够帮助业务快速回滚到上一个稳定版本,并能够按照业务上下游编排顺序进行回滚
提供时间窗口功能,默认不能够在业务定义的黑名单时间点上线
提供备份功能,每次变更都需要将可能影响到的内容进行单机备份,便于快速回滚,默认是需要将上次的发布包进行全量备份尽量排除掉日志
提供灰度发布功能,能够定义分组间和分组内的并发度,分组变更的暂停时长等
提供效果检查功能,自动化的对业务进行预定义的各类检查并和部署动作联动,如暂停变更,继续变更以及调整灰度的比例
提供编排功能,满足多模块的联合上线
配置变更的常见案例
配置文件错误
在配置变更的过程中,因配置文件错误,导致服务不可用,进而导致全局的服务故障,可能的原因有配置文件被截断,配置文件合法性校验缺失导致配置错误进程无法启动,常见的故障:
- Nginx 配置文件错误导致网站整体不可用
DNS 配置文件错误导致网站整体不可用
基础服务如数据库的授权白名单被清空导致多个业务服务异常
规则冲突
在规则变更的过程中,基于不同业务的规则生效顺序不同,新增规则后可能会和原来的一些规则冲突,进而导致业务的异常,常见的场景:
- Iptables 规则,在现有的 100 条规则中新增 1 条
Nginx 的规则,基于正则匹配的方式进行域名规则的处理 - 本文地址:https://www.linuxprobe.com/high-availability-of-services.html