【事件级别】
P0
【解决过程描述】
9：33 小程序将预发布包发布至线上
10：15 发现签到预发布日志刷的有点快，怀疑是后端把预发布发到了线上，找到相应研发询问。
10：20 确认后端上线没问题，找到前端沟通。
10：25 经前端检查代码发现环境是第二套预发布环境。
10：30 及时进行了代码回滚。
10：44 将第二套预发布提单接口停掉
11:11 将预发布订单取消，金额原路返回
15:41 梳理出有问题的红包套餐购买记录，操作退单、退款
【事故总结】
1、 提审和发版前未再次确认环境，后续会加强提审和发版前的核实确认，组内成员互相监督。
2、 体验版增加浮窗标记，能快速识别是正式还是测试。
3、 建议后台监控预发布流量，超过阀值报警。
4、 后台预发布针对支付，领券有白名单限制，防止外部用户领取或支付。
5、 各个涉及的部门和业务成员拉个群，每次发版人员群里及时通知。
【规避生产环境打预发布包结论】
发版前预防：
- 控制发版节奏，避免单个小需求频繁发版的情况。
- 研发在发版前进行js脚本检查，确认配置的是线上域名。
- 在进入预发布环境页面时增加弹窗，告知是预发布环境，以此区分线上与预发布页面。 发版后补救：
- 增加主要服务接口的流量监控预警。
- 小程序物理网关域名后缀从.com改为.care，只能内网访问预发布环境。用户用外网访问时打不开小程序，测试也无法在公司外进行。
事后分析总结：
我们在流程化上线过程中，经常会误把预发布的包发布至线上，导致事故频发
为了尽可能的避免这种情况，总结了如下几点
上线前：
（1）编译打包的过程一定要注意是不是master分支
（2）打包后 我们反编译软件 再确认下配置文件里面的别名是否为master分支
（3) 线上预发布进行数据隔离、域名隔离、服务隔离，一般出现事故的都是线上生产环境和预发布未进行隔离导致。
（4）做好业务降级，确保业务回滚的时候误伤其他服务（不可降级的情况下 更需要慎重）
上线中：
（1）如果是web服务，上一台进行验证，用Nginx指向上线服务器ip，测试充分验证后再进行全量上线
（2）如果是service服务，上一台服务器，用测试工具验证线上dubbo或者webservice接口，进行测试回归验证充分验证完毕后全量上线
上线后：
（1）对预发布服务的调用进行监控，观察是否有线上流量请求打过来
（2）持续观察线上功能是否正常。
