分类归档: Arch

谈谈去 IOE 运动

这篇文章算是今年年末的一个技术总结。谈谈技术圈一度的热门话题「去 IOE」这件事。

何谓 IOE ?

所谓 IOE 是个简称。是指以 IBM 、Oracle、EMC 为代表的小型机、集中式数据库和高端存储的技术架构。其中 I 指 IBM p 系列小型机,操作系统是 AIX,IBM 专有的 Unix 系统;O 指 Oracle 数据库(RDBMS);E 指 EMC 中高端 SAN 存储,曾经一度是 IT 企业很喜欢采用的技术架构。IOE 这个说法怎么来的? 据我所知应是来自阿里技术团队内部的称谓,然后才在整个业界流传开来。如果你去问国外技术专家什么是 IOE,对方肯定一头雾水。当然,随着国内案例逐渐被介绍到国外,或许某一天这个术语能输出价值观也说不定。

在小型机领域,只有 IBM 这一家,独步武林;HP 当初把宝押在安腾上,算是早早退出这个市场;Sun 日薄西山,SPARC 机器…那就更不必说了。另外,需要说明的是,IBM 也生产存储产品,但 IBM 的存储产品早期其实挺山寨,竞争不过 EMC ,而且有些用户会忌讳把所有的东西困在一家公司身上,尾大不掉。 起码在国内,EMC 的占有率应该更高。中高端存储这个领域,还有一家 HDS,不过曾经一度在阿里也栽过跟头。数据库软件方面,在当初几乎没的选择,只有 Oracle 这一家,IBM 的 DB2 实在是不行,虽然号称市场占有率不错。国内用 Oracle 数据库支撑互联网应用的话,一般是采用 Data Guard 这个架构方案。

为何要「去 IOE」?

说起「去 IOE」,跟阿里的王坚博士有直接关系。我无从得知他当时为什么要做出这个决定。但根据我的推断,当时淘宝、支付宝等公司每家技术体系各有特色,技术团队也各是一套,只有去「去 IOE」,才有可能将淘宝、支付宝等公司的网站核心体系架构迁移到云上,体现阿里云的价值,某些管理者才有可能从集团公司层面对整个技术团队有更好的控制力。否则,阿里云师出无名。注意,这个说法只是我个人臆测,肯定不是事实,只是逻辑上是说得通的。实际上,阿里云当时自己的活儿做的很垃圾,也幸亏这个「去 IOE」运动进行并不那么快。当然这是后话了。

或许有人认为「去 IOE」会节约企业成本,实际上,当时的 Oracle 和 EMC 等软件成本已经足够低,硬件上,硬件上的每年的成本也是可控的,如果考虑迁移后总体成本,新硬件成本、开发人员成本、运维成本、时间成本等等,通通算下来,未必能节约多少。这个不是我拍脑袋给出来的,而是跟不少技术人事后复盘,结论基本一致。

客观的说,当时「去 IOE」有一种公司政治的倾向,或者成为一个一窝蜂的运动,这很令人讨厌,或者说这事情出发点未必如何好,但令人意外的是,最后在阿里诸多优秀技术人才的努力下,却取得了一个令人惊讶的很好的结果,那么,就别管出发点如何了。

为何「去 IOE」是必要的?

从另外一个角度考虑,尤其从运维 DBA 的角度去审视,「去 IOE」 实际上是必须要进行的,或者说去「O」是必须的,因为当时存在的问题是,Oracle 数据库对用户 (DBA) 来说已经不够灵活,常用的 Data Guard 模式无法适应互联网公司快速增长,最基本的一点,读写分离就做不到,只能向上扩展(Scale Up),拼硬件能力,几乎无法做到横向扩展。或许有人说,不是有 RAC 么? 但 Oracle RAC 是无法对付高并发下的 OLTP 应用的 – 一直到现在很多人都认识不到这一点,RAC 跑跑数据仓库什么的倒是不错。

