1.  2007年元旦过后也不用上班了，等待广州的通知，当时大部分人已经走了，剩下的也收拾好东西准备随时出发。

2.  1月上旬某天接到通知让去广州报道，随后与同事带上东西坐火车赶往广州（坐火车主要为了安全），到位于广州大道广州大桥的局点找项目经理报道，随后去宾馆休息，第二天正式报道。

3.  第二天一早到局点报道，相互认识下，等各局点的同事都到齐后开始开会，主要是分配导师和一月份的工作安排，结束后部分 同事就奔赴局点了，当时我被派到佛山，但佛山局点还没准备好暂时先待在广州等待通知。

4.  一周后也就是1月中旬了，接到通知让赶到佛山，于是动身从广州芳村客运站坐车到佛山季华五路的局点，当天先安排好住宿。

5.  第二天随导师去拜访局方领导、接口人等，然后就正式开始了在局点的工作，第一个事情就是12月需求版本的上线，要在一周内完成，当时对局点的情况一无所知感觉到无从下手，好在导师的指导下先学习需求、整理好版本、了解了与需求内容有关的服务器情况、各服务器的升级步骤注意事项，第一次升级时导师操作，我注要是学习记录升级过程。

6.  下来的一周就是熟悉上百台服务器的情况，整理各机器部署了什么服务、目录结构是什么、主要配置文件是什么、日志文件、机器配置等，其实这些都有现成的，只不过自己摸索一遍会更加熟悉。

7.  1月下旬又进行了两次升级，第一次升级接口23点开始，由我操作导师旁边指导，先升级了佛山的dtproxy，然后再升级其它三个地市的（中间导师出去了一会，就在这一会的时间出事了，但当时并没发现直到第二天7：30后才发现），升完后开始测试佛山的结果正常，其它三个地市没有测试条件也没有测试，反正时间也不早了，先回去了早上可以早点来守局。

8.  第二天7：30电话响起是接口人的，说三个地市查不了BOSS资料，赶紧去处理下（当时座席是7：30上班，其余人是8：30上班），赶紧起来先给导师打电话通报情况，导师说你先把备份的配置文件回退，别的先不要动等我去了再检查。在路上我就想是哪里出了问题呢？为什么单佛山的正常，别的不正常。一定是我用佛山的配置文件替换了其它3个地市的配置文件所导致的，到局点后马上回退文件重启服务一切正常后通知了接口人。随后把新旧文件进行对比，发现dtproxy的2个配置文件的前几行是各地市数据源的名称、用户名、密码、对端BOSS的IP地址， 后面的命令字部分才是完全一样的，我当天准备时只看了后面的，没注意开头几行，文件覆盖后导致其它地市都从佛山的BOSS里取到数据， 但佛山BOSS根本没有其它地市的资料，所以就无法查询了，但它是有收发包的，就是这个收发包当时把我迷惑了。后来导师来了检查也是这个原因，有讲了dtproxy的原理和调用过程（座席-->Dtproxy-->BOSS，座席-->IUAS-->本地数据库），上班后导师给接口人讲了故障的原因，说是 一时疏忽导致的，由于早上影响小又很快解决，就这样完事了。回退的文件找了个晚上又升上去了。

9.  1月最后一次是升级座席，座席的配置文件是键值对的形式，要修改配置文件对应的时间值和系统参数表中的时间值，这样才能进行自动升级，当时我没有修改系统参数表中的时间，根本就没有升级，而测试时我本机的文件是最新的，我误因为是升级成功了，直到第二天客户来问我怎么没有升级提示时，我还感到很纳闷，后来还是导师检查出来是系统参数表时间没修改，修改后重新签入座席开始自动升级。

10.  当时是月底，马上要去广州开会和汇报工作了，我半个月就搞了两个事故，有点担心客户投诉，导师说不用担心，都提前给客户说过了他们不会投诉的，不过吃一堑长一智，以后不能再发生类似的错误了。1月底没有进行答辩，主要是大家刚到局点还没学到什么东西，推到下月。

11.  进入2月主要是掌握升级方法，学习系统资料，当时的资料有几个G，先从常用的座席、流程、接口学起，报表是本行就不用学了，所有的报表故障都由我处理，其它的工作流、知识库、考试培训、公告便签、质检考评、外呼营销、平台各组件根本无暇顾及，先把常用的掌握了。

12.  2月一次升级流程时，在晚上20点就提前加载了数据库脚本（准备晚上加程序文件修改配置），刚加载完就接到报障电话，流程出现故障了，想回退脚本已经不行了（部分表结构已经修改了、数据、函数、过程已经加了好多），当时很紧张，赶紧给导师打电话说明情况，导师说那你只能把文件全升上去了，我马上赶到局点。我赶紧升级流程文件，但加载配置数据很慢，加载一条要提交一次，加载完后配置生效，然后逐台重启IVR服务器，测试正常后，一个小时已经过去了，晚上20点正式话务的高峰期，这个故障搞的动静有点大，第二天上班后跟着导师去向客户说明情况，由于当时还没有完备的上线流程 ，这个事也就那样过去了，不过导师当时替我扛了不少责任。   

