极简设计

李彦宏的“罪己诏”

领导总以为自己高高在上,神圣不可侵犯。事情做好了,功劳都是自己的,心情好了赏仨瓜俩枣给手底下辛苦干活的员工;事情搞砸了,就开始埋怨员工不好好干活,没有“奉献自己100%的热血和青春”

底层技术人员确实想做一些技术上的事情,但被中层经理压制,有心无力。技术上不去,一切都是空谈,所谓的业绩报表,除了欺上瞒下,就是自欺自娱。房地产企业的土地房子可以升值,但互联网企业的代码机器却会腐朽

封闭的技术开发

中国互联网企业的毛病:没有开源共享精神,对开源社区索取大于回馈 不想做那些"琐碎"的基础工作,将开源的项目拿过来修修补补贴点牛皮藓后就开始到处吹牛逼说什么世界领先国内一流 百度宣称自己的Hadoop集群在规模、负载和利用率上是世界前三的 第一,Hadoop不是百度开发的,百度只是打了点补丁做了些定制而已 第二,百度的Hadoop集群数量只有10+个,远远比不上Google 100+个GFS集群这样的规模,其整体的自动化运维水平也差了一个世代第三,百度所做的所有“改进”很少回馈过开源社区

百度用Hadoop前,也曾想过开发自己的GFS+MapReduce+BigTable,叫Pyramid,就是基于Google那三篇著名论文,领衔人是王选的高徒阳振坤博士 Pyramid大约开发了2-3年,最终以失败告终,据说最后与Hadoop PK的时候完败下来 GFS论文是03年,MapReduce04年,BigTable应该是07年,Google应该也是开发了4-6年左右的时间 Pyramid的失败直接导致了Hadoop在百度的崛起,不到两年,Hadoop的机器数量从无到有,很快就突破了万台的规模,并且机房也从北京开始像长三角扩展,百度也终于迈出了跨数据中心的步子,尽管这个步伐似乎比Google慢了5-8年

百度虽然自己用Hadoop用得很High,负载什么的,报表都弄得不错,集群规模也上了国内少有的3000+台,但是却很少对Hadoop社区进行开源回馈。内部Hadoop是基于Hadoop 0.19-0.20改进的。好处就是快,一方面依赖社区拿到已有的代码基,整合测试就可上线,同时也不用管什么伦理道德奉献回馈的鸟事,但其缺点就是内部的Hadoop和官方的Hadoop会逐渐越走越远,上游的Patch和改进越到后来会越难引进合并。这样做的结果就是和社区分离,用自己一人之力对抗全球智慧,最终只能自讨苦吃

内部年会上工程师跳起来问,“公司可不可以做一些开源的产品呢?很多东西本来就是从外边拿过来的。” 其中一位女高管脸色稍变,过了一会又开始讲什么“做开源需要时间精力;好的东西才好意思开源出去,否则会丢脸”什么什么 IT公司有没有勇气拥抱开源,是对自己技术没有足够自信的一个表现。百度此方面乏陈可善,不但没有代码,连论文也很少。而淘宝在章文嵩的带领下,其开源已经做的如火如荼,算是国内IT企业中开源做的最好的一个

世界上最优秀的工程师? 百度的内部邮件中不止一次的提到“世界上最优秀的工程师”这个字眼,可惜作为这封邮件的收件人,连我们自己都不相信自己是世界上最优秀的工程师。09-11年高速扩张的两年,百度的招人标准降低了很多。这也是无可奈何的事情,毕竟中国的人才储备有限,有时候即便你想花钱,也不一定能招到足够的人。

你当然无法否认,百度内部有很多牛人,可是大凡拿得上台面的公司,那个手里没有一些牛人呢?重要的是保证整体人才的平均质量,而不是树立几个典型,然后就自吹自擂说自己的工程师是世界上最优秀的。

KPI为王

