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

距离上一次发博客已近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次机会咱们能够去发现并阻止这次事故的发生，但一次机会咱们都没有把握住。有严重的失职，有严重的不严谨，有严重的不负责，做为产品，很自责，同时也在不停的提醒本身，之后不容许这样的事件出现。同时也提醒同事，作事要有责任心。

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

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