传奇 Netflix：全周期开发人员 – 运维你构建的内容 | 译文

这一年是2012年，在 Netflix 运营关键服务非常辛苦， 部署感觉就像穿行湿沙。 Canarying 正在开始验证耐力（“在一周狂欢后，没有什么能够打破，让我们推动它”），而不是正确的功能。 研究问题就像在团队之间弹跳球一样，很难找到根本原因并且难以阻止问题彼此之间的“弹跳”。 所有这些都是需要改变的迹象。

快到2018年，Netflix 已经发展到全球1.25亿名会员，每天可观看1.4 亿多个小时。 我们为改善工程团队的开发和运营工作投入了大量资金。 在此过程中，我们尝试了许多方法来构建和运营我们的服务。 我们希望分享一种在 Netflix 中相对常见的方法，包括其优点和缺点。 我们希望分享我们的经验以激发他人从辩论中想到替代方案，并从我们的历程中学习。

一个团队的旅程

Edge Engineering 负责 Netflix 流式传输工作的第一层 AWS 服务。在过去，Edge Engineering 拥有以运维为中心的团队和SRE专家，他们拥有软件生命周期中的部署+运维+支持三个部分。发布新功能意味着开发人员需要与指导团队协调处理诸如指标，警报和容量考虑因素等事宜，然后交付运维团队部署和运行的代码。

为了有效运行代码和支持合作伙伴，运维团队需要对新功能和错误修复进行持续培训。如果事情进展顺利，拥有独立运营团队的主要好处就是开发人员的中断减少。

当事情不顺利时，成本加起来。开发人员与运维人员/ SRE之间的沟通和知识传递是有损的，需要额外的往返调试问题或回答合作伙伴问题。部署问题由于运维团队对正在部署的更改没有直接的了解，因此需要更长的检测时间和解决时间。代码完成和部署之间的差距比今天长得多，发布时间为几周而不是几天。反馈来自运维人员，他们直接经历了诸如警报/监控或性能问题以及延迟增加等痛苦，对于那些第二手听到这些问题的开发人员。

为了改进这一点，Edge Engineering 尝试了一种混合模式，在这种模式下，开发人员可以在需要时自行推送代码，还负责下班时间的生产问题和支持请求。这改善了开发者的反馈和学习周期。但是，只有部分责任留下了空白。例如，即使开发人员可以自行部署和调试管道中断，他们通常也会遵从运维系统发布专家。对于以运维为中心的人员，他们有动力去做日常工作，但发现很难优先考虑自动化，以便其他人不需要依赖他们。

为了寻找更好的方法，我们退后一步，决定从第一原则开始。我们试图完成什么？为什么我们不能成功？

软件生命周期

软件生命周期的目的是优化“时间到价值”转换过程; 有效地将创意转化为针对客户的工作产品和服务。 开发和运行软件服务涉及如下全套责任：

图1 系统生命周期组件

我们一直在细分这些职责。 在极端情况下，这意味着每个功能区域都由不同的人员/角色所有：

图2 系统生命周期专业人员

这些专业角色可以在每个细分市场中创造效率，同时可能会在整个生命周期中造成效率低下。 专家在重点领域发展专业知识，并优化该领域的需求。 他们更有效地解决他们的难题。 但软件需要整个生命周期为客户提供价值。 拥有各自拥有生命周期一小部分的专家团队可以创建一个“孤岛”，以减缓端到端的进展。 将不同的专家组合成一个团队可以减少“孤岛”，但是由于不同的人担任每个角色会增加通信开销，引入瓶颈并抑制反馈循环的有效性。

运维你构建的内容

为了重新思考我们的方法，我们从 devops 运行的原理中获得灵感。 我们可以通过打破孤岛并鼓励整个软件生命周期的共享所有权来优化学习和反馈：

图 3 devops规则下的生命周期

“运维你所构造的”通过让开发系统的团队也负责运维和支持该系统，将devops原则付诸行动。 将这一责任分配给每个开发团队，而不是将其外化，从而创建直接反馈循环并调整激励措施。 通过改变他们的系统设计或代码，团队可以感受到手术痛苦，从而有能力补救疼痛; 他们对这两项职能负责并负责。 每个开发团队都拥有部署问题，性能错误，容量规划，警报差距，合作伙伴支持等。

通过开发人员工具定标

完整开发生命周期的所有权极大地增加了软件开发人员的期望。 简化和自动化共同开发需求的工具有助于平衡这一点。 例如，如果软件开发人员需要管理其服务的回滚，那么需要丰富的工具，既可以检测并警告他们的问题，也可以帮助回滚。

Netflix创建了集中团队（例如云平台，性能和可靠性工程，工程工具），其任务是开发通用工具和基础设施，以解决每个开发团队遇到的问题。 这些集中的团队通过将他们的专业知识转化为可重复使用的构件来充当力量倍增器。 例如：

图4 开发可重复使用工具的专业人员

通过掌握这些工具，开发团队可以专注于解决其特定产品领域内的问题。 随着额外的工具需求的出现，集中的团队会评估多个开发团队的需求是否共同。 当他们合作时，随之而来的是合作。

有时候这些本地需求太具体，不能保证集中投资。 在这种情况下，开发团队决定他们的需求是否足够重要，以便他们自己解决。

在类似问题上平衡本地投资与中央投资是我们方法中最棘手的问题之一。 根据我们的经验，寻找针对开发人员需求的新颖解决方案的好处值得让多个团队创建并行解决方案的风险，这些解决方案需要融合。