注:有人会说 Orale RDBMS 11g 的 Data Guard 可以读写分离呀,这个所谓的读写分离可靠性其实是不够的,而且出现的时间也太晚了,此外,不够灵活。还会有人争论 Oracle RAC 怎么就不能应付 OLTP 呢? 别争论了,你非要说可以应付,没问题,但是在阿里体系的公司里,还真没人敢这么玩儿,为什么? 是做不到? 还是他们掉进坑过?

如果要动「O」,那么 「I」 和「E」就必须要动 – 相信不会有人在小型机上跑 MySQL 的,而且,只换掉「O」也没有意义,换汤不换药不会有成效。

随着中国电子商务的快速发展,整个阿里系其实已经在面对全世界增长最快最复杂的业务系统之一,这是机遇,也是挑战。旧有的技术架构已经不足以支撑更大的梦想。从这个意义上来说,去「IOE」是相当必要的。或许,这也是王坚博士以及一些人的初衷。

为何「去 IOE」成功了?

阿里几家子公司这么复杂的技术体系,「去 IOE」这事情堪比高速公路上给飞驰的汽车换轮胎,最后成功是相当不容易的。

成功的因素有哪些呢?

1.功不可没的当然是一群出色的技术人才,很了不起。我想这是无需多说的,面对这么复杂的业务环境,这个任务如果没有一批优秀的工程师是绝对做不到的,没有阿里 B2B 技术团队、淘宝团队、支付宝技术团队的先后投入以及合作实践也是绝对做不到的。要强调一下的是,阿里在在分布式事务上的处理能力和解决方案,这应该是独门绝技。在业界各种会议上也经常能看到这一群牛人出来分享,同行应该能感受到。

2.开源软件的快速成熟。举个例子,这两年 MySQL 体系的软件进步相当惊人,各种经验证的解决方案如雨后春笋般涌现出来。这得益于不少知名互联网公司(比如 Facebook、淘宝)在使用 MySQL 的同时也将其技术改进回馈给技术社区,把技术方案分享给业界,业界在吸收这些技术的同时再次回馈给技术社区,形成正向的反馈,极大地提升了开源软件在商业领域的竞争力。

3.硬件革命。硬件的进步给技术体系的变迁做好了铺垫。最主要的关键词:「SSD」。如果没有「SSD」的技术成熟以及在商业应用上被普遍接受,「去 IOE」几乎是不可能做到的。要知道物理机械硬盘存储的性能数十年几乎没得到什么大的改进 – 当然每年提升一点是有的。但 SSD 相比机械硬盘来说,则是质的飞跃。我记忆深刻的是,每年做 I/O 容量规划的时候都会发愁,因为即使已经使用上了很高端的 EMC 存储设备,但实际上只要应用层 I/O 没有命中到存储内存,直接打到后面的磁盘上,几乎没什么抵抗能力。比如当时一个硬盘极限能撑 100 多个 I/O,100 块硬盘也不过是万把个 I/O 就不行了。 但这样的 I/O 「打击」对 SSD 来说,则不是什么大问题。SSD 给解决「IOE」体系最大的瓶颈 – I/O 能力提供了硬件先决条件。

4.摩尔定律。这一点最初我不想提及,但不提及,就会有别人说,所以还是补充一下。提到摩尔定律,重点要说的 X86 芯片的计算能力不断进步,而 IBM 的 Power 芯片虽然也在不断进步,但正式商用的节奏明显在控制。这就给 Intel 体系带来了机会和空间。

国内对「去 IOE」的反应

在出现阿里这个成功案例之后,技术圈很是震动,曾经一度讨论热烈,随后则是国内产业界对此出现了一些跟风的倾向,不少公司则打着「国产」软件的旗号出来蒙人,这是值得警惕的。去掉 Oracle 不意味着就要采用国产的垃圾数据库,因为 MySQL 以及衍生的各种分支数据库才是最佳选择。同样,不用 IBM 的小型机也不意味着国产服务器就迎来新机会,在用户那里,适合的解决方案才是最重要的。「去 IOE」不应该成为一个噱头。任何时候,「国产」都不应该是一个互联网企业选型所要优先考虑的因素。在全球化的今天,我们应该忘掉「国产」,才有可能早点做出来更牛的软件来。

