雖然事情已經過去好久了，但今天剛好又被同事重新提交，所以我覺得有必要把事情的經過，和處理方案及過程記錄下來，以供自己日後查閱。
去年某天，收到用戶投訴，說自己的積分無端端多了
收到投訴後，我對此用戶的相關數據進行檢查，發現後臺在做數據結算的時候，重複給他發了N次積分，隨後在結算代碼中發現是某個存儲過程的bug導致的
查看所有用戶的數據，發現影響面很大，涉及80%的用戶，我第一時間向上級彙報了這個事情，並召開了緊急會議A
緊急會議A的結論是：先統計出，這次bug造成影響的實際用戶數是多少，實際損失是多少，也對受影響的用戶進行分類，並擬寫針對投訴用戶的解釋口徑安撫用戶
U1 沉默用戶 （用戶數據受到影響，但是用戶至數據變更到現在還未登陸過系統，即用戶還不知道此數據變更）
U2 非沉默用戶 （用戶數據受到影響，且已經登陸過系統，可定義爲用戶已經指定此數據變更）
會議A 的統計數據出來後，再把數據向更上一級彙報，並同時研究解決方案，召開緊急會議B
緊急會議B的結論是： 以減少用戶投訴爲重心，儘可能的召回積分減少公司是實際損失
因爲積分是虛擬的貨幣 ，在系統裏召回積分即可，但對於超額發放積分的用戶，又可以根據積分餘額情況分爲兩種：
1 積分餘額大於等於超額發放的部分；2 積分餘額小於超額發放的部分
所以，對於積分餘額大於等於超額發放的沉默用戶，按超額部分全額扣除積分，並備份名單以供客服諮詢使用；對於積分餘額大於等於超額發放的非沉默用戶，由於這部分用戶已經知道其積分變更情況，所以不能直接扣除，最後討論決定，在此名單，排除存在“投訴名單，極端客戶，差評師”等比較容易產生糾紛的用戶後，做全額扣除，然後發郵件告知“由於近期系統故障，造成您的積分數據顯示錯誤，我們已經修復，對您造成不便請諒解。。。” 類似這樣的郵件，並備份名單，以供客服諮詢使用，排除名單的用戶積分沒有動，我們需要用對平訂單來處理，使系統數據完整；對於積分餘額小於超額發放部分的用戶，除了按實際餘額扣除外，其他的同上。
最後我們需要提供幾個統計表，包括各種處理方式的用戶數，超發額，召回額，實際損失額，這些表不但可以很全面的看到這次處理的大致情況，而且還可以詳細查詢每個用戶的處理情況
就這樣，我們用最小用戶影響度，最小損失的方式處理了這次的生產事故。
----其實也沒什麼高明之處，只是在減少損失和客戶滿意度中做了權衡，覺得這個經驗可以記錄下來，供以後參考