产品经理历险记-1-记录一次事故

刺骨的言语ヽ痛彻心扉 2021-11-17 02:36 378阅读 0赞

距离上一次发博客已近10个月了

在转型产品的路上也探索了半年了

精彩纷呈，千姿百媚，层出不穷，再也没有其他形容词能记录这半年来的心路历程了

今晚，线上环境出现了第一次的不可逆的大规模的数据型错误，记录下来，以警后世

这是个很长的 Story，简单的说

现在有个业务系统，主流程如下：

前方市场业务团队提交 Work Request，后方业务团队接收到 Work Request后，将其拆分为不同的子任务Task，并交付给不同的人员完成，所有的子Task完成后，Work Request则完成。

现在有个详细逻辑如下，业务部门要求，Work Request 完成后，在第 N 天，Work Request需要被归档，所有Work Request所属文件需要被删除，非指定人员不可查看。

收到此需求后，我同业务部门进行了详细的需求分析，明确了Work Request完成后的定义，即 Work Request 的所有子Task被完成的时候为Work Request 被完成，同时，最后一个Task完成的时间为此Work Request的完成时间。

将此需求转给开发人员，开发人员进行了开发。具体的操作是，有一张流水表，用于记录 Work Request的状态变化，从创建，到被操作，等等，最后一条流水是 完成状态流水。此由于需要判断是否是最后一个Task完成才进行记录。故稍微有一点点的逻辑在里面。

判断N天后需要被设置为归档状态根据流水表中被完成的流水进行判断Work Request 完成时间进而进行推断是否要删除文件操作。

整个功能由2个开发人员完成，A 同事负责进行Work Request 流水记录，B同事负责N天后的数据处理，经过一个测试人员C测试于11月份上线

今晚在进行数据检查时发现。无一个WR被正常删除文件操作，马上进行了紧急的问题排查。

经过一系列排查，我们发现，A同事在Work Request 流水记录的时候，把应该将 Work Request ID记录在流水表中错误的写入了Task ID。导致整个数据混乱。

询问了一圈，

A同事表示自己已经在一周前就意识到此bug的存着并寄希望于本次功能上线可以修复数据

B同事表示自己在开发测试的时候使用的是修改数据库数据，自己造假数据进行开发测试

C同事表示自己在测试阶段仅通过修改数据库数据进行了测试

以上是整个Story并且简单的说无力吐槽。

反思此次重大事故。

首先是作为此次系统需求负责人，作为此功能，此系统的产品，未对完成的功能进行严格的验收，也只是通过测试人员的反馈以及UAT人员的反馈进行判断应该无问题并且同意了上线，此属于不负责任的表现

其次是A同事，我们检查了代码，其代码从最初写的时候即存着错误，未正确的获取Work Request ID,而是使用Task ID，这是最基本的需求要求都未达到，再发现此问题后，未及时上报进行紧急修复，任由事态发展，期间其反馈说有和Tech Leader反映此情况，暂无法查证是否属实

再次是B同事，B同事在开发阶段造数据无问题，没毛病，但在联调阶段依旧通过造数据进行检查判断，此属于不严谨，不负责的表现

最后是C同事，C同事作为测试工程师，未进行测试用例记录，未进行最基本的正向流程模拟，通过修改数据库进行测试，同时回顾的时候，我们发现即使通过修改数据库也能发现问题，只有在非常粗心大意并且欠缺思考的情况修改数据才能忽略A同事犯的错误。但偏偏也被忽略。作为研发部门的最后一道防线，此属于不严谨，不负责的表现

综上，整个事件过程中，一共有4次机会我们可以去发现并阻止此次事故的发生，但一次机会我们都没有把握住。有严重的失职，有严重的不严谨，有严重的不负责，作为产品，很自责，同时也在不停的提醒自己，以后不允许这样的事件出现。同时也提醒同事，做事要有责任心。

最近心力憔悴，每天人肉运维，外有业务部门强敌，内有攻城狮困局。

产品这条路，回首看到的都是带血的脚印

转载于:https://www.cnblogs.com/LionelMessi/p/10106210.html