12. 6月某天下午接到报障说电话断线，马上测试跟踪流程，发现执行到携号转品牌存储过程时断线，应该是这个过程出了问题，test存储过程发现表被锁，此表每秒被调用几百次，只能先杀掉进程了。事后调查原因得知是业务室通过座席向携号转品牌表导几十万数据，导致此表被锁。公司明确规定严禁业务高峰期进行导入导出数据，大数据量必须通过datastation工具进行，通过座席只能导少量的数据，携号转品牌表已经存在几百万数据了，再通过座席导几十万数据，不出事才怪呢。
13. 7月05日到10日东莞进行流程改造，共分两次进行，搞的都不是很顺利，特别是第二次搞完后都中午12点了，赶紧吃过饭睡觉，第二天早上9点多还没去局点时，就打电话说语音有问题，赶紧赶到局点，找业务室的人问什么问题，人家说流程暂时不用了先不管了。既然不用了就早点说，让我白跑一趟。流程改造完成后，报表的故障接着而来，主要是按键轨迹进行调整后，所有的业务按键都发生了变化，这样存储过程中按照按键轨迹进行的分类统计必然就会变化，导致统计出来的业务数据量不准确了。只能从完全调整后开始统计，调整期间的一周数据基本上是无法使用了，把整个的原理给业务室的领导进行了说明，后来他们都接受了，期间的那些报表故障也就不用处理了，客观地讲这个也没法处理。
14. 7月AMS单报障说黑名单号码进入人工，骚扰座席让处理，查询话单发现提供的几个黑名单号码每天要打几百个电话，但只有一两次能进入座席，其余的都被拦截，看来这是个棘手的问题。找来号码先加入黑名单表然后测试了几十次都没有进入座席，一时也没有什么结果，就给客户说明情况，后续继续跟踪，把AMS单先结了。过了几天又报了几个骚扰号码让分析，这次直接用通用座席模拟黑名单号码测试，结果按照拨打轨迹测试了几十次没有一次能进座席的，这就奇怪了，也不知道那帮骚扰分子是怎么打进来的，一天到晚24小时不停的拨打也不嫌累，绝对是竞争对手找人干的，其他人是不会干这种即损人又不利己的事情的，这里面肯定是有利益驱动的。 后来定制也帮忙分析，修改了几个文件但也没什么作用，这个事情就这样拖了一两个月，再后来3.0的系统也快下线了，客户也不催了，就这样不了了之了。
出处:http://srsunbing.blog.51cto.com/3221858/896255
