進入IT這個坑轉眼快10年了，從開發到運維到DBA，一直做著***層的工作，干些瑣碎的事情，今天來巴拉巴拉那些年做過的項目，告慰一下失去的青春歲月！小項目就不提了，講幾個拿得出手的。

[[136782]]

***個拿的出手的項目是廣東移動的多媒體痤席項習，時間大概是2007年十月、十一月左右吧，多媒體坐席是個什么東西呢，它不是東西，它其實是廣東移動網 頁版的10086系統（類似于QQ），是廣東移動布局互聯網服務的一個入口，也是為了在不方便打電話的情況下，還可以通過網絡來解決服務問題，不至于出現 服務肓區。項目的系統架構：終端  + 集群應用服務器 + 集群中間件 + RAC 9I數據庫，開發語言：Java + PL/SQL。

項目初期各種資源投入很到位，項日進展也很順利，但到了后期情況就有所變化了，主要是2008年廣東移動開始進入3G網絡時代，現有的一套系統是2003 年建立的，面向2G網絡的，己不能滿足3G業務的發展需要了，一套全新的系統已經開始規劃，不久就要開始實施。而這套多媒體坐席系統還是2G網絡的一部 分，顯然已經不能適應3G業務的發展需要了，因此這個項目處于一種尷尬的局面。既不能上也不能下的狀態，上呢遲早要淘汰，下上呢做了一大半，以前的努力就 白費了。因此項目后期資源投入跟不上，一些問題拖著無法解決。

主要問題有消息丟失、消息分配不及時、消息重復分發等，而這些問題都比較棘手，因此天天要進行跟蹤，分析日志、修改代碼。但是這些問題也不是天天都有的， 基本都是在業務高峰時可能會出現，所以就給跟蹤分析帶來很大困難，你跟時不一定會出現，而且跟蹤時會影響系統性能，如果等問題出現了再跟己經來不及了，這 就是問題的棘手之處。但是客戶他不管你這些，他出了錢就要一個能正常使用的系統，你說日志跟不到無法定位，這不是理由??！因此搞的我們見了客戶就像老鼠見 了貓一樣，都躲著走。后來實在沒法再拖了，才從總部了來了兩個研發到現場解決，再加上市場的忽悠，問題總算是解決了，客戶才在驗收報告上才簽了字，項目總 算是搞完了。 

   這個項目客戶雖然拖著不簽字，但不代表客戶不支持我們的工作，相反在項目中客戶還是給了我們很大的支持，比如我們懷疑移動的內網可能有攔截敏感消息的可 能，建議***能去外網測試，客戶馬上就安排十幾個人去網吧測試，沒想到還真與網絡有關。說實在話如果客戶不幫你，要自己找一批人測試也不是一件容易的事， 這也是我這么多年做項目唯一的一次難忘的測試經歷。所以和客戶多交流多溝通，充分利用客戶的資源，對于順便的完成項目是有很大幫助的。包括后來做的幾個項 目，客戶都給予了很大的幫助包括吃飯住宿等，在此也要對客戶表示感謝。

   對這個多媒體座席項目的評價是‘累、散、慢’。

#p#

2008年廣東移動主要的項目是BOSS 的項目，我們客服主要是協助BOSS方面做技術支持工作，做為雙方的接口人，定位出測試中發現的問題到底是那方的，由誰來解決。先后參與了廣東移動八地市動感地帶回割項目、中山移動OCE回割智能網項目，地點都是在中山市。這種項目都比較大，參與人數較多，廠商也不是單一的一家。項目的組織架構也較復雜，都是項目總指揮負責制。由移動方出任項日總指揮，各廠商出任付總指揮，下設若干職能小組，每組一個組長，組員是混合組成的。

動感地帶回割項目，就是把動感地帶的計費由以前的其它系統全部割到由BOSS系統進行計費，項目是封閉式開發，比較辛苦，但是這個項目的待遇比較好，項目經理天天晚上領著一幫人去喝酒，到***一聽到喝酒兩字都想吐。每周還有一次自助餐吃外加一次外出活動，如去中山市外爬山郊游，項目場地還有娛樂健身器材，總之項目活動是很豐富的。不像有的項目從早到晚都是一件事，埋頭苦干寫代碼。這個項目是我做過的最爽一個項目，主要是項目主體不在我們這邊，所以不用操太多的心，完成自己的本職工作就可以了，以致于***都不想離開了。項目***割接的時候，中山市電視臺還進行了現場報道。對這個項目的評價就是一個字‘爽’，這個項目同時也驗證了一個道理，就是有錢好辦事，錢能把所有人團結起來，不管你們互相認不認識，只要你們都認識錢就行了，看來錢這玩意真是個神奇的東西！

