SteveY对Amazon和Google平台的吐槽

SteveY对Amazon和Google平台的吐槽

Steve Yegge, Amazon的前员工,现任Google员工,其本来想在Google+上和Google的员工讨论一些关于平台的东西,结果不小心把圈子设成了Public,结果这篇文章就公开给了全世界,引起了剧烈的反应。发布后很快他就马上把这篇文章删了,不过,互联网上早备份了下来——SteveY’s Google Platforms Rant。后来,Steve在其Google+上作了一些解释,大体是说他喝多了,而且又是在凌晨,所以大脑不清,文章中的观点很主观,极端且不完整,还有Google的PR对他很好,等等,等等 。

几个星期前看到时就一直都想翻译一下这篇文章,不过因为最近事情太多,文章又很长,所以现在才翻译完成,翻译的不好,还请大家指正。

导读

在你阅读正文以前,我想说明几点,希望你注意一下:

  • Steve这个人非常喜欢写长篇大论的东西。而且比较喜欢辛辣调侃和恶搞的文风,这点大家要注意!
  • 文中先“骂”Amazon公司,再通过“骂”Amazon的创始人贝索斯Bezos并烘托出他的的悟性和雄心,最后教育了一下Google。
  • 我把文章分成了三个部分,这样方便大家阅读和讨论。第一部分只是个人情绪化的抱怨,第二部分是说Amazon的成长,第三部分是教育Google,我觉得第二部和第三部分是重点。
  • 对于我们来说,我们应该获取Steve那些关于平台(Platform)相关的那些有价值的观点。尤其是他说的Amazon如何进化成一个平台性的公司,以及阐述Google应该怎么做的那些观点。
  • 关于对Amazon的那些指责,我想说,6年,对于一个世界级的互联网公司,已经很不一样了。

正文

第一部分

我曾在Amazon工作了六年半,现在,我在Google的日子也差没不多这么长了。对于这两家公司,有一件事总是萦绕着我——这种感觉一天比一天强烈──那就是,Amazon每件事都做错了,而Google每件事都做对了。当然啦,这是很笼统的话,但却是惊人的准确,相当的疯狂吧。大概有一百甚至两百种不同的地方可以让我们去比较这两个公司,而Google可能在每一项都能胜出,如果我记的没错,除了其中3项以外。因为,我曾用电子表格把这些项都列出来了,只是法务部门不会让我给任何人看,即使人事招募部门很喜欢这个报表。

这里,让我先给你个例子让你稍微体会一下:Amazon的人事雇用流程有根本上的缺陷,因为各个团队各招各的人,以至于,各团队之间的招聘标准相当的不一致性,即使他们通过各种努力来统一标准,但是实际操作上却是一团糟;他们没有真正的SRE(陈皓注:Site Reliability Engineer ),工程师们什么事都要做(陈皓注:所谓SDE – Someone Do Everything)、几乎没时间编码。当然,不同的部门有不同的情形,不过,这取决于你的运气。他们不搞慈善,也不帮扶贫困人群,也不搞社区贡献,或是其它相似的活动。在那里,他们从来不谈这些,或许只有在说笑话的时候才会提到。他们的办公环境是个灰尘及污迹四处的像农场一样的隔间,他们在公共区域连一分钱装修的都不会花,而且,他们的薪水和福利相当差,只是近来与Google和Facebook竞争人才,这个差距才变得非常地小。不过,他们没有我们有的津贴或额外奖金——他们只是给你录用信上的那个数字,就这么多。他们的程序代码完全就是灾难,无论什么都没有任何的工程标准,除了各别团队有一些。

公平起见,他们的确有套非常非常不错的版本控制管理系统,而这是我们(Google)需要尽力赶上他们的地方,他们还有一个漂亮的发布/订阅系统,我们也没有相对应的东西。不过,就大体而言,他们有的不过是一堆蹩脚的工具,用关系数据库来读取或写入状态机里的信息中罢了。我们不应该这么搞就算这样做是可以。

