历年客服系统故障总结

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多台服务器组成的新系统。