進入2009年主要是在東莞做項目，先說下東莞的地名：橫坑、小坑、長坑、井上等等，聽聽這名字，不是坑就是井，不坑也不行啊！移動客服的地點也比較偏僻，東西北三面一公里內是荒蕪人煙的。2009年的***個項日就是廣東移動一級客服項目，這是個內部的報表系統，就是省公司把各地市公司的運營數據抽到省公司的數據庫，然后再進行各種處理展示，以便省公司進行分析決策。系統架構與上面的幾個項目一樣，廣東移動的主要系統架構基本都是一樣的，這里就不重復了。當然了這個報表系統就是多了兩層的數據抽取轉換，***層是從六大中心的數據庫進行數據抽取，加入省公司的數據庫，還有一層是在省公司的數據庫中進行數據的再次處理，別的都一樣。

項目過程也沒有什么多講的，資源到位項目進展很順利，唯一不好的就是要常去機房，但是那塊的交通不方便基本上無車可座。因此只能搞個舊自行車騎著去機房，吃飯也不方便，屬于拿著錢也找不到花的地方，只能靠泡面解決了。為什么這個項目和上面的項目有天壤之別呢？除了地理因素外，還有一個核心的問題，就是沒錢。準確的說是沒有多余的項目活動經費，沒錢只能是吃泡面了，拿什么吃肉喝酒??！這是我做過的待遇最差的一個項目，還好項目本身沒什么問題，早早完工了，自己也早點解脫。

   對這個項目的評價是‘苦、累、差’，太差了，差的不得了！

#p#

  2010年12月底項目實施過程中， NGCC系統發生了一次重大的故障，當時的處理過程和上月底支付寶故障的處理過程有點相似，在這里來說說吧。故障的原因是一臺數據庫主機的交換分區耗完了（是P595主機的配32個CPU 96G內存），但是主機并沒有宕掉，導致服務不能自動切換到另一臺主機上，當時的影響是廣東移動半個省的10086電話受到影響，而時間大概11點多，已經進入了業務的高峰期。這是個非常嚴重的故障立刻上報省公司。分析故障***給出的解決方案是關掉監聽，讓應用自動切換另一臺主機。把方案上報后，等待省公司領導批準。但事情并沒有想象的那么簡單。為什么呢？就是因為有一套應急系統在那放著。***省公司的領導讓切到應急系統上，先讓主流程開始服務，其它的問題后續再解決。

好吧，領導讓用應急那就用應急吧，結果應急系統上面還是舊系統的流程文件，馬上從新系統上拷貝一份完整的流程文件替換到應急上面，修改配置，啟動相關服務，大概20分鐘左右完成，至此10086電話可以打通了，當然只能提供主要的流程服務。時間已經過了1個多小時了，主流程可以使用了，下面馬上解決主機交換的問題，修改交換分區重啟主機，幾十分鐘又過去了，主機終于搞好了，數據庫能正常使用了，再次上報省公司領導是否馬上切換回來，因為應急系統無法提供完整的服務，等待.................，終于領導下令了切換回來，切換很快完成，故障解決了，但是時間已經過去了兩個多小時。

支付寶的故障是怎么處理的，我不清楚，但估計不是那么簡單的進行二選一（即讓高層領導在啟用應急和重啟服務之間做出選擇），少不了要層層匯報，同時還要給領導講出充分的理由，為什么要這么做，利弊是什么。然后領導們再進行決策，估計是集體的決策。領導也要考慮責任問題的，集體的責任總比個人的責任強吧！所以事情沒有我們看的那么簡單的，絕對也不會簡單的。 我們可以把問題看簡單，但領導不能把問題看簡單，這恐怕就是為什么我們當不了領導的原因吧！

2011年離開通信行業進入互聯網行業，也做過一些項目，如某公司的CRM系統，某電商公司的分布式服務平臺項目（系統架構：LVS + 集群應用服務器 + 11G RAC，前端使用DNS加速，后端使用memcache緩存），對這些項目的感受是，無論從規模上、技術上、項目管理水平、項目參與人員的素質等方面，與廣東移動的項目都有很大差距。別的不說，沒錢沒權，什么也干不了，干了也干不好，我曾經遇到個只有幾十萬的小項目，拖拖拉拉一年多，***項目不了了之，買方拿到的東西不是他所想要的，賣方說那點錢只能做出這個啊！***買賣雙方都是一無所得?？粗祭?，更別說做了。經常有人問，項目成功靠什么，什么時間、成本、質量、范圍，狗屁！我看靠的就是權和錢，沒錢沒權拿什么做項目、拿什么籠絡人心、拿什么吃吃喝喝、拿什么進行黑幕交易，在這個非常現實的社會里，必須先解決這些非?，F實的問題，然后才能開始做項目，當然了時間、成本、質量、范圍、溝通也是很重要的。

以上就是本人那些年做過的項目，就先嘮叨到這吧！