歷年客服系統故障總結

1. 2007年1月，F客服系統，升級時接口機配置文件加載錯誤（把A地市接口機的配置文件拷貝到B、C地市的機器上），致使B、C地市不能查詢 BOSS資料。
   --總結：升級準備不足，升級結束沒有全面測試、沒有認真檢查，人爲致使故障。
  
2. 2007年2月，上需求時提早加載了數據庫腳本（準備晚上加程序文件），加載後系統立刻出現故障。
   --總結：違反公司的升級要求，隨意升級，人爲致使故障。

3. 2007年5月，下午處理報表故障時，把一個公共函數編譯了，致使300多個存儲過程失效，形成多個子系統沒法使用。
   --總結：白天違規操做線網數據庫，導致系統20多分鐘沒法使用。

4. 2007年4月，下午業務數據庫宕機，致使整個話務中斷（現象是工做流先不能使用，而後其它系統也不能使用，座席所有進入故障模式）。
   --總結：數據庫的共享內存用光了，重啓後釋放內存。

5. 2007年9月，知識庫升級期間的故障,緣由是配置文件設爲在白天每2小時建一次全量索引，話務量高時致使小型機IDlE值太低，系統宕機。 
   --總結：工程交接前沒有認真檢查，配置參數仍是用之前的，致使話務高峯時系統連續出現故障。

6. 2007年9月，晚上處理短信滿意度的問題，test線網存儲過程，致使某重要表被鎖，座席出現白屏沒法操做。
   --總結：違規操做，隨意在線網test，致使人爲故障。

7. 2007年11月，客服系統發生兩次CCS主備倒換，一次是上午業務部門加載數據致使，一次是晚上的緣由不詳，對系統沒有任何影響。
   --總結：在系統話務量大時，不要進行參數改動，也是人爲故障。

8. 2007年12月，凌晨在排隊機上加了XXXXXXX的業務字冠，與A地市的字冠發生衝突，致使電話撥打斷線。
   --總結：一是對排隊機不熟，二是測試不全面。
  
9. 2008年4月，版本升級後短信滿意度不能下發，故障持續到次日12點才解決。
   --總結：一是版本bug，二是處理問題思路不清晰，實質是需求沒有吃透。

10. 2008年6月，下午建應急庫時把線網導出的數據又導入到線網中（2個cmd窗口同樣致使），致使電話撥打斷線（緣由是地市數據源表加了重複數據，此表無主鍵，存儲過程當中沒有加rownum=1的限制），後把線網數據所有truncate後，再加入一次數據後解決。
   --總結：故障持續30多分鐘，違規操做，故障出現後報障詢問電話鋪天蓋地而來，壓力很大，影響了處理的思路。
  
11. 2008年7月，版本升級時，沒有按照升級手冊操做，多升級了一個有bug的dll文件，次日致使大量用戶投訴。
   --總結：違規操做，升級時隨意發揮，結束後尚未通報。  

12. 2008年8月，白天誤刪了分發表數據，又當即進行了恢復（時間短5秒內，沒有出現故障），緣由是在一個窗口中進行了備份和刪除。
    --總結：本質仍是違規操做。

13. 2008年8月，ITC執行了錯誤的sql語句，致使座席信息表的狀態所有更新爲1（失效），致使座席所有不能登錄。
    --總結：違規操做，個別人的技能不夠所致。
   
14.  2008年10月，開發同事違規登錄線網數據庫test存儲過程，致使線網大量對象失效 。
    --總結：安全意識不強致使，人爲故障頻繁發生。 

15.  2008年10月，需求上線時，本應刪除F數據庫的數據，結果誤刪了D數據庫的數據。
    --總結：同時鏈接了2個數據庫，進行操做，好在發現及時，沒有形成什麼影響。

16. 2009年5月，G中心晚上座席程序陸續異常退出，沒法再次登錄，持續4個小時，後查明是座席的一個參數致使，修改後全省更新（特別嚴重故障，驚動了部長大人）。
   --總結：系統bug致使（屬於高級別的bug），5年多才爆發。
  
17.  2009年7月，D中心同事查用戶清單，引發用戶投訴。
    --總結：違反信息安全，後果是很嚴重的，搞很差會承擔民事和刑事責任的，切記。 
   
18.  2009年7月，M中心繫統升級後致使沒法驗證密碼，引發用戶投訴，緣由是升級版本中的CHK擴展名文件被個人電腦自動刪除了，後從新更新一次文件解決。  
     -- 總結：使用我的電腦保護軟件時，配置刪除功能時要謹慎，防止誤刪有用的文件。

19. 2009年9月，D中心ITC私自修改線網表結構及存儲過程，不編譯也不及時通知，使得大量數據庫對象失效，致使系統出現重大故障。
    --總結：典型的人爲故障，並且相關人員技能不過關。

20. 2010年5月，D中心的電話撥打斷線，後查明是有人把一臺死機的服務器從新啓動，致使上面的應急Cti-link與線網Cti-link同時爭奪CCS鏈接，使的兩個都沒法鏈接，把應急Cti-link關掉後解決。
     --總結：首先是應急程序部署不規範，二是出現故障後處理思路有問題，缺乏組織協調5我的同時在處理，雖然進行過屢次應急演練，但真正故障出現時仍是手忙腳亂，可見實際和理論仍是有很大差距。

21. D中心平臺數據庫IDLE值很低，致使座席接續異常，緣由是業務室在同一時間大量查詢話務報表所致（發生屢次）。
    --總結：大量報表的查詢最好不要在話務量高峯時進行。

22. 2010年某月提取每個月例行數據時，沒有觀察表空間的狀況就開始日結數據，致使次日發現表空間爆滿，多個job異常終止。
   --總結：好在用的是放臨時數據的專用表空間，若是是放到其它域的表空間，後果可想而知。

23. 2010年10月，早上大量座席沒法登錄，緣由是晚上的某個需求上線後登錄座席時自動調用存儲過程查詢我的話務指標，致使數據庫繁忙，回退備份的存儲過程後不讓登錄時調用，問題解決。
    --總結：沒有充分考慮到需求上線後產生的後果，致使了嚴重的故障。

24. 2010年12月，新系統37的數據庫發生故障（沒有徹底宕機）沒法自動切換，致使半個省的業務中斷，後關掉37上的監聽，自動切換到36上，故障解決。      --總結：解決這個故障時，方法有問題走了彎路，使得故障持續了一個小時（中間切換到應急系統上）。           以上是本人幾年來經歷過的衆多故障中的一部分，能夠看出十之八九都是人爲故障，違規操做、任意發揮、不及時通報、有的甚至隱瞞故障，致使了不少重大故障的發生，也產生了嚴重的影響，但願對從事此類工做的同行有所警示，避免相似事件的再次發生。        上面提到的系統是由100多臺服務器組成的，使用了六、7年時間，如今已經光榮的下線退休了（本人也同步下線了），接替它的是一套全新的、先進的、功能更增強大的、業務更加複雜的由400多臺服務器組成的新系統。