工作日志2008年、二

1. 5.1过后，5月4日各区域人员回广州进行web知识培训，其实也就是让大家聚聚交流下感情，下午项目经理找我，说广东八地市动感地带回割项目要在中山进行，中山属于佛山区域，安排你去技术支持明天就去报到。第二天一早动身去中山，找到项目地点中山盛景酒店报道，主要工作是分析定位座席接口故障，是BOSS的问题BOSS解决，是座席的问题客服来解决。刚到现场就给发了200多个问题让处理，发这么多鸟问题这搞到什么时间啊，先给问题分类发现有些是重复问题，先定位座席的，座席的好跟踪日志在客户端跟踪，可以顺便调节日志级别，而流程要在服务器跟踪就不方便了，当天搞到晚上12点左右把所有的座席问题定位完，回去睡觉，走的时候现场还有部分人在加班。

2. 每天测试组又会测试出一堆问题，每天都有好多问题要定位，看来还是要做长远的打算，一天两天是搞不完的，问题基本都是BOSS造成的，如BOSS修改了协议，增加减少了返回值、字段类型或字段长度发生变化，而客服系统没有来得及修改，导致IUAS不能解析，就会报错。基本上每天是早上10点去，晚上23点才能回去，回去后项目经理还拉着兄弟们去喝酒，折腾到凌晨两三点才回去睡觉。

3. 5月12日下午正上班，有人喊道地震了，有人问道那地震了，快上网看上网一看四川汶川大地震，十几个省都受到影响，这下现场一下子乱了，200余人一时各各给家里打电话问平安，我也赶紧给家里打电话，西安也有强烈震感，人都跑到外面避震，家人平安也就放心了。

4. 八地市动感地带回割是以BOSS为主导，客服只是协助定位接口故障，也没有什么大的事情，定位出故障是谁的问题谁去修改。之间佛山搞流程改造回去了一趟，我离开那几天广州的同事去中山顶替了下。佛山的全流程改造4月下旬就开始准备了，把线网的几百个流程和按键轨迹重新整理下，搞这个东西有风险，所以一直就拖着，现在客户下了死命令5月底必须整理完，不然也不会从中山现场紧急抽回来。整理的过程大概是：业务室梳理语音和按键轨迹，然后重新配置分发表数据，调整IVR服务器的按键文件。过程看着不难就是很麻烦，分发表五千多条数据，够调整一阵子了，分了两个晚上分地市进行了调整，基本还算顺利，搞完佛山的流程改造后又赶到中山，去替换广州的同事，流程改造表面上看是风平浪静，其实更大的麻烦已经在等着我了，只是暂时没有发现罢了。

5. 中山割接的时候，一帮人又在珠海搞OCS的割接，OCS的问题也归到我这里来定位，每天都一大堆问题，5月28日中山第一次割接，第二天早上佛山打电话报障充值流程出现故障，赶到现场跟踪流程分析发现不是割接的问题，属于BOSS的问题，让找BOSS处理下就行了。30日晚第二次割接，割接当天省公司各市公司的领导都到现场参观，忙了三四个月马上就要结束了，中山电视台的也来报道，割接晚上一直待到凌晨两点也没有什么问题就先回去，早上八点再来值守，八点赶到现场值守发现好多人还没有回去，当天也没什么事，下午有些人就陆续离开中山了，6月1日风平浪静就请示项目经理后离开中山，离开时项目组给每人送了一份中山特产已表示感谢。

6. 5月的时候公司搞任职资格制度，工程师要评定级别，采用自评加考评的方式，我给自己评的是工程师三级，后来结果出来了给的也是三级，当时07年初来的那批人基本都是三级，个别时间更早的人是四级，后来09年、10年又调整了两次基本上是增加一级，有的到了四级、高级一级，但是我的一直没变，后来我从别的途径得知没给我增加的原因是我被客户投诉过，09年后期又被客户投诉了一次，这两次导致了我与晋级无缘了。那个鸟级别也倒无所谓了在外面没人认这个东西，但是级别相差一级工资就差500元，当时为了一时口舌之争最后导致了这个结果，是谁的错误呢？

7. 从中山回来后休息了两天，然后去上班，刚到局点客户就来找，你终于回来了报表出大问题了，我问什么问题啊，没见派单啊，客户说流程调整后各节点的业务办理和咨询量大幅下降，赶紧看下是那出错了。登陆报表查询了好几张报表发现以调整的那天为界，调整前有些业务一天十多万的办理量，调整后成了几万的办理量，还出现了大量的无名办理量，奇怪那个配置出错了呢？分析报表过程-->中间表-->业务量按键表-->业务配置表-->触发器-->分发表（咨询表），发现业务配置表的数据与现在的分发表数据不一致，难道触发器出错了，test触发器没有错啊，又在分发表加了几个测试数据，然后到业务配置表查询，并没有发现加的数据，看来这个触发器不触发了，以前有人说过这事。触发器不能自动修改那只能手动修改业务配置表数据了，花了一天时间重新调整了数据，第三天查看报表，发现各业务的办理量与以前相当了。但是中间的那段数据是修改不回了，把结果告诉客户，客户也只能这样接受了，至于那个触发器先删除然后又重新加了一次，竟然又正常了。

