今天中午大概1-2點的時候，剛好在午睡養(yǎng)精蓄銳，不然下午怎么寫bug改bug呢？突然微信語音和手機同時響了，結果一看都是同一家單位的客戶，只是是兩個不同的人而已。

這時候心里開始萬馬奔騰了，“臥槽，有點愛心好不好，大中午的”。

對方都表示，小程序部分數(shù)據返回不了，幫忙看看是什么問題。其實做開發(fā)的都清楚，最怕聽到的就是“部分數(shù)據有問題”、”在通過xx在通過yy在通過zz后出現(xiàn)了這個問題”、“今天突然出現(xiàn)了某個問題，但現(xiàn)在不再出現(xiàn)了”。

因為這樣的問題一般意味著bug藏得深，需要殺死一堆腦細胞了。

然后馬上去看其中的一個API接口，結果一看發(fā)現(xiàn)連網絡都不通….然后再訪問其他的API接口都是網絡不通….;再訪問用戶沒有反饋到的其他接口，還是網絡不通。結果直接訪問服務器，還是不通。

對，沒錯，服務器掛了。

當然，掛了也要幫用戶解決不是。雖然我們的代碼早就通過對方技術團隊驗收并交付給他們自己維護了，但不是“客戶是上帝”么。還是跟用戶進行了溝通，協(xié)助他解決這個問題。因為這個項目訪問量不大，而且基本可以斷定軟件不存在致命（足矣讓服務器宕機）的bug；后面用戶說內部先溝通后在跟我聯(lián)系。

過了兩個小時后，用戶發(fā)給我這么一張圖：

對，沒錯，服務沒續(xù)費

而且已經過期五天了，還過個兩三天可能數(shù)據都被服務商清空了

對，沒錯，bug拯救了整臺服務器的數(shù)據

要知道這臺服務器還有其他的數(shù)據在的，而且據說用戶的用戶向用戶幾天前就已經反饋了，然而用戶內部并沒有及時來處理這問題，于是就有了上面的故事。

其實用戶自己的團隊也有做開發(fā)的，只是也許內部的人員都覺得這個事情應該跟我沒關系吧，結果就成了三個和尚沒水喝了。因此，我們一直建議，用戶如果項目訪問量比較低的時候（每天幾千個pv）可以使用我們的公共服務器，當有較高訪問量的時候可以升級到自己獨立的服務器甚至集群。然后交給我們來維護，比較專業(yè)的人做專業(yè)的事兒；而且交給我們來做，對于我們來講就是我們的事兒，就不會出現(xiàn)如此尷尬的故事了，雖然可能要適當收取點服務費（也許用戶可能就是不舍得這部分服務費吧，哈哈哈…..）。