更好笑的,还搞出来一个什么「去 SOA」的组织,我觉得这是不太正常的,实际需求为前提,不能本末倒置,难道是为了「去」而「去」么?

2014 以后会有更多公司「去 IOE」

从目前的种种趋势来看,在今后几年,国内一些互联网公司以及 IT 企业会逐渐的「去 IOE」化。相比几年前,现在的「去 IOE」的主要原因则是:旧的「三件套」已经的确不适合互联网应用了。开源数据库更为可靠成熟,SSD 可靠性也得到验证,技术人才甚至都不需要从头开始进行储备 – 类似「沃趣科技」这样的团队已经能够提供足够好的技术支持服务,新的技术体系毫无疑问会让企业更有竞争力,总体成本更低。

上文提到的「沃趣科技」是由一群前阿里的工程师组成的技术团队,汇集了一群从数据库到存储到网络架构的专家,如果要找「去 IOE」技术顾问,似乎他们是独一份(这里不是广告)。相比之下,IBM、Oracle、EMC 等公司近些年来,实际上对国内那些快速发展的互联网公司已经提供不了有力的技术支持了,IBM 拿苏宁电商练手更成为业内笑柄。或许这也是 IOE 们被抛弃的一个原因,也可能是一些创业团队的新机会。

一个时代过去了。

EOF

关于 IOPS 的数据补充:

机械硬盘现在最高号称能跑到 400 IOPS,但应该 200 左右(走 SAS 接口)也就是极限了; 单块 SSD(走 PCIe 接口)的最高记录是九百多万,用不了多久突破千万 IOPS 是没问题的,相当了不起, 即使百万量级也足够吓人了。(Refer)

此文位于 Arch on by .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Instagram 架构分析笔记

Updated: 2012 年4月10日凌晨消息,Instagram 被 Facebook 以10亿美金收购。团队规模:13 人。

Instagram 团队上个月才迎来第 7 名员工,是的,7个人的团队。作为 iPhone 上最火爆的图片类工具,instagram 用户数量已经超过 1400 万,图片数量超过 1.5 亿张。不得不说,这真他妈是个业界奇迹。

几天前,只有三个人的 Instagram 工程师团队发布了一篇文章:What Powers Instagram: Hundreds of Instances, Dozens of Technologies,披露了 Instagram 架构的一些信息,足够勾起大多数人的好奇心。读罢做点笔记,各种线索还是有一定参考价值的。能打开原文的建议直接读原文。

Instragram.png

Instagram 开发团队奉行的三个核心原则:

  • Keep it very simple (极简主义)
  • Don’t re-invent the wheel (不重复发明轮子)
  • Go with proven and solid technologies when you can(能用就用靠谱的技术)

OS/主机

操作系统的选择,在Amazon EC2上跑 Ubuntu Linux 11.04 (Natty Narwhal) ,这个版本经过验证在 EC2 上够稳定。因为只有三名工程师,只有三名工程师,所以自己部署机器到 IDC 是不靠谱的事情。幸好有亚马逊。

负载均衡

此前曾用过两台 Nginx 做 DNS 轮询承载前端请求,这样做会有副作用,现在已经迁移到Amazon的ELB(Elastic Load Balancer),起了三个 Nginx 实例,在 ELB 层停掉了 SSL , 以缓解 CPU 压力。DNS 服务使用 Amazon Route53 服务。

应用服务器

启用了 25 个 Django 实例,运行在 High-CPU Extra-Large 类型的服务器实例上,之所以用 High-CPU Extra-Large 实例是因为应用请求是 CPU 密集型而非 IO 密集型。

使用 Gunicorn 作为 WSGI 服务器。过去曾用过 Apache 下的 mod_wsgi 模块,不过发现 Gunicorn 更容易配置并且节省 CPU 资源。使用 Fabric 加速部署。

数据存储

用户信息、图片元数据、标签等大部分数据存储在 PostgreSQL 中。主要的 Shard 数据库集群有 12个节点。

实践中发现 Amazon 的网络磁盘系统单位时间内寻道能力不行,所以有必要将数据尽量放到内存中。创建了软 RAID 以提升 IO 能力,使用的 Mdadm 工具进行 RAID 管理。

