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

慣例

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

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

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

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

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

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

?

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

拔劍四顧心茫然

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

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

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

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

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

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

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

關鍵詞：領軍者的魄力。魄力不足。魄力，是做減法的能力。資源有限時，唯有做減法才能形成局部優勢，力出一孔。而從戰略決策，到戰術動作，沒有人做減法。做減法需要有橫眉冷對千夫指的心理素質，也要有泰山壓頂腰不彎的傲骨，而我們缺這樣的領軍人物。

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

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

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

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

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

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

?

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

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

研發

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

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

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

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

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

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

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

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

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

已經做出來的東西，是沒有后續成本的，丟了可惜。

業務需求優先，DFX不重要，如果DFX出了問題，研發負責搞定，沒有成本。

?

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

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

?

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

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

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

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

?

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

外面的機會

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

如果要創業，要么做大平臺（但你會遇到BAT），要么做精準細分市場下的高品質產品及服務，總之，機會很多。

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

FusionManager

終于到了我心中最割舍不下的部份，FusionManager。

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

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

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

?

只是這樣一個產品，生不逢時，命比紙薄。此產品一度被劃到IT軟件DU，然后又回到云計算。回到云計算又趕上了OpenStack當道，只能接受被廢掉的命運。而且因為此產品不在數據中心，數據中心就規劃了ManageOne SC/OC兩個產品，來替代FusionManager，但是卻是基于FusionManager提供的云化能力在做。再后來虛擬化戰略收縮，FusionManager變成了FusionCompute套件中的一個附屬功能。

?

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

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

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

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

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

?

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

?

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

多次被拿下的教訓

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

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

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

?

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

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

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

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

?

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

回憶

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

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

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

2014年，FusionManager 2.3，在上海移動納管vmware成功，整個團隊欣喜若狂。

2015年，FusionManager團隊也走到了窮途末路，我帶著設計團隊，花光了所有的部門經費，在一個溫泉酒店呆了一晚上，鐵鍋羊肉，打牌泡澡，不訴離觴。

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

加油

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

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

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

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

38歲起步，不算太晚。

軟件開發技術群

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

QQ群：26931708

Hadoop源代碼研究群

興趣范圍包括：Hadoop源代碼解讀，改進，優化，分布式系統場景定制，與Hadoop有關的各種開源項目，總之就是玩轉Hadoop

QQ群：288410967?