一次清理生产数据导致的重大生产事故
~
其实这件事发生在本周，但是是前几天，事后想想真的是很怵，具体是这样也的
。
前几天上线了一个答题活动小程序
~
~
但是这个小程序由于搭建的比较匆忙 ，很多定制的功能没有完全做干净，但是留下了一些接口，已备后面需要。
在日常的答题活动中，需要我对数据进行一定的清洗操作，
大家看到这个清洗，就大概能猜到了，问题就出在这
所谓清洗就是对规则之外的答题记录进行删除，这个操作极具危险性，所以在平时的时候，还是建议大家多备份，慎删除。
具体是这样的，
这个答题活动，存在二个答题场景
~
在这个活动里面，有二个场景
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、对于有参数的云函数，一定要对这个参数部分做二次校验逻辑