首页 > 资讯 > 行业资讯 > 正文

亚马逊是如何进行软件开发的?
2019-05-15 10:05:29阅读:1863次

关键思路:

通过细胞分裂的方式来实现规模增长。团队以单个服务为单位分解成更小的团队。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 的讨论思路,很多来自亚马逊的员工也同意我这个观点。

微信客服
工作时间
周一至周五 9:00-18:00
工作时间咨询电话
13007777180
节假日咨询电话
13109769892
我们的地址
青海·西宁市海湖新区万达中心一号写字楼29楼
微信客服
我们的联络邮箱
642430621@qq.com
Copyright 2008-2027 青海巨人网络科技有限公司 ALL Rights Reserved. 青公安网备案:63010502000106 工信部备案号:青ICP备17001736号-1 青海·西宁市海湖新区万达中心一号写字楼29楼