AWS 是如何做软件开发的 ？这里给你答案
软件在亚马逊是如何开发的？不妨看看对AWS开发者工具总经理Ken Exner的这段精彩专访。值得注意的是，Ken来自工具开发部门，因为行业的进步几乎总是离不开开发更好的工具。
专访的几大主题是分解、自动化以及围绕客户进行组织。
主要理念：
扩展就好比有丝分裂。团队分成一个个小组，每个小组全面拥有一项服务。EC2起初是一个两个披萨小组（two pizza team）。
上面这句话充分地体现了这三大主题，也是AWS在公共云市场常胜不衰的主要原因。自下而上，亚马逊根据客户意见，与时俱进地发展整个组织。
AWS正在蚕食世界，因为客户不断要求品种更齐全的产品和服务。
下面是这次专访的主要内容：
亚马逊喜欢分解。亚马逊过去拥有整体式组织和软件架构（Perl/Mason/ C++）。他们将整体式系统分解为一项项服务，将组织分解为一个个两个披萨小组。小组是独立自主式的，拥有所有权。每个小组全面拥有一项服务。它们处理客户、开发、测试和支持等。
亚马逊喜欢自动化。使一切都实现自动化。亚马逊的首批工具使构建和发布过程实现自动化，然后使部署实现自动化。最初，提交的变更自动进入到生产环境让人害怕，但你可以手动执行的任何操作都能实现自动化，所以确保每次都一样。作为每个部署的一部分，亚马逊会进行几种不同的测试。先是集成测试，然后是基于浏览器和Web的测试，最后是负载测试。他们监控和衡量一切。他们发现能够更频繁地发布变更，而且质量更高。他们可以更频繁地发布更好的代码。
部署是个悲观的过程，他们不断试图找到在预生产环境或生产环境中部署失败的原因。在生产环境中，他们部署到一个可用区（AZ）中的一个设备。部署遇到问题？回滚。部署成功？部署到该AZ，然后部署到更多的AZ，最后部署到更多的区域。如果发现问题，就回滚到已知良好的状态。
在整个过程中妥善做好安全。开发人员需要像安全工程师那样思考问题。这是亚马逊文化的一部分。工程师需要是开发人员、运维人员、架构师、测试人员和安全专家。亚马逊教开发人员这些技能。Robert A. Heinlein会很自豪。DevOps也是DevSecsOps（开发安全运维），其使命就是将安全纳入到整个过程中。
开始一个新项目时，开发人员首先要做的是架构和威胁模型。威胁模型由安全工程师来审核。开发人员做好自己的安全，因为他们最靠近问题，所以他们最有可能发现问题。然后开始开发工作。代码提交以便审核。提交之前，同事给予反馈。执行静态分析。然后代码进入到构建环节，这个环节也有静态分析。之后进入到发布管道，这个环节有更多的检查。代码发布之前，金丝雀版本监控人员对部署执行正负面检查。
通过结合本地执行的策略和全局执行的策略，将检查机制融入到整条管道中。如果你可以检查管道，就可以确定它是否遵循最佳实践。如果你可以描述最佳实践，别人可以创建规则，以便管理管道的形状、结构和内容。作为组织领导者，你可以为你的小组制定规则，比如每次新提交在部署之前必须达到70%的单元测试代码覆盖率。一些面向整个AWS的规则适用于每个部署，比如你无法同时部署到每个区域。这是糟糕的做法，可以用规则来终止。可以在小组层面、组织层面和公司层面运用规则。这种检查能力确保人们无法做糟糕的事情。管道内置了多年积累下来的最佳实践。开发人员没必要犯错误、汲取深刻的教训。通过自动化，你可以确保每次都遵循流程。
小组中的开发人员负责架构，架构并不来自架构师。一旦他们有了架构，就由架构师或首席工程师来审核。首席工程师的角色是审核和教授，而不是搭建架构。安全也一样。安全工程师的角色不是创建威胁模型（那是小组中开发人员的职责），而是负责审核威胁模型。测试也一样。一个小组拥有整个过程。教授方面花很多时间，因为你希望开发人员从中学会。
预计亚马逊的领导者对重要事项进行建模。运维在亚马逊很重要，因为领导者在运维上花很多的时间。对于要认真对待的事情，领导者必须认真对待。比如说，每个小组必须能够在每周运维会议上展示仪表板，必须能够解释每个要点。
最佳的计划方式是自下而上。最靠近产品的小组最靠近客户。他们知道客户想要什么。离客户最近的人应告诉亚马逊该做什么。每年都有两个文档OP1和OP2（运维计划）。每个组织部门都写一份6页长的文档，阐明明年想要做什么。在该计划中，你阐明如果资源不变和递增，你会做什么。这种6页长的业务计划在组织的每个层级予以介绍。经理们从他们管理的所有小组搜集这6页长的文档，制作自己的6页长的文档，并拿给管理层过目。这一路上报到贝索斯。然后资源下拨到一个个小组。
管理层对不同的请求作出公断并予以判断。想法仍来自最靠近客户的小组。
小组也有目标，它们被分配了实现这些目标的资源，这些目标得到追踪。小组好比是初创公司，而管理层充当董事会，审核目标和度量指标，以此管理不同的初创公司。
小组可能有专业人员。他们可能拥有不同的技能，比如Web开发、软件工程、项目管理、文档撰写和市场营销等。
沟通和一致性可能很难，因为小组是各自分开的。亚马逊常常最终有两套东西，不过有两套东西胜过一套都没有。这是可以接受的风险，事后可以解决。最好不要减慢速度。重构小组解决了一致性问题。创建另一个小组和另一个服务来处理责任问题。
你如何说服另一个小组做你需要他们做的事情？你必须有说服力。全局性计划在年度计划过程中自上而下推动。比如说，如果他们要进入一个新的区域，小组必须为此做好计划。
