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