摘要：原著中桃谷六仙是給令狐沖硬灌真氣，作者筆誤但不妨礙意思。華為擅長鑄劍，卻不擅長用劍。而這些深入接觸用戶痛點的產(chǎn)品，我們都看不上，因為太小，不能在華為的銷服體系下大規(guī)模批量復制，所以都不愿意做。所有資源向公有云傾斜，導致其他領(lǐng)域全部貧血。

慣例

元旦過了，分紅混到了，該慣例了。

慣例就該瀟瀟灑灑的走，不需要哀哀惋惋仿佛全世界都欠你的，或飛鳥出籠仿佛逃出生天一般歡脫自在，這都不是我的范。

先說一下慣例的原因，向內(nèi)看滿眼茫然，向外看機會很多。年近不惑，還奮斗的動，又不愿在這里混吃等死。

忘了多久以前開始混吃了。直到一天我孩子給我講了個故事，一只母雞教育孩子要辛勤下蛋，說“一月不下蛋，高壓鍋里見”，讓我給她解釋是怎么回事，我才警醒，這樣混吃下去，下場就是“高壓鍋里見”。

我不想混吃等死。但是拔劍四顧，心中茫然，空有力沒處使。再加上公司的政策逐漸對不惑之年的老稈子們不友好，外面又有大把的機會和挑戰(zhàn)。這時只能眼睛向外，換一種活法。畢竟再等幾年，身體只能越來越走下坡路。既然該受的苦遲早要受，為什么不早受，早受還有體力扛。

所以大家不要在我的帖子下面抱怨被辭職，被不續(xù)簽，被慣例，被C，我不是那樣的。

?

這些年的經(jīng)驗，教訓很多，最近想了很多事情，趁著慣例總結(jié)一下。有用沒用，既然進來就當看個熱鬧吧。

拔劍四顧心茫然

說說拔劍四顧心中茫然的事。最近心聲上幾個熱帖，刀刀見血的針砭我廠云計算，都很到位。種豆得豆，其實這些事很早就埋下了種子。既然胸有塊壘，不妨吐一下，就按我腦中的優(yōu)先級，一個一個的解說。

關(guān)鍵詞：慣性。產(chǎn)品-解決方案，盒子，批量復制，再挖存量金礦。定下目標，一定會完成。換個人來，一樣能搞定。沒搞定一定是用錯了人。非我族群，其心必異。壓強投入，什么都能搞定。研發(fā)兜底。

關(guān)鍵詞：ISV。企業(yè)產(chǎn)品的銷售，其實業(yè)界通用的玩法是轉(zhuǎn)售和被集成。大部份的生意，其實是ISV在做，而且是ISV吃肉，我們喝湯。這個很簡單，ISV有客戶關(guān)系，理解客戶業(yè)務，清楚怎么攢出一個成套方案。這時，ISV可以替我們屏蔽大量的定制化需求，或引導，或外包定制，或集成，方法很多。而我們根本沒有在構(gòu)建ISV關(guān)系上花大力氣，仍然繼續(xù)著運營商時代直銷的方式。直銷，肉和湯都是我們的，卻是和大量的ISV為敵，進而和整個生態(tài)為敵。企業(yè)市場上的機會太多，項目都不大，指望我們的一線產(chǎn)品經(jīng)理盯一個區(qū)域，幾個行業(yè)，根本盯不過來。加上我們的產(chǎn)品經(jīng)理不是以ISV的SA視角跟蹤客戶，導致大量的定制化需求---我們又不能隨便在項目中集成第三方，而且一線產(chǎn)品擠也不可能有這種視野。

關(guān)鍵詞：生態(tài)。企業(yè)解決方案的銷售，其實需要的是發(fā)動生態(tài)。而我們根本沒有將建立生態(tài)作為我們的戰(zhàn)略。結(jié)果，就是我們處處碰壁，好像到處都是不懷好意的敵人。想起一個故事，一個人開車逆行，然后打電話給家里人說所有的車都在逆行，太危險了。

關(guān)鍵詞：山頭。外部內(nèi)部山頭林立，互相制肘。外部的山頭：虛擬化，操作系統(tǒng)，Paas，Docker，大數(shù)據(jù)內(nèi)核在2012，網(wǎng)絡(luò)/安全在交企，運營/運維在軟件產(chǎn)品線。內(nèi)部的山頭：數(shù)據(jù)中心，云計算，服務器，存儲。每個團隊都有自己的目標，但是力氣無法擰到一起。