沟通和协调是成功的关键。 通过开始与需求相一致以及它们的普遍程度，我们可以更好地将投资与Netflix开发团队的收益相匹配。

全周期开发人员

通过将所有这些想法结合在一起，我们得出了一个模型，在这个模型中，配备了惊人的开发人员生产力工具的开发团队负责整个软件生命周期：设计，开发，测试，部署，运维和支持。

图5 授权的全周期开发人员

预计全周期开发人员在软件生命周期的所有领域都具有丰富知识和有效性。对于许多新到Netflix的开发人员来说，这意味着要加强他们之前没有关注的领域。

我们运行开发训练营和其他形式的持续培训，以传授这些知识并建立这些技能。

知识是必要的，但并不充分;用于部署流水线（例如Spinnaker）和监控（例如，Atlas）的易于使用的工具对于有效的全周期所有权也是需要的。

全周期开发人员将工程学科应用于生命周期的所有领域。他们从开发人员的角度评估问题，并提出诸如“我如何自动执行运维此系统所需的操作？”和“什么自助服务工具能够帮助我的合作伙伴回答他们的问题而不需要我参与？”这些帮助。我们的团队通过倾向于以系统为中心而不是以人为本的思维和自动化而非人工方法来扩大规模。

转向全周期开发人员模式需要思维转变。一些开发人员将设计+开发视为主要方式，并且有时将测试视为创造价值的主要方式。这导致了查看运维的反模式成为分心，有利于短期修复运营和支持问题，以便他们能够恢复到“真正的工作”。

但全周期开发人员的“真正的工作”是利用他们的软件开发专业知识来解决整个生命周期中的问题。一个完整周期的开发者认为和行为就像一个SWE，SDET和SRE。有时，他们创建解决业务问题的软件，有时他们会为此编写测试用例，有时还会自动化该系统的运维方面。

要使这个模型成功，团队必须致力于其带来的价值，并认识到成本。团队需要适当配备足够的空间来管理构建和部署，处理生产问题并响应合作伙伴支持请求。时间需要用于培训。需要利用和投资工具。

需要通过集中的团队培养合作伙伴关系，以创建可重用的组件和解决方案。在规划和回顾过程中需要考虑生命周期的所有领域。

像自动化警报响应和构建自助式合作伙伴支持工具等投资需要与业务项目一起排列优先顺序。通过适当的人员配备，优先次序和合作伙伴关系，团队可以成功运作他们所建立的项目。如果没有这些，团队的风险就会超负荷和倦怠。

要在Netflix之外应用此模型，必须进行修改。开发团队的常见问题可能类似 - 从持续交付管道，监控/可观察性等方面的需求。

但许多公司没有人员投资Netflix等集中团队，也不需要Netflix规模所需的复杂性。 Netflix的工具通常是开源的，它可能会引人注目地将它们作为第一遍。

但是，针对这些问题的其他开源和SaaS解决方案可以满足大多数公司的需求。首先分析潜在价值并计算成本，然后进行思维转换。评估你需要什么，并注意引入必要的最低复杂性。

权衡

技术行业有多种解决开发和运营需求的方法（ 请参阅 devops 拓扑结构以获得广泛的列表）。这里描述的完整周期模型在Netflix中很常见，但也有其不足之处。在选择模型之前了解权衡可以增加成功的机会。

采用完整周期模式，通过工具优先考虑在更广泛的领域中拥有更大的所有权和有效性。广度需要各种技术的兴趣和才能。

一些开发人员更倾向于专注于在狭窄领域成为世界级专家，我们的行业在某些领域需要这些类型的专家。

对于那些专家来说，需要在每个领域都有合理的深度，可能会感到不舒服，有时甚至无法实现。

Netflix的一些人更喜欢在需要深厚专业知识的领域，而不需要持续的广度，我们支持他们找到这些角色;其他人则享有并欢迎更广泛的责任。

根据我们在构建和运行基于云的系统方面的经验，我们已经看到开发者看重拥有完整周期所需的广度的有效性。

但是，这种广度增加了每个开发者的认知负担，并且意味着一个团队将每周平衡更多的优先事项，而不是仅仅关注一个领域。我们通过轮流召开轮换，让开发人员轮流处理部署+运营+支持责任，从而减轻这一负担。

如果做得好，这为其他人做出专注的，流程型的工作创造了空间。如果做得不好，团队会投入到所有参与高级中断工作的人员中，例如生产问题，这可能导致职业倦怠。

工具和自动化有助于扩展专业知识，但没有工具可以解决开发人员生产力和运营空间中的每一个问题。

Netflix有一套“铺平道路”的工具和实践，由集中的团队正式支持。我们没有要求采用这些铺砌的道路，但鼓励采用，确保使用这些技术的开发和运营比不使用这些技术更好。

我们方法的不足之处在于，“每个团队在每种工具中为他们最重要的需求使用每个功能”的理想几乎无法实现。要实现我们集中化团队解决方案的投资回报，需要付出努力，保持一致并不断进行调整。

总结

从 2012 年到今天的路线充满了实验，学习和适应过程。

Edge Engineering 过往积累了创造更好模型的经验，目前也是正积极全周期开发人员应用的模型。 部署是常规和频繁的，canaries 需要几小时而不是几天，开发人员可以快速研究问题并进行更改，而不是跨团队反弹。

其他团体也看到类似的好处。 但是，我们认识到我们通过应用和学习其他方法来到这里。 我们预计明天的需求将推动进一步的发展。