高可用服务变更的关键点
焦振清
讲述：子阳大小：2.28M时长：04:59
近期， Cloudflare 在更新 WAF 配置规则时，因其中一个规则包含了正则表达式，导致 Cloudflare 全球机器上的 CPU 峰值使用率达到 100%，在最糟糕的时候，流量下降了 82%，对整个互联网都产生了明显的影响。
可见，变更的定义，不仅仅是狭义的上线新版本代码，也应该包含配置变更，数据变更，操作系统变更，网络变更，基础设施变更等方面。变更是运维人员的主要工作内容，同时也是导致服务故障的主要原因。据 Google SRE 统计，线上 70% 的故障都是由某种变更而触发的。所以在服务变更中需要注意几个关键点，降低故障风险。
1. 部署清单
部署清单主要是管理部署期间的整个生命流程，通过将各个阶段的各个步骤进行罗列和长期维护，从而逐步形成针对特定变更场景的说明手册。
如果只是升级一台服务器的二进制代码，需要部署清单吗？答案是肯定的。不能把二进制代码变更等同于二进制文件替换，在替换动作之外，有很多的工作内容，仅仅是更新完毕以后，就需要考虑如下问题：
程序是否正常启动
日志是否存在异常信息
服务功能是否正常
服务性能是否符合预期
服务关键指标是否异常
对于多模块，多系统，多团队配合的变更操作，如果没有一份事前经过充分验证的部署清单，那这种复杂变更的结果就只能靠运气了。
2. 灰度发布
在灰度阶段，有针对性的选择灰度流量，尽可能完整的覆盖各类业务场景和用户类型，并通过流量调度形成局部热点，对服务的性能进行验证，避免全量上线可能出现的性能下降。
3. 快速回滚
变更操作一定要有回滚预案，并能够快速回滚。日常的变更操作，只要有备份，大多数情况都可以进行回滚。那些无法进行回滚的，一般都是重大变更，这时候，等着你的基本上就是直接在线上调试并修 bug 以及超长的停机时间和大批的脏数据了。
4. 功能开关
比回滚更高效的方案是功能开关，在发现新功能上线有问题后，可以通过功能开关立即关闭该功能，从而起到更快速的止损效果。
5. 线下测试
既然线上有了变更保障能力，那为啥还要在线下费劲搞集成测试呢，直接在线上测不就行了吗？假设这个观点是正确的，那么所有未经测试的代码全部推送到线上开始灰度，在灰度阶段去发现各种问题，然后回滚，修复后继续上线。但灰度的流量，也是真实的用户，怎么能够拿用户的真实流量做这样的事情呢。因此，线下测试还是非常重要的环节，通过线下测试，将 80% 以上的基本问题拦截在线下环节，在灰度环节，更多的去解决线下环境无法覆盖的场景。
6. 效果检查
服务变更后，需要有一系列的基于部署清单管理的效果检查的内容，通过对变更的效果进行验证，才能最终确认本次变更是否正确。同时，针对服务相关的全局核心指标的监控，在变更期间，既不应该出现异常，更不能被随意屏蔽掉。
7. 时间窗口
时间窗口主要是用来降低变更导致的影响，常见的时间窗口有如下建议：
尽量避免节前做变更，即使是 BAT 和运营商，对于全年重要的节假日，往往会提前数周停止业务的非必要性变更，或者是将自动流程转为审批流程；
尽量避免在业务每天的高峰期做变更，避免对业务产生影响；
尽量避免在下班前尤其是周五下班前做变更，提前通告。
8. 隔离
如果服务是分组部署，且分组间能够做到尽量避免服务间的交互和基础设施共享，那么在变更中，就需要利用该特性，对分组进行逐一升级和观察，避免问题发生扩散，在出现问题的时候，通过流量调度即可快速摘掉流量止损。
9. 通告
任何的变更，都需要事前进行通告，告知相关的上下游团队，变更时间，变更内容，可能的影响，应急联系人等，并在变更期间的各个阶段，进行通告。同时，也应该将变更信息录入到统一的系统中，便于相关上下游订阅。
以上就是今天的内容，下一篇文章继续介绍服务变更的最佳实践及配置变更的常见案例。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
爱学习的大叔讲的不错
收起评论