上线规范

上线前

• 代码review，代码必须由其他人review并+2（即使只改了一行代码或者加个日志也需要找人review）
• 整理上线文档，上线文档需要包含以下内容
  • 责任人，包括开发、产品、测试
  • 相关依赖，例如依赖了其他服务的新接口，需要在其他服务上线之后才能上；被其他服务或者前端依赖，上线后需要周知相关人员
  • 上线流程，上线流程超过3个步骤需要找人review
    
    • 准备资源和配置，包括但不限于以下内容
      • 如果是新服务，是否需要配置nginx
      • mysql数据库，包括建表、改表、改索引、刷数据等
      • 消息队列
      • 缓存，申请缓存实例，例如redis、memcached
      • 其他数据库，es建索引等
      • captain、nacos配置
      • conan-config配置
      • 第三方ip白名单，第三方平台配置等
    • 上线服务，同时上线多个服务时，多个服务之间是否有依赖关系和上线顺序
  • 上线后验证方案
  • 回滚方案，回滚方案也是测试内容的一部分，回滚方案必须是可操作的
  • 少数情况下可以不写上线文档，例如上线流程非常简单，只有1-2个步骤，对现有功能没有影响
  • 紧急上线时线下讨论上线流程可以不写详细的上线文档，但是这种情况下往往更需要遵循上线规范
  • （如果有）后续下线旧代码或兼容代码的计划

上线时

• 尽量避免高峰期上线，尽量避免在16:00-21:00之间上线
• 合并代码，合并pr代码到master分支，合并master代码到online分支，合并时注意周知相关开发并再一次review自己的代码
• 在产品研发测试群周知相关人员，包括上游、下游、产品、开发、测试
• 用online代码build，检查build的内容是否和合并的代码一致
• 上线第一台机器并stage
  • 周知相关开发
  • 观察第一台机器的日志（新代码），是否有错误日志，是否有不符合预期的日志
    
    • 新代码本身有问题
    • 至少保证新代码被执行一次（可以通过业务逻辑，数据库等确认，如果有新表上线，需要确认新表是否有写入新数据等）
  • 观察第二台机器的日志（旧代码），是否有错误日志，是否有不符合预期的日志
    
    • 新旧代码不兼容导致的问题，例如新代码写入一个新的枚举类型，旧代码不识别报错
  • 观察下游服务的错误日志
    • 修改了对外提供的接口或者消息，导致下游代码不兼容
  • 观察业务日志
    • 例如公平分班关注新收到的订单是否正常分班，电话系统关注新的外呼请求是否成功等
  • 观察sentry
    • 某个类型的错误数量飙升
    • 上线过程中出现的新错误（last seen）
  • 观察grafana
  • 线上验证
    • 调用接口正常，接口流量符合预期
    • mq消息发送和消费正常
    • 数据库数据写入正常
    • 缓存数据正常
• 部署其他机器，部署过程中持续观察
• 执行上线文档中的其他流程

上线后

• 自己及时走查，确保自己的逻辑正确
• 周知相关人员，包括开发、产品、测试、上游
• 通知测试开始线上回测
• 观察线上运行情况
• 周知下游开始上线
• 一段时间内持续观察线上运行情况，包括但不限于sentry、grafana、线上数据等

注意事项

上线过程中如果出现大量报错、收到产品、技术支持、运维报障，立刻执行回滚方案，回滚的并发度可以提高一些，回滚完之后再考虑原因

上线过程中出现任何问题，立即在上线群周知

解决完问题之后需要考虑是否产生了脏数据，以及是否需要修复

新同学上线时如果出现任何问题，立刻找自己的mentor