中了复盘的毒

最近，拖延症又犯了，迟了一周的C项目V2.5版本的复盘来了，虽迟但到。

2.5版本是个小版本，在测试过程中，没有复杂的逻辑，总体来说，质量还行，最后由于开发人员中间穿插了其他任务，导致项目延期半天上线，还好是在可控范围内的。

但是线上出现了三个问题：

一、数据部修改接口未通知，导致出现重大Bug

上线3天后，出现了一个比较严重的线上Bug，该系统C（属于研发部）本来是用来给用户生成链接，去运营投放的，结果生成链接报错了。

出了问题之后，根据内部IM群里的提示消息，开发同学第一时间进行了排查，发现是依赖于数据部的系统R，昨天上线了新版本，修改了接口，没有通知到我们这边，导致报错了。

该接口之前，两边协商的是都传产品名称字段，但是昨天数据部系统R，修改了接口，我们这边只能传ID，与其保持一致，临时商量了解决方案，系统C，将页面的产品名称改成产品ID，与数据部保持一致，让用户先用起来。

通过这个线上事故，反应出了一些问题，部门内部流程问题。数据部的系统，本身就会对接很多平台，开发同学修改接口的时候，对于这种与多个系统对接的系统，尤其需要注意是否影响了外部对接的系统，这块可以在代码处备注，或者形成规范的文档，或者查看线上接口调用日志，后续在修改该接口的时候，务必通知关联的其他系统。

一周后，也就是今天，数据部的领导，梳理了一个基本流程：

1、开发同学发送提测邮件，描述本次提测和变更的功能点

2、由项目负责人进行评估，并通知关联方

3、测试通过后，项目负责人安排验收，并发送验证通过邮件

4、运维同学收到项目负责人的验收邮件后，才能安排上线

流程出来后，就能避免上述事故了，犯错不可怕，可怕的是在同样的坑里跌倒多次，领导思维：出现事故--担责--复盘--想办法规避错误--让团队正常运转起来。

二、数据库未加主键，重推后会出现大量重复数据

系统C的很多数据，都是依赖于数据部进行推送的，但是在测试环境由于时间关系，未考虑重新推送的问题，结果上线后，由于需要，会多次推送数据，结果，就出现了很多重复的数据。

系统C对接了很多产品，但是每个产品的代码还不同（与之前的架构有关），而且，正处于业务方内测阶段，而开发同学修复Bug是一个产品一个产品来的，需要系统C和数据部的研发同学一起配合修复，两边的工作重点又不一样，没有一个人去主动推荐这件事情，最后修复了好几天，最后给业务方的印象就不太好，据说是开发同学响应不及时。

经过这个事情，有3点启发：

1、测试同学，以后即使时间很紧，也要考虑数据重推的问题，可以自查数据库的主键，提醒开发同学加上主键，保证数据不要重复。

2、业务方反馈的线上问题，需要第一时间响应，确保给业务方留下好的印象，否则，后续的工作，不太好开展。

3、遇到重要紧急的需求，下游方需要主动找上游去推进，即使上游例如数据部的研发同学有其他工作要做，也要主动去找其领导商量，否则一直拖，拖到最后，所有的锅都甩到下游方头上了。

三、测试场景覆盖不全

这个问题，其实是上次2.4版本遗留下来的，系统C会接入很多产品，但是每个产品在数据部的代码计算逻辑都是不一样的，不知道为啥没复用，可能跟之前设计的架构有关系。

在之前的测试过程中，系统C和数据部的研发同学表示，只覆盖一个产品就ok了，其他都差不多，时间很紧，没有多想，于是就只测试了一个产品。

后来上线之后，发现接入的其他产品可能会有无法生成数据的情况，后来开发同学排查，才发现是每个产品的代码逻辑不一样。

经过与研发同学和项目负责人讨论，后续的测试方案会变化，即每次接入一个新的产品，需要在测试环境走通流程后再上线，不能不经测试就直接在线上接入新产品。

这个问题，后续的避免方式是，与开发尽量多沟通，准确确认测试范围。

复盘就会有收获，以上仅代表个人观点，希望能对你有所启发~

ps：我是lc馨馨紫，全网名称统一，期待优秀的你关注我~

原创文章，转载请注明出处~

原文链接：https://mp.weixin.qq.com/s/U1Sh7srDCuwRXN2IXo6W7A

复盘系列文章：
对，还是项目复盘
对称日上线项目的日常复盘
项目提前上线的7点感受
项目延期半天的8点感受