缺陷整体时间线

业务方向中台侧进行求助

起因：

某日,下游业务方通过oncall，表达了我们的sdk，存在逻辑上的缺陷，需要我们协助进行问题的定位与分析，

业务方为小程序-小游戏方向，业务方表示灰度期间客诉激增从小程序打开小游戏手机app会崩溃，而且业务方通过监控发现小程序打开小游戏失败率呈现激减，且app崩溃率也在激增，业务方尝试根据客诉信息、客诉环境，进行复现，均不能复现，定位到异常崩溃是由本部门负责的sdk引入的，故oncall进行求助

中台侧协助业务方排查缺陷-确定缺陷影响范围

本中台qa介入排查,根据客诉排查，客诉环境，使用客诉使用版本的集成包，也无法进行bug的有效复现,本部门rd根据描述，与三方相关rd进行协商，拉对应的相关pm，评估该崩溃影响的范围，通过监控发现crash只在某一个版本发现，且还只存在灰度期间，而且崩溃只存在于首次打开小程序-小游戏这个场景，经过评估，需要发客户端热修，排查bug到问题解决再到热修ddl是晚上八点。

rd定位引入的缺陷的问题代码

rd通过回捞日志，分析用户行为，与三方业务进行逻辑上面的确认，最终定位到bug产生的原因，定位到原因后，确定bug影响的范围，确定本sdk的影响范围，以及对于三方业务的影响。最终确认修复不会引入其他问题

bug产生的原因分析

bug产生的原因是：

本部门的sdk，负责根据设备信息采集 -> 转发给服务端 -> 服务端召回did -> 最终返回did，本sdk回调did给其他业务方消费,然后在回调did给其他业务方消费时，之前的rd在这块的逻辑上，加了一个延时等待，也就是，获取did后，不需要再等到设置的延时到期后，再将did回调给业务方进行消费，如果这块加了强制等待的延时后，那么其他对于商业化转化比较高的业务，可能就拿不到did，会导致拿不到did，程序会崩溃，因为缺少了身份标识。

确定bug，热修发布

rd评估回测范围，和测试范围后，首先出fix包，进行测试验证和测试回归，确认修复后，会再出热修包，下载热修包后，进行加白，此处需要验证加白是否成功，可以通过抓包，是否下发有效插件进行check，确认修复无问题，集成回归核心case无其他问题，那么就开始发布热修，热修会按照时间，下发不同的人数比例，在热修放量时需要实时监控启动崩溃率，小游戏打开成功率，客诉是否继续激增。如监控回复到业务正常阈值，会继续放量，直至全部放量结束

中台侧组织复盘

复盘大致内容

定义发现缺陷时间-到定位缺陷-解决缺陷总体时间

事故影响范围,业务方使用客户资损评估,业务方实际资损评估

评估事故分,定位事故等级，一般是p0-p4，以及notice

分析开发和测试阶段为何没有发现/召回该bug

记录改进todo项，以及todo事项ddl