關(guān)鍵詞：場景。場景太多：公有云，私有云，虛擬化，云平臺，NFV，NFVI。各種場景差異巨大，卻要放在同一套代碼，同一個版本中相互融合協(xié)調(diào)。這就像桃谷六仙給張無忌硬灌的幾股真氣一樣，難以調(diào)和。試想天下有幾人能練就乾坤挪移啊。（原著中桃谷六仙是給令狐沖硬灌真氣，作者筆誤但不妨礙意思。）

關(guān)鍵詞：薅羊毛。我們用開源的原罪：改，改不得，不改，又不行。開源與我們，就像一件反穿的軟猬甲。其實業(yè)界用開源的玩法，主要是薅羊毛，賣周邊，不像我們自己沖上去做了羊。

關(guān)鍵詞：領(lǐng)軍者的魄力。魄力不足。魄力，是做減法的能力。資源有限時，唯有做減法才能形成局部優(yōu)勢，力出一孔。而從戰(zhàn)略決策，到戰(zhàn)術(shù)動作，沒有人做減法。做減法需要有橫眉冷對千夫指的心理素質(zhì)，也要有泰山壓頂腰不彎的傲骨，而我們?nèi)边@樣的領(lǐng)軍人物。

關(guān)鍵詞：簡潔。技術(shù)方案是為客戶需求服務的，越簡潔的方案越容易穩(wěn)定。太復雜的技術(shù)方案，不是好事。IT行業(yè)，并不是一個板凳要坐十年冷的行業(yè)，因為十年，技術(shù)已經(jīng)更新了幾代了。君不見虛擬化，下一跳的Docker，再下一跳的Lambda計算，大家都已經(jīng)看到了。其實，從技術(shù)上講，這些“新技術(shù)”有多少是從零構(gòu)建的全新的技術(shù)呢？沒有。每一個又有多復雜呢？沒有，而且一個比一個簡單。

關(guān)鍵詞：用劍的大師。下一個時代，區(qū)塊鏈，人工智能，一上來就是以服務的形式登場，而不是我們熟悉的產(chǎn)品或解決方案形式。我們所熟悉的七遠八按三免九自，在這種場景下其實沒有任何用武之地。我們所期望的，依靠產(chǎn)品經(jīng)理給客戶講講產(chǎn)品就能拿下銷售的時代也將遠去。破解之道是服務化，構(gòu)建生態(tài)，專家社區(qū)，咨詢服務等更貼近客戶的方式。這時“市場呼喚研發(fā)”已經(jīng)不管用了，鑄劍的大師，并不是用劍的大師。華為擅長鑄劍，卻不擅長用劍。而不構(gòu)建用劍的能力，有敗無勝。須知劍法的極致，飛花摘葉也可傷人，為什么非要用你的劍不可？順便問一句，說到“構(gòu)建”，看到這里的您，想到的是華為該成立一個咨詢部門嗎？如果是，說明您下意識里仍然是封閉的，還沒有想到利用生態(tài)這一層。

關(guān)鍵詞：爆款。互聯(lián)網(wǎng)產(chǎn)品的營銷原則：爆款+面向目標受眾的病毒式傳播，而爆款必然是針對某個細分市場的擊中痛點的產(chǎn)品。我們還在夢想一個不接觸用戶實際業(yè)務的“平臺”能成為爆款，有點“緣木求魚”的感覺。而這些深入接觸用戶痛點的產(chǎn)品，我們都看不上，因為太小，不能在華為的銷服體系下大規(guī)模批量復制，所以都不愿意做。這時，不妨搞一些內(nèi)部創(chuàng)業(yè)，讓愿意做的人(比如我)去做，或者聯(lián)系ISV去做，合作方去做，構(gòu)建生態(tài)。

關(guān)鍵詞：貧血+枷鎖。所有資源向公有云傾斜，導致其他領(lǐng)域全部貧血。盒子時代的成功，阻礙了下一跳的發(fā)展。君不見，大數(shù)據(jù)，Paas，Docker，天生貧血，多個部門掣肘，還得帶上不碰應用，不碰數(shù)據(jù)的枷鎖。而大數(shù)據(jù)，Paas，Docker，更是那種鑄劍的大師不是用劍大師的產(chǎn)品，再加上我們的枷鎖，這些產(chǎn)品如果能發(fā)展得好，只能是神跡。

