关于于某次生产线数据修复的处理方案

虽然事情已经过去好久了，但今天刚好又被同事重新提交，所以我觉得有必要把事情的经过，和处理方案及过程记录下来，以供自己日后查阅。

 

去年某天，收到用户投诉，说自己的积分无端端多了

收到投诉后，我对此用户的相关数据进行检查，发现后台在做数据结算的时候，重复给他发了N次积分，随后在结算代码中发现是某个存储过程的bug导致的

查看所有用户的数据，发现影响面很大，涉及80%的用户，我第一时间向上级汇报了这个事情，并召开了紧急会议A

紧急会议A的结论是：先统计出，这次bug造成影响的实际用户数是多少，实际损失是多少，也对受影响的用户进行分类，并拟写针对投诉用户的解释口径安抚用户

       U1 沉默用户 （用户数据受到影响，但是用户至数据变更到现在还未登陆过系统，即用户还不知道此数据变更）

       U2 非沉默用户 （用户数据受到影响，且已经登陆过系统，可定义为用户已经指定此数据变更）

会议A 的统计数据出来后，再把数据向更上一级汇报，并同时研究解决方案，召开紧急会议B

 

紧急会议B的结论是： 以减少用户投诉为重心，尽可能的召回积分减少公司是实际损失

        因为积分是虚拟的货币 ，在系统里召回积分即可，但对于超额发放积分的用户，又可以根据积分余额情况分为两种：

        1 积分余额大于等于超额发放的部分；2 积分余额小于超额发放的部分     

        所以，对于积分余额大于等于超额发放的沉默用户，按超额部分全额扣除积分，并备份名单以供客服咨询使用；对于积分余额大于等于超额发放的非沉默用户，由于这部分用户已经知道其积分变更情况，所以不能直接扣除，最后讨论决定，在此名单，排除存在“投诉名单，极端客户，差评师”等比较容易产生纠纷的用户后，做全额扣除，然后发邮件告知“由于近期系统故障，造成您的积分数据显示错误，我们已经修复，对您造成不便请谅解。。。” 类似这样的邮件，并备份名单，以供客服咨询使用，排除名单的用户积分没有动，我们需要用对平订单来处理，使系统数据完整；对于积分余额小于超额发放部分的用户，除了按实际余额扣除外，其他的同上。

 

最后我们需要提供几个统计表，包括各种处理方式的用户数，超发额，召回额，实际损失额，这些表不但可以很全面的看到这次处理的大致情况，而且还可以详细查询每个用户的处理情况

就这样，我们用最小用户影响度，最小损失的方式处理了这次的生产事故。

----其实也没什么高明之处，只是在减少损失和客户满意度中做了权衡，觉得这个经验可以记录下来，供以后参考