并非所有的团队都能达到Netflix的高度，但了解他们如何进行开发者生产力工程仍可能对你的团队有所帮助。
译自 Developer Productivity Engineering at Netflix 。
今年，技术行业对开发者生产力指标显得痴迷不已。但单独测量可能造成更大的伤害。通常，开发者不信任生产力工具，随着裁员消息持续出现，他们可能会为了保住工作而操纵系统。
而且，已经证实快乐的员工更有生产力。因此，任何削弱开发者快乐度的因素都会降低生产力。
比仅仅测量个人产出更好的是，有一股向软件交付实现转变的趋势，关注团队甚至部门和部门的效率和速度。这种基于团队的视角有助于组织心理安全感，并且可扩展性更强。随着这一受欢迎趋势的出现，开发者生产力工程团队兴起，他们关注开发者体验(DevEx)和实现超过测量。
“开发者生产力就是一个通用定义，关于我们如何使技术社区能够专注日常工作，而不必担心Netflix的所有不同之处，从启动到软件开发生命周期的每个阶段，” Netflix生产力工程总监Kathryn Koehler告诉The New Stack。
当然，工程是一门科学，这就是为什么Netflix、谷歌、领英、Spotify和Atlassian等高绩效组织都在测量他们的平台团队对开发者生产力的影响。不同之处在于，他们关注的测量并不是为了变革管理，而是为了持续改进他们自己的工艺。
现在，让我们来看看Koehler如何介绍Netflix组织和测量自己的平台工程和开发者生产力工程，以便你可以学习一些方法来帮助你自己的软件工程团队。
不出所料，Netflix 拥有一系列Team Topologies所说的使能型、复杂子系统和平台团队。(是的，这是复数形式。)
首先，有一个由150人组成的集中的平台团队，他们“开发工具、平台和基础设施，用来处理各种约束，这样我们的开发者社区——他们是我们的客户，我们公司内部的开发者社区——就可以专注于自己最擅长的领域，发挥最佳水平。” Koehler说。采用一种“枢纽与辐射”的模式，平台团队下面有两个团队。首先是Koehler领导的80人开发者生产力工程团队，负责内部开发循环——构建、测试、编码、持续集成，直到但不包括部署，以及端到端的开发者体验，包括源代码控制和依赖管理。
“我们正在打造一个端到端的开发者前门，一个命令中心或控制中心，让人们拥有和运营自己的软件。”她解释说。她的伙伴负责交付、监控和站点可靠性工程。
此外，更大的Netflix平台工程团队还包括云基础设施团队和数据平台团队。Koehler表示: “我们将生产力与云基础设施分离开来，这应该是关注点分离，你不需要了解计算、网络和存储这些底层细节。”
实际上，“这些底层东西应该只限于超级用户。”她继续说。“但如果你是一个应用程序开发者，或者正在开发一个服务，你只需要提供一些应用程序配置参数，不需要关心底层复杂的实现。”
注意组织设计只能持续大约18个月，Koehler指出，现在的大部分已经存在了大约3年，而集中式基础设施的部分要追溯到更早之前的几年。
总体而言，更大的Netflix生产力和平台部门旨在抽象出任何会打扰开发者专注的东西。
Netflix平台团队——包括产品管理和内部客户支持——为2500人的工程组织以及另外500人的数据团队提供支持。这是15%的使能角色，而大多数拥有成熟平台工程计划的组织接受The New Stack采访时表示使能角色不到10%。
一个集中的团队为平台团队处理一线和二线客户支持，Koehler解释说，“这有助于让我们的客户——工程人才——只需要专注处理那些非常复杂的支持问题。否则，我们在总体支持上的‘保持服务’时间会过于繁重。所以这是我们更好扩展的一种方式，也可以保持我们的工程规模较小。”
这是The New Stack采访的第一个将此类正式内部平台客户支持作为产品的平台组织。因此我们请Koehler进一步详细解释。Netflix有几位内部客户支持工程师，他们由领域专家进行培训，处理一线请求——即帮助开发人员找到并使用最佳工具完成工作——和二线请求——会更深入调试，帮助处理更复杂的问题。三线支持在需要对底层基础设施有更深入理解的特殊情况下启用。
Koehler说，这些人往往是非常喜欢帮助他人的技术人员。但是“找到这个团队需要多大与主题专家团队需要多大之间的平衡点非常复杂。”她反思到。“我们也有很多间接效应，他们可以更好地发现趋势。”
当然，不是每个组织都有Netflix这样的平台预算和规模，但这种策略对Netflix很重要，可以让其大多数10倍的工程师发挥得更好。
尽管Netflix会跟踪DORA和其他定量指标，但Koehler说很多补充的开发者生产力指标是定性的。这包括大量的用户调查，“弄清楚什么是你的苦差事”，她说，以及“完成你的工作有多难”。
Netflix使用2021 SPACE开发者生产力框架，该框架提出了25个社会技术因素，这些因素分为首字母缩写的五大类别:
- 满意度和福祉
- 绩效
- 活动
- 沟通和协作
- 效率和流程
Netflix开发者生产力工程团队对工具的看法也有一些非常具体的问题:
- 你觉得这个工具令人愉快吗？
- 如果你要离开Netflix， 离开这些工具你会难过吗？
- 你会推荐朋友因为工具太好而在Netflix工作吗？
- 由于你的工具，你觉得自己工作有多有效？
- 你可以部署的频率是多少，并对所部署的内容有信心吗？
- 你认为该工具有多buggy？
Netflix的平台团队记录他们收到多少内部支持电话。根据他们服务的团队和平台，也有具体的问题。例如，他们询问Java开发者:
- 应用程序生成的启动时间是多少？
- 构建时间是多少？
- 执行测试套件需要多长时间？
- 你对可观察性工具有多大信心？你可以一目了然地确定系统运行状况吗？你是否先于客户发现事情出错？
他们过去每年进行两次这些调查，但Koehler说，现在变成由工程领导根据情况决定最佳时间。
“我们让工程领导与我们的客户自由建立良好关系——因为他们都是内部的。”她说。平台团队还是大致每季度一次地联系各负责人，请求对他们刚开发的内容提供反馈。
Netflix计划很快会构建更多仪表盘， 整合定性反馈以及更多定量报告和仪表盘。Koehler说，后者的目的是“教会开发者自己查看系统运行情况和效率，比如: 机群（fleet）健康状况如何?是否使用最新版本库?”
她的团队也在推动开发者采取更主动、持续的沟通，而不是一年四次大规模调查，她说这可能“有点奇怪”，并易于解释。 “提出有见地的调查问题非常困难。也取决于谁在回答以及是否喝咖啡。”
Netflix的公司价值观包括公开、广泛和谨慎地共享信息，以及坦率和直接的沟通。毫不奇怪，没有一个开发者的回复是匿名的，这保证了一个更紧密的DevEx反馈循环。
“重要的是我们知道谁提供了此反馈，人们不会回避。”她说。这也使她的团队可以与内部开发者客户闭环: “嘿，你之前真的在抱怨这个，我们在这里做了这项工作，所以想再次联系你，看情况是否改善。”
Netflix将其平台称为“铺平的路径”。这条更平坦的道路包括一流的支持基础设施、语言和工具。还有一系列尚未铺平部分的功能请求。
过去两年，Netflix基础设施团队不得不将工作范围广泛扩展到工作室和流媒体之外。这意味着为游戏、广告和直播等全新业务和技术需求铺平道路。游戏需要快速让开发者上手，方便他们发挥创造力，而直播需要高可用性、低延迟和弹性。
“我们有各种不同的考量，需要铺设足够的跑道，让这些飞机能够起飞，这在很大程度上影响了基础设施这一方面。” Koehler说。
在不同的客户组织内，Netflix还有不同的平台团队，以构建特定平台产品组合，甚至为特定用户组从零开始构建。“如果我们立即为所有人做所有的事情，那将不太可扩展，”这就是为什么她说他们为不同群体(如消费者和内容)有其他托管的平台扩展。
当前，生产力团队负责数十种不同的工具和平台，这就是为什么他们正在努力汇集很多东西，创建一个集中的开发者门户，以提供一致的用户界面和开发者体验。但Koehler说，它不会囊括一切，因为并非所有内容都适合放入其中，但它正在朝着实现“更多重心”的方向发展。
文档是开发者最想要的，但他们发现很难养成为其做出贡献的习惯。Netflix也不例外。
“我们有非常强的自由和责任文化，我们的工程师有时在某些情况下会偏向自由而非责任，特别是在编写完整文档方面。” Koehler说。 再次呼应平台工程师可能有的自以为是的习惯，她说: “有时我们在从平台提供商而非客户角度编写文档方面存在挑战。”
平台团队现在正与Netflix教育团队合作，提高文档质量，致力于回答:
- 我们是否有正确的信息架构？
- 它是否可搜索？
- 它是否可发现？
- 它是否集成在一个工具中？
这一国际化文档策略致力于将所有内容集成到一个可索引、可搜索、规范和可用的工具中。
“我坚信发现应该真正成为工具的一部分。所以，如果我们让人们进入托管环境或这个门户，我们如何在他们需要时显示上下文文档和信息？” 和许多组织一样，Koehler说，他们正在研究如何利用AI，像90年代的Clippy，但更有用，并具有组织上下文，因为“当您管理这么多不同的产品时，可发现性是一个大问题。” 他们正在研究如何将文档集成到软件开发生命周期中。
她的部门也在研究如何使单个平台工程师对文档负责，方法是将文档和运行手册作为完工定义的一部分。
Netflix平台团队也经常遇到的另一个困难，就是平台工程策略中非常普遍的——沟通和营销保持在那条铺平道路上的好处。
“推动大家使用最新库、工具或框架具有挑战性。因为我们的客户有日常工作，在他们的时间表中找到预算进行迁移——这可能很复杂或困难——是很难的。” Koehler说，“我们需要加倍努力，便利大家进行迁移，使迁移尽可能无缝，因为我们总是在迁移。总会有我们自己正在构建的或者我们作为第三方工具使用的下一个版本，我们的客户应该采用它。”
应用和数据团队不能超过长期支持窗口非常重要，否则他们可能会引入风险，如安全漏洞。她说，健康的组织会定期重建和部署整个机群，这依赖于保持机群更新。这归结为技术债务的权衡。
“人们从未为技术债务分配足够的时间。” Koehler说，希望团队努力将他们的“保持服务”——缺陷修复、现代化等——控制在30%以下，这意味着努力降低技术债务。 “走出困境的唯一方法是开始填平它。”
但是有希望，不仅对Netflix，而且对整个行业都有好处，因为开发者生产力工程正在上升。这甚至是Koehler终于开始在简历上看到的东西。
“人们从高质量、令人愉快的体验角度思考这些工具，这在过去从未受到过那样的关注。” 她继续说，“创造令人愉快的工具，经过精心打磨的工具，坚实的工具，设计师致力于此——这很棒。 这应该是首要或最重要的事情。这是一个非常好的领域，因为我们的客户都是内部的。我们还能与我们服务的人更加接近吗？”