管理内存中的数据,vmtouch 这个小工具值得推荐。

PostgreSQL 设置为 Master-Replica 方式,流复制模式。利用 EBS 的快照进行数据库备份。使用 XFS 文件系统,以便和快照服务充分配合。 使用 repmgr 这个小工具做 PostgreSQL 复制管理器器。

连接池管理,用了 PgbouncerChristophe Pettus 的文章包含了不少 PostgreSQL 数据库的信息。

TB 级别的海量图片存储在 Amazon S3 上,CDN 采用的也是 Amazon 的服务,CloudFront。

Instagram 也是 Redis 的重度用户,Feed 以及 Session 信息都用 Redis 处理,Redis 也是以 Master-Replica 方式部署。在 Replica 节点上进行数据备份。

使用了 Apache Solr 承担 Geo-search API 的工作,Solr 简单的 JSON 接口也不错。

缓存使用了 6 个 Memcached 实例,库使用 pylibmc 和 libmemcached。亚马逊也提供缓存服务-Elastic Cache service ,Instagram 也有尝试,不过不便宜。

任务队列/发布通知

队列服务使用 Gearman ,通知系统则使用 pyapns 来实现。

监控

前面提及的服务器实例数量加起来,的确有100多个,有效的监控是相当有必要的。使用 Munin 作为主要监控工具 , 也写了不少定制插件,外部监控用 Pingdom 的服务。通知服务使用 PagerDuty

对于 Python 的错误报告,使用 Disqus 团队开源的 Sentry 来处理。

几个感想

0)轻装上阵说起来容易,做起来非常难。这也是 Instagram 团队目前最令人着迷的地方;

1)Python 社区已经足够成熟,各个环节上都已经有不错的解决方案了。

2)如果要问我最大的一个感慨,我要说:Amazon 真是一家伟大的公司,甚至比 Google 还伟大

EOF

此文作者:, 位于 Arch 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Quora 用了哪些技术 ?

很多团队都在学习、研究 Quora 。前段时间看到这篇 Quora’s Technology Examined ,阐述了 Quora 的技术架构,有一些值得关注的信息,记录并分享一下。

使用云计算服务

Quora 大量使用 Amazon EC2 与 S3 服务;操作系统部署的是 Ubuntu Linux,易于部署和管理;静态内容用 Cloudfront.服务分发,图片先传到 EC2 服务器,使用 Pyhon S3 API 处理后后传到 S3。

从开始就使用云计算服务的的好处是节省了大量人工维护硬件服务器的成本,当然这个做法在咱这片土地上不太可行。

Quora_China_chat.png.scaled500.png
(refer: Copyright )
Web 层与 CMS

HAProxy 作为前端负载均衡服务器,反向代理服务器是 Nginx,Nginx 后面则是 Pylons (Pylons + Paste) , 承担动态 Web 请求。

Webnode2 与 LiveNode 这两个内部系统承担创建、管理内容的重任,Webnode2 生成 HTMLCSS 与 JavaScript ,并且与 LiveNode 轻度耦合。LiveNode 的作用用以显示 Web 页面内容。用 Python、C++ 与 JavaScript 写的。特别提到用到了 jQuery 与 Cython。LiveNode 有可能开源。

为什么用 Python?

前面已经提到了一些 Python 相关的技术组件。有意思的是从 Facebook 出来的团队居然用 Python 作为主要开发语言。Quora 对此有所解释: Facebook 选择 PHP 也并非是最佳选择,而是有历史原因。Quora 技术团队在考察了多个语言之后选择的 Python ,当然理由有一大堆,总体看来,并非很激进。

通信处理

后端通信使用的是 Facebook 开源出来的 Thrift,除了开发接口简单之外,可能更为熟悉也是一个因素吧 :) Comet 服务器使用的是 Tornado,用以处理 Long polling 以及 Push 更新(不知道知乎用的什么?),Tornado 是前 FriendFeed 技术团队开源的产品。

实时搜索