这就是我所所说的那3件事中的两件事Amazon比Google强的,那就是的他们的发布/订阅系统以及版本控制和管理系统。

我猜你也许会为他们争辩到——他们要更快更早地推出服务并通过狂热地迭代来不断地改进和完善。他们把服务发布的优先级看得比任何事都重,包括工程纪律或是其它一堆可能会让其花时间的事务。所以,即使这么做让他们在市场上有了某种程度的竞争优势,但也造成其他足够多的问题,总之,这样的做法算不上是个漂亮的扣篮。

但是,他们有一件事做的非常非常好,其好到可以把其他政治,理念,技术上的消耗和混乱完全弥补回来。

第二部分

Jeff Bezos是个臭名昭彰的微管理经理人,他的微管理都管理到了Amazon零售网站上的每一个显示像素。他雇佣了Larry Tesler——Apple的首席科学家,他可能是全世界最有名也最受尊敬的人机交互接口专家,然而,Bezos忽略了Larry三年来提出的每一个建议,直到Larry最后——明智地——终于离开了公司。Larry本应做一些大型可用性(Usability)研究,并可以系统地了解那个根本就没有人能够搞懂、使用那该死的网站,可是,Bezos对于那些像素不放手,这些页面上的那几百万个显示像素就像是他的孩子一样。所以,他的这些孩子还留着,而Larry没有。

当然,微管理不是第3项Amazon做的比我们好的事。我的意思是,没错,他们微控管理做地非常地好,但我不会把这项列在他们的强项清单上。我这样说只不过是为了我下文做铺垫,帮助你了解我后面要说的事儿。我们现在要说的这个人,是在多个严肃的公开场合说要来Amazon工作就应该付他钱才对的人。当有人跟他意见不同时,他会递出写有他名字的黄色即时贴以提醒那个人“谁是公司的老大”。这家伙是……,Steve Jobs,我想,除了没有品味和设计能力,他们很相似。千万别误解我,Bezos是个绝顶聪明的人,只不过他把那些正常的管控搞得像嗑了药的嬉皮士一样罢了。

所以,有一天,Jeff Bezos下了一份命令。当然,他总是这么干,这些命令对人们的影响来说就像用橡皮槌敲击蚂蚁一样。这个命令大概是2002年,我想误差应该是在正负1年内 —— 这个命令发布的范围非常地广,设想很大,让人眼珠子鼓出来的那种,这种惊讶程度和其他的命令相比,就好像你突然收到公司给你的奖金一样让人惊讶。

这份大命令大概有如下几个要点:(陈皓注:这里是本篇文章的要点!如果这真是Bezos发出来的,那么太赞了,Bezos完全就是一个系统架构大师啊,那可是2002年左右啊。作者调侃Bezos完全是正话反说啊)

  • 1) 所有团队的程序模块都要以通过Service Interface 方式将其数据与功能开放出来。(陈皓注:Service Interface也就是Web Service)
  • 2) 团队间的程序模块的信息通信,都要通过这些接口。
  • 3) 除此之外没有其它的通信方式。其他形式一概不允许:不能使用直接链结程序、不能直接读取其他团队的数据库、不能使用共享内存模式、不能使用别人模块的后门、等等,等等,唯一允许的通信方式只能是能过调用 Service Interface。
  • 4) 任何技术都可以使用。比如:HTTP、Corba、Pubsub、自定义的网络协议、等等,都可以,Bezos不管这些。(陈皓注:Bezos不是微控经理吗?呵呵。)
  • 5) 所有的Service Interface,毫无例外,都必须从骨子里到表面上设计成能对外界开放的。也就是说,团队必须做好规划与设计,以便未来把接口开放给全世界的程序员,没有任何例外。
  • 6) 不这样的做的人会被炒鱿鱼。
  • 7) 谢谢,祝你有个愉快的一天!

哈哈!你们这150个前Amazon的员工,当然能马上看出第7点是我开玩笑加上的,因为Bezos绝不会关心你的每一天。

