2010年12月底項目實施過程中， NGCC系統發生了一次重大的故障，當時的處理過程和上月底支付寶故障的處理過程有點相似，在這裏來說說吧。故障的原因是一臺數據庫主機的交換分區耗完了（是P595主機的配32個CPU 96G內存），但是主機並沒有宕掉，導致服務不能自動切換到另一臺主機上，當時的影響是廣東移動半個省的10086電話受到影響，而時間大概11點多，已經進入了業務的高峯期。這是個非常嚴重的故障立刻上報省公司。分析故障最後給出的解決方案是關掉監聽，讓應用自動切換另一臺主機。把方案上報後，等待省公司領導批准。但事情並沒有想象的那麼簡單。爲什麼呢？就是因爲有一套應急系統在那放着。最後省公司的領導讓切到應急系統上，先讓主流程開始服務，其它的問題後續再解決。
好吧，領導讓用應急那就用應急吧，結果應急系統上面還是舊系統的流程文件，馬上從新系統上拷貝一份完整的流程文件替換到應急上面，修改配置，啓動相關服務，大概20分鐘左右完成，至此10086電話可以打通了，當然只能提供主要的流程服務。時間已經過了1個多小時了，主流程可以使用了，下面馬上解決主機交換的問題，修改交換分區重啓主機，幾十分鐘又過去了，主機終於搞好了，數據庫能正常使用了，再次上報省公司領導是否馬上切換回來，因爲應急系統無法提供完整的服務，等待.................，終於領導下令了切換回來，切換很快完成，故障解決了，但是時間已經過去了兩個多小時。
支付寶的故障是怎麼處理的，我不清楚，但估計不是那麼簡單的進行二選一（即讓高層領導在啓用應急和重啓服務之間做出選擇），少不了要層層彙報，同時還要給領導講出充分的理由，爲什麼要這麼做，利弊是什麼。然後領導們再進行決策，估計是集體的決策。領導也要考慮責任問題的，集體的責任總比個人的責任強吧！所以事情沒有我們看的那麼簡單的，絕對也不會簡單的。 我們可以把問題看簡單，但領導不能把問題看簡單，這恐怕就是爲什麼我們當不了領導的原因吧！
2011年離開通信行業進入互聯網行業，也做過一些項目，如某公司的CRM系統，某電商公司的分佈式服務平臺項目（系統架構：LVS + 集羣應用服務器 + 11G RAC，前端使用DNS加速，後端使用memcache緩存），對這些項目的感受是，無論從規模上、技術上、項目管理水平、項目參與人員的素質等方面，與廣東移動的項目都有很大差距。別的不說，沒錢沒權，什麼也幹不了，幹了也幹不好，我曾經遇到個只有幾十萬的小項目，拖拖拉拉一年多，最後項目不了了之，買方拿到的東西不是他所想要的，賣方說那點錢只能做出這個啊！最後買賣雙方都是一無所得。看着都累，更別說做了。經常有人問，項目成功靠什麼，什麼時間、成本、質量、範圍，狗屁！我看靠的就是權和錢，沒錢沒權拿什麼做項目、拿什麼籠絡人心、拿什麼吃吃喝喝、拿什麼進行黑幕交易，在這個非常現實的社會裏，必須先解決這些非常現實的問題，然後才能開始做項目，當然了時間、成本、質量、範圍、溝通也是很重要的。
以上就是本人那些年做過的項目，就先嘮叨到這吧！