在前一篇博客中谈到了是上课学的是"上世纪"的软件工程思想,先买呢谈谈我推崇的软件工程思想----敏捷开发
为什么要敏捷开发
“没有人喜欢敏捷，但我们不得不敏捷。就像没有人喜欢工作，但你必须工作。”这是我经常用来调侃敏捷的一句话。
试想一下，拿到一份完整详尽的需求文档，逐个功能Coding，测试部署上线。不需要再次确认需求，不会有人打断思路。没有需求更改，只要自己不犯错，不存在推倒重来这才是大部分开发人员最舒服的工作方式吧，简直太完美了。但它很像瀑布，一点都不敏捷。
既然我们喜欢的工作方式是传统的、瀑布的，为什么要敏捷？这还不都是市场环境逼的。今天的市场向我们提出了三个问题：
1.如何做出真正满足用户需求的产品？
我不确定这世上是否有人可以做到，他所做出的全部决定都是对的。但绝大多数人是无法一次性做出真正满足用户需求的产品的。我们无法预测未来，我们必须通过一次次的测试，去寻找用户需要的产品是什么？想要更快地获得好的产品，必须迅速将产品推向市场，快速试验，避免走弯路。
2.如何满足不断变化的用户需求？
今天所有的事情的都在快速变化，用户的需求也在变化。毫不夸张地说，我们正在全力开发的一些功能，当它们上线的时候，我们的用户已经不再需要了。我们没有办法让一切不变，我们只能选择去拥抱变化。
3.如何同时满足不同层次用户的需求？
过去我们的产品会遵循产品生命周期，早期追求新奇的尝鲜者，中期普通大众，后期落后者。今天，产品的生命周期变化非常地快，我们可能会同时面对尝鲜者、普通大众、落后者，不同的用户类型的需求是不一样的，你如何满足他们？我们必须快速响应，没法快速响应，就没法留住用户，没有用户就没有一切。
迅速将产品推向市场，拥抱变化、快速响应。今天的市场向所有的从业者提出了一个要求：拥有应对快速变化的需求的软件开发能力。而敏捷就是赋予团队应对快速变化的需求的软件开发能力的方法，而这就是敏捷流行的原因。
什么是敏捷开发
敏捷绝非某一种特定的开发方法，它只是一种应对快速变化的需求的一种软件开发能力。敏捷本身只包含了《敏捷软件开发宣言》和《敏捷软件的十二条原则》两份文档。敏捷相信，只要符合这两份文档的开发方法，就能让开发团队拥有应对快速变化需求的能力，这样的开发方法都叫做敏捷开发方法。
最流行的敏捷开发方式是什么
敏捷开发的方法有很多：ASD、AUP、DSDM、XP、FDD、Kanban、RAD、Scrum。目前国内最流行的应属Scrum。
Scrum本意是指橄榄球运动中的“带球过人”，它可以解决非常复杂的项目，并且能高效并创造性地交付高价值的产品。Scrum包含3个角色、3个工件、5个价值观、5个事件（详情https://www.scrum.org/）。
相比其他敏捷方法，Scrum既不简单又不复杂。它有完善的指南，你可以按照指南，轻易在团队内推广尝试。但想要实践好Scrum，又需要很好的技巧。这种易上手难精通的方法，特别适合培训机构。所以近几年，关于Scrum的培训机构遍地都是。可以说，在Scrum流行这件事上，这些培训机构做了很大的贡献。
下面来谈谈Devops:
什么是DevOps
DevOps对不同的人来说有不同的意义。在深入思考这个主题之前，我认为明确DevOps对我的意义非常重要。
维基百科将DevOps定义为：
DevOps（区分开的“开发”与“运维”的复合体）是一种软件工程文化和实践，旨在统一软件开发（Dev）和软件运维（Ops）。DevOps运动的主要特点是在软件构建的所有步骤（从集成，测试，发布到部署和基础架构管理）中大力提倡自动化和监控。DevOps旨在缩短开发周期，增加部署频率和更可靠的版本，与业务目标紧密结合。
DevOps的定义对于我来说更狭义且稍有不同：
DevOps是开发人员负责在生产中全天候运维服务的实践。这包括使用共享基础架构原语进行开发，测试，待命，可靠性工程，灾难恢复，定义SLO，监控设置和告警，调试和性能分析，事件根本原因分析，准备和部署等。
维基百科与我对DevOps的定义（开发理念与运维策略）之间的区别很重要，这是我在个人的行业经验中得出的。DevOps“运动”的一部分是将前进缓慢的“遗留”企业引入现代高度自动化基础设施和开发实践，其中包括：松散耦合的服务，API和团队；持续集成；小型迭代部署；敏捷的沟通和规划；云原生弹性基础设施等等。
在我职业生涯的最后10年里，我曾在超快速发展的互联网公司工作过，包括AWS EC2，上市前的推特和Lyft。此外，由于创建和探讨Envoy的缘故，我花了两年时间与无数超速发展的互联网公司的技术架构和组织进行会面和交流。对于所有这些公司而言，拥抱自动化，敏捷开发/规划以及其他DevOps“最佳实践”是一个既定的因素，能很好地解释生产力的提高。相反，这些工程组织面临的挑战是如何平衡系统可靠性与业务增长，人员增长和竞争（业务和招聘）的极端压力。本文的其余部分均基于我的个人经验，可能并不适用于所有情况，尤其是那些习惯了每季度仅全量发布一次和正在被引入更快速和敏捷的开发实践的缓慢前进的企业。
运维互联网应用程序的简史
在我称之为现代互联网时代的过去大约三十年中，互联网应用程序的开发和运维已经经历了（在我看来）三个不同的阶段。
- 在第一阶段，互联网应用程序的构建和部署与“伸缩包装”软件的运输方式类似。三个不同的工作角色（开发，QA和运维）相互协作，经过很长的工程周期将应用程序从开发转移到生产。在此阶段，每个应用程序都部署在专用数据中心或托管设施中，这进一步需要熟悉特定站点网络，硬件和系统管理的操作人员。
- 在第二阶段，主要由亚马逊和谷歌在90年代末和00年代初带头，互联网应用程序在超高速发展的公司中开始采用类似于现代DevOps运动的做法（松散耦合的服务，敏捷开发和部署，自动化等等）。这些公司仍然运行私有的（大型）数据中心，但由于涉及的规模，他们开始开发集中式基础架构团队去解决所有服务所需的常见问题（网络，监控，部署，配置，数据存储，缓存，物理基础设施等）。然而亚马逊和谷歌从未完全统一开发工作角色（亚马逊称之系统工程师，谷歌称之网站可靠性工程师）以及认识到每个人所涉及的不同技能和兴趣。
- 在第三阶段或云原生阶段，互联网应用程序现在依赖托管弹性架构以从头开始构建，通常这由“三大”公有云服务商之一提供。尽可能快地将产品推向市场的主要原因一直是因为产品失败的可能性高，但是在云原生时代，“开箱即用”的基础技术允许一种比以前更加笨重的迭代速度。在这个时代开始的公司的另一个定义特征是避免聘用非软件工程师角色。可用的基础设施基础是如此相当强大，他们认为创业资金应更好地花在可以同时进行工程和运维（DevOps）的软件开发人员身上。
在第三阶段此类型公司不雇用专职运维人员的变化至关重要。虽然，很显然这样的公司不需要全职系统管理员来管理托管设施中的机器，但是之前从事这类工作的人通常也具备其他20％的技能，例如系统调试，性能分析，运维的直觉力等。新公司成立需要那些缺乏关键性、不易替换的技能的“劳动力”。
为什么DevOps适用于现代互联网初创公司？
DevOps，正如我所定义的那样（开发和运维各自服务的工程师），对于现代互联网初创公司来说效果非常好，原因有以下：
- 根据我的经验，成功的早期创业公司工程师是一个特殊的工程师。他们具有风险承受能力，学习速度极快，无论发生何种技术债务都能尽快完成工作，通常可以在多种系统和语言中工作，并且通常具有操作和系统管理的先前经验，或者愿意学习所需知识。简而言之，典型的创业工程师非常适合成为DevOps工程师，无论他们是否想这样子称呼自己。
- 如上所述，现代公有云为构建提供了令人难以置信的基础架构。过去的大多数基本操作任务都已自动化，剩余的底层足以发行最小的可行产品去验证是否有适合的产品市场。
- 我坚信，当开发人员被迫on-call并对他们编写的代码负责时，系统的质量将会提高。没有人喜欢经常被寻呼。这个反馈循环构建了一个更好的产品，正如我在（1）中所描述的那样，吸引到早期初创产品工作的工程师非常愿意学习和完成操作工作。鉴于对可靠性差的初创产品通常几乎没有反响，这一点尤为如此。可靠性需要足够好以使产品找到适合市场并进入超高速发展阶段。
当现代互联网初创公司经历过度增长时会发生什么？
事实是大多数创业公司都失败了。因此，任何花费大量时间在Google中创建基础架构的早期创业公司都是在浪费时间。我总是告诉人们坚持他们的单体架构，除了人力可扩展性问题（通信，规划，紧耦合等）需要向更加分离的架构迈进之外，不要担心任何其他问题。
那么当现代（第三阶段）互联网初创公司获得成功并进入高速增长时会发生什么？一些有趣的事情将同时开始发生：
- 人员增长率迅速增加，对通信和工程效率造成严重压力。我强烈推荐阅读The Mythical Man-Month（在最初出版近50年后仍然具有相关性），以获取有关此主题的更多信息。
- 上述几乎总是导致从单体架构向微服务架构转变，这是一种解耦开发团队并提高通信和工程效率的方法。
- 从单体到微服务架构的转变将系统基础架构的复杂性提高了几个数量级。网络，可观察性，部署，库管理，安全性以及以前不难解决的数百个其他问题，这些现在都是急需解决的主要问题。
- 与此同时，超高速发展意味着流量增长和由此产生的技术扩展问题，以及对完全失败和次要用户体验问题的更大影响。
核心基础设施团队
普遍大部分遵循早期创业特征，现代互联网超高速发展公司最终都以类似的方式构建其工程组织。这种通用组织结构由一个集中的基础架构团队组成，该团队支持一组实施DevOps的垂直产品团队。
核心基础架构团队如此普遍的原因在于，正如我上面所讨论的那样，超高速增长带来了一系列相关的变化，包括人员和底层技术，现实情况是，如果每个产品工程团队都必须单独解决有关网络，可观察性，部署，配置，缓存，数据存储等方面的常见问题的话，那先进的云原生技术就太难应用了。作为一个行业，我们与“Serverless”技术差距已有数十年，它足以完全支持高可靠，大规模和实时的互联网应用，且可以让整个工程组织可以在很大程度上关注业务逻辑。
因此，核心基础架构团队的诞生是为了解决大型工程组织的问题，而不仅仅是基于云原生基础架构原语存在的问题。显然，谷歌的基础设施团队比Lyft这样的公司的规模要大几个数量级，因为谷歌正在从数据中心层面开始解决基础问题，而Lyft依赖于大量公开可用的原语。但是，创建核心基础架构组织的根本原因在两种情况下都是相同的：抽象尽可能多的基础架构，以便应用程序/产品开发人员可以专注于业务逻辑。
（人员）可替代性的谬误
最后，我们得出了“可替代性”的概念，这是纯粹的DevOps模型失败的关键，当组织超出一定数量的工程师时。可替代性表示所有工程师都是平等的，他们都可以做所有事情。无论是作为一个明确的招聘目标（至少是亚马逊或许还有其他的公司），或者通过“训练营”的方式（明确表示在没有团队或角色的情况下）招聘工程师，可替代性已成为许多公司在过去10到15年间的现代工程的一个流行组成部分理念。什么原因导致这样？
- 正如我以上描述，现代云原生技术和大量抽象允许使用越来越复杂的基础设施来构建功能非常丰富的应用程序。自然而然，大多数公司将不再需要一些专业技能，如数据中心设计和运维。
- 在过去的15年中，业界一直专注于软件工程是所??有学科的根本。例如，微软淘汰了传统的QA工程师，并将其替换为软件测试工程师，其理念是手动QA效率不高，所有测试都应该自动化。同样，传统的运维角色已经被站点可靠性工程师或类似的所取代，其理念是手动操作效率不高，并且扩展的唯一方法是通过软件自动化。首先声明我是同意这些趋势的，自动化是一种更有效的扩展方式。
然而，正如许多新的互联网初创公司所做的那样，这种想法已经发挥到极致，导致只聘请全能型（全栈）工程师，期望这些（DevOps）工程师能够处理开发，QA和运维。
对于早期初创公司而言，可替代以及通用型人才招聘通常都很好。然而当超出一定的规模，所有工程师都可替代的想法就变得几近荒谬，原因如下：
- 通用型与专家。更复杂的应用程序和体系结构需要更多的专业技能才能成功，无论是前端，基础架构，客户端，操作，测试，数据科学等。这并不意味着全能型不再有用，或者全能型不能学会并成为专家，它只是意味着更大的工程组织需要不同类型的工程师才能取得成功。
- 所有工程师都不喜欢去做所有的事情。有些工程师喜欢做全栈。有些人喜欢专业化。有些人喜欢编写代码。有些人喜欢调试。有些喜欢UI。有些喜欢系统。一个支持各类型专家不断发展的工程组织必须解决这样一个事实，即员工的幸福感有时涉及某些具体类型的问题，而非其他。
- 所有工程师也不都擅长做所有事情。在我的整个职业生涯中，我遇到了很多很棒的人。某些人可以从IDE中的空文件开始，从头开始创建一个令人难以置信的系统。与此同时，这些人对如何运行可靠系统，如何调试它们，如何监控它们等等几乎没有直觉经验。相反，我一直在进行许多令人激动的访谈循环，其中一个真正令人难以置信的是运维工程师可以纯粹通过调试方面的专业知识和如何运行可靠系统的天生直觉，对整个组织产生巨大好处，但他们被拒绝仅是因为没有展示“足够的编码技能”。
具有讽刺意味的是像亚马逊和Facebook这样的组织也优先考虑软件工程角色的可替代性，但他们同样重视开发和运维之间的技能区分，继续为每个人提供不同的职业道路。
失败
纯DevOps如何以及在何种组织规模下失败？出了什么问题呢？
- 迁移到微服务。当一个工程组织达到约75人时，几乎可以肯定有一个核心基础设施团队开始开发构建产品团队构建微服务所需的基础通用功能。
- 纯粹的DevOps。与此同时，产品团队被告知要做DevOps。
- 可靠性顾问。在这种组织规模上，那些倾向于从事基础设施工作的工程师很可能是那些在该领域具有先前运维经验或良好直觉的工程师。这些工程师不可避免地成为事实上的SRE/生产工程师，并作为顾问来帮助组织内的其他成员，同时继续开发业务运行所需的基础架构。
- 缺乏教导。作为一个行业，我们现在希望雇用可以介入开发和运维互联网服务的人。然而，我们普遍在新员工以及执行这项任务所需的继续教育方面做得很糟糕。当我们从不教授技能时，我们怎能指望工程师具备操作直觉？
- 支持失败。随着工程组织招聘率的不断提高，核心基础架构团队不再能够在继续构建和运维对业务成功至关重要的基础架构的同时还要保持支持帮助产品团队完成运维任务。基础设施工程师在其现有工作量的基础上，作为组织范围的SRE顾问，承担双重责任。每个人都明白培训和文档是至关重要的，但是很少有人优先安排去完成这两件事的时间。
- 职业倦怠。更糟糕的是之前描述的情况造成了人员流失并降低了整个组织的士气。产品工程师觉得他们被要求做他们不想做或者没有被教过的事情。基础设施工程师在提供支持的重压下开始倦怠，虽然知道培训和文档迫切需要但却无法优先处理它，当同时在保持整个公司的现有系统以高可靠性运行。
在什么规模下工程技术组织里的某些环节会开始掉链子，因基础设施团队为支持纯粹的DevOps模型让组织开始出现人为扩展问题。我认为这个大小取决于当前公有云原生技术的成熟度，这篇文章说的是总共有几百名工程师这样子的规模。
“老方式”和DevOps方式之间是否存在中间立场？
对于成立已超过10年的公司，网站可靠性或生产工程模型已经很普遍。虽然各公司的实施情况各不相同，但我们的想法是聘请能够完全专注于可靠性工程而不受产品经理影响的工程师。但是有些实施细节非常相关，其中包括：
- 仅是SRE需时刻待命还是软件工程师也分担待命职责？
- SRE是否实施实际工程以及自动化，还是他们仅需要执行手动和重复性任务，例如部署，重复页面解析等？
- SRE是属于核心咨询机构还是嵌入到产品团队？
该实施计划的成功及其对整个工程组织的影响往往取决于上述问题的答案。但是，我坚信在一定规模的情况下，SRE模型是将工程组织扩展到许多工程师的唯一有效方式，超出了纯粹DevOps模型发生故障的程度。事实上，我认为在本文概述的人员扩展限制之前成功引导SRE计划是现代超高速发展型互联网公司的工程领导的关键责任。
什么是正确的SRE模型？
鉴于目前业内实施的案例过多，这个问题没有正确的答案，所有模型都存在问题。我将根据我过去十年的观察概述我认为的最佳点：
- 认识到运维和可靠性工程是一个独立且极具价值的技能组合。我们急于实现一切自动化以及软件工程师可互换的想法，使得与软件工程师同等价值的工程人员的一部分边缘化。运维工程师和软件工程师是合作伙伴，而不是可互换的齿轮。
- SRE不是随叫随到的，监控仪表面板或是只会部署的猴子。他们是专注于可靠性任务而非产品任务的软件工程师。理想的结构要求所有工程师会执行基本的运维任务，包括待命on-call，部署和监控等。我认为这非常重要，因为它有助于避免可靠性和软件工程师之间的类/工作分层，并使软件工程师更直接地对产品质量。
- SRE应该嵌入到产品团队中，而不是向产品团队工程经理报告。这允许SRE与他们的团队融合，获得相互信任，并且仍然具有适当的核查与平衡，以便在尝试权衡可靠性与功能时可以进行真正的对话。
- 嵌入式SRE的目标是通过实施面向可靠性的功能和自动化，指导和教育团队其他人员的运维最佳实践来提高产品的可靠性，并充当产品团队和基础架构团队之间的联络人（文档反馈，痛点，所需功能等）。
如上所述，在成长阶段早期实施的成功的SRE计划，以及对新员工和继续教育和文档的实际投资，可以提高整个工程组织的门槛，同时减轻之前描述的许多人员扩展问题。
结论
很少有公司能达到超快速发展阶段，那么这篇文章表达的能直接适用。对于许多公司而言，因为涉及的工程师数量，所需的系统可靠性以及业务所需的产品迭代率，基于现代云原生基元的纯DevOps模型可能完全足够。
适用于这篇文章的相对较少的那些公司，关键的要点是：
- 任何希望参与竞争的新技术公司都需要DevOps风格的敏捷开发和自动化。
- 公有云原生基元以及一个小型的核心基础架构团队可以允许工程组织在由于缺乏教导和角色特性而开始出现运维损失之前扩展到数百名工程师。
- 想要在可掌控的人员扩展问题上获得成功，需要对新员工和继续教育，文档以及嵌入式SRE团队的开发进行真正的投资，这些团队可以在产品团队和基础架构团队之间架起桥梁。
现代超高速发展的互联网公司（在我看来）存在极大的倦怠，这主要是由于严苛的产品需求以及对运维基础设施的投资不足。我认为领导层可以在组织的稳定性成为主要障碍之前先采取行动以逆转这一趋势。
虽然较新的公司可能会认为云原生自动化的进步正在使传统的运维工程师过时，但事实并非如此。在可预见的未来，即使在利用最新技术的同时，也应该认识和重视专门从事运维和可靠性的工程师，以提供任何其他方式无法获得的关键技能组合，并且他们这一重要角色应正式编入到早期发展阶段的工程组织中。
参考:
https://www.zhihu.com/question/19645396/answer/410025559
http://dockone.io/article/8189
原文地址：https://www.cnblogs.com/dingzihu/p/10181614.html