關(guān)鍵詞：劍法教練。客戶買劍，有一些是掛起來的，但大部份是舞起來的。我們的核心客戶群應該首先是舞劍的，而不是掛起來的。因為只有舞起來，才能給客戶自己帶來收益，才能源源不斷的買我們的劍。而我們并沒有教客戶舞劍，我們的銷售只是賣劍，我們的服務僅是對劍的養(yǎng)護。服務器，存儲，云計算，這樣尚可，大數(shù)據(jù)，Paas，Docker這樣就不行了。不用教客戶舞的好看，但起碼也得掄的起來才行。

關(guān)鍵詞：不碰。數(shù)據(jù)是蛋，應用是雞，數(shù)據(jù)和應用是雞生蛋蛋生雞的問題。但這和平臺有什么關(guān)系？平臺不過是個雞窩。你能壘出多少個9的雞窩，能抗八級臺風九級地震，一鍵部署，平滑升級，有意義嗎？

?

看完這些，您是否也覺得云計算是一個心比天高，命比紙薄，拽著豬隊友，背著玄鐵劍，扛著三座山，反穿軟猬甲，帶著一幅枷，形單影只的獨行者，盯著滿天的小星星，卻幻想著追上太陽。你覺得，他快得了嗎？

而對手已經(jīng)組了團，而團里不乏用劍的大師，做小產(chǎn)品的大師，做集成的大師，懂行業(yè)的大師，沒有枷鎖，瞄準一個一個細分目標客戶群歡脫的飛奔而去。

研發(fā)

我在公司呆得最久的，是研發(fā)。其實MKT，在市場/服務眼中，也仍然是研發(fā)，PDT經(jīng)理/BMT主任，在一線眼里，也還是研發(fā)。所以一線會說研發(fā)太牛氣了。

而真正的研發(fā)團隊，完全沒有發(fā)言權(quán)，像螺絲釘一樣勤勤懇懇悶不吭聲，是沉默的大多數(shù)。不吭聲，不代表沒意見。忍，狠，滾，這個三部曲適合于每個人。狠和滾，不只在行為，也在心態(tài)。就像我自己開頭說的“混吃等死”，其實就是心態(tài)上的滾。

如果心態(tài)上已經(jīng)“滾”了，就“滾”徹底，眼睛向外，找找機會。時下的機會還是相當多的，下面我專門開一章來寫，這一章還是來寫寫讓我又愛又恨的研發(fā)。

前幾天和一個跳出研發(fā)的兄弟聊，他說研發(fā)怎么一點追求都沒有，我很無語，因為他在研發(fā)時也一樣的沒追求。

最近心聲上有一篇“肩扛手提交付公有云”的帖子，其實反映了這個故事的一個切面，暴露的問題很多，試舉一二。

廟堂之上作決策的人有一些假設(shè)(就讓我度一下君子之腹…)：只要飽和攻擊就一定能成功。

研發(fā)都是磚頭（美其名曰全棧工程師），擺在那里都行，所以工作量/效率=人月，只要湊夠人頭就可以。

研發(fā)會搞定一個功能在所有場景下的所有事，而且是免費的。

研發(fā)效率要不斷提升，所以是可以壓一壓的。

已經(jīng)做出來的東西，是沒有后續(xù)成本的，丟了可惜。

業(yè)務需求優(yōu)先，DFX不重要，如果DFX出了問題，研發(fā)負責搞定，沒有成本。

?

其實，很多時候，為了快，大家欠了太多的技術(shù)債務，卻沒有時間去還。逐漸的，技術(shù)欠債成為常態(tài)，已經(jīng)不再會有人去想還了。窗戶上沒有洞時，很少有人扔石頭。而只要有了第一個，就會有第二個，很快整個架構(gòu)就千瘡百孔，到達熱力學上的熵無限大，形成焦油坑。

如果你恨你自己寫的代碼，說明你還有有救。如果你對你寫的代碼已經(jīng)沒有感覺，沒有感情，說明你已經(jīng)在狠，在滾了，千萬小心。在技術(shù)上沒有了理想，和咸魚有什么區(qū)別？

?

研發(fā)內(nèi)部，最珍貴的，是系統(tǒng)工程師。這個位置需要懂技術(shù)，有全局的視野，熟悉每個模塊，熟悉業(yè)務流程，熟悉團隊的每一個人，有極強的責任心和溝通協(xié)調(diào)能力。而系統(tǒng)工程師不是天上掉下來的，都是踩著特性的尸體成熟起來的，養(yǎng)成成本極高。偏偏這個位置又特別關(guān)鍵，特別重要，勞心勞力。而我看到的，是大家都不愿意做系統(tǒng)工程師，這里面有一些問題：