13.  2月14日--23日在网上搞了一张黄牛票春节回家过年。

14.  年后来已经到2月底了，要准备答辩了，还是至少3个案例的PPT，刚去也没有处理什么故障，主要写了各个模块的升级过程和注意事项，以及1月多的学习情况，答辩当天整个项目组的人全到了，会议室人满为患了，上午一个人答辩一小时，先讲案例然后领导与各导师相继提问，下午由于时间不够分开答辩，我的PPT写的东西基本都掌握了，但问题一扩展开后就不知道了，各部分的原理还不了解，反正是大家的总体答辩情况都不好，答辩完已经天黑了。

15.  进入3月，除了继续掌握系统升级外，就开始接手处理部分故障了，先从座席、接口开始，这两部分已经玩了一个多月了，基本原理也熟悉了，日常问题也基本能处理了，其它部分也开始加快学习了，在导师的指导下先后在空闲的服务器上部署了座席、接口、工作流、知识库、考试培训的应用服务，了解了体系结构、配置文件、基本的数据流转、所用到的主要数据库对象，熟悉了系统的数据字典等。

16.  3月底第二次答辩，这次主要是写了处理的案例，每个部分一个，最重要的是一个流程的案例，那段时间导师请假不在局点，局点就我一个人，此问题从现场到定制开发再到总部研发，才最终找出故障所在，原来是分发表的一个不常用参数为空值导致，分发表的每行数据对应一个流程后面有4个参数，常用前两个，后两个基本都为空，这个故障正好是第四个参数为空导致的。第二次答辩情况比第一次要好，大家都掌握了升级的技能，全面向日常维护迈进了。

17.  4月最严重的故障是某天下午业务数据库宕机，小型机PING不同，导致整个话务中断超过半小时，这种故障发生后立即上报项目经理，并逐级上报，客户接口人马上赶到位于南海桂城的机房，重启机器后恢复正常。后经IBM的人检查是数据库的共享内存用光了，重启后释放内存。

18.  4月份又开始学习平台组件的相关知识，平台组件关系着话务的正常流转，通过学习平台知识，才明白了当时在深圳培训时说的一个话务经过三个设备（IVR、队列、座席）分别产生一条话单的含义。简单提下话务的流转过程：用户打客服电话-->大网-->排队机-->CTI-Link-->CTI-Server-->CCS-->VP台放音-->读分发表数据-->集中配置台-->IVR-->队列-->座席-->VP录音-->座席与用户通话-->通话结束转满意度调查-->写话单结束（其中IVR-->Aplogic-->本地数据库，IVR-->Dtproxy-->BOSS），中间任一环节出现异常则转入异常流程。

19.  4月底进行第三次答辩，还是写3个案例，通过案例引申到系统的流转过程，即就是上面的话务流转过程，掌握了这个过程就把整个系统掌握了，只可惜当时根本没有掌握。3次答辩后有三分之一的人正式转正，剩余的人又经过一个月也相继转正。

20.  2007年的5.1长假好像是最后一个7天长假，一天正在佛山书城看《江山风雨情》（讲的是明末陈圆圆、崇祯皇帝、吴三桂的故事），突然接到电话说系统出现故障，只好放下书回局点进行处理，是个小故障一会就搞完了。当时还没有形成完善的值班体系，只能是各局点处理各自的故障，后来打通了各区域网络，才形成了统一的值班体系，这样可以提高故障处理的效率，节省了人力。假期的后几天每天都去书城，看了好几本小说。

21.  5月某天下午，客户催着让处理几个报表的故障，结果一不小心把一个公共函数编译了，立刻导致300多存储过程失效，立马把我吓了一身冷汗，赶紧编译，但一编译电脑马上死机反白 ，只能一个个编译，报障电话接着就来了说多个子系统无法使用，编译了半个多小时全部成功了，从此以后再也不敢白天玩这种高危操作了。

22.  5月某天早上还没有上班，BI就发了10个故障单过来（派单时有提示短信），当时很生气，10个单上面领导不清楚还因为发生什么重大事件了，上班后导师来了说他打电话把派单的人训斥了一顿（后来得知把BI的小MM给骂哭了，小MM向省公司投诉我们态度不好），当时这件事也就那样不了了之，但它为后来埋下了伏笔。自从与BI方产生接口往来后，双方的口水战就没有停止过。

23.  5月底剩余同事的第四次答辩，至此我们1月来的这批人答辩全部结束。

24.  6月除过需求外主要的工作就是佛山数据库升级包括小型机、AIX、ORACLE全部升级，其中数据库由ORACLE 8.1.7 OPS升级到9.2.0.8的RAC，数据的迁移采用EXP/IMP工具，以某个时间点为准开始导出数据，大概用了5个小时左右，然后导入新库大概用时12小时左右，这个工作在白天就开始进行了，晚上0点正式把所有系统的数据源切换到新数据库上面，等数据导完后再把时间点之后产生的那些数据导到新库上，一切都进行的很顺利，只有报表受到影响，其余系统未受影响，后把那2天的报表数据重新日结，报表恢复正常。整个迁移工作用时大概30小时。