相信push消息 是每个电商事故影响范围最大的、暴击最强烈的 比如18年的36氪推送门事件，短短几天让何文辉上了热门，相信负责测试消息push的同学 死的心都有了吧。
接下来我们看下另外一起推送消息导致的事故过程。
事故发生处理过程如下
- 17:29 在群里让查一个问题，当时研发在和测试讨论这一期的测试功能点，没有及时查看群消息；
- 17:31 研发反馈在预发布测试，只会圈出最近30天内在预发布访问过的用户；
- 17:39~17:43 群里反馈真实用户可以收到，不仅仅是测试账号；
- 17:43:47 停止预发布推送worker，但已经触达海量用户；
【根本原因】
1、预发布引用生产环境用户 单独为预发布做一套用户不现实，因为预发布数据做不全； 2、研发不知道预发布的消息通道可以触达真实用户； 3、研发没有养成测试环境发消息，也要使用真实文案的习惯；
【TODO】
1、业务收口
- 签到 改为7天最多发一条push；已经配置完成；
- 结算页未支付的用户push 停止；已经停止
- 疫情紧俏商品到货提醒 停止；已经停止
2、培训与考核（
- 以往将新人大礼包发给新入职同事，研发组内没有组织相应的培训、考察；
- 周会review历史事故，也没有做相应的考察，无法确定大家吸收了多少；
- 需要对新人进行系统化培训、考察，一个月后再考察，确定关键问题已经充分理解、熟练掌握；
3、系统限制
- 底层通道，预发布环境做白名单功能，只能发送给研发和测试，其余pin全部过滤；
- 底层通道，预发布+生产环境，对文案进行过滤：无汉字、字数过少等；同时添加风控敏感词过滤；业务系统陆续接入，签到系统已通过评审。
- 业务系统，梳理触达通道，加入审批流；业务系统陆续接入，签到系统已通过评审。
- 隐患梳理，业务系统在调用 消息中心、优惠券发券、微信触达消息时，是否使用了 jsf reTry 机制，需要排查和禁用所有重试机制；
【二次复盘todo】
系统todo：
-
我们系统内部，有哪些高危的接口，用了retry，会重复发送？需要梳理： 发短信、发push、发模板消息、发公众号消息、领券、兑换红包；
-
我们所有系统，有哪些高危的接口没有接入审批流，需要梳理；
-
底层通道在预发布做白名单过滤，建议返回具体错误提示；因为新入职的员工还没加入白名单，可能在自己尝试新系统时，发现不了无法收到消息的原因；
-
白名单，目前物理网关已经有了，能否提供一个接口，让各系统依赖这个统一的接口，一次维护，处处受用；
题外扩展：
-
拦截器，防止预发布包发到线上，新项目经常忘记加，能否在项目生成脚手架里面新增该功能；
-
系统ump报警，值班表有所变更，需要集中完善一下，以免重要的报警收不到；
-
每次做一个需求，都要询问产品是否和老版本做ab，是否做版本兼容；因为小程序从发版到全量安装时间非常短，大部分情况下不用保留老版本，但ab场景通常需要；
-
预发布环境的用户数据；
-
开发工具自动拉分支，自动改编译参数，自动编译，自动发布，提升工作效率的同时，也避免了将线上包打到预发布的风险；
- worker，建议添加一个中文备注字段，便于描述风险，无论是生成环境还是预发布环境，如果一个worker是停用状态，一定有它的道理，不能随意启动；
发生事故时
-
先止损，不要排查原因，而是第一时间思考解决问题的办法，快速落实；
-
再复盘，排查原因，反思如何规避，静下心来慢慢想，不要在思考“我手上还有哪些活没完成，得抓紧时间干活”之类；
优化节奏
在需求提测后，找产品问问下一步有哪些规划，自己思考未来产品规划的时候，我们系统做哪些优化，做了这些优化有哪些价值产出，优化的开发量是多少，和产品沟通后，一起提到下一版需求中，一起申请测试资源；
周会&复盘
咱们恢复每周三下午2点的周会，主要内容还是review历史事故，群里的人轮流主持，主持人必须预习，要一句话点名要害，让所有人都听得懂；
对一些内部系统，做一些分享和知识互通；
规范
-
rpc层的注释，应当补充接口文档的cf地址，风险，以及现有接口对接人；
-
金额计算，需要谨慎，比如精确到小数点后多少位，整数是否保留小数点，精度问题等等；
-
对于高风险的场景，应当先梳理一下如何拆分自测；
-
自己做测试时，先问问周边有没有测过类似需求的人，用别人的测试用例指导自己的测试方法；
-
自测数据循序渐进，先用自己账号测试通道连通性，然后注释掉通道，测业务逻辑；
-
测试的时候，要观察日志，通过量级、执行速度，可以感知到预发布和生产有所不同；
使用合理的文案做消息测试
-
调用生产环境有风险，需要提前考虑周到；http的接口，应当通过域名区分生产和预发布；
-
避免一个系统来回交接；
-
worker通常无法测试，需要我们自己编写测试用例 testUnit，并且将用例拆分得足够细，避免一次性操作太多业务逻辑；