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的系統也快下線了，客戶也不催了，就這樣不了了之了。