上线发布流程

本文记录了服务上线发布流程规范

上线发布流程规范的原则，从风险角度出发，预想最坏的情况，做最充分的准备。目标是尽可能用较小的成本发现本次发布变更的问题。

核心：要能准确评估本次变更的影响范围，通过灰度发布等手段将影响降低，又有足够的手段做好功能的测试验证，一旦有问题要有机制可以快速发现，同时具备快速恢复的能力，包括但不限于回滚。

名词解释

• 灰度发布：指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度
• RD、PM和QA：
  • RD：Research and Development engineer
  • PM：Product Manager
  • QA：Quality Assurance
• 回归测试：指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

流程规范

上线总体要求：可验证、可灰度、可回滚

• 上线准入：上线操作人保证待发布的代码经过充分的测试，包括：
  • RD自试：单测、CI流水线、集成测试、联调测试
  • QA介入测试：测试流水线、功能测试、回归测试
• 上线清单：所有的变更都需要有发布计划/清单，明确每个需求的上线时间
• 上线窗口：发布时间要避开公司静默期，尤其重大节假日前三天禁止重大生产变更
• 人员要求：上线过程至少2人参与（操作人+观察人）
• 上线前准备：
  • 上线发布checklist规范
  • 所有的操作（DB变更、数据变更、MCC配置等）都必须具备可回滚性或可降级性，且经过线下验证有效
• 上线周知：
  • 周知小组范围内
  • 对于线上发布可能对上下游系统/业务造成影响的变更，负责人与相关上下游系统进行必要的周知，要保证消息触达率
  • 非紧急上线外，正常上线需至少提前4小时周知（不兼容变发布至少提前一周，且发布前再次通知。重大发布提前至少一天）
• 灰度策略：
  • 发布过程强制灰度，plus灰度与自定义灰度
  • 如果因为系统架构原因导致方案不能满足时，则需要对系统进行升级改造
  • Plus机器分组发布，检查间隔时间不少于5分钟
  • 灰度粒度不能过大（比如一台机器不影响一大片业务）、灰度时间需要足够长，对于核心服务的发布，建议灰度分至少3个批次
  • 除了考虑机器分组外，还可以考虑基于代码覆盖率进行灰度放量
• 执行发布
• 上线后检查：
  • 发布过程和完成后需要遵循PDCA方法论，观察并手机信息：在Raptor（含Falcon）监控以及内部的监控大盘
  • 灰度发布的不同阶段，观察判断的点不一样：
    • 单台发布阶段，一般重点观察本台机器是否有错误日志，要尽可能通过日志来做本次变更正确性的验证，观察数据库和缓存数据的正确性，要观察上下游的业务正确性，抽查的请求日志尽可能覆盖所有场景
    • 比例发布阶段，一般重点观察是否有错误或者异常，因为灰度的比例达到比较高的阈值，可以比较容易触发监控指标的变化和报警，同时需要关注到上下游是否正常，是否有问题的暴露
    • 全量发布阶段，一般重点观察业务和系统的大盘，从宏观的统计数据上看是否有业务问题，同时观察性能指标（耗时等）和机器指标，如果有做相关业务数据的买点，可以通过具体的业务数据指标分析来发现问题。全量发布完成后，需要做全场景的验证回归，防止有些场景不能实时出发（比如定时任务触发）
  • 上线后需进行核心功能的回归验证，如新上线feature，也必须进行功能性回归验证
• 回滚：
  • 如果发布完成后发现指标异常或收到用户反馈异常，需要第一时间按照预定的回滚方案进行回滚，而不是选择排查问题。如果回滚后依然解决不了问题，再通过分析日志或指标来排查原因
  • 回滚方案要提前演练，保证有效性
  • 回滚需要考虑回滚所有相关的程序、配置和数据修改，不要只考虑程序本身
  • 回滚顺序，不管是完全回滚到上一个版本，还是选择再次发布一个新版本，仍旧需要遵循灰度的顺序。