“DevOps”的人性化可扩展性

“ DevOps”的人性化可扩展性

正如我最近在 Twitter 上面写的那样，我最近花了相当多的时间思考“ DevOps”的人工可伸缩性(我在 DevOps 周围使用引 ，因为有各种各样的定义，我将在后面讨论。)我得出的结论是，虽然 DevOps 在小型工程组织中可以非常好地工作，但是如果不仔细考虑和管理，这种做法可能会导致相当多的人员/组织扩展问题。

什么是 DevOps

术语 DevOps 对不同的人有不同的含义。在我深入思考这个问题之前，我认为弄清楚 DevOps 对我来说意味着什么很重要。

维基百科将 DevOps 定义为:

DevOps (“ development”和“ operations”的简称)是一种软件工程文化和实践，旨在统一软件开发(Dev)和软件操作(Ops)。DevOps 运动的主要特点是在软件构建的所有阶段，从集成、测试、发布到部署和基础设施管理，都大力提倡自动化和监控。DevOps 的目标是缩短开发周期，增加部署频率，以及更可靠的发布，与业务目标紧密一致。

我使用了一个更加狭义和略有不同的 DevOps 定义:

DevOps 是开发人员在生产环境中负责运行他们的服务的实践，24/7。这包括使用共享基础设施原语的开发、测试、随叫随到、可靠度、灾难恢复、定义 SLOs、监控设置和 警、调试和性能分析、事故根本原因分析、配置和部署等。

维基百科的定义和我的定义(开发哲学和运营战略)之间的区别很重要，并且以我个人的行业经验为框架。60. DevOps”运动”的一部分是向缓慢移动的”遗留”企业介绍现代高度自动化的基础设施和开发做法的好处。这些包括: 松散耦合的服务、 api 和团队; 持续集成; 来自主人的小型迭代部署; 敏捷通信和计划; 本地弹性基础设施; 等等。

在我过去的10年职业生涯中，我曾经在高速增长的互联 公司工作过，包括 AWS EC2、 pre-IPO Twitter 和 Lyft。此外，主要是由于创建和谈论特使，我在过去两年中与无数高速增长的互联 公司的技术架构和组织结构进行了会晤和学习。对于所有这些公司来说，拥抱自动化、敏捷开发/计划和其他 DevOps“最佳实践”是一个必然，因为生产力的提高已经得到了充分的理解。相反，这些工程组织面临的挑战是如何在系统可靠性与业务增长、人员增长和竞争(业务和雇佣)的极端压力之间取得平衡。这篇文章的其余部分是基于我的个人经验，我认识到这可能不适用于所有情况，尤其是那些可能每季度部署一次单片软件并被诱导成更快速和敏捷的开发实践的传统企业。

互联 应用操作简史

在我称之为现代互联 时代的过去大约三十年里，互联 应用程序的开发和运行经历了(在我看来)三个不同的阶段。

1. 在第一阶段，互联 应用程序的构建和部署与“搜索封装”软件的发布方式类似。三个不同的工作角色(开发、质量保证和操作)将通过极其长的工程周期协作将应用程序从开发转移到生产。在这一阶段，每个应用程序都部署在一个专用的数据中心或托管设施中，进一步需要熟悉特定 络、硬件和系统管理的操作人员
2. 在第二阶段，主要由亚马逊(Amazon)和谷歌(Google)在90年代末和本世纪初牵头，高速增长的公司的互联 应用开始采用类似于现代 DevOps 运动的做法(松散耦合的服务、敏捷开发和部署、自动化等)。这些公司仍然运行着他们自己的(非常大的)数据中心，但是由于所涉及的规模，也可以开始开发集中的基础设施团队来解决所有服务( 络、监控、部署、供应、数据存储、缓存、物理基础设施等)所需的共同问题。然而，亚马逊和谷歌从未完全统一开发工作角色(亚马逊通过系统工程师和谷歌通过Site Reliability Engineer 现场可靠性工程师), recognizing the differing skills and interests involved in each. ) ，认识到不同的技能和兴趣所涉及的每个
3. 在第三个阶段，或者说本地云阶段，互联 应用程序现在是从头开始构建的，依赖于托管的弹性架构，通常由“三大”公共云之一提供。尽快将产品推向市场一直是首要目标，因为这样做很容易失败。然而在云计算本土时代，“开箱即用”的基础技术允许的迭代速度让之前的技术相形见绌。在这个时代开始的公司的其他拥有属性一直在避免雇佣非软件工程师的角色。可用的基础设施基础是如此强大，以至于他们认为——我会正确地指出——创业公司的员工总数最好花在能够同时进行工程和运营的软件开发人员身上(DevOps)