系統(tǒng)太復雜，溝通矩陣太長太大，系統(tǒng)工程師力不從心；

考評/任職/獎金沒有特別考慮傾斜，系統(tǒng)工程師吃力不討好；

一次失敗，不再任用。導致華為公司為培養(yǎng)系統(tǒng)工程師交的學費，打了水漂；

?

我所看到的，系統(tǒng)工程師的流失率極高，從Galax8800開始，到FusionCompute，F(xiàn)usionManager，到現(xiàn)在的OpenStack。而這些人的流失，如果是走到了更前端的SA，PM也還好，全局視角不會被浪費掉，但如果去了其它產(chǎn)品線，就太可惜了。

外面的機會

外面的機會。話說天下大勢，出口逐漸疲軟，人口紅利消失，互聯(lián)網(wǎng)+手機+微信已經(jīng)完成了“人連網(wǎng)”的基礎(chǔ)設(shè)施布局，國家在謀求產(chǎn)業(yè)升級，政府在謀求智慧城市。技術(shù)上，AI，IoT，區(qū)塊鏈已經(jīng)在跨越裂谷。智能制造，工業(yè)4.0已經(jīng)引燃。民眾從溫飽到更有品質(zhì)的生活追求，可以創(chuàng)造出大量的機遇。

如果要創(chuàng)業(yè)，要么做大平臺（但你會遇到BAT），要么做精準細分市場下的高品質(zhì)產(chǎn)品及服務，總之，機會很多。

年過40，再給人打工，也是一種選擇。見過有一篇講40歲的職場人的帖子，很不錯，但總有一種英雄遲暮的悲涼在里面。

FusionManager

終于到了我心中最割舍不下的部份，F(xiàn)usionManager。

來云計算，我做了兩件讓我自豪不已的事，Galax8800和FusionManager，讓我覺得我對得起華為付給我的報酬。往事不堪夸，我不想說這兩個產(chǎn)品有多好，而且我也確實知道他們的千瘡百孔，以及錦袍下面有多少跳蚤。

簡單介紹下這兩個產(chǎn)品。Galax8800是我們在云計算上的第一個產(chǎn)品，基于Eucalyptus架構(gòu)，但基本重寫了。Galax8800當時定位是大規(guī)模公有云架構(gòu)，做了三個版本，及時剎車轉(zhuǎn)向了虛擬化。這一次剎車轉(zhuǎn)向，是非常正確的。

FusionManager，是轉(zhuǎn)向FusionSphere架構(gòu)后，在FusionCompute之上開發(fā)的云服務層。支持云服務化，支持自助服務，多數(shù)據(jù)中心，支持VPC/VFW/VPN/NAT/VLB等等大量的虛擬網(wǎng)絡(luò)服務，支持硬件管理，異構(gòu)虛擬化。對應到現(xiàn)在的產(chǎn)品組合上，基本等于OpenStack + ManageOne SC + AC 2.0 + eSight IT+OpenStack OM。而構(gòu)建這個產(chǎn)品只用了三個版本(2.3/3.0/3.1)，團隊峰值100人左右。截止2014年底，運營私有云+公有云80+項目，不算虛擬化項目里面捎著賣的。這種產(chǎn)品形態(tài)，在2013年基本是天下獨一份的，甚至現(xiàn)在看來也絲毫不落后。

?

只是這樣一個產(chǎn)品，生不逢時，命比紙薄。此產(chǎn)品一度被劃到IT軟件DU，然后又回到云計算。回到云計算又趕上了OpenStack當?shù)溃荒芙邮鼙粡U掉的命運。而且因為此產(chǎn)品不在數(shù)據(jù)中心，數(shù)據(jù)中心就規(guī)劃了ManageOne SC/OC兩個產(chǎn)品，來替代FusionManager，但是卻是基于FusionManager提供的云化能力在做。再后來虛擬化戰(zhàn)略收縮，F(xiàn)usionManager變成了FusionCompute套件中的一個附屬功能。

?

這個故事很長，說多了都是淚。但我的目的不是要說它，而是要總結(jié)經(jīng)驗教訓。

組織越復雜，架構(gòu)越復雜，成本越高。FusionManager只用了100來人，兩年時間就可以做得相當好，而我們基于OpenStack+SDN卻要更多的人，更長的時間來作。