因为 Sphinx 不能满足实时性方面的要求,Quora 启用了自己开发的搜索引擎,只使用了 Thrift 与 Python Unicode 库,此外没有用别的。Quora 的搜索比较特别,因为要对输入内容做关联并且要做有效提示,所以需要提供更好的前缀索引(Prefix indexing)功能。

Quora 搜索的实现还是挺有技术含量的,对后端的查询请求压力也不小(或许当前的并发请求量还没那么大)。对这个场景,做相关开发的朋友不妨仔细研究一下。如果大体框架类似,那么决定最后生出的因素很可能是那些细节。

数据持久层

大量使用 MySQL 作为存储方案,Memcached 作 Cache 层。没有使用当前比较火爆的 NoSQL 相关产品。Quora 这样做有自己的理由,用户量级没有达到百万的 SNS 站点完全没必要用 NoSQL 的东西。或许以后 Quora 也会启用。

创始人查理·奇弗(Charlie Cheever)与亚当·德安杰洛(Adam D’Angelo)之前都在 Facebook ,所以,Quora 的技术还真有不少 Facebook 的基因。Quora 的团队规模并不大,做技术的估计十余人而已,这么紧凑的团队利用了这么多的技术与产品,可见很多人都是多面手了。这是国内技术团队需要向国外同行学习的地方。

EOF

这只是一篇概要性的描述,如果要知道一些更为细节的东西,请看 Quora 上的相关评论,上文中已经给出相关链接。

此文作者:, 位于 Arch 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Facebook 如何发布代码 (How Facebook Ships Code 译文)

按:这篇 How Facebook Ships Code 提供了大量的细节信息,之前已经有朋友提供了一个翻译版本,阅读之后发现有些许错误,并且原文有更新,所以基于前面的翻译版本我重新翻译了一个(完整的)版本。一并谢过。希望这个版本对大家也有所参考。

我对 Facebook 的运作方式着迷。这是个非常独特的环境,很难被复制(这个方式并不适合所有的公司,即使有些公司尝试过这么做)。下面这些笔记来自我和Facebook的许多朋友的交谈,关于他们开发、运维与软件发布等方面。

好像很多人都对 Facebook 感兴趣… 这家公司的工程师驱动文化(Developer-driven culture)已经被公众大加研究,并且其它其它公司也在探求是否/如何实现工程师驱动文化。Facebook 的内部流程实在够神秘,当然,工程师团队也会发布一些关于新功能以及部分内部系统公开备忘,不过这些大多数是”说明”类的文章(What),而非讲述”机制”(How)… 所以,外部人员很难明白 Facebook 的创新以及如何比其它公司做到更有效的对服务进行优化。我作为外部人员尝试深入理解 Facebook 的运作,汇集了几个月来的这些观察信息。出于对信息来源的隐私保护,我去掉了特定功能/产品的名字。我又等了6个月以后才发布这些记录,所以,有些信息肯定过时了。我希望发布这些信息会有助于了解 Facebook 的管理机制如何在组织中进行决策的推行而非逐步陷入混轮…很难说这与 Facebook 的成败或是 Facebook 的产品协作相关。我相信很多面向消费者的互联网公司会从 Facebook 这个案例受益。

*非常*感谢那些帮助我整理这篇文章的 Facebook 内部的朋友们。也要感谢项 epriest fryfrog 这样的朋友,他们协助我进行对本文进行校正、编辑。