在第三阶段公司雇用专门的业务人员至关重要。虽然，很明显，这样的公司不需要全职的系统管理员来管理托管设施中的机器，但是这类人之前会填补这样的工作，通常也会提供其他20% 的技能，如系统调试，性能分析，操作直觉等。新公司的员工队伍缺乏关键的、不容易替换的技能。

为什么 DevOps 在现代互联 创业公司中运作良好？

正如我所定义的 DevOps (开发和运营他们服务的工程师) ，对于现代互联 创业公司来说非常好用，原因有几个:

1. ( 根据我的经验，成功的早期创业工程师是一种特殊的工程师。他们具有风险容忍能力，学习速度极快，无论技术债务多少，都能尽快完成任务，经常能够在多个系统和语言中工作，并且通常拥有操作和系统管理的经验，或者愿意边干边学。简而言之，一个典型的创业工程师非常适合做 DevOps 工程师，不管他们是否愿意自称为 DevOps 工程师(I prefer not 我宁愿不要 ). )
2. 正如我上面所描述的，现代公共云提供了一个难以置信的基础设施basic 基本的 过去的操作任务已经自动化了，留下了一个基板g足够好 运送最小可行产品，看看是否有适合市场的产品
3. 我坚信，当开发人员被迫随叫随到并对他们编写的代码负责时，系统的质量就会提高。没有人喜欢被呼叫。这个反馈循环构建了一个更好的产品，正如我在第(1)中所描述的，一个典型的工程师被吸引到一个早期启动产品的工作中，他非常愿意学习和做操作工作。考虑到对于一个可靠性较差的早期启动产品的影响很小，这一点尤其重要。可靠性需要公正 足够好让产品找到市场契合点，进入高速增长阶段

当一个现代互联 创业公司经历高速增长时会发生什么？

大多数创业公司都会失败。这就是现实。因此，任何早期的创业公司花费大量时间以谷歌的形象建立基础设施都是在浪费时间。我总是告诉人们坚持他们的单片体系结构，不要担心其他任何事情，直到人类的可伸缩性问题(通信、规划、紧耦合等)需要向更加分离的体系结构转变。

那么，当一家现代(第三阶段)互联 初创企业获得成功并进入高速增长时会发生什么呢？一些有趣的事情同时发生:

1. 人员增长速度迅速加快，对通信和工程效率造成严重压力。我强烈推荐阅读The Mythical Man-Month 人月神话 (在首次出版近50年后仍然在很大程度上是相关的)了解更多关于这个主题的信息
2. 以上几点几乎总是导致从单片机到微服务架构的转变 作为解耦开发团队，提高沟通和工程效率的一种方式
3. 从单一体系结构到微服务体系结构的转变使系统基础设施的复杂性增加了几百万数量级。 络、可观察性、部署、图书馆管理、安全以及其他数百个以前并不困难的问题现在都是需要解决的主要问题
4. 与此同时，高增长意味着流量增长和由此产生的技术扩展问题，以及对完全失败和次要用户体验问题的更大影响

中央基础设施团队

几乎所有的公司都遵循早期的启动阶段，现代互联 高速增长的公司最终以类似的方式构建他们的工程组织。这种常见的结构包括一个中央基础设施团队，支持一组实践 DevOps 的垂直产品团队(不管他们是否这样称呼它)。

