一次清理生产数据导致的重大生产事故

~

其实这件事发生在本周，但是是前几天，事后想想真的是很怵，具体是这样也的

。

前几天上线了一个答题活动小程序

~

~

但是这个小程序由于搭建的比较匆忙 ，很多定制的功能没有完全做干净，但是留下了一些接口，已备后面需要。

在日常的答题活动中，需要我对数据进行一定的清洗操作，

大家看到这个清洗，就大概能猜到了，问题就出在这

所谓清洗就是对规则之外的答题记录进行删除，这个操作极具危险性，所以在平时的时候，还是建议大家多备份，慎删除。

具体是这样的，

这个答题活动，存在二个答题场景

~

在这个活动里面，有二个场景

1、积分赛答题

2、好友pk答题

其中，积分赛是每天可以答题1次，好友pik答题每天可以5次

但是有些用户，会突破这个次数限制，比如，积分赛参加了多余1次的

这个时候，我需要每天对数据进行清洗，删除多余的答题记录，然后重新统计得分

这个操作是通过云函数进行的

我按天清理，在前几天我都是手工修改这个today参数

where({

today: '2021-08-15'

})

比如今天会这么执行删除操作

但是我在周四的时候，犯了一个错误，我把这个today放在了云函数的参数里面来接受，但是问题就出在我当时执行云函数的时候，忘记给today赋值了

同时云函数么有对这个地方做逻辑保护

结果大家可想而知

where({

today: today

})

如果这个today未定义的话，其实相当于where是不生效的

就造成了按用户所有的答题进行清理了

比如用户A之前参加了10次，今天参加了2次，按规则，我应该清理今天的1次，但是会清理10-1=9，就把用户除第一次答题的保留之外，其余的都清理i了

由于当时活动已经举办了一段时间了

当时执行完

瞬间我就慌了，

我赶紧找下这个集合之前有没有备份，最后找到了前天的记录，只能用这个数据来重新导入下，这样就损失了，昨天和今天，二天的答题记录

~

好在这个活动持续时间，有点长，估计得一个月左右

这一两天的答题并没有很明显的体现到排名里面

~

从这次生产事故，让我明白几件事情

1、任何对生产的修改或者删除操作之前，一定要做好数据备份

2、对于云函数的执行，一定要核对是否有参数

3、对于有参数的云函数，一定要对这个参数部分做二次校验逻辑