评论

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

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

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

~

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

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

~

~

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

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

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

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

具体是这样的,

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

~

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

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、对于有参数的云函数,一定要对这个参数部分做二次校验逻辑

最后一次编辑于  2021-08-15  
点赞 0
收藏
评论

1 个评论

  • 马尚尚
    马尚尚
    2021-08-15

    今天写这篇文章,主要是为了说明云开发查询里面的where,如果条件里面有未定义值,其实是未生效的。

    这一点十分重要

    2021-08-15
    赞同 1
    回复
登录 后发表内容