终究还是人的问题！

       近日，每天早上推给领导的数据发生错误，于是让项目组做了个复盘。

        复盘之后，我发现剖析问题的原因都是资源不足、数据未备份、没看出错误等原因，后续解决办法就是增加预警机制、出现问题@具体值班人员、程序做先删后插的处理等等。

        我觉得复盘没有复到根本！我指出问题的根本原因在于大家对早上推送数据给领导这件事儿的重视程度不够，说白了就是没把这个数据推送当回事儿！但凡能把这个推送的数据当回事儿，就不会有今天这个情况发生！

        在程序层面、机制层面其实已经做得很好了，比如有问题推企微群，数据先发UAT，没问题之后再正式推送等等。关键还是人的责任意识问题，其实数据有问题已经在前一天下午提醒到企微群里了，但是相关值班人员可能是阳了，身体不舒服就没太关注；第二天一早，看数据的时候，只看了数字貌似没问题，没有做实质确认；对预警的日志超长也没有警醒！就这样，不正确的数据就推送出去了！结果，就是一大早，各种领导找我，说数据有问题！

        再有，说因为资源不足导致的，那多少资源够？有没有做资源的评估？现在复盘里面写的都是后面要怎么怎么做，那都是预防。如果真得发生问题怎么办？应急预案是什么？有问题了，数据没法出去的时候怎么应急，是通知延迟发送还是怎么办？有问题了，数据发出了又怎么办？是撤销，还是通知数据异常？如果通知数据异常，是继续企微推送，还是邮件发送，还是二者兼有？

        有成员提出来进行数据比对，但遭到其他人的反驳，理由是占用资源过多。我倒是赞同，核对多个占资源，那就少核对几个呗，目的主要是发现数据是否异常！大家都是搞报表的，都是做数据的，数据有没有差异，就不能跟昨天相比较一下？怕资源不够，那就做一个指标的对比，这样总影响不了啥吧？有问题了，通过加粗、加下划线、文字变色等方式一眼就能看出来，这也比用肉眼看着数差不多就是没问题强啊！

        当然，我也做了自我批评，后续也应该多关注一下数据的准确性！

        最终决议如下：

1、时间轴，增加我发现问题有误的时刻；

2、去申请远程操作的权限，看能否进行远程控制，这样有问题就不用等到非得到达公司之后才能处理。

3、资源不足，就去评估资源，看多少够用，如果自己评估不了，就请外援，也包括扩展服务器节点的评估。

4、日志保留半天肯定是不行的，出了问题，想查原因，都无从查起。

5、程序处理上，在做先删后插的操作之前，要先判断上一步的数据是否成功了，成功提取之后，再做插入删除操作。

6、补充应急处理预案：抽数有问题，数据延迟发送怎么办？数据有问题，没发出去怎么办？数据有问题，已经发送出去了怎么办？能不能撤回？能不能提醒？提醒的话是企微提醒，还是邮件发送系统异常，还是二者兼有？

2024年9月6日