华为人在云计算转型中的苦逼之旅

摘要：原著中桃谷六仙是给令狐冲硬灌真气，作者笔误但不妨碍意思。华为擅长铸剑，却不擅长用剑。而这些深入接触用户痛点的产品，我们都看不上，因为太小，不能在华为的销服体系下大规模批量复制，所以都不愿意做。所有资源向公有云倾斜，导致其他领域全部贫血。

惯例

元旦过了，分红混到了，该惯例了。

惯例就该潇潇洒洒的走，不需要哀哀惋惋仿佛全世界都欠你的，或飞鸟出笼仿佛逃出生天一般欢脱自在，这都不是我的范。

先说一下惯例的原因，向内看满眼茫然，向外看机会很多。年近不惑，还奋斗的动，又不愿在这里混吃等死。

忘了多久以前开始混吃了。直到一天我孩子给我讲了个故事，一只母鸡教育孩子要辛勤下蛋，说“一月不下蛋，高压锅里见”，让我给她解释是怎么回事，我才警醒，这样混吃下去，下场就是“高压锅里见”。

我不想混吃等死。但是拔剑四顾，心中茫然，空有力没处使。再加上公司的政策逐渐对不惑之年的老秆子们不友好，外面又有大把的机会和挑战。这时只能眼睛向外，换一种活法。毕竟再等几年，身体只能越来越走下坡路。既然该受的苦迟早要受，为什么不早受，早受还有体力扛。

所以大家不要在我的帖子下面抱怨被辞职，被不续签，被惯例，被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