太原做网站费用,为什么一个网站做中英文双语版,网页设计属于什么行业类别,wordpress 首页文章摘要内容来源#xff1a;DevOps案例深度研究 –Amazon持续交付之道战队#xff08;本文只展示部分PPT及研究成果#xff0c;更多细节请关注案例分享会#xff0c;及本公众号。#xff09;本案例内容贡献者#xff1a;单冰 (Topic Leader)、 赵栋、梁兴龙、李杰、毛艳清、牛恒… 内容来源DevOps案例深度研究 –Amazon持续交付之道战队本文只展示部分PPT及研究成果更多细节请关注案例分享会及本公众号。本案例内容贡献者单冰 (Topic Leader)、 赵栋、梁兴龙、李杰、毛艳清、牛恒本次案例解读王立杰图片来源于网络上一篇文章《DevOps案例研究|史上最能“拜客户教”的公司是如何做到持续交付的第1趴》通过介绍Amazon实行DevOps的背景为大家解答了为啥Amazon被称为史上最“拜客户教”的公司以及它如何在这种理念指导之下通过DevOps提升研发效能从而支持业务增长。注整个案例研究分成如下几个部分本文为该系列文章的第二篇后续内容会在本公众号持续发布请大家关注“DevOps”公众号避免错过后面的精彩内容。了解了实行DevOps的背景那么Amazon这家史上最能“拜客户教”的公司具体是如何做到持续交付的呢本文将为大家拆解Amazon持续交付的具体实践。Amazon的DevOps也是端到端的闭环过程即先有构建Build-测试Test-发布Release的交付流水线再从客户经历监控Monitor-下次计划(Plan)的反馈闭环。在整个打造闭环的过程中Amazon一共经历了四个方面的变革。一、组织变革1.1 “两个披萨”团队任何时候、任何大的变革都需要先从“人”的层面进行。这涉及到组织文化的重构、组织价值观与行为的梳理。Amazon也不例外。Amazon的“两个披萨”团队在业界流传已久“两个披萨”团队是指在Amazon内部划分团队的规则购买两个最大号的披萨如果能够让你的团队吃饱那就可以保留这么多人如果不能吃饱说明你的团队人数太多需要拆分。这个说法其实也是在提倡敏捷小团队典型的敏捷团队是5-9人也差不多两个披萨可以吃饱。1.2 一流的人才团队组建成功要想充分激发起团队的主动性、能动性必然离不开授权与激励因此Amazon提倡充分授权即“完全所有权完全问责制一致的激励措施”一句话概括就是权责利的奖罚分明。当然开发与运维的协同必不可少毕竟这是狭义DevOps的基本范畴。这里需要强调一点Amazon对人才的要求极高。贝索斯认为雇佣最优秀和最聪明的员工是公司走向成功的保证。Amazon一直坚持招人的高标准坚决不会为了满足各业务部门的人力资源需求而放低招聘标准。每次招募员工时无论男性还是女性都要求一个比一个水平高只有这样才能使整个人才储备的标准提高。随着Amazon的不断壮大贝索斯对员工的要求更高了并在会上不断重申要求员工要用心工作、努力工作和超时工作。同时贝索斯不能容忍愚蠢的行为即使是偶尔为之也无法容忍。2009年2月Kindle2发售前夜的大会彩排现场由于出现了一些计算失误贝索斯怒斥了通讯部门的员工“我不知道你们是不是没有用高标准要求自己还是你们只是不知道自己在做什么。”在这样的高标准要求之下那些不满以及不适合Amazon的员工都被贝索斯坚定地解雇了取而代之的是拥有新观念和更多经验的人。当然留下来的老员工都得到了丰厚的回报。1.3 充分授权有了一流的人才还需要对员工充分授权。为了强化沃尔玛创始人山姆-沃尔顿“崇尚行动”的理念贝索斯创造出了“放手去做”just do it这一奖项Amazon非常支持员工发挥主动精神去取得显著业绩尤其是在其主要工作职责之外取得的成绩并认为即使员工因此出现了很大的失误也应该获得褒奖因为他们承担了很大的风险并在此过程中展现了足智多谋的一面。另外贝索斯认为等级制度对变化不利他在会议和演讲上表示要把Amazon的经营重点放在权力下放和独立决策上并且一以贯之地执行。二、架构变革2.1 变革背景在2001年Amazon网站仍然是一个大的单体应用由数百万行C代码组成。几千个开发者同时开发一个大的版本开发完成再由一个工程师团队手工进行应用上线。如下图所示很明显这种单体架构的开发效率之低和协作成本之高可想而知。所有人修改的代码都是一个应用代码代码冲突不断。 构建时间长任何小修改都必须重新构建整个项目这个过程往往很长。 稳定性问题一个小问题都可能导致整个应用挂掉。 代码高度耦合新人的学习成本太高不容易融入团队。 不易扩展无法满足高并发的业务需求在必须规模化时很快达到其极限。这样的单体架构已经严重影响到业务的增长。为了彻底解决这一问题贝索斯2002年发了一封信要求必须改变如果谁不改就开除谁。这个背景我们在上篇文章有提到点击复习?【DevOps案例研究|史上最能“拜客户教”的公司是如何做到持续交付的第1趴】。这个突破口就是“架构变革”整个网站需要从单体应用转变为面向服务的架构也就是SOA。每个服务只需要单一用途让每个开发团队都可处理一个独立的可交付的代码单元要简单不要复杂各个业务的组成都是通过API实现连接和数据交换从而实现去耦合。2.2 变革成效在完成这样的架构变革后收效显著1) 发布效率提升在Amazon初始架构中任何一个bug修复都需要更改应用程序中某些C 单个修复完还要等待其他人完成对应用程序其他模块的更改并对整个应用程序进行测试之后才能发布。切换到微服务体系架构后开发团队可以只对其负责的微服务进行更改可以独立发布只要保证质量即可。2) 错误隔离在微服务体系架构中每个团队都在独立的代码基础上工作不仅团队间的代码冲突减少而且错误被隔离到单个微服务中。3) 技术多样性以前所有的代码都是C代码整体开发团队被限制在一个通用的技术堆栈和过程中。采用微服务后允许独立的团队为给定的服务选择正确的流程和技术采用Java或者Python等框架都可以。这样就可以吸引更多有才华的工程师让他们采用各种新技术。4) 新人融入快新工程师可以安全地在一个小型的微服务上进行编码。对于一个工程师来说没有必要仅仅为了修复一个bug而去学习一大堆代码库学习曲线降低。5) 团队拥有更大的自主权采用微服务的最大变化可能是文化。为了提高敏捷性和效率微服务开发团队做出以前无法控制的决策比如发布日期、质量策略。这一点跟前面的组织变革正好相辅相成。三、工具变革3.1 APOLLO一个云应用程序可能拥有数百个单独的微服务每个微服务可能由多个实例组成(为了可用性和可伸缩性)这就带来微服务规模的增长而每个微服务将由各自的开发团队独立更新。快速增长的微服务数量和更新的频率要求一个完全自动化的部署工作流程和基础设施。Amazon内部的APOLLO工具在这种场景下应运而生。APOLLO主要对环境进行管理比如某一个服务上线需要用到哪些package group、依赖有哪些、参数要设置哪些、机器要多少台等。按最小的服务单元每次也会涉及到在几十台主机上做部署。APOLLO可以自动化整个部署工作流程这也是目前大多数类似工具的通用功能。从代码到客户的全自动化。通常一旦开发人员将代码提交源代码库就会有一个按钮流程自动获取最新的源代码并将其打包到部署工件中如容器然后将整个工件部署到准生产或生产环境中。这被称为持续交付。弹性缩放。微服务本质上是相当短暂的部署新版本、退出旧版本并根据利用率添加或删除新实例。Amazon采用的是Elastic Compute Cloud支持弹性扩展地部署基础设施。3.2 Build toolsAmazon崇尚每个人有更小更明确的任务“you build it, you run it.” 落到工具层面这主要得益于一个叫Build tools的组他们把Platform和Internal tools做到了功能性和易用性在业界内数一数二。这个组做的主要工具有5类 1Brazil Build对package进行分发和建立每次build至少涉及上百个package可以在几分钟甚至几十秒内完成build并保证不出错。2Apollo Deployment对环境进行管理比如某一个service上线需要用到哪些package group、依赖有哪些、参数要设置哪些、机器要多少台等。按最小的service单元每次也会涉及到在几十台host上做deployment。3Code base所有代码存放在中央代码库可以按reference、method、keyword之类搜索所有相关代码。4Monitoring System对service进行监控、告警、故障分析等。5Pipeline把build、test、deploy全部串起来对整个流程进行监控。大部分操作如rebuild、代码回滚、停止deploy一键操作就可以完成。Amazon的所有工具是全公司统一使用的更新及时且统一有一个非常大的组专门负责开发维护在Amazon随便一个开发通过Apollo只需一键就可以实现回滚。而大多数公司由于组织架构的原因各个组之间的代码不是互相可见的做这些工具也各自为战你做一套我做一套精力分散加上code/API等不透明导致online infra做得非常渣以至于想回滚一次得叫上PM、QA、Dev等人一起弄个大动作这也导致很多公司想做每日部署几乎不可能更别说分钟级部署了。 四、流程变革人都是不可靠的都会犯错误但机器不会只会忠实地执行。提高效率避免错误的关键就是要把一切能流程化的东西自动化。关于这部分就不多做赘述了。总结正是上述四大变革提升了Amazon公司的整体DevOps能力Amazon可以让一个Dev从功能的设计、开发、测试、发布、后续的监控由一个人完成。平均每十几秒就有一次发布每天发布好几千次让Amazon最终实现一年5000万次的部署。如果你对搭建流水线感兴趣想体验一下如何用工具实现真正的交付流水线体验从修改代码再到一键上线的快感体验如何从0到1打造一款产品建议你来我们的DevOps黑客马拉松识别文末图片中的二维码即可报名~号外号外如果你想跟“无敌哥-王立杰”老师微信交流请在公众号后台回复“无敌哥”您将会得到“无敌哥-王立杰”老师的微信二维码添加时注明理由。拓展阅读DevOps案例研究知人善任——Google敏捷核心文化DevOps案例研究进取到让自己毛骨悚然Netflix公司的简介和文化DevOps案例研究|史上最能“拜客户教”的公司是如何做到持续交付的第1趴DevOps案例研究庖丁解牛剖析Google持续交付之道历久弥新 - 微软万亿市值背后的文化支撑上|DevOps案例研究历久弥新 - 微软万亿市值背后的文化支撑下|DevOps案例研究DevOps黑客马拉松 9月7-8日 北京专业大咖陪你一起进化欢迎企业组队PK企业团队报名有特惠目前已经有两家企业组队赶紧报名吧~⬇️⬇️⬇️
