1、发布前

代码包版本确认：确认发包的分支，代码是否正确

依赖梳理：定制好各应用的发布以及变更的先后顺序

服务端灰度方案确认：

  • 开关控制业务流来控制代码逻辑，常结合机器唯独灰度方案配合使用。比如先发一台机器，然后把新代码逻辑开关开了，然后去验收新代码逻辑的功能
  • 按业务白名单进行新功能验收，比如根据 UID 来灰度
  • 按机器唯独进行灰度，比如只把代码发到集群的一台机器进行灰度；或者只把配置下发到具体的部署机器
  • 按部署池进行灰度，比如让某个部署池的所有机器都部署新代码进行验收
  • 按上下游调用方的IP、域名来灰度，比如通过路由策略配置，只有来自某台机器或者某个应用的流量能访问到新代码
  • 按流量比例来灰度，比如新代码发布到第一台机器后可以让该机器的流量权重从1%逐步切到100%；再比如重构后的新服务新接口，需要先把小部分流量达到新服务去慢慢观察

变更顺序及确认：

  • DB变更，消息频道、队列申请、配置变更、环境
  • 消息频道申请及下发
  • 配置中心配置
  • 环境变量下发
  • 搜索引擎搜索配置及查询模板

回滚方案确定：版本域涉及各应用任意一个出现异常回滚后，其它应用的应对措施

监控配置确认：确定新的监控规则是否已配置(风险预测、异常监控)

验收方案的制定：

  • 验收人员确定：产品经理、测试、开发
  • 验收顺序确定：确定变更，刷数，配置，代码的先后顺序
  • 验收环境确定：测试环境、预发布环境、生产环境
  • 验收场景及预测结果设计：接口验收、业务链路验收
  • 验收方式确定：自动化、人工
  • 验收数据 & 脚本准备

风险预案的准备：

  • 脏数据查询脚本
  • 数据修正脚本

  • 受影响业务评估：应用维度、数据维度、链路维度

    2、发布中

    控制发布节奏：

  • 必须分批发布

  • 核心应用第一批和第二批之间必须间隔30min
  • 核心应用第一批必须通过流水线发布，即流量从1%~100%逐步放量

多维度监控：

  • 日志监控
  • 业务错误 & 告警日志
  • 框架异常日志：熔断，服务异常日志
  • 机器负载监控：
    • CPU
    • 网络
    • 内存
    • IO
    • GC
    • 响应时间：发布应用本身的响应时间、上游响应时间、下游响应时间
  • 链路监控：上下游链路的业务异常
  • 流量监控：发布应用本身流量、应用本身设计的各组件
    • 消息
    • 数据：DB、缓存、搜索引擎

及时验收

  • 新功能验收：能预发布验的一定要预发布验收
  • 旧功能回归：引流对比成功率

风险应对原则：最快回复业务并降低影响

  • 通过开关或者配置变更改变代码执行逻辑
  • 业务降级
  • 摘流(某一台机器停止)
  • 回滚(最不希望看到的处理方式)

    3、发布后

  1. 确定变更和配置是否全部下发完成
  2. 跟进验收结果
  3. 持续关注生产告警