不过第6点是很真实的,于是,所以人们都去工作。Bezos并派出了几位首席牛头犬来监督并确保进度,领头的是和熊一样大的牛头犬:Rick Dalzell,Rick是以前是陆军突击队队员,西点军校毕业生,拳击手,和沃尔玛的首席虐刑官 / CIO,而且他也是个高大、和蔼、令人敬畏的人,还是经常使用”hardened interface”词的人,Rick 本来的走路和说话都比较hardened interface,所以不用多说,每个人都得干 出有重大的进展,这样Rick才能看得见。

在接下来的几年,Amazon内部转变成面向服务架构SOA(Service-Oriented Architecture),在这华丽转身的过程中,他们学到了相当巨多巨多的东西。我在的那个时候,世界上就有很多很多的关于SOA的学术文档,但在Amazon的那种超大规模的面前,世间的这些文档就好像告诉印第安纳琼斯(陈皓注:电影夺宝奇兵男主角)过马路前要先看看两边有没有来车一样没用,Amazon的研发工程师们在这个过程中发现了很多很多的问题,并从中学到了很多。下面只是他们这些问题中的沧海一粟:

  • pager escalation(陈皓注:生产线上问题的寻呼系统)变得比较困难,因为ticket可能会转过来转过去(陈皓注:ticket就是处理问题的工单),只到转了20次,都找到真正能解决问题的团队和人。如果每一个呼叫都花去团队的15分钟的响应时间,那在找到真正的团队之前,几小时就已经过去了,除非,你能建造出很多很多的脚手架,测量标准和报告。
  • 每一个和你的相关团队突然间都可能成为一个潜在性的DOS攻击者。没人可以让事情有进展,直到在每一个Service里放上配额(quota)与节流阀(throttling)的机制。
  • 监控与QA是被统一了。如果你不进行一个大规模的SOA,你就不会这么去想。但是,等到你的Service说,“是的,我还好!”,但实际情况可能是,服务器里唯一能正常运作的功能就是一个快乐的机器声音在呼叫你:“我很好,收到,收到”。为了要确认整个服务能正常运作,你需要对Service的每一个部分都去Call一下。这个问题会以递归的形式地出现,直到你的监控系统能够全面性地系统地检查所有的Services和数据,此时,监控系统就跟自动化测试QA没什么两样了,所以两者完美的统一了。
  • 如果你有上百个Services,而且你的程序只能通过由这些Services来跟其他团队的程序做沟通,那么,没有一套Service发现机制的话,你就不能找到这些Service。所以,你得先有一套Service的注册机制,这也是一个Service。所以,Amazon有一套全体适用的Service注册机制,以例可以通过反射机制来找到Service,并知道Service的API,以及是否可用,在哪儿。
  • 调试其他人的代码以调查问题变得非常的难,几乎都不可能,除非有一套全面性的标准的方式,他可以在可被调试的沙盒里运行所有的Services。
上面这些只是极少数几个例子,在Amazon在进化的过程中,Amazon遇到这样的问题可能一打甚至数百个,Amazon都一一学习和总结了。对于把Service外部化甚至还有很多几乎没有人会想到的非常生僻的东西,当然,也不会有你想像的那么多,Amazon都学到了。把业务组织成Service让团队学会了不能相信对方,就如同他们不能信任公司以外的程序员一样。

当我在2005年中期离开Amazon加入Google时,这个努力进化的过程还在进行时中,但那时已经相当的先进了。从Bezos颁布法令的时间到我离开的时候,Amazon已经把文化转变成了“一切以Service第一”为系统架构的公司,今天,这已经成为他们进行所有设计时的基础,包括那些绝不会被外界所知的仅在内部使用的功能。

那时,如果没有被解雇的的恐惧他们一定不会去做。我是说,他们今天仍然怕被解雇,因为这基本上是那儿每天的生活,为那恐怖的海盗头子Bezos工作。不过,他们这么做