成立于1994年的亚马逊公司，一直以来都是颇具争议的存在。多年来，Jeff Bezos在用户至上（Customer
Obsession）的理念下，让整个电商业务通过价格、选品和可用性（availability）聚焦于客户体验，并为获取长期优势而持续将收入投入到保持低价、扩大规模以及优化仓储和物流等基础设施上。亚马逊这种持续刻意的不盈利，不但使亚马逊与华尔街的投资人之间的关系微妙而紧张（多年来从未对股东分红，今后也不会！），而且其模式也不断被质疑是【注1】。同时，Jeff
Bezos对社会凝聚力的以及其反传统的管理方式【注2】也极大地塑造了亚马逊内部带有冲突的，这样的文化被具体化为14条并用以指导整个公司范围内从上至下的日常决策，虽然对这种文化不乏，但也有众多离开亚马逊的员工表达了对这种工作方式的热爱。
在这种文化指导下的技术研发工作也展现出非同寻常的特点：亚马逊在物流管理、推荐引擎、Web2.0、云计算、人工智能、数据化管理、平台设计、DevOps等领域一直走在行业前列，不乏叫好又叫座的产品，但从外部看，其在开源社区和公开的技术演讲中却鲜有声音；与外在的沉寂不同，在亚马逊内部，研发则是另一番景象，一个又一个想法被不断提出和尝试，各团队为了共同的目标高效地竞争与合作，知识和经验被不断的累积与分享……
我自2009年加入亚马逊至2014年底离开，期间接触了多个团队的技术研发和研发管理的工作。在离开亚马逊加入创业公司后，研发团队遇到的一些问题常常将我带回对往事的思考中：“是什么让亚马逊的研发如此不同？”，“如何学习亚马逊的经验来打造高效的研发团队？”……。
本文正是我近几年对亚马逊研发和管理的一些思考，并结合了具体实施的一些经验。由于整个亚马逊的研发和管理体系的复杂性，加之多数结论也是基于实践的一些揣测，其中不乏不妥和错误之处，望阅读的过程中加以斧正。
最后，亚马逊那种直接鼓励竞争性的角斗士文化本身就有非常大的争议，其本身确实不是以优先考虑员工感受为出发点，但作为亲历者也确实能够感受到在压力下不断创新和超越自我所获得的满足感，因此，有关文化的讨论并不是是非对错的探讨，读者还需要自行判断和采用。
成为全球最以客户为中心的公司，在这里，人们可以找到和发现他们想从网上购买的一切。
—— 亚马逊网站使命宣言
Bezos通过一张图（如图1）诠释了亚马逊的运营逻辑，这逐步演化为整个亚马逊电商的运营核心——飞轮（Flywheel）。这个飞轮简单解释如下：
亚马逊提供丰富的选品和购物便利，而丰富的选品和购物便利带来了更好的用户体验，用户体验的提升引发更多的消费者来到网站，流量的提升将吸引更多的供应商加入，结果进一步丰富了选品，而这又使得亚马逊可以通过供应商竞争以及在更宽泛的基础上分摊成本来进一步降低价格，价格的降低又使消费者的满意度进一步提升，这个良性循环持续发生，推动这亚马逊整个平台越来越好。
背后暗藏着这样的逻辑：一旦核心部分各就其位，飞轮被激活，飞轮就会随着时间产生持续的动力并变得更强。在整个循环中，每个部分会产生自己的能量，这又被用来驱动系统的其它正能量。
在亚马逊的研发体系中，类似飞轮这样的良性循环机制发挥着广泛而巨大的影响，大到人员招聘和培养体系，小到事后分析机制的设计，甚至亚马逊平台化的思路中也多有类似的飞轮思想。【注4】另外，之后将要介绍的领导力准则，其各个部分往往也会相互影响，形成类似飞轮的机制，正如John Rossman在《The Amazon
Way》中所说，“一旦你在组织中建立起责任感（Ownership），它就会像飞轮一样驱动着创新与简化（Invent and Simplify）”。
当我们去分析一个公司的企业文化时，其领导者的个性应该是重要的考量因素之一。对于创业公司而言，这一点尤为明显，创始人的行事方式几乎会完全影响和定义公司的文化【注5】。因此，不难理解，一个喜欢资本运作的老板，很难关注用户和产品的长期发展，其公司的快速衰落就在情理之中。同样的，一个靠投机获得财富的人，天然地会利用互联网作为更大的传销平台来兜售其狡黠的捷径哲学，而本身并没有像样的产品和经得起推敲的方法论。【注6】
Bezos的成长经历，并描述了这位亚马逊创始人不一样的性格特点。从这些资料以及网上公开的分析文章中，我们不难发现Bezos的高标准严要求、节俭、固执、不讲情面、深入细节、相信数字、结果导向等等特点。作为一个知名的例证，《一键下单》和谈到了Bezos小时候劝说外祖母戒烟的故事，有趣的是，同样的故事在3个地方被用来反映3个完全不同的主题！【注7】
首先，《一键下单》用这个故事表现Bezos缺乏同情心：
贝佐斯天生就没有同情心。他10岁时，在和祖父母的一次旅行中，他试图让他的外祖母戒烟。 对于一个让人难堪的话题，他靠的更多的是他的书呆子办法而不是善解人意。他算出她所吸入的尼古丁含量会减少她9年寿命。外祖母哭了。外祖父不得不教导他应该有更多的同情心。“我外祖父注视着我，沉默片刻，然后平静地轻轻说道，‘ 杰夫，有一天你会理解，做到善良比聪明更难。’”贝佐斯说。
其次，纽约时报的文章则用这个例子反映Bezos数据驱动的管理天分：
最后，Bezos自己在普灵斯顿的毕业演讲中[9]，用这个例子来说明选择比天赋更重要【注8】：
回归正题，在亚马逊成立时，Bezos就在思考如何避免公司随时间变得官僚主义、挥霍无度以及骄奢安逸。他想将他对工作的想法变成新人能够理解的简单指示，足够通用以便适用于所有业务，并且足够严格以防止他所担心的平庸，其结果就是我们这里探讨的14条领导力准则（如图2），我们可以通过亚马逊招聘网站在线查看对的简单解释。不难看出，这些领导力准则有些反映出Bezos个人的行事特点（如Frugality，Dive
有别于其他企业夸夸其谈、含糊不清的的价值观，亚马逊的领导力准则从来不是埋藏在员工手册中的漂亮文字。这些信条在整个公司范围内——从上到下——被用来指导日常工作、绩效评估、人员招聘，甚至被用来解决会议中的争论、跨团队的协作（如图3）等等问题。亚马逊领导力准则就像亚马逊这头巨兽的血液，它在思想层面统一了亚马逊人对做事方式和做事标准的认知，并提供了一套高效沟通的标准语言。【注10】
图3 在日常邮件中使用领导力准则进行沟通，反馈问题，给出解决的建议。
此外，通过领导力准则在人员招聘和绩效评估上的使用，亚马逊将这些能力固化为亚马逊人所应具备的标准竞争力（Competence）。比如，亚马逊的绩效评估使用OLR（Organization and Leadship Review）的机制，其中L就代表了领导力准则（Leadership
Principle）。评估分成3个部分：员工自评，经理评价和360度互评。这些评价都需要落脚到具体的领导力准则上，并且要给出具体的改进建议。
为了使这些准则明确和更具操作性，亚马逊还为每位员工刊印了指导手册，里面具体解释了使用方式以及使用过度和运用不足的情况（如图4）。而且，作为指导亚马逊日常工作中决策的依据，其与公司战略和人员情况始终保持着紧密的互动，也就是说，这些领导力准则会被定期评审以判断是否适用，例如，最近自我批评（Vocally Self
那么，我们要如何学习亚马逊的领导力准则呢？
我们必须要明白，亚马逊所呈现的这些均是其发展的结果（现状），这些结果是由亚马逊发展过程中所遇到的问题所塑造的（）。因此，机械照搬亚马逊的领导力准则肯定是行不通的，我们需要先清楚自己要解决的问题并明确要达到的目的，在这个基础上进行选择，必要的时候我们需要发展出自己的领导力准则。
围绕亚马逊的文化，公开讨论比较多的是面向客户（）【注11】和建立远景视图（take
Big）的体现，这方面的资料网上俯拾皆是——举凡谈及亚马逊必然要讨论到这两方面，这里就不在赘述。但这并不意味这这两点不重要，也不意味着这两点很容易达成。事实上，对创业企业来说，这两点毫无疑问是知易行难的代表。就我的经验而言，在团队内强调这两点其实是非常必要的，因为聚焦客户有助在企业内部建立一种面向客户的服务意识（文化），这不仅会帮助团队成员建立同理心（empathy）和共赢意识，而且可以润滑团队间的合作；而愿景视图则可以帮助团队在用短期方案解决眼前问题的时候养成思考长期方案解决根源问题的意识。
正如亚马逊领导力准则所能达成的目的，为整个公司建立一种行事的标准和方法并依此标准来选择或培养人员。为了能在公司或团队范围内建立一种担责、行动和服务的文化，我在创业公司通常会逐步要求客户至上（Customer Obsession）、责任感（Ownership）、执行力（Bias for action）、聪明做事的方式（Invent and Simplify）、深入细节（Dive
Deep）和达成业绩（Deliver Result），这样比较容易和快速让整个团队建立起服务意识（聚焦客户的结果，业务团队或者内部的依赖团队都应该被当做客户）、勇于担责并且不推诿的做事方式（来自责任感，我们会明确的要求团队不推事，要考虑整个公司或产品的目标，在明确超出范围时，也要说明原因并帮助反映问题），并可以让技术团队自然的关注于业务（深入细节的要求）等等。
同时，在面试的过程中，也会着力考察面试者在责任感、执行力、深入细节，甚至远见卓识（Think
Big）上的情况，而不仅仅考察其技术能力。当人员具备这些素质时，一个能打硬仗的自我驱动的团队就不再是遥不可及的事情了。此外，需要注意的是，这种标准需要在各个层面一致地进行贯彻，你不能一边要求团队有责任感一边自己不担责，另外，当团队遇到问题时，要适时地进行教育，必要时需要建立纪律进行奖惩。比如，我们的一个系统出了问题，研发人员在周五下班前发了一份邮件给异地的开发团队，然后就心安理得的回家了，之后当被问及系统问题为什么没有得到及时处理时，该研发人员说已经给对方团队发了邮件，认为责任不在自己（已经移交给对方团队）。我们在之后的会议上分析了这个问题，对双方的团队成员进行了批评，明确任何问题的责任人要对问题全程负责，不能认为发了邮件就没自己的事情了，在没有得到明确反馈时需要想其它办法获得反馈，并积极推动事情向前。此后，类似问题发生后，邮件没有得到快速反馈时，研发人员就会主动打电话联系对方的团队成员或领导，并能快速地将事情的进展进行反馈。
Bezos期望通过领导力准则让每一个亚马逊人成为企业的领导者（leader）或者主人（owner），他想让你就像对待自己的事业一样来推动亚马逊的业务，而不只是来上班和社交。这也正是许多企业主和管理者的所面对的问题，在这方面亚马逊确实做得不错，但是这样的角斗士文化并不适合每一个人。对于企业而言，我们能够借鉴亚马逊建立更为适度的竞争环境？而对于求职者来说，你是期望一个不断将你踢出舒适区并不断促使你成长的环境，还是一个舒适的工作，这取决与你的选择。
实现跨越的公司的领导人不会追求这样一个领导模式：“先普遍撒网，后重点培养”。而是走这样一条路线：“我们会事先花上大力气进行严格的人员挑选。一旦找对了人，就会想方设法把他们留在自己身边。如果不合适了，我们也会诚实地去面对，这样我们可以继续我们的工作，他们也可以继续他们的生活。”——《从优秀到卓越》
文化的受众、组成与影响的都离不开人，可以说，文化由人决定，又决定了人。像亚马逊或者Google这样的优秀企业必须要有与其文化相适应的人员才能高效运转，尤其是亚马逊这种冲突性的角斗士文化，必须不断吸纳在竞争力上能够适应它的人（在国外，亚马逊两年内的流失率非常高）。我们在介绍亚马逊领导力准则时说过，亚马逊的领导力准则会用于人员招聘和培养。这是如何做的？
一方面，在领导力准则中有两部分与人员的选择与培养相关：
领导者不断提升招聘和晋升员工的标准。他们表彰杰出的人才，并乐于在组织中通过轮岗磨砺他们。领导者培养领导人才，他们严肃地对待自己育才树人的职责。领导者从员工角度出发，创建职业发展机制。
领导者有着近乎严苛的高标准 — 这些标准在很多人看来可能高得不可理喻。领导者不断提高标准，激励自己的团队提供优质产品、服务和流程。领导者会确保任何问题不会蔓延，及时彻底解决问题并确保问题不再出现。
另一方面，在亚马逊的招聘过程中，会围绕领导力准则所要求的竞争力进行重点考察。
让我们先来简单地描述一下亚马逊的面试流程。（不确定亚马逊的技术面试是否是世界上最难的，但持续时间长是一定的。【注12】）
从候选人的角度看，当候选人员通过了HR和技术的电话初筛，接下来就会被请到亚马逊的办公室进行Onsite面试。整个Onsite面试通常有5到8轮——依据具体的职位会有所变化，时间通常会占用半天到一天，由于面试后有可能会有内部轮转的可能，因此，偶尔会遇到多个不同组进行多次Onsite的情况。这里以5轮面试为例，整个安排会是技术面试占两轮，其中一轮考察编程能力，另一轮考察设计能力，然后是招聘经理面试，HR面试，最后是Bar
而从面试者的角度看，HR先将面试者的简历信息录入到内部的面试管理系统，然后确定电话面试的面试官，电话面试通过后（可能会是HR和技术各一轮），面试的反馈会录入系统备查。之后，HR和面试经理一起确定Onsite各轮的面试官，尤其是Bar Raiser人选。在Onsite之前，会举行一个快速的kick
off，在这个会议上，HR会简单的介绍候选人和职位的情况，然后，面试经理会和大家一起将1领导力准则和其它方面的面试内容分配到具体的面试上，比如，第一轮的技术面试除了考察编程能力，还会重点考察候选人的Ownership和Dive Deep的能力。在面试的过程中，各个面试官会通过提问不断探查（probe）和挑战（challenge）候选人，以便客观和全面的了解候选人的情况。
各面试官在面试后要在系统中详细进行反馈【注13】，这些反馈包含：
-
1 明确的投票，录取还是放弃
-
3 候选人的优势和劣势
-
4 问题、回答以及分析
最后，Bar Raiser会主持一个debrief会议，在会议开始，各个面试官会先花一些时间阅读所有人的反馈信息，而后开始汇总和讨论候选人的情况，最后Bar Raiser和招聘经理会根据分析情况最终确定是否offer候选人。
这里，我们看到亚马逊面试设计的两个特色。
首先，对叙述性文档的钟爱，在亚马逊内部管理中，叙述性文档是最常用的工具，而PPT除了技术分享外，是被禁止使用的。这是因为PPT中只有少量信息，观众只能抓住那些要点，这种机制对演讲者友好，但对观众却很困难。相对的，书写文档时，完整的句子和段落会促使作者深入的思考和更清晰的表达，这些文档可以无需额外的解释就能分享更多信息。
就候选人的反馈而言，由于整个面试过程通常是在纸上进行编程，因此，面试官在录入反馈时需要将程序和问答细节都录入系统，这确实是一个不小的负担（通常会花30~60分钟），但也正是这个过程，使得面试官在录入的过程中能够再次审视候选人，尽量客观的对其进行评价。另一方面，这样的反馈工作也锻炼了面试官的分析能力，并对其面试进行快速反思，从而使得面试官能够更出色地完成未来的面试工作。
其次，Bar Raiser的设定。Bar Raiser是公司内部经过培训的一些特殊面试官，他们会作为第三方参与到整个公司的面试流程中，并且代表公司在人员招聘方面的长期利益，这种长期利益主要是来平衡招聘经理快速补充用人的短视诉求。在一个面试中，Bar Raiser必须同意才能给候选人发offer。
Bar Raiser是如何代表公司招聘的长期利益？在Bar Raiser判断的过程中，他们需要考虑如下两个问题：
-
候选人是否超过亚马逊当前职位上50%人员的能力？
-
候选人是否能为亚马逊带来长期的影响？
正如之前论述飞轮时谈及，Bar Raiser就是推动人员能力持续优化的飞轮中的重要一环。通过Bar Raiser的设定，亚马逊期望通过不断提升招聘门槛来提升整个公司的人员水平。整个面试循环如下图所示。
图5 通过不断提升招聘门槛（Hiring Bar）来提升整个公司的人员水平
毫无疑问，亚马逊的整个面试过程是很繁杂的。但考虑到亚马逊招聘的主旨——Hiring The Best。这样的流程就显得稳妥而高效。
如果我们不假思索地将这样流程直接用于初创公司，那一定会遇到问题！
当我最初加入某个创业企业时，拿着整套方法，期望通过叙事性反馈和基于反馈的debrief来提高招聘的质量，但经过几次尝试，HR和参与面试的人员就开始抱怨。稍作分析后不难发现，多数创业公司的用人诉求是快速找到能干活的人员，至于面试体系的优化、人员水平的提高或者人员长期的潜力都是次要得。在这种情况下，我们可以对亚马逊招聘流程进行一定的调整，形成一套适合自己的招聘体系：
在实施过程中，还需要在公司内对潜在的面试人员进行定期培训，培训的内容主要是如何考察和分析候选人的能力与潜力，这方面可以参考GitChat之前的分享。另一个常常遇到的问题就是大家对面试结果举棋不定的时候，如果遇到这种情况就大胆的淘汰掉候选人。
通过前面的讨论，我们知道这些通过面试的候选人很大的可能性会契合亚马逊的领导力准则，优于该角色当前50%的人的能力，而且其潜力能够在将来对亚马逊产生影响，那么，在具体技术方面，亚马逊对技术人员有怎样的要求呢？这些要求又如何影响了亚马逊研发的效率呢？
SDE全称是Software Development Engineer，他们是亚马逊系统的建设者，是技术研发的中坚力量。【注14】当我们探讨亚马逊对技术人员的要求以及研发效率的问题时，主要是针对这个岗位的人员。在我们具体看亚马逊对技术人员的要求前，我们先分析一下技术人员在亚马逊所面对的问题。
-
1 亚马逊零售网站，这部分被称为Retail
-
2 电商业务涉及的所有支持系统，这部分被称为OpsTech
-
4 与硬件相关的系统及其业务支持系统
-
6 战略性预研工作的研究所，如神秘的
无论是#1~3这样传统的电商研发团队，还是之后更为技术性产品的研发工作，这些工作在当时（甚至现在）都是前无古人的探索，相应的，其技术团队除了了解其所面对的问题外——有时对问题的了解都是模糊的，很少有现成的东西可以参考。如此，当我们在技术岗位的JD上看到这样的描述就一点都不觉得奇怪了：
候选人能够独立地创造性地解决挑战性（模糊的）问题。
从另一个侧面看，决策要快就意味着业务快，而业务快就要求支持的研发必须快！那么在业务驱动的大背景下，研发人员必须能够在信息有限的情况下和业务团队一起创造性的快速解决问题，这也是责任感的一种体现【注15】。当然，亚马逊的领导力准则仔细推敲起来就是要达到一种低成本、高质量的快速行动力。
再进一步看，当我们有一些想法，需要研发团队配合开发一些支持系统，以便整个业务能够运转起来。当业务运转起来以后，通过系统了解业务的运转情况，我们会有新的理解，而后就产生新的想法，研发了解并进行相应的开发，改进的业务运转起来。之后继续这样的循环……
这个循环让我们了解到第一个有关研发的事实：软件研发本质上是一个学习的过程，尤其是快速学习相应领域中的业务知识。我们对业务领域越是了解，我们开发出的系统就越简单好用。因此，亚马逊的技术研发人员必须要有优秀的学习能力，考虑到业务和技术变化的速度，研发人员必须有快速学习的能力。
再进一步看，当我们了解了业务并清楚需求后，我们要把这些业务需求变成运行的系统，这个过程要涉及一系列工作：
-
1 产品设计（原型设计，交互设计等）
-
2 系统设计/软件设计
这些工作中，什么是最核心的？从业务的角度看产品设计和系统设计是最核心的，编码实现则更像某种翻译工作。因此，我们得到第二个有关研发的事实：软件研发本质上是设计。如果我们将产品设计的工作交给TPM（类似产品经理）或者PM（业务人员），我们可以将这个事实针对研发人员进行改写：软件研发能力最关键的是设计能力。
至此，我们稍作总结，亚马逊的SDE是什么样的人？
他们符合亚马逊领导力准则所要求的竞争力，尤其是在客户至上、责任感、执行力、深入细节、远见卓识、创新简化、达成业绩方面，此外，他们还关注业务、快速学习，能够通过设计、实现和运营系统来创造性地解决业务问题。
这大概也是你心目中对研发人员的要求吧？无论如何，我们在创业公司中是按这个要求寻找同行的小伙伴的！
为什么亚马逊内部将SDE戏称为啥都干的人（Someone Do Everything）？这可以引出亚马逊内部有关研发工作的两个有趣举措：
首先，我们来探讨一下人人都是架构师。
正因为亚马逊认为研发人员最关键的技术能力是设计能力，所以在岗位要求和面试安排上，系统和软件的设计能力都是关键点。比如，SDE1需要了解设计，而SDE2就必须能够独立地进行设计工作，到SDE3，需要把握复杂系统的架构。
当进入公司的研发人员已具备（或有潜力习得）设计和架构能力，并有问题解决能力，还可以深入细节、快速学习，此时，单独划分出架构团队的意义就不大了，而且一旦设置独立的架构团队则必然引入额外的沟通和决策过程，而且架构团队脱离具体的业务也很难给出适合的架构，这些架构团队就会成为高效研发的桎梏。近些年主流的看法是让架构师参与到开发工作中，也就是架构师要参与编码或者实际参与实现其架构。亚马逊的做法是从另一面入手，既然所有人都具备架构和设计能力，那么就让实际业务的开发人员做架构吧。
不可否认，即便对于亚马逊的研发工程师，架构工作仍然是非常复杂的。为了让开发人员能够真正担负起架构工作，一些措施必须就位来降低架构工作的复杂性。这些举措涉及：
-
1 通过团队划分来降低问题规模
-
2 通过合理分工来分担架构工作
-
3 通过内部框架限制选择、提高效率
-
4 通过工具或服务封装支持性架构和运营维护工作
-
5 通过制度保证知识积累
稍后，我们将涉及这些举措，可以这样说，正是这些举措使具体的研发工作变得简单高效。在此之前，先让我们聊一下开发人员完成一切。
2006年，亚马逊CTO Werner Voegls【注16】接受ACM访谈，在谈及服务化过程中所获经验时，他给出亚马逊研发人员同时负责研发和运营维护工作背后的理念——“You build it，you run it”，如下是摘自的内容。
这段谈话给出让研发进行运营维护工作的好处：
在这篇访谈的其它部分，谈到如何确定该不该发布一个功能时，Werner Voegls的回答透漏出当研发接手运营维护工作的另一个好处，就是与产品运营相关的数据意识的建立，而数据驱动和基于数据管理是亚马逊非常重要的实践。原文如下：
现在，让我们将思绪放到2006年。3年后的2009年，敏捷社区才忸怩地提出DevOps的概念，而且那时还只是强调Dev、QA和运维人员相互协作；而在2006年之前，亚马逊已经让研发人员承担（大部分）测试和（应用）运维的工作，而且以服务构建和部署为核心的整个研发运维支持体系（当时应该是ABB【注17】）早已完全就位，通过这些工具，研发人员可以将精力投注在业务学习和核心模块的实现上。系统搭建、部署、监控等支持性工作都能通过这些工具简单地完成，这正是之前降低架构复杂性时提到的措施之一：通过工具或服务封装支持性架构和运营维护工作，这里支持性架构通常是指物理架构、运维架构，可能还包含常见的系统架构（如，用以支持高可用和高并发的架构，或者基于消息的架构），虽然这些工作并不直接与业务相关，但确实又不能不做。
对于亚马逊而言，业务部分是变化最快的，新的业务不断涌现，旧的业务需要不断优化调整，相应地，业务团队和研发团队应该将精力放在与业务相关的工作上。与之相比，物理架构、系统架构和运维架构的问题解决往往有固定模式，也容易通过服务化的工具进行封装和提供，其变化性更多来自服务的量级而不是内容。【注18】
当我们将这些知识和实践用工具或服务封装后，开发人员只需学会使用这些工具或服务即可，而不需要关心其背后复杂的知识。因此，从系统开发实现的角度看，相关的设计、编码、测试、部署、运维等等工作都可以由研发人员一力承担，像OpsTech负责的多数内部服务系统，甚至连产品设计的工作也由研发完成。这就是从谁构建谁运营（You build it，you run
it）发展出的研发人员完成一切，如下图。
需要注意的是，虽然多数情况下，SDE会优先且尽力承担研发中涉及的所有工作，但当需要更强的专业性时，亚马逊也并不排斥在团队中设置相应的角色，并将工作交给他们。例如，服务供应商的Seller Centre系统，由于用户体验和交互对提高用户使用效率非常关键，因此，整个大团队会设置产品经理和前端团队。类似的，有些业务会需要数据工程师（Data
Engineer）或者是嵌入式系统架构师（Embedded System Architect）这样的研发人员，对这些人员而言，则需要学会这些支持性系统，有时甚至是必要的开发技能，以便在资源有限的情况下依然能够保证业务推进和系统的运营维护。
另一个比较容易引起误解的地方是对测试以及测试人员的定位和使用。毋庸置疑，测试是非常重要的工作，只是对大多数系统或服务而言，测试更多地通过自动化和程序性的完成，即便还会有一些手工验证的工作，这些工作也常常由系统的开发者内部消化掉。在一些强调用户体验和可用性的系统或服务中——如移动端应用，也会设置专职的测试人员。除了QA，亚马逊的SDET（Software
近几年非常流行的全栈工程师在亚马逊内部并不会提及，既然亚马逊对SDE的潜在要求是一人多能——尽量独立、尽力全能（干），为了达成业绩（Deliver Result）什么都得学会，谁还会觉得多学一些东西是了不起的事情？毕竟，在这样的环境下，全栈只是全能的一种副产物！
在目前的创业公司中，我们尝试通过开源工具搭建出与亚马逊相对应的支持工具链体系，如下图，并让研发人员完成一切开发和运维工作。在近百人的研发团队中，我们只保留了两名传统运维人员来负责机器、网络等基础设施维护，而且完全没有测试人员。
当研发人员开始运营维护自己的系统时，自然需要时时刻刻关注系统运行的状况。当生产系统发生问题时，监控和报警系统会捕获这些问题，并生成与这些问题相对应的报障，这些报障会根据之前设定的负责团队和排班情况自动找到对应解决的人，之后通过pager或短信进行通知。此时，无论你身在何处，无论你从事何事——很有可能是睡觉，你都需要马上打开电脑，快速跟进和处理问题，这也是你身边的亚马逊朋友总是背着电脑和你一同出游的原因。【注19】
不难看出，7x24的OnCall确实是个辛苦的负担，尤其是打扰到睡觉或私生活的时候，这个负担会尤其痛苦，但这也恰恰正是让SDE担负OnCall的有趣之处。当事情让人痛苦时，我们可以采取两种方式处理，一种是拍拍屁股走人，让问题变得更糟；一种是留下来咬着牙把问题解决了，让整个世界美好起来。显然，无论哪种职场鸡汤都会鼓励后一种行为。事实上，痛苦确实能够激发创新，要知道亚马逊的部署工具链和Google的应用运维系统都是在研发人员完全不能好好睡觉的情况下被现实逼着开发出来的！
对于OnCall这种痛苦，研发团队也会想一些办法来缓解。比如，早前有些团队尝试在印度组建支持性团队来专门负责OnCall和解决Bug，但运作一段时间后，此种方式的弊端就显现出来了。首先，支持性团队的流动性非常高，解决问题这样的工作不但工资不高而且少有成就感，很自然，这些支持性团队的成员要么离职要么熟悉系统后转为该系统的SDE。其次，系统的质量没有得到明显改善，支持性团队的成员由于不直接对业务系统负责，因此他们更关注将遇到的问题解决掉，至于隐藏在问题背后的根源，那就要看相应支持性团队成员的心情和人品了，结果有些问题会周而复始的重复发生。另外一种方法则需要研发团队在不同时区有研发组，这样一来，大家可以相互负责处理对方晚上的OnCall，恩，终于可以安心睡个觉了！
OnCall制度还有另外一些好处。首先，通过OnCall可以让新人快速熟悉业务和系统。有些团队会在新人加入团队后先让其OnCall一段时间，这段时间新人通过解决实际问题了解了开发流程、工具、业务、系统，以及相关的人员。
另外，OnCall还和OE（Operation Excellence）相关，而OE在研发层面则会促进系统质量的提高和研发资源的有效利用。
当判断一个系统质量好坏时，我们会采用什么方法？显然，线上系统问题的数量、类型和严重程度会给我们一个从外部洞察系统的机会。一个总是发生问题的系统或者不时发生严重问题的系统，其质量自然不高，更糟糕的是，由于研发人员还要负责运营维护的工作，如果系统问题占用了太多时间，那么研发人员就没有时间开发新的功能。Google通过SRE和故障预算来平衡研发和运维工作的比例，亚马逊则是通过YOY（Year
of Year）的OE目标来促使系统进步。
研发团队需要在业务持续增长的情况下，系统每年的问题数量下降10%，相应的支持性人员（工作）要减少10%……
举个例子，如果团队有10个SDE，去年有1000个Tickets，那么今年系统Ticket数量要在900以内，而且还要解放出一个SDE，这样团队就可以用同样的人负责更多业务，如果业务没有明显增长则可以缩编。这里10%是一个用于参考的底线值，通常团队会根据自身情况设置一个相对合理的值，如果数值低于10%或者无法完成，这种特例需要上报到高层管理批准。由于OE目标是来自Bezos的要求，而且还作为各级管理者绩效考核的内容，因此，系统问题的数量、趋势，以及严重问题的事后分析会被每周的管理会议过问。
亚马逊的事后总结与分析的方法称COE（Correction Of Error）。其通过识别问题的根本原因并追踪识别的行动项来解决这些问题，从而提高服务（或系统）的整体质量并推进负责团队的责任。需要注意的是，COE不是寻找问题责任人并进行处罚的过程！
COE在形式和作用上类似Google SRE的事后分析，内容包容如下部分：
-
1 简要描述出了什么问题
-
2 问题对业务和客户的影响
-
4 通过5Whys给出问题根本原因的详细分析
通过COE，研发团队可以识别出问题的根本原因，并通过可追踪和交付的行动项来解决问题的根本原因，最终，我们要防止问题再次发生。而且，在这个过程中，我们需要将分析得到的经验保留下来并与其他人分享。
-
通过OnCall，研发人员可以切实地感受到系统问题带来的影响，并产生解决问题的动力。
-
通过OE，在制度上保证了运维工作在合理的范围内，并且推动系统和团队持续优化。
-
通过COE，研发人员可以识别根本问题，并关注长期解决方案的落地。
让研发人员直接负责在线报障可能是快速提高业务服务水平和系统质量的最好方法了。我曾在两个创业公司内尝试建立由开发人员负责运营维护并进行7X24
OnCall的制度。在第一家公司，其后来负责研发的老大认为应该保护研发团队——运维的痛苦应该找专门运维的人员来负责，最后，系统中的问题总是周而复始的重复出现。在第二家公司，我们为此建立了整个流程和支持工具，如下图，效果真是谁用谁知道！
2002年左右，亚马逊进行了其最为知名的一次组织和架构的调整。经过此次调整，亚马逊在系统架构上从直接共享数据访问的单体应用逐步调整到基于服务的SOA结构，在组织上则逐步转变到以小团队为基础的。【注20】这种小团队就是我们常说的2 Pizza Team，关于2 Pizza Team的来源，可以参考Fast
Company写的，这里摘录如下。
网上有关2 Pizza Team的文章很多，对其好处分析的比较详细，我们在这里不再多费键盘。从结果上看，小团队还带来了其它两方面的好处：
其一，当业务系统按功能（或具体业务）分配到2 Pizza Team时，其所能处理的问题规模和复杂性将是有限的，同样的，团队所要面对的架构问题的规模和复杂性也就相应的降低了——这正是探讨人人都能做架构时，我们说的通过团队划分来降低问题规模。
其二，当人数变少后，官僚主义就很难发展起来，整个团队更容易形成积极、自治的氛围。这也不难理解，在一个结果导向的角斗士文化氛围中，如果有人混或搞权谋的话，团队就很有团灭的风险——不管你是不是自认为做了正确的事情。
以下是来自网络的一幅图，大致描述了亚马逊转变后的组织结构。
在这种组织结构下，亚马逊按业务线对组织进行垂直划分，而技术通常在业务线内，如下图【注21】。业务线进一步划分常常，而技术团队通常会负责全球支持，因此，技术团队的进一步划分通常会根据业务的需要按业务或者按系统。业务与技术的汇总一般发生在VP层，有时会在Director层。另外值得一提的是，2
Pizza团队的原则适用于组织层级中任何部分，如果某个Director直属人员过多就会进一步拆分，当然也会有特例。
这样的划分使技术团队能够专注解决对应业务的问题，或者说这是业务驱动技术在组织结构上的体现（或者说业务优先）。由于此时团队规模通常在7+/-2人，所以一般不会有特别复杂的工作，而有关业务的设计决策将在团队内部消化。这样划分的另一个好处是技术人员，尤其是技术团队的领导，会对业务非常熟悉，因此，一些业务团队的高层领导（Director和VP）都是从技术线上去的！
但一个具有挑战性的结果是团队增多，一个业务性的需求可能需要不同的团队配合才能发挥作用，此时团队的协调将是一个问题。亚马逊是通过计划流程（Operation Planning）来帮助团队在战略性层面解决工作安排的问题，我们随后讨论。现在，我们先看看技术团队和业务团队要如何合作？
如上图，技术团队和业务团队的合作并非经由上层协调，双方主要的沟通都是团队之间直接的水平的沟通，也就是说，在基层，需求、问题和日常交流都是由业务团队直接反馈给技术团队的负责人。另外，在各个层面上都会有对等的水平沟通，向上的汇报机制主要用来反馈问题或者汇报业务进展情况。
让我们看看需求提报后会的处理方式，如下图。需求提报上来后，通常是接收方（团队）来识别所依赖的外部系统，但这个工作会涉及很多沟通和对高层视图（尤其是业务过程）的了解。有时，业务人员可以帮助技术团队识别被依赖的业务团队，有时，技术团队可以将这部分工作交给TPM，但更多的时候，需要负责的技术人员自己搞定。依赖一旦被识别出来，技术团队将发挥完全的Ownership，与相关技术团队合作，推动功能最终实现。
无论是团队层面还是公司层面，产品和功能要进入开发前必须回答下面这些问题：
从业务的角度看，产品计划的一些工作需要指明前进的方向，在项目启动阶段，亚马逊的研发经理或者业务经理会承担一部分产品的职责，他们会通过新闻稿的形式来尝试回答这些问题。有关新闻稿的更多信息，可以参考Chris Vander Mey的。
团队拆分后，业务性的需求可能需要不同的团队配合才能发挥作用。计划的过程中一个重要的工作就是识别出依赖团队，并将自己的需求加入到依赖团队的计划中。亚马逊使用的方法是Operation Planning。这个Operation
Planning一年要进行两次，年初2月份左右一次，这是OP1；年中8月份来一次，对OP1做整理检查同时增补一些新的需求，这是OP2。制定OP的过程，整个亚马逊的团队——从业务到技术都会动起来，将业务要做的事情、技术想做的创新和技术要填的坑都提出来，尤其是需要其它团队配合的事情，要提到对方团队的OP中。这些集中在一起的需求经过研发和业务的商讨细化、确定定优先级和评估工作量后，排出一个大计划。这个计划再按各自汇报线（业务和研发有各自的OP）向上汇总，逐级PK，最后汇总到姐夫那里。如下图，是OP1计划的一个示例，图中文字故意模糊。值得注意的是，这个计划中包含了优先级、工作量估计、外部团队依赖、初步业务价值的判断、预计的交付时间等信息。计划表上部的小表格会自动计算出完成各优先级项目累计需要人员的数量情况，并与当前人员数量对比，为接下来人员招聘的数量提供一个初步的建议。
在实际执行OP1和OP2的过程中，业务团队仍然会有临时需求，甚至是自上而下来自Bezos的需求。这些需求（除了Bezos的）都会由业务和技术团队沟通，并依据其业务价值来与OP上的需求进行比较，进行计划的调整。
亚马逊的计划过程并不适合创业公司，但具有启发意义：
我们已经谈及通过组织结构层面的调整来简化架构的复杂性，也了解了通过工具和服务封装支持性架构和开发运维工作来降低研发工作的复杂性，接下来我们看看架构工作是如何在研发人员之间分配的。
SDE的职级、责任，以及其它角色
亚马逊有一个内部文档，其详细地列出SDE1到Senior
Principal各级的软技能和硬技能的要求，以及从一个级别到更高一个级别要做的事情，以便研发人员自行对照修炼。如下图，我们简单地分析了各个级别所属团队、共享情况、职责和影响力。由于亚马逊没有专门的架构师团队，而且亚马逊期望所有人都能进行架构工作，因此，越高级的技术人员就需要尽可能在这方面发挥更大的作用，可以说能力越大，责任越大。虽然SDE3以上的研发人员需要隶属于某个业务部门，但他们已经是某种程度的共享资源，其工作安排的顺序是从部门内到部门外。虽然其工作重心可能不再是专门实现小团队量级的业务需求，但其依然会参与其中，尤其是在关键项目的攻坚上。对于Principal，他们常常会做一些前沿性的探索和开发工作，比如，AWS上无比好用的SWF（Simple
对于SDE3以上的技术人员，公司层面会有一些附加性的职责，如设计评审、辅导新人和传播理念。就Principle而言，亚马逊有一个称为Principle Talk的定期分享，Principle会被要求讲一下他目前从事的工作中的一些新的技术和想法。
对于设计评审，现有功能的扩充通常不需要进行设计评审，新功能的设计评审通常在团队内部完成。当涉及的业务影响比较大或者技术上有一定的挑战时，团队经理会在本部门内（通常是沿组织结构向上）寻找高级别的技术人员对设计进行评审，偶然也会跨部门找某些领域的专家来进行评审。虽然偶尔需要刷脸或者需要更高层面的管理者介入协调，但研发人员通常是比较热心的——一封言辞真切的邮件就足够了，再者，作为亚马逊人，在Ownership的名义下臭不要脸是必须的！
Manager），亚马逊对SDM和TPM有技术性要求，也就是说，他们需要懂编程和设计，所以，当你在亚马逊办公室漫游时，看到一个SDM抱着一堆AWS产品的技术说明文档啃，这是一点都不奇怪的，因为他们要上云了。
Manager——可以帮助团队识别被依赖的团队，甚至和这些团队确定接口细节，以及推进项目前进。
PM就是我们常说的业务人员，这些人常常可以自己根据需求画出产品原型……
架构工作的一项内容就是对不同解决方案的进行选择。这种选择即可能涉及业务层面，也可能涉及技术层面。系统的架构更多是技术层面上的选择。不难理解，技术层面的某些问题具通用解决方法，相对应的，这些方案就成为一些固定的（或推荐的）选择，如下图所示，这些方案在专制水域。经验告诉我们，专制带来效率上的优势，但同时抑制了创新。那么，在一个公司内，如何让这样的选择简单高效，但又不会抑制创新？
在公司范围内，亚马逊对一些关键的技术架构做了强制或推荐，比如，RPC必须用Coral，定时任务应该用DJS（Distributed Job Scheduler），工作流推荐用SWF，消息中间件推荐SQS等等。有时，同样的问题可能会有多个框架在专制水域，它们各自可能对某些特定情况有更好的表现。
相对应的，在各团队内部，其系统所用的语言、框架都可以自行确定，甚至对重新发明轮子也会足够宽容。但如果系统的影响较大，而且使用了非推荐的技术，那么在设计评审时就必须用证据来说服参与的人员，尤其是那些高级别的SDE——他们经常会问为什么不用某某已有的技术。某些情况下，当某个团队的某项工作被证明有更为广泛的影响时，这些工作会从民主水域上升到专注水域，成为公司范围内的推荐解决方案，比如，SWF最初只是一个Java的库，后来在业务中被证明可以极大地简化开发工作，其不但成为AWS上的服务，还成为公司内工作流推荐解决方案。
如前所述，软件的开发过程就是一个学习的过程。每一天，会有大量的问题产生，每一天，会有大量的知识累积。利用好这些知识将会极大地节省后来者的时间。比如，亚马逊会将历史上遇到的问题做成视频供大家观摩学习。
亚马逊一直重视知识的积累和共享工作。这里我们简单地介绍一下：
-
WIKI：这是整个知识系统的核心，所有和业务、系统、流程有关的信息都按某种固定的格式书写下来，方便阅读和分享。
-
邮件列表：亚马逊的邮件列表是一个开放服务，每个人都可以创建，一些固定的邮件列表用来在公司范围内寻求帮助，比如Linux，Java等等。
-
SAGA：一个类似StackOverFlow的内部问答社区，用来替代邮件列表的问答功能。
-
Broadcase：一个类似Youtube是内部视频分享网站，这里可以查到所有Bezos的内部讲话、Principal Talk，或者是某些系统的培训。
-
Community：亚马逊内部的技术社区，维护了内部的一些开源项目和讨论。
-
Amazon Patterns：UI设计的规范，各个产品线可以给出自己的规范和使用指南。
-
Issues：一些业务性问题的跟进工具，也可以做类Scrum的项目管理工具，其用来取代JIRA和一部分Ticket系统的能力。
由这些工具还可以看出亚马逊对代码的态度，除了某些关键性项目，亚马逊并不限制员工查阅和学习其它团队的代码。从某种意义上看，亚马逊对数据的态度则更为严格，曾有浏览核心数据直接走人的先例。
另一点就是，支持性工具始终处于不断演化的状态——内部支持性系统和工具也是这样，随着规模扩展，更高效和易用的工具会被创建以便提升研发人员的效率，比如Simple Search，在12年左右推出，可以同时搜索亚马逊内部3个主要的知识库。
最后，亚马逊无论业务和是研发，其对工具和自动化有着与生俱来的痴迷。根据不完全统计，其内部用于研发和管理的工具总计有近50个，这些工具多数是自研的，而且多数都在日常工作中使用。
至此，与研发效率直接相关的方面大致都已涉及，接下来我们聊聊亚马逊内部一些有趣的事情，他们有些间接地影响了研发效率。
在2008年2月的全员大会上，Bezos分享了这个想法。这中间最有趣是，Bezos谈到他和亚马逊客服团队参考丰田TPS中的安灯拉绳创建了客服安灯拉绳的故事。这个故事的细节在前同事张思宏的中有详细的描述，强烈建议大家学习一下，由于篇幅，我这里就不再赘述。
这个故事给我们的另一些启发是：作为公司高层的Bezos对效率的持续关注和对新知识的了解。就我的了解，亚马逊在2008年之前已经实践过ToC和Lean，而且是得到老板亲自关注的，这就是我常常调侃的——你们公司效率低是因为你们老板效率低。另一点就是亚马逊那种面向问题解决问题的文化，在这种文化下，亚马逊很少谈论概念。
在亚马逊工具研发中——对内和对外，自服务和平台化的特点是其重点关注的特点，这方面John Rossman在《The Amazon Way》的附录中有两篇文章涉及，建议读者朋友研究一下，下面摘录了其中Bezos对自服务的看法。
亚马逊的研发有什么特点呢？
行文仓促，还有一些话题没有涉及，有一些也没有深入，如绩效评价OLR和Dog Fight、Engineering Excellence、工具链等等，期望未来可以更深入的思考和总结。
亚马逊有一个内部宣传标语：“Work Hard，Have Fun，Make History！”。我们常常调侃说只需要Work Hard，其它两条可以忘记。但离开亚马逊两年后，却发现亚马逊对自己的历练和改变如此巨大……，最后，以《The Everything Store》中的Bezos的话纪念我和一帮前同事在亚马逊的日子：
你可以超时工作、勤奋工作、动脑工作，但在亚马逊，你不能三选二。
注2：Bezos和Jobs都是臭名昭著的坏老板，属于经常咆哮（yelling）和羞辱下属的人，请从以下金句中领会[3]：
注4： 复杂的商业系统背后，其本质往往是简单的，只有骗局才故作高深并且无比复杂；与之类似，研发体系的整个基石梳理到最后往往也很简单。这里所谓的复杂是指complex，比如，供应商入驻过程会涉及十几个系统的对接，其过程可以说非常繁杂（complicated），但其原理却并不复杂（complex）。
注5：所有的公司都有企业文化，最不济也是老板文化！
注6：不要以信众的数量来评判一些互联网大V言论的正确性，因为萧伯纳说过，“瓜怂虽傻，但还有更傻的‘瓜怂’为其喝彩！”
注7：这也提醒我们独立思考的重要性，尽信书不如无书！
注8：国内有个定期刷屏的类似理念——人品比能力更重要。
注10：幻想狂刘先生这篇让人从侧面看到语言对组织的一些另类影响力。
注11：国内的互联网媒体上经常刷屏的一个流行词就是不忘初心，我觉得Bezos在行动上算是这方面的典范，每年的致股东的公开信都要附上1997年的股东公开信。国内马云也是有心人，你今天都能看到当年马校长推销中国黄页的视频。各位，买好录音笔和摄像机，用得上！
注12：调侃一下我的另一个前东家，自12年某个平台将其评为最难的面试公司之一后，其后每年的市场文章都会时不时的拿这个出来撩拨一下。
注13：面试官在完成自己的反馈之前是无法看到其他人的反馈情况的，这样做避免了面试官之间相互影响判断。
注14：我之前在内部分享中有看到将SDE称为System Development Engineer，其实我觉得这个定位似乎更为准确。
注15：在互联网高速发展的大背景下，一切都需要快起来。国内有两个类似的理念，一个是互联网唯快不破，另一个是这两年流行起来的搞定，这个搞定其实就是问题解决的能力、责任感与执行力的结合。
注16：我第二喜欢的胖子，我技术上的精神导师……
注17：ABB代表如下系统：
现在整个工具链主体是ABCP，P代表了持续部署的Pipeline。有关亚马逊交付系统的信息可以参考一下，本文不会深入讲解这些系统的原理。
注18：由于亚马逊业务上的诉求更重要而且更频繁，相比较，高并发和稳定性这样的要求只有极少数面向大量用户的系统需要，如Retail网站，因此，Google的SRE制度是不可能从亚马逊这样的公司产生的，而且当Apollo和Coral这样的系统和工具就位后，大多数高并发和稳定性的问题的处理会变成简单的操作性问题。在资源维护的层面，亚马逊应该有类似Google
Borg这样的分布式资源调度系统，不过从应用开发和维护的角度看，在系统云化后，这种调度反映出来的服务就是ASG（Auto Scaling Group），至于资源的切换和物理机的管理，对SDE则是完全透明的！
注19：亚马逊内部的在线报障被分成1-5级，数字越小问题越严重，只有Serv1和Serv2的问题才会通知Oncall人员并要求快速处理。如果不巧你没有在指定的时间响应，那么Serv1的问题会通知Bezos，而Serv2的问题则会一路上报到VP，恭喜你，这个时候整个世界都在找你，即便你的经理找到人解决，你还是要复制之后的跟进和事后问题分析，当然你还要表达必要的歉意。1-4级的ticket都有对应的SLA，相应的绩效数据会被定期分析。
注20：传说中，2002年，Bezos给全公司发了一封信，吹响了整个架构演进的号角：
-
从今天起，所有的团队都要以服务接口的方式，提供数据和各种功能。
-
团队之间必须通过接口来通信。
-
不允许任何其他形式的互操作：不允许直接链接，不允许直接读其他团队的数据，不允许共享内存，不允许任何形式的后门。唯一许可的通信方式，就是通过网络调用服务。
-
具体的实现技术不做规定，HTTP、Corba、PubSub、自定义协议皆可。
-
所有的服务接口，必须从一开始就以可以公开作为设计导向，没有例外。这就是说，在设计接口的时候，就默认这个接口可以对外部人员开放，没有讨价还价的余地。
-
不遵守上面规定，就开除。
注21：这里会有看似的特例，比如负责内部支持性工具开发的组应该是隶属于Engineering Excellence的，但其实他们的业务就是服务内部开发。
注22：显然，亚马逊并不在意你的工作和生活的平衡，它只是尊重你的想法和工作成果，当然一切看结果。
