1. 8月开始进行全省大夜班集中项目，把全省的夜班话务全部转到东莞来处理，采用的是二次呼出重定向技术。先上线大夜班集中专项需求， 部署了专用的服务，在集中配置台、IUAS、Dtproxy上配置各地的数据源，随后的两个月中分地市把全省夜班话务割到东莞，每天8点前把数据从东莞回传到各中心。
2. 8月公司安排了一批研发进驻现场各局点，全面挖掘各局点的系统隐患，历时一个多月对系统进行了一次彻底的整改，进行了重大的系统升级，目的就是防止亚运期间出现重大故障。又根据亚运期间可能出现的问题，进行了多次系统应急演练，调整和完善了演练方案和流程，做到每个现场工程师熟悉应急流程、掌握应急方案、在发生故障时能从容应对。
3. 9月初周五提取每月例行数据时，查看表空间还有几个G的空间就没有清理以前的数据，开始日结上月的数据。到周一来后查看日结是否完成时，发现只日结了十多天的数据，一查看表空间已经百分之百满了，只能把表全部truncate了，然后再重新日结。好在日结表用的是放临时数据的专用表空间，如果是放到其它域的表空间，后果可想而知。看来以后再日结大量数据时，必须要充分估计数据量的大小，不然会出大故障的。9月中旬佛山局点割接到NGCC系统，佛山割接前后用了三个月。
4. 10月国庆过后东莞中心四地市NGCC割接工作正式启动，先召开项目启动会，参会人员有客户业务部门、BSC部门、定制开发、维保、工程团队，会上明确人员职责分工、确定了关键事件的时间点。
5. 10月某天系统升级结束后，早上还在睡觉接到报障大量座席无法登陆，应该与需求有关赶紧去局点，检查发现小型机的IDLE很低，资源很忙，应该 是晚上的需求‘个人数据中心’导致的，因为这个需求是登陆座席时IUAS自动调用存储过程，查询每个人前一天的工作指标，自动显示供座席查看。上线前有所担心，但没想到这么严重，因为上千个座席同时登陆，IUAS自动调用存储过程必然导致数据库繁忙，结果是每个人都无法登陆。后来回退备份的存储过程后不让登陆时调用，座席才能正常登陆，后来这个需求也没有再上线。
6. 10月份主要的工作就是NGCC流程配置及测试工作，部署服务并进行测试故障处理，主要是为月底的万号段割接做准备。三次全业务测试100%通过后 ，月底万号段第一次割接及需求上线，新旧两套系统并行运行，主要是检验新系统的性能、功能和对人员的培训等。
7. 11月亚运会即将召开，进入封网期，但NGCC项目还是继续进行，基本不受封网影响 。 11月10日东莞的亚运值班保障动员会召开、当天早上在会场外的停车场停车时发生了一个小事故，最后交警来了让赔对方100元了事，看来运气不好。会上宣布纪律、明确职责、确定保障期间的签到、值守、故障通报、应急、后勤等各个方面的执行细则，人手一本手册、每人一套衣服。亚运期间又从别的省调了人到东莞支持，基本上我是每天16点到24点值守， 8点到16点其他同事值守，值守期间也没发生什么事。但在别的地方有人在休息时间擅自离开宾馆出去逛街，正好发生了故障，打电话找他时竟然说在外面逛，客户直接通报到指挥部，后果是此人立即从哪里来回那里去。
8. 11月26日最后一次周末3.0客服系统巡检，12月3日割接后，这套使用了6年多的系统就要退出历史舞台了，因此当天的巡检比以往的时间都要长，看着这些曾经参与过的系统即将走到尽头，难免有些感慨。
9. 11月27日晚上23点30分亚运保障结束，紧接着又是NGCC需求版本上线，搞了一个晚上第二天刚离开东莞，还在车上就接到报障，系统出故障了， 赶紧联系东莞的同事去局点处理，这个故障要是出现的再早那么一点，就赶上亚运会的闭幕式那就麻烦了，看来运气还是不错的。
10. 12月2日中午开始准备NGCC系统的正式割接和需求上线，所以人员都进行了明确的分工，晚上23点正式开始，第二天早上7点结束，吃完饭回去睡觉，另外一批人来守局，一天无事，看来割接顺利，应该不会出现什么大问题了。第二天AMS单报障，部分上传BI的数据没有上传，随后把3.0系统上传的数据重新部署到新的服务器上，有根据需求部署了好多数据接口，看来上传的数据是越来越多了。
11. 12月12日残亚运会保障开始，当天晚上23点30分当天值守结束，刚回到住处就接到电话报障，一级客服几个小时的文件没有上传，有用第二天要上传集团， 让立即赶回局点处理，由于住的地方打车不便，无法赶去局点，最后商定第二天处理。 第二天一大早赶到局点，查看昨晚的故障现象，22点数据抽取服务异常退出，导致小时结存储过程没有运行，昨晚22点到今天7点的文件全部没有生成，因此必须手动分小时重新日结，8点多处理完毕文件上传集团， 随后召开电话会议，商讨应急的对策。
12. 12月18日早上还在睡觉，电话响了报障说语音播报出现故障，领导很重视，必须马上解决，立即起床，脸也没洗直奔局点，登陆语音服务器发现有几个地市的语音文件在昨晚22点被修改过，随后让负责语音的人回退了文件，语音恢复正常。后得知是昨晚业务部门更改了语音，但是要等到所有服务器同步后才能生效，且晚上进入夜班服务时间，无法测试发现，第二天7点30进入白天服务时间，问题才出现，由于是特殊日子这个事件我们得了一个严重故障单，后来针对这个问题专门开了系统安全电话会议。19日亚残运会闭幕式结束，至此整个亚运值守全部结束，当天晚上又进行了12月紧急需求上线。
13. 12月NGCC系统割接后每天早上7点多就接到报障，系统查不到资料，检查发现新接口机每天早上不能连接BOSS，需要重启服务后才恢复正常，后来查明如果dtproxy两个小时没有发包，服务就会自动关闭，后修改配置参数解决。
14. 12月底某天中午正吃饭，报障说半个省的电话全瘫了，赶紧上报，检查发现所在域的数据库发生故障（没有完全宕机），当时决定切换到备机上，但是省公司不同意，让启用应急系统，谁知应急系统是3.0的系统，有赶紧让定制修改版本，搭建了6.0的应急环境，切换到应急系统后，再开始讨论下一步怎么办，后来还是切换到备机上故障才完全恢复。这样一折腾故障持续了两个小时，后查明是数据库服务器所在的交换空间过高导致。
15. 12月底进行离线报表库打补丁操作、12月NGCC需求版本上线，折腾了一晚上天亮后2010年也就马上结束了。
来源：oschina
链接：https://my.oschina.net/u/4328465/blog/4870890