我在Hadoop运维组做到第4个月的时候,一手创立Hadoop运维的经理走了,空降了一位新来的经理。当然,这位经理是不懂Hadoop的,加上他又实在繁忙,所能做的就是从报表入手。比如说每周几千台机器几百条小报警有没有都处理掉,预算做的怎么样,总之都是报表性的东西。至于技术上的,监控怎么做,如何才能更好的自动化,怎样统一归约化的整合集群的各个系统,从来就不是他关心的重点。我辛苦两周做出来一个小的监控系统,可以自动的检测各个集群的一些指标参数,并且支持自定义插件,自动化的生成监测报告发送到邮箱中,他给的评价是“这算啥,T2的工程师都能做”。我当时特别火也特别委屈,心里想“T2的工程师都能做,可是为什么一直没有人做呢?站着说话不腰疼”。

再比如我们每周都要写Hadoop集群运维周报,内容无非是去几个监控系统上鼠标copy/paste一些数据到一个模板里。其实这样的东西完全可以稍微花些人力写点程序抓点网页完成,可是一直没有人做这个事情,大家就这样一周一周的写下来。反正经理要的就是这个,谁管你怎么得来的呢。

当一家技术公司由技术驱动变成KPI驱动的时候,也就意味着这家公司发展到了一个瓶颈期。不断有前同事跟我聊,说自己想做一些事情,但是经理不让。为什么呢?比如说一个4、5年的产品代码,由于人员的交替加上技术的封闭,必然是有很多丑陋的代码的,这个时候后来接手的人如果是个有责任心又有代码洁癖的人的话,自然就想对代码做些重构和改进。这就带来了一个问题:万一由于这种额外的改动造成产品出现事故,怪谁?经理是不想承担这样的责任的,因为百度的经理不写代码,多一事不如少一事。这样一个技术人员的积极进取心就这样被压制了。还有的经理说,”做,可以做,如果一个星期之内可以完成,就去做”。可是有多少伟大的产品是一个星期内完成的呢?GFS不是,MapReduce也不是。可是经理才不会管这些,他关心的是他的KPI,是报表。一个东西,如果短期内无法出成果,就不要做。

所以像Puppet这样的工具是不可能出自百度之手的。即便是工程师在平时的工作之中有一些思考,但也很少能有时间形成系统化的,并且能够走出百度被业界认可的东西的。

部门繁多,流程繁杂,真的想做一件事情,如果没有自上而下的推动,光预算、排期、开会就要耗掉几周甚至几个月的时间 产品风格差异极大。无论是网页产品还是客户端产品,UI方面从来都没有给人一种非常明朗统一的感觉,能够让人一看就知道这是百度的东西。这方面,苹果做的最好,Google次之,百度毫无章法

百度并不是一个Geek公司。Facebook是,Google是,但百度不是。大多数工程师还在用着10年前的XP系统,用着盗版的Office和SecureCRT软件登录SSH写着各种文档和代码。

工程师没有追求美感的习惯,包括但不限于代码风格、文档排版、产品设计等 Google代码提交之前都会经过一系列的检查 代码写了一年多,才想到要重新整理,规整风格。内部的wiki、代码审查,项目管理系统从来也是破破烂烂

3.9 有啊

百度历史上有很多失败的产品,但是从来没有一个产品,如有啊这般惨烈悲壮8。这样的人,这样的团队,这样的条件下这样的时间内做出了这样的牺牲和这样的业绩,但最终依然无法摆脱失败的命运。有的时候,我真的怀疑,当你怀着“我坚信让我一往无前的唯一力量就是我热爱我所做的一切”这样的信念去努力去拼搏的时候,你的老板能够看到并且认可你的付出吗?有啊的惨败,百度的高管可曾做过认真的反省?这究竟是公司战略上的问题还是员工的问题?员工犯错可以扣钱扣绩效,但如果是公司犯错呢?公司做过这样的检讨吗?

国内IT企业对待开源大多如此,有些企业已经开始觉醒,比如新浪之于OpenStack

原文 http://cnlox.is-programmer.com/posts/37276.html

with :