记录:

  • 截止到2010年6月,Facebook有将近2000名员工,10个月前只有大约1100人,一年之间差不多翻了一番!
  • 工程部和运维部是两个最大的部门,每个大概都有 400-500人。这两个部门人数大约占了公司的一半。
  • 产品经理(PM)与工程师的比例大约为1-7到1-10。
  • 每个工程师入职时,都要接受 4 到 6 周的 “Boot Camp” 培训,通过修复Bug 和听更资深的工程师的课程来熟悉 Facebook 系统。每次 Boot Camp 大约有 10% 的人无法完成课程而被淘汰。
  • 培训结束后,每个工程师都可以访问线上的数据库【标准课程”能力越大,责任越大” ( “with great power comes great responsibility”) 对此有阐释,另有一份明晰的”不可触犯的天条”,比如共享用户的隐私数据】。
  • [修改, 感谢 fryfrog] “Facebook 有非常牢靠的安全保障,以免有人(你可以想象内部有人有这个权限的)不小心/故意做了些糟糕的的事。如果你已经”成为”了需要别人支持的人,事由将被记录,并且有谨慎的审计。这里不允许钻空子。
  • 任何工程师都可以修改Facebook的代码库,签入(Check-in)代码。
  • 浓厚的工程师驱动文化。”产品经理基本可以被忽略”,这是Facebook一名员工的话。工程师可以修改流程的细节,重新安排工作任务,随时植入自己的想法。[评论] “本文的作者是一个产品经理,所以这个论断引起里我的注意。你看完整篇文章后会发现,很显然,Facebook 的文化实际上是拥抱产品经理的实践的,所以,不是产品经理的角色被忽略,而是,这家公司的文化看上去是想让”每个人”感受到对产品的责任”。
  • 在每月的跨部门会议上,由工程师来汇报工作进度,市场部和产品经理会出席会议,也可以做些简短的发言,但如果长篇大论的话,将如实反馈给他们的主管,”产品人员在上次会议说的太多”。他们确实想让工程师来主导产品的开发,对自己的产品负责。
  • 项目需要的资源都是自发征集的:
  • 某个产品经理把工程师们召集起来,让他们对自己的想法产生兴趣。
  • 工程师们决定开发那些让他们感兴趣的特性。
  • 工程师跟他们的经理说:”我下周想开发这5个新特性”。
  • 经理会让工程师独立开发,可能有时会让他优先完成一些特性。
  • 工程师独立完成所有的特性 — 前端 JavaScript/后端数据库,等等所有相关的部分。如果需要得到设计人员的帮助,需要先让设计人员对你的想法产生兴趣(专职的设计师很少)。请架构师帮忙也是如此。但总体来说,工程师要独立完成所有的任务。
  • 对于某个特性是否值得开发的争执,通常是这么解决的:花一个星期的时间实现,并在小部分用户中(如1%的内华达的用户)进行测试。
  • 工程师通常乐衷致力于架构、扩展性以及解决”难题”,那样能获得声望和尊敬。他们很难对前端项目或用户界面产生太大的兴趣。这跟其他业务为导向的公司可能正好相反,那些公司人人都想做客户能直接接触到的东西,然后会指着某个特定的用户体验说,”那是我做的”。在 Facebook,后端的东西,比如 News Feed 算法、广告投放算法、Memcache 优化等等,是工程师真正倾慕的项目。
  • News Feed 因为太重要了,扎克会亲自审查任何变动。这是个特例。
  • [更正, 感谢 epriest ]”所有的代码变更都要经过强制性的代码审查(比如一个或者多个工程师)。我相信这篇文章只是说 扎克并不自己审查每一个变更”。
  • [更正, 感谢 fryfrog ]”所有的修改至少要被一个人审查,而且这个系统可以让任何人很方便地审核其他人的代码,即使你没有邀请他。提交未经审查的代码,将被视为恶意行为”。
  • 工程师负责测试、Bug 修复以及启动对自己项目的维护。有单元测试和集成测试的框架可用,但很少使用。
  • [更正, 感谢 fryfrog ] “补充一下,我们是有 QA 的,只是没有正式的 QA 组而已。每个办公室或通过VPN连接的员工会使用下一版的 Facebook,这个版本的 Facebook 会经常更新,通常比公开的早 1-12 小时。所有的员工被强烈建议提交 Bug,而且通常会很快被修复”。
  • 回复:很奇怪只有很少的 QA 或自动测试 — “大部分工程师都能写出基本没有bug的代码,只是在其他公司他们不需要这么做。如果有 QA 部门,他们只要把代码写完,扔给他们就行了” [编辑:请注意这是很主观的,我选择包括这部分内容是因为这和那些其它公司的标准开发实践完全相反]
  • 回复:很奇怪,缺少产品经理的影响和控制 — 产品经理是很独立的和自由的。产生影响力的关键是与工程师和工程师的管理者搞好关系。需要大致了解技术,不要提一些愚蠢的想法。
  • 默认情况下,所有提交的代码每打包一次(周二)。
  • 只要多一分努力,终于一天会发生改变。
  • 星期二的代码发布,需要所有提交过代码的工程师在场。
  • 发布开始前,工程师必须在一个特定的 IRC 频道上候命,否则将会被公开问责。
  • 运维团队通过逐步滚动的方式进行代码发布:
  • Facebook 有大约 60000 台服务器。
  • 有9个代码发布级别。
  • [更正 感谢 eriest] “九个级别并非同轴的(concentric)。有三个同轴的阶段(p1=内部发布, p2=小范围外部发布, p3=完整的外部发布),其余六个阶段是辅助层,比如内部工具、视频上传主机等等”。
  • 最小的级别只有6台服务器。
  • 比如,星期二的代码发布会先发布到 6 台服务器上(第一级),运维组会观测这 6 台服务器,保证代码正常工作,然后再提交到下一级。
  • 如果发布出现了问题(如报错等等),那么就停止下一级的部署,提交出错代码的工程师负责修复问题,然后从头继续发布。
  • 所以一次发布可能会经历几次重复:1-2-3-修复,回到 1, 1-2-3-4-5-修复, 回到1, 1-2-3-4-5-6-7-8-9。
  • 运维团队受过严格训练,很受尊敬,而且极具有业务意识。他们的工作指标不止包括分析错误日志,负载和内存使用状态等等,还包括用户行为。比如,如果一个新的发布导致一定比例的用户对 Facebook 功能进行声讨,运维团队将查看相关指标,可能基于他们的调查停掉该次发布。
  • 在发布过程中,运维组使用基于 IRC 的通知系统,可以通过 Facebook、Email、IRCIM SMS 通知每一个工程师,如果需要他们注意的话。对运维组不做回应会被公开问责。
  • 代码一旦发布到第9级,并且稳定运行,本周的发布宣告结束 。
  • 如果一个特性没有按时完成,也没什么大不了的(除非外部依赖严重),下次完成时一并发布即可。
  • 如果被 SVN-blamed(应该指没按照规范提交代码会受到的惩罚)、公开问责(Public shamed, 示众?还是通告批评?)或工作经常疏忽就很可能被开除。”这是一个高效的文化”。不够高效或者不够聪明的员工会被剔除。管理层会在 6 个月的时间里观察你表现,”你不能适应这种文化,只能说再见”。每一级都是这个待遇,即使是 C 级别和 VP 级别,如果不够高效,也会被开除。
  • [更正, 感谢 epriest ] “人们不会因为导致 Bug 而被解雇,只有在发布他们的代码时导致问题,而他们恰恰又不在场(也找不到其他可以替代的人)”。
  • [更正, 感谢 epriest] “被问责不会导致解雇。我们特别尊重别人,原谅别人。大部分高级工程师都或多或少犯过一些严重的错误,包括我。但没有人因此被解雇”。
  • [更正, 感谢 fryfrog] “我也没有遇到过因为上面提到过的犯错而被解雇。我知道有人不小心将整个网站宕掉过。一旦有人犯错,他们会竭尽全力修复问题,也让其他人得到了教训。就我来看,这种公然蒙羞与被解雇的恐惧相比更为奏效”。

分析 Facebook 的研发文化如何随着时间演化是件非常有趣的事。特别是当公司发展壮大到数千员工的时候,这种文化是否还能够延续?

你觉得如何?在你公司里,”开发者驱动(developer-driven)文化” 将会可行么?

译者后记:很多时候是管中窥豹也是非常有趣的,而且,应该细致一点儿。另外,或许我们更应该关注为什么 Facebook 能够形成这样的文化。你说呢?

译者后记续:Facebook 能形成工程师主导的文化,应该和 Facebook 的产品形态有很大关系。毕竟 Facebook 人人都会用 Facebook … 换言之,如果是 Amazon / eBay 这样面向商业的用户的公司,业务逻辑会让工程师陷入五里雾中。

EOF
延伸阅读:Hacker News: What I Learned from Zuckerberg’s Mistakes

此文作者:, 位于 Arch 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.