亚马逊是如何进行软件开发的呢？如果你确实对这个话题感兴趣，不妨邀请三五好友，订上几个披萨，然后一起坐下来观看这个对 Ken Exner 的精彩访问，他是 AWS 开发者工具部的部门经理。这里着重强调 Ken 来自工具部，是因为毕竟每一个行业的进步都需要更好的开发工具。

本访问强调了三个关键主题：细化团队、自动化和以客户为导向。

关键思路:

通过细胞分裂的方式来实现规模增长。团队以单个服务为单位分解成更小的团队。EC2 一开始也只不过是七八个人的小团队。

上述引文很好地体现了这三个主题，实际上，它也是 AWS 能够笑傲公共云市场的关键因素。亚马逊根据客户需求，从开发底层不断分拆出新的团队，从而增长了其自身规模。

如果你想要参考一个实例，不妨收听一下重型网络 433：深入 AWS 中转网关。这个讲座详细介绍了一个复杂的 AWS 功能（中转网关）是如何从客户需求发展而来的。

随着顾客需求的不断增大，AWS 也在不断推出更多的产品，不知不觉 AWS 已经走在了公共云行业的前列。

下面是整个采访的一些总结：

• 亚马逊喜欢细化团队。过去亚马逊内部只有一个统一的组织和软件架构 (perl/mason/c++)，但随着规模的扩大这个模式很难再发挥作用，于是他们将这个架构按照单独服务的形式进行了重构，整个组织也全部分拆成了小于十人的小团队。团队本身是完全独立的，他们提供一个端到端的服务，并且负责所有服务相关的工作：与客户接触、开发、测试以及后续的技术支持等。
• 亚马逊钟爱自动化。亚马逊开发部门几乎自动化了所有事情：构建、发布以及部署。每一次提交的变更都自动推送到生产环境，这一开始很令大家担心，但其实无非就是把手工做的工作自动化了而已，使其每次都以相同的方式执行。为确保证生产环境正常进行，我们在自动化过程中增加了很多不同的测试：集成测试、基于浏览器和网络的测试以及负载测试等；我们也监测了自动化的整个过程。结果表明，通过自动化我们可以更频繁更及时地推出更新，从而可以做到更多的、质量更好的发布。
• 亚马逊实现了滚动式部署。部署一直是一个很打击人的事情，不论是预生产还是在生产部署，我们需要找出每一次失败的原因。对此，亚马逊内部实现了滚动式部署。首先将服务部署一个 AZ 中的一台机器上，如果部署失败，则回滚本次操作；部署成功，则部署到另一个 AZ，进而扩展到更多的 AZ，更多的地区；一旦发现问题，则回滚到前一个可正常工作的版本。
• 亚马逊推崇安全为先的开发模式。开发人员需要像安全工程师一样思考，这是亚马逊文化的一部分。工程师同时也必须是开发人员、操作人员、架构师、测试人员和安全专家，为此亚马逊为开发者提供了学习所有技能的机会。罗伯特·海莱应该很喜欢这种模式，毕竟他主张人类应该掌握尽可能多的技能。在亚马逊 DevOps 也称作 DevSecsOps，因为安全已经完全融入到了整个全栈开发流程。
• 开发人员需要为新项目架构和安全模型负责。安全模型由安全工程师进行审查。每个开发人员都需要负责自己代码的安全隐患，因为他们离问题最近，所以也最有可能发现问题；正式开发中，代码提交会被审查，同事在提交之前也需要静态分析并给予反馈；构建过程中，也存在自动静态分析；最终发布流程，会有更多的检查，也会有金丝雀监视器对部署进行全方位测试。
• 检查无处不在，整个生产环节处处都有检查。亚马逊为此制定了各种不同的政策。如果我们可以检查一个流程，那么我们就可以确定它是否遵循了最佳实践。而如果我们能够描述这个最佳实践，那大家就可以针对流程的方方面面制定规则。作为一个组织领导者，我们可以为团队制定规则，例如每个新提交必须达到 70% 的单元测试代码覆盖率才能部署。我们也有针对整个 AWS 部门的规则，例如不能同时部署到所有区域（特殊情况下可以，详情见相关信息）。我们需要使用规则来阻止那些错误的做法。规则在团队级别执行、也可以在部门或公司级别。这种检查能够避免大家犯一些常见的错误。亚马逊通过多年的实践经验积累，已经建立了一个非常有效的工作流程，避免了开发上的很多弯路，开发人员不必再走试错和汲取教训这一艰辛之路了。通过对这个最佳实践的自动化实现，亚马逊保证了每次都能最优地完成全部工作流程。
• 团队中的开发人员对架构负责，而不再由架构师来完成。一旦团队有了一个架构，就由架构师或首席工程师对其评估。首席工程师的职责是审查和培训，而不是设计架构。安全方面也是如此，安全工程师的角色不是设计安全模型，而是审查开发人员创建的安全模型。测试也是如此。亚马逊花费了很多时间在内部培训上，因为他们希望开发人员能够主导一切。
• 亚马逊需要领导者时刻做好表率作用。我们知道在亚马逊运营很重要，这是因为我们看到领导者的确很重视它。要想员工认真对待某件事情，领导者就必须先认真对待。例如，每个团队都必须在周会上展示他们当前的工作安排，每一个细节都需要给出解释。
• 最好的计划方式来自底层开发。直接开发产品的团队也最接近客户。他们知道客户的需求，因此应该由他们告诉亚马逊该做什么。亚马逊每年需要提交两个文档 OP1 和 OP2（即 Operating Plan 运营计划）。每个开发组都需要提交一份关于下一年计划的 6 页文档。在计划书中，团队需要列明所需要的常规资源和新增加资源，并注明资源用途。这 6 页商业计划书将会自下而上呈现给公司各级组织。经理们会从所有团队计划书中归纳出一份新的 6 页文档，并上报给他们的管理层。最终报告会一直上交到贝佐斯手中（CEO），在做出最终决策后，资源下发给各个团队。
• 管理层需要发挥监督作用。尽管最接近客户的团队往往能够提供最好的创意，但这些创意需要管理层的仲裁和判断。
• 每个团队都有目标考核。公司会根据团队计划分配相应资源，整个过程会被跟踪管理。每个团队都被认为是一个创业公司，而管理层则是董事会，他们通过审查和衡量目标进度来管理所有团队。
• 团队可以有专家。这些专家可以有不同的技能组合，像一个 Web 开发、SE（系统工程师）、PM（项目管理）、文档编写者甚至是营销人员。
• 每个团队都是独立的，这也增加了沟通和达成共识的难度。由于很难及时沟通，亚马逊通常会存在两个甚至多个相同的产品计划，但这总比没有计划要好，毕竟这仍在可控风险内，可以随后加以修正，但最好不要拖延计划执行。团队一致性上则通过内部重构来解决，公司会创建另一个团队和服务来处理这些额外的责任。
• 你可以说服任何一个团队去协助你的计划，前提是你能够说服他们。在年度规划过程中，公司性决策则是由上向下驱动。例如，如果公司要进入一个新的区域，每个团队必须为此做好计划。

当看到一个公司高层在解释其公司的软件开发流程时，我总觉得很奇怪。作为一个从业多年的个人开发者，我发现管理层其实并不需要知道工作是如何实现的。让我惊讶的是，根据下面 reddit 的讨论思路，很多来自亚马逊的员工也同意我这个观点。

相关信息

• Reddit
• 网站可靠工程师

Mjr00：需要更正一下，我们可以在一天内部署到所有地区，但这只限于尽快修复一个关键 bug 的情况，另外这也需要副总裁的批准，因此这只发生在极少数情况下。然而，真正有趣的不是修复 bug 而是修复后的事：你需要挖掘所有日志和数据来解释发生了什么、为什么发生、为什么没有被更早地检测到，以及如何确保以后不再发生等。然后你要准备一份报告，又被称为 " 错误更正 "（COE），如果够幸运，这份文件只会被你的主管审查和批准；但如果运气不好，你很有可能要在工程组会上把这份报告展示给 Charlie Bell 和 Andy Jassy，他们可是会把它撕成碎片的，更糟糕的是这一切会被所有参会人看到，甚至在网上直播。

英文原文地址：http://highscalability.com/blog/2019/3/4/how-is-software-developed-at-amazon.html