8. 6月客户派单让新建个测试库，以做平时测试用，一天下午开始导数据，开了两个CMD窗口一个从线网导出，一个导入到测试库中，谁知一时疏忽把从线网导出的数据又导入了线网，命令还在运行电话就来了，报障3个地市的电话全部断线，听到这吓一跳，下午三四点电话全部断线那还了得，赶紧测试，这时还不知道是加了重复的数据，导入窗口还在运行。跟踪流程分析日志中的存储过程，从拨打电话到放第一个音共调用十多个存储过程，应该就是断线前的那一两个过程，打开过程一看晕了，几百行代码调用了好几个表，到底是那块的错误，这时已经发现数据导错了，领导们的电话铺天盖地的就打来了，你们干什么呢？电话全瘫了，流程的同事也在协助定位故障了，客户领导就站在旁边问是怎么回事啊，当时的情形真如热锅上的蚂蚁，有点手忙脚乱了，这时有人说把所有数据全truncate掉，再导一次试试看，照着这个做了后，电话恢复正常了，中断时间超过30分钟，这可是个一级故障啊。这时日志也分析出了，原来是数据源表中加了两条重复的数据，导致流程找不到数据源了，走了异常，数据源表只有3条数据也没有约束限制，调用它的过程中where 条件也没有rownum = 1的限制，随后对表和过程进行了修改，防止下次再出现问题。第二天给客户写了故障报告，客户也倒没有指责什么，只是让以后这种事要尽量小心，这事闹的省公司已经知道了。

9. 这个事情发生后ITC让我们搬到市公司去上班，不要在客服中心上班了，以前已经搬过一次了，从座席区搬到业务室，现在又要搬，那就搬吧反正包一背去那都可以，从客服中心到市公司也就两站路，在ITC上班可能还更好，因为业务室想找你找不到了，什么事都要派单处理，对我们来说是一件好事。

10. 6月中旬发现多媒体座席中的业务树与座席中的业务树不一致，检查数据库发现MSP数据库无法通过数据库链调用到业务库数据，test存储过程可以正常同步，但是JOB调用就无法同步，在没有找到原因前先每天手动同步一次吧。后来研发分析说是oracle 9.2.0.8的版本问题，那只能升级MSP数据库的版本了。

11. 每月底各中心都要向省公司上传半月的业务运营数据，正好6月底佛山的数据有问题，需要重新日结数据，客户找到我想让我帮他们修改下数据，把运营指标提高些，本来公司要求严禁随意修改客户的数据或帮客户修改数据，最后扛不住客户的请求，就重新建了一套日结，修改了算法重新日结了一个月的数据。后来听说各区域都在这样搞，后来省公司就停止让各区域上传数据了，而是新建了一套一级客服系统，把各区域的原始数据通过datastation导入一级客服数据库中，然后日结处理展示，这下没人敢弄虚作假了，毕竟原始数据没有人敢修改。

12. 7月全省又要修改满意度调查的规则，这个烂满意度从07年9月到现在就没有消停过，搞了好多故障，现在又要折腾，顺便讲下满意度的规则：座席通话结束-->转满意度调查-->规则判断-->触发器取数据-->自启动流程-->扫描数据到当前表-->超时更新状态-->第一条短信下发更新状态-->扫描用户上行更新状态-->下发第二条短信更新状态-->再次扫描用户上行内容更新状态-->下发第三条短信更新状态-->转移数据到历史表。

13. 7月初项目组组织大家去番禺长隆水上乐园玩一天，降降温放松下，结果到了这个鸟地方感到有种上当受骗的感觉，一条20元不值的劣质泳裤竟然要200元，黑真黑啊，看来中国的奸商，已经从头到脚黑透了。在哪晒了一天回来后身上蜕皮，疼了半个月真可恶，结果是没放松，差点把命丢到那，那种烂地方以后倒找钱也不会去了。

14. 7月佛山Dtproxy版本升级，当天晚上升级时看到当月需求中也有个dproxy.dll动态库，只是版本时间不同，心想都是同样的文件，需求文件的版本号高，一块升得了，升完后测试Dtproxy调用BOSS正常，升级通报中也没有提这个事，第二天正在睡觉被电话吵醒了，报障说现在系统不能验证密码，但BOSS系统能验证，应该是晚上升级的问题吧赶紧来看下。赶紧到局点跟踪Dtproxy消息，发现验证密码时返回是失败的，把跟踪的消息发给现场开发，过了一会让把Dtproxy.dll动态库发去看看，最后开发告诉我是动态库中的判断逻辑写错了，重新修改后发给我让测试了，先找了一台替换测试后密码验证正常，随后把所有的全部替换问题解决。对于我私自改变升级版本，导致严重故障罚款50，此版本的开发也罚50.项目经理负连带责任自罚10元，以作警示。07、08两年因版本质量问题罚了好多钱，基本人人有份，后来版本质量好了，就很少罚款了，罚的款基本上买零食吃了。

15. 7月底去广州开会，结束后去K歌放松吃自助餐，上次去长隆大家意见很大现在去K歌以示弥补，去的时候下着大雨晚上10点回来时下还在下大雨，回来时从头到脚全湿了，那雨真叫大啊。

本文出自 “srsunbing” 博客，请务必保留此出处http://srsunbing.blog.51cto.com/3221858/885005