產(chǎn)品的媽重要，婆婆也很重要。婆婆不看重的產(chǎn)品，會淪落到做妾都沒人要的地步。所以，有志于做產(chǎn)品的兄弟，一定要找個好婆婆啊。

虛擬化市場下強推云的概念就是作死。有一段時間產(chǎn)品的戰(zhàn)略是用云來打虛擬化，每個項目都必須賣FusionManager，結(jié)果收到罵聲一片。對于客戶就是想要個虛擬化的情況下，組織/VDC/VPC太過復雜。而時至今日，我們的私有云和公有云仍然是這些概念（哈哈，企業(yè)云的網(wǎng)絡(luò)概念都是哥玩剩下的），客戶就可以接受了。大家總是想復制軟交換反打交換機那樣的成功經(jīng)驗，但沒有看到本質(zhì)的不同---軟交換還是交換機，客戶體驗是一樣的。而虛擬化和云，體驗完全不同，想用云反打虛擬化，很難。后面做的OpenStack納管虛擬化特性，也從側(cè)面印證了這個道理。

架構(gòu)不是產(chǎn)品的競爭力。FusionManager 5.0作的死很能說明問題。FusionManager 5.0完全拋棄3.1架構(gòu)進行重構(gòu)，花了大量的力氣，做了個很厚的平臺，倒是統(tǒng)一了FusionManager，ManageOne SC，OpenStackOM的代碼。然并卵，到5.1還不是因為各種原因拆開了。想想那個年代我和我的團隊被架空，一幫人有多大膽地有多大產(chǎn)的紅小兵，精英團隊，胸脯拍的山響，最后又是自己挖坑自己埋。而FM 5.0，功能比3.1不僅沒有增加還有減少，業(yè)務模型還變化了，徒然給自己惹來煩惱。

?

中間的故事太長，有基于FusionManager作產(chǎn)品卻個個版本換架構(gòu)的奇葩上游，有為了自己KPI強奸產(chǎn)品硬落架構(gòu)整改的大架構(gòu)師和PDU主管，有為了好銷售要把FusionManager包裝成另一個產(chǎn)品的PLM團隊，有游說產(chǎn)品使用后又棄坑的平臺團隊，有SC和FM的各種恩怨癡纏，有苦逼的UHM團隊的躑躅獨行，有借著FusionManager賣高端防火墻和高端交換機的一線兄弟，有高大上到處演示卻沒什么項目用過的圖形化編排功能，有為了FusionManager嘔心瀝血卻不得不另謀高就的網(wǎng)絡(luò)架構(gòu)師，有二起來能到四卻人見人愛的版本SE“二爺”，有專職的不進迭代卻累成狗的代碼架構(gòu)師，有在相聲中跟我一起變兔子的鐵桿兄弟們。話說，我是不是該寫一部產(chǎn)品開發(fā)那些事的情景劇……但是，產(chǎn)品開發(fā)狗們哪有時間看啊。

?

FusionManager，我為之嘔心瀝血，視如己出，卻成為我心中永遠無法割舍的痛，同時她也成為了我的牢籠。離開她之后，我就一直在混吃等死，直到現(xiàn)在。癡情無過，但蹉跎有錯。我是自己的面壁者，也只有自己能破這個壁。

多次被拿下的教訓

關(guān)于我多次被“拿下”，有些難堪，有些痛苦，但都必須面對，以警后來人。

視野要開闊一點，千萬不要站在研發(fā)團隊的角度去想事情。比如2010年我們和新加坡Starhub合作公有云，需要緊急開發(fā)定制一些自服務界面。當時我以團隊超負荷為由極力抵制，最后這個系統(tǒng)由技術(shù)開發(fā)團隊作了。雖然最終Starhub沒有成氣候，但是當時也是云計算拓展項目的一個嘗試。我從Galax8800被拿下，就是因為這個原因。

