1. 1月份东莞中心各部门陆续搬迁到新办公场地，整天车来车往乱糟糟的，也没有进行需求上线，系统也没有什么大的故障，我们是坚持到最后一批搬的人，我们所谓的搬迁就是背上电脑去就行了。
2. 2月1日正式到新场地上班，当天晚上就搞系统升级，因为快过年了有些人快要回去了，再不升级只能等到年后了，当晚升级结束后已经凌晨两三点了，打电话叫的士但人家不来嫌太远了，没办法只能在办公室睡了，好在还有几个简易床能用，但蚊子又叮咬的不行根本无法入睡，好不容易熬到天亮，赶紧出去挡个车回去睡觉。
3. 2月10日到24日放假回家过年，当年实行实名制购票，不能找黄牛了，只能自己打电话订票了。
4. 过年来后又到了两会封网，但当时有个紧急需求要上线，写了需求上线方案，经过层层审批终于走完了审批流程，要是在平常也不需要这么麻烦， 但在特殊时期流程就要比平时繁琐很多，线网的所有操作都要进行申请，只有得到授权后才能进行，不过这也不是件坏事，得到授权后再出了故障可以不负责任，记得以前客户的领导说过“按流程办事，做错了也是正确的，不按流程办事，做对了也是错误的”。
5. 4月某天上午接到报障电话拨打断线，先登陆机器把所有IVR服务器重启了一下，测试还是断线，立即跟踪流程发现没有日志，应该在进流程之前就出问题了， 跟踪排队机消息，分析日志发现有两个Cti-link同时争夺CCS连接，赶紧给ITC打电话了解情况，才知道是ITC把一台应急服务器重新启动，导致上面的应急Cti-link与线网Cti-link同时争夺CCS连接，使的两个都无法连接，后来去机房把应急的机器关掉后系统恢复正常。后来省公司让各区域把所有的 应急系统进行整理上报，防止类似的事件再次发生。这个事件对我们的教训是：首先应急程序部署不规范一些人根本不知道。二是出现故障后处理思路有问题，缺少组织协调5个人同时在处理，导致了重复工作。最后虽然进行过多次应急演练，但真正故障出现时还是手忙脚乱，可见实际和理论还是有很大差距。
6. 4月某天报障有个流程出了故障，后跟踪日志分析发现是流程中用的分区表没有建本地索引，建的是全局索引，刚上线后数据量较少没有问题，等过了一段时间后数据庞大了，索引已经不起作用了，因为流程六秒超时，数据还没有返回流程已经报超时了。后来规定谁写的脚本中分区表不建本地索引，一经发现立即罚款50元。
7. 5月21日到25日，去江门支持NGCC割接，进行系统割接前的数据配置和测试工作，现场三十多人，每人负责一部分工作，在江门待了一周，每天都安排一堆事情，天天晚上都是到11点多回去睡觉。
8. 5月底某天上午接到报障座席接续异常，马上查看平台数据库发现IDLE值很低， 一定是查询报表系统引起的，报表系统链的是平台数据库，在同一时间大量查询话务报表必然引起数据库资源的大量消耗，搞不好会造成宕机的，先暂时关闭报表系统，并通知业务室不要在高峰期同时查询报表，避免类似事件的再次发生。
9. 5月低两个从南京来的同事培训结束回去了，同时07年和我一起来广州的一个同事离职去了杭州，NGCC项目一下少了三个人，显得人手有点紧张。
10. 6月中旬江门局点割接到NGCC系统，各区域派人到江门进行支持并观摩学习，为后续其他区域的割接积累经验。
11. 6月某天接到报障，某报表查询不到数据，经分析发现中间表在当天后就没有日结数据，分析日结存储过程发现正常，job日志表也没有异常记录，手动日结后数据正常，也没深究。过了一周又接到同样的报障，分析后还是老样子，不能自动日结，但手动日结后又正常，从头到尾分析了存储过程没有任何异常，真是奇怪，此表的数据很大有几十个G，就找个晚上清理了一部分数据，又观察了几天能正常日结，心想应该是没有问题了。谁知过了十多天又报障还是自动日结有问题，看来真要好好重视下了，应该不是数据量的问题，仔细和其它日结存储过程进行对比，发现在判断异常日志表状态时有点小差别，随后进行了修改，后来再也没有出现过此故障。但是这个问题是怎么引起的，那个存储过程已经用了几年了怎么现在才出现问题呢，一直搞不明白是怎么回事。
12. 6月某天下午接到报障说电话断线，马上测试跟踪流程，发现执行到携号转品牌存储过程时断线，应该是这个过程出了问题，test存储过程发现表被锁，此表每秒被调用几百次，只能先杀掉进程了。事后调查原因得知是业务室通过座席向携号转品牌表导几十万数据，导致此表被锁。公司明确规定严禁业务高峰期进行导入导出数据，大数据量必须通过datastation工具进行，通过座席只能导少量的数据，携号转品牌表已经存在几百万数据了，再通过座席导几十万数据，不出事才怪呢。
13. 7月05日到10日东莞进行流程改造，共分两次进行，搞的都不是很顺利，特别是第二次搞完后都中午12点了，赶紧吃过饭睡觉，第二天早上9点多还没去局点时，就打电话说语音有问题，赶紧赶到局点，找业务室的人问什么问题，人家说流程暂时不用了先不管了。既然不用了就早点说，让我白跑一趟。流程改造完成后，报表的故障接着而来，主要是按键轨迹进行调整后，所有的业务按键都发生了变化，这样存储过程中按照按键轨迹进行的分类统计必然就会变化，导致统计出来的业务数据量不准确了。只能从完全调整后开始统计，调整期间的一周数据基本上是无法使用了，把整个的原理给业务室的领导进行了说明，后来他们都接受了，期间的那些报表故障也就不用处理了，客观地讲这个也没法处理。
14. 7月AMS单报障说黑名单号码进入人工，骚扰座席让处理，查询话单发现提供的几个黑名单号码每天要打几百个电话，但只有一两次能进入座席，其余的都被拦截，看来这是个棘手的问题。找来号码先加入黑名单表然后测试了几十次都没有进入座席，一时也没有什么结果，就给客户说明情况，后续继续跟踪，把AMS单先结了。过了几天又报了几个骚扰号码让分析，这次直接用通用座席模拟黑名单号码测试，结果按照拨打轨迹测试了几十次没有一次能进座席的，这就奇怪了，也不知道那帮骚扰分子是怎么打进来的，一天到晚24小时不停的拨打也不嫌累，绝对是竞争对手找人干的，其他人是不会干这种即损人又不利己的事情的，这里面肯定是有利益驱动的。 后来定制也帮忙分析，修改了几个文件但也没什么作用，这个事情就这样拖了一两个月，再后来3.0的系统也快下线了，客户也不催了，就这样不了了之了。