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，就找个晚上清理了一部分数据，又观察了几天能正常日结，心想应该是没有问题了。谁知过了十多天又报障还是自动日结有问题，看来真要好好重视下了，应该不是数据量的问题，仔细和其它日结存储过程进行对比，发现在判断异常日志表状态时有点小差别，随后进行了修改，后来再也没有出现过此故障。但是这个问题是怎么引起的，那个存储过程已经用了几年了怎么现在才出现问题呢，一直搞不明白是怎么回事。