千萬不要越級搞事，除非你認為再無辦法。這是我的真實故事。上面講FusionManager最后有一句，“為了好銷售要把FusionManager包裝成另一個產(chǎn)品的PLM團隊”，這個事如果落實，F(xiàn)usionManager就會多出一個便宜婆婆，而且界面，資料都得多出一套，純粹屬于不增值活動。這件事因為我給總裁發(fā)的一封郵件而停了下來。但是反過來講，我沒有求助我的直接主管，資源線主管，而是直接越級上報，這種行為在華為公司是行不通的。因為華為公司是一個等級森嚴的“金字塔”結(jié)構(gòu)，至少在他被炸掉前還是，你的主管不會喜歡一個這樣搞事的下屬——很簡單，你挑的事越有價值，就越表示你的直接主管沒看到，不作為。大家不必罵這種想法，只要吸取教訓就好。我從FusionManager被拿下，而且一直被冷凍，被邊緣化，跟這個有非常大的關(guān)系。

?

然而，塞翁失馬，焉知非福。從Galax8800被拿下后，云計算經(jīng)歷了長時間的“反攻倒算”，我的繼任抗不住，離職創(chuàng)業(yè)去了，現(xiàn)在也做得不錯。而我僥幸躲過這一劫，沒有被波及。

這半年先是在中外運的交付項目里面混跡了一個月，結(jié)識了一幫好兄弟，也懂得了IT實施項目的過程。然后在技術(shù)開發(fā)認真學習了大數(shù)據(jù)的知識，理解了開源軟件的玩法，更重要的，知道抬頭看世界了。

后來趕上老板要求力出一孔，技術(shù)開發(fā)的大數(shù)據(jù)團隊解散了，我于是拉著這一票隊伍又回到開發(fā)，正是這一票隊伍成就了FusionManager。

FusionManager生不逢時，最終混到連妾也做不了，但FusionManager鍛煉的隊務，又成就了公有云。無論如何，我都為這個隊伍感到驕傲。

?

而我自己，終究是因為心有魔債，走不出來，怨不得別人。

回憶

那應該是在2010年的夏天的一個周末，連著三天的假期，我請設(shè)計團隊的同事到我家做客，我自己包餃子請大家吃。我整整忙活了兩天，買菜，剁餡，收拾屋子。第三天大家如期而至，很高興的吃餃子，聊天，打牌。

2012年我被拿下時，我給大家發(fā)最后的郵件中，還說到如果有機會，我還想請大家吃一次餃子。

2013年春天，大數(shù)據(jù)技術(shù)開發(fā)團隊面臨被解散的命運。我?guī)е业膱F隊，在唐延路的草坪上打了一下午的三國殺。在那以后，我的團隊被拆，核心骨干跟著我到了FusionManager。我們自己寫的流處理系統(tǒng)，還沒有完成alpha版本就胎死腹中，我還在3ms上立帖“重整河山待后生”。

2014年，F(xiàn)usionManager 2.3，在上海移動納管vmware成功，整個團隊欣喜若狂。

2015年，F(xiàn)usionManager團隊也走到了窮途末路，我?guī)еO(shè)計團隊，花光了所有的部門經(jīng)費，在一個溫泉酒店呆了一晚上，鐵鍋羊肉，打牌泡澡，不訴離觴。

在每一個命運的轉(zhuǎn)折點，即使你早有準備，即使你先知先覺，卻依然是無能為力。且留下這些沉甸甸的回憶，或許哪一天午夜夢回，大家還在一起，多好。只是不知道，我會不會哭醒。

加油

該說的，不該說的，都說了。華為與我，珍貴如生命，畢竟為之奮斗了十六年（當然其中有混吃等死的日子）。無論如何，我總是希望華為能夠基業(yè)常青，云計算能夠托起華為的未來。

雖然我今天絕望了，但希望總是有的，沉舟側(cè)畔千帆過，還有那么多為之奮斗的兄弟姐妹。只是，恕我先走一步了。

但無論如何，我以曾經(jīng)是華為人而榮，為華為而榮，今生今世。

下定決心前是痛苦煎熬的，等到?jīng)Q心已定，心底卻感到輕松了許多。只是離開了公司的大平臺，往后的日子，需要自己打拼了。功罪寵辱身后事，淡看云起云舒，老的一頁翻過，新的一頁開始。

38歲起步，不算太晚。

軟件開發(fā)技術(shù)群

興趣范圍包括：Java，C/C++，Python，PHP，Ruby，shell等各種語言開發(fā)經(jīng)驗交流，各種框架使用，外包項目機會，學習、培訓、跳槽等交流

QQ群：26931708

Hadoop源代碼研究群

興趣范圍包括：Hadoop源代碼解讀，改進，優(yōu)化，分布式系統(tǒng)場景定制，與Hadoop有關(guān)的各種開源項目，總之就是玩轉(zhuǎn)Hadoop

QQ群：288410967?