中央基础设施团队如此普遍的原因是，正如我上面所讨论的，高速增长带来了一系列与人和底层技术相关的变化，而现实是，如果每个产品工程团队都必须单独解决 络、可观察性、部署、配置、缓存、数据存储等方面的常见问题，那么最先进的云本地技术仍然很难使用。作为一个行业，我们距离“无服务器”技术能够完全支持高度可靠、大规模和实时的互联 应用还有几十年的时间，在这些应用中，整个工程组织可以主要关注业务逻辑。

因此，中央基础设施团队的诞生是为了解决更大的工程组织的问题，这些问题超出了基础云本地基础设施原语所提供的范围。很明显，谷歌的基础设施团队比 Lyft 这样的公司要大10个数量级，因为谷歌正在从数据中心层面解决基础性问题，而 Lyft 依赖于大量公开可用的原语。然而，在这两种情况下，创建中央基础结构组织的根本原因是相同的: 尽可能抽象基础结构，以便应用程序/产品开发人员可以专注于业务逻辑。

可替换性的谬论

最后，我们得到了“可替换性”的概念，这是当组织规模超过一定数量的工程师时，纯粹的 DevOps 模型失败的关键。可替换性是指所有工程师生来平等，可以做任何事情。无论是明确的招聘目标(至少像亚马逊(Amazon)或其他公司那样) ，还是通过“训练营”(例如雇佣工程师时不考虑团队或角色的招聘方式) ，可替换性在过去10-15年里已经成为许多公司现代工程哲学的一个流行组成部分。为什么会这样？

然而，正如许多新的互联 创业公司所做的那样，这个想法走向了极端，结果只雇佣了通才软件工程师，期望这些(DevOps)工程师能够处理开发、质量保证和操作。

可替换性和通才招聘对于早期的创业公司来说是很好的。然而，超过一定的规模，认为所有工程师都可以交换的想法几乎变得荒谬，原因如下:

具有讽刺意味且虚伪的是，像亚马逊和 Facebook 这样的组织优先考虑软件工程师角色的可替换性，但显然重视开发和运营之间的分工(但仍然重叠) ，继续为每个角色提供不同的职业道路。

崩溃

纯 DevOps 是如何以及在什么样的组织规模下崩溃的? 出了什么问题？

在“旧方式”和“ DevOps 方式”之间是否存在一个中间地带？

对于大约10年以上的公司，现场可靠性或生产工程模型已经成为常见的。尽管各个公司的实施情况各不相同，但是我们的想法是雇佣一些工程师，这些工程师可以完全专注于可靠度，同时不受制于产品经理。然而，一些实施细节是非常相关的，其中包括:

什么是正确的 SRE 模型？

鉴于目前在行业中实现的示例过多，这个问题没有正确的答案，所有模型都有自己的漏洞和由此产生的问题。根据我过去10年的观察，我将概述一下我认为最佳点是什么:

如上所述，一个成功的 SRE 项目在成长阶段的早期实施，以及对新雇员、继续教育和文档的真正投资，可以提高整个工程组织的门槛，同时减轻许多以前描述的人力扩展问题。

总结

很少有公司达到高增长阶段，在这一点上，这个职位是直接适用的。对于许多公司来说，一个基于现代云本地原语的纯粹的 DevOps 模型可能已经完全满足了所涉及的工程师数量、所需的系统可靠性以及业务所需的产品迭代率。

对于相对较少的申请这篇文章的公司来说，关键的要点是:

在我看来，现代高速增长的互联 公司已经出现了大量的过度疲劳，主要是由于对产品的苛刻需求，以及对运营基础设施的投资不足。我相信工程领导者可以在这种趋势成为组织稳定性的主要障碍之前，通过领先于业务来逆转这种趋势。

新公司可能会错误地认为，云计算本地自动化的发展正在使传统的运营工程师变得过时，但事实并非如此。在可预见的未来，即使使用了最新的可用技术，专长于操作和可靠性的工程师也应该得到认可和重视，因为他们提供了其他方法无法获得的关键技能，他们的重要角色应该在早期发展阶段正式构建到工程组织中。