全循环开发人员 - 操作您的构建（2018）
今年是2012年，并在Netflix经营关键服务艰苦。部署觉得像穿过湿沙一样。金式水电片正在验证耐力（“无需在一周后发生了，让我们推动它”）而不是正确的功能。研究问题觉得像在团队之间弹跳橡胶球，难以抓住根本原因，尚未停止在彼此之间弹跳。所有这些都是需要更改的迹象。
快进至2018年。Netflix已经成长为125米的全球成员，每天享受140米+小时的观看。我们在改善我们的工程团队的开发和运营故事方面投入了重大。一路上，我们试验了许多建设和经营服务的方法。我们希望分享一种方法，包括其利弊，在Netflix中相对普遍。我们希望分享我们的经验激励其他人辩论替代方案并从旅程中学习。
Edge Engineering负责第一层的AWS服务，必须为NetFlix流工作。在过去，Edge Engineering拥有ops的团队和SRE专家，他们拥有软件生命周期的部署+操作+支持部分。释放一个新功能意味着与OPS团队更协调指标，例如指标，警报和容量注意事项，然后删除OPS团队的代码部署和操作。为了有效地运行代码和支持合作伙伴，OPS团队需要对新功能和错误修复的持续培训。当事情进展顺利时，有一个单独的OPS团队的主要营业队的初级上层较少。
当事情不顺利时，成本增加了。 DEVS和OPS / SRES之间的通信和知识转移有损，需要额外的圆形旅行来调试问题或回答合作伙伴问题。由于OPS团队较少地对正在部署的更改的直接知识较少，部署问题具有更高的时间 - 检测和时间。代码填补和部署之间的差距比今天要长得多，发布在周数而不是几天。反馈来自ops，他们直接经历的痛苦，例如缺乏警报/监测或绩效问题以及增加延迟，他们在第二次听到那些问题的开发者。
为了提高这一点，边缘工程实验有一个混合模型，其中DEVS可以在需要时推送代码，也负责离事时间的生产问题和支持请求。这改善了开发人员的反馈和学习周期。但是，只有部分责任留下差距。例如，即使DEVS可以进行自己的部署和调试管道断开，它们通常会推迟OPS发布专家。对于以举行的ops为重点的人，他们有动力去做日常工作，但难以确定自动化优先考虑，以便其他人不需要依赖他们。
寻找更好的方法，我们返回并决定从第一原则开始。我们试图完成什么，为什么我们不成功？
软件生命周期的目的是优化“时间值”;有效地将思想转换为客户的工作产品和服务。开发和运营软件服务涉及全套职责：
我们一直在分割这些责任。在极端，这意味着每个功能区由不同的人/角色拥有：
这些专业角色会在每个段内创造效率，而在整个生命周期中可能产生效率低下。专家在集中区域开发专业知识，并优化该地区所需的内容。他们在解决他们的拼图时更有效。但软件需要整个生命周期向客户提供价值。拥有各自拥有一片生命周期的专家团队可以创建筒仓，减慢结束到最终进度。将不同专家分组到一个团队中可以减少筒仓，但有不同的人每角色都会增加通信开销，引入瓶颈，并抑制反馈回路的有效性。
为了重新思考我们的方法，我们从Devops运动的原则制作了灵感。我们可以通过打破孤岛和鼓励完整软件生命周期的共享所有权来优化学习和反馈：
“操作您构建的内容”通过使开发系统的团队还负责运行和支持该系统的团队，将Devops原则置于行动中。将此责任分发给每个开发团队，而不是外部化，创建直接反馈循环并对齐激励措施。感到患有操作疼痛的团队通过改变其系统设计或代码来赋予痛苦来解决痛苦;它们对两种功能负责并对负责任。每个开发团队都拥有部署问题，绩效错误，容量规划，警报差距，合作伙伴支持等。
完整开发生命周期的所有权对预期的软件开发人员进行了显着增加。简化和自动化共同开发需求的工具有助于平衡这一点。例如，如果预计软件开发人员可以管理其服务回滚，则需要丰富的工具，可以检测并警告它们的问题以及帮助回滚。
Netflix创建了集中团队（例如，云平台，性能和可靠性工程，工程工程工具），使其开发普通工具和基础设施来解决每个开发团队所拥有的问题。这些集中团队通过将专业知识转换为可重复使用的构建块来充当力量乘法器。例如：
在手中授权这些工具，开发团队可以专注于解决特定产品领域内的问题。随着额外的工具需求，集中团队评估多个开发团队的需求是否常见。当他们是，合作随之而来。有时，这些当地需求太具体而无法保证集中投资。在这种情况下，开发团队决定他们的需求是否足够重要，让他们自己解决。
平衡当地与类似问题的中央投资是我们方法最棘手的方面之一。在我们体验中，为开发人员需求寻找新颖解决方案的好处是值得多组创建需要汇聚道路的并行解决方案的风险。通信和对准是成功的键。通过开始良好的需求和他们可能的常见，我们可以更好地与Netflix跨越队伍的利益。
通过将所有这些想法组合在一起，我们到达了一个开发团队，配备了惊人的开发人员生产力工具的模型，负责全软件生命周期：设计，开发，测试，部署，操作和支持。
预计全循环开发人员将在软件生命周期的所有领域知识渊博和有效。对于许多新的Netflix开发人员来说，这意味着在他们以前没有专注的区域上升。我们运行Dev Bootcamps和其他形式的持续培训，以赋予这种知识并建立这些技能。知识是必要的，但不足;有效的完整循环所有权，还需要易于使用的部署管道（例如，Spinnaker）和监测（例如，Atlas）的易于使用的工具。
全循环开发人员将工程学科应用于生命周期的所有领域。他们评估开发人员的角度来看问题，提出问题，如“如何自动化操作该系统所需的内容？”并“在不需要我涉及的情况下，有什么自助工具将使我的合作伙伴能够回答他们的问题？”这有助于我们的团队通过偏重于系统，而不是通过手工方法来实现专注的系统，而不是人类的思维和自动化。
移动到完整的循环开发人员模型需要心态移位。一些开发人员查看设计+开发，有时是测试，作为它们创造价值的主要方式。这导致视图的反模式作为分散注意力，有利于短期修复运营和支持问题，以便他们可以回到他们的“实际工作”。但是全循环开发人员的“实际工作”是使用他们的软件开发专业知识来解决整个生命周期的问题。完整的循环开发人员认为和行为像SWE，SDET和SRE。有时他们创建解决业务问题的软件，在其他时候他们编写了测试用例，仍然是他们自动化该系统的操作方面。
对于这种模型成功，团队必须致力于它带来的价值，并认识到成本。团队需要适当的人员使用足够的余量来管理构建和部署，处理生产问题，并回复合作伙伴支持请求。时间需要致力于培训。需要利用和投资工具。伙伴关系需要促进集中团队，以创建可重复使用的组件和解决方案。在规划和回顾期间，需要考虑生命周期的所有领域。像自动化警报响应和建立自助服务合作伙伴支持工具的投资需要优先考虑业务项目。通过适当的人员配置，优先级和伙伴关系，团队可以在经营他们构建的内容中取得成功。没有这些，团队风险过载和倦怠。
要在Netflix之外应用此模型，适应是必要的。您的Dev团队中的常见问题可能是类似的 - 从不需要连续送货管道，监测/可观察性等。但许多公司不会有员工在Netflix上投资中集中团队，也不需要Netflix的规模所需的复杂性。 Netflix的工具通常是开源的，可能会引起将它们作为第一次通过。但是，这些问题的其他开源和SaaS解决方案可以满足大多数公司的需求。从分析潜在价值开始，并计算成本，其次是思维方式。评估您需要的东西，并注意到所需的最小复杂性。
科技产业有各种各样的方法来解决开发和运营需求（有关广泛的清单，请参阅Devops Topologies）。这里描述的完整周期模型在Netflix是常见的，但有其缺点。在选择模型之前了解权衡可以增加成功的机会。
通过完整的循环模型，优先考虑通过工具在更广泛的域中的更大的所有权和有效性。广度需要在各种技术中的兴趣和能力。一些开发商更愿意关注成为狭窄领域的世界级专家，我们的行业需要一些地区的专家。对于那些专家来说，需要广泛，每个区域的合理深度都可能是不舒服的，有时候是不合适的。 Netflix的一些愿意在一个需要深度专业知识的区域，而无需持续宽度，我们支持他们寻找这些角色;其他人享受并欢迎更广泛的责任。
在我们与建筑和经营云的系统的经验中，我们已经看到了与价值全周期所需广度的开发人员的有效性。但是，这种广度增加了每个开发人员的认知负荷，并意味着一支球队每周将平衡更多优先事项，而不是他们专注于一个地区。我们通过开启旋转来缓解这一点，开发人员轮流处理部署+操作+支持职责。完成后，为其他人创造了空间，以进行聚焦，流动状态类型的工作。当没有做好时，团队将陷入高中跳跃的大家，如生产问题，可以导致倦怠。
工具和自动化帮助缩放专业知识，但没有工具将在开发人员生产力和运营空间中解决每个问题。 Netflix有一个“铺砌的道路”一套由集中团队正式支持的工具和实践。我们不授权通过那些铺砌的道路，而是通过确保使用这些技术的开发和运营来鼓励采用，而不是不使用它们的经验。我们的方法的缺点是“每个团队在每个工具中使用每个功能的每个功能，为他们最重要的需求”的理想是不可能实现的。实现集中团队解决方案的投资回报需要努力，对齐和持续的适应。
从2012年到今天的路径充满了实验，学习和适应。 Edge Engineering，其先前的经验激励找到更好的模型，正在积极应用全周期开发人员模型。部署是常规的，频繁，金丝雀需要数小时而不是日子，而开发人员可以快速研究问题并进行更改，而不是在团队中弹出责任。其他群体正在看到类似的好处。然而，我们通过申请和学习从替代方法来看，我们得到了认识。我们预计明天的需要激励进一步的进化。
有兴趣在行动中查看此模型吗？想成为探索我们未来方法的一部分吗？考虑加入我们。