“代码简洁”和“理解软件”的作者、领英公司的马克斯·卡纳特-亚历山大就平台工程团队常见的错误提出建议。
译自 Platform Teams: Adopt These 7 Developer Productivity Drivers 。
你想让你的开发者变得效率低下、心情不快乐吗?当然没有人想要这样的结果对吧?
事实上，更快乐的开发者会更有工作效率。The New Stack 采访了领英公司的 Max Kanat-Alexander，讨论了一些持续对开发者效率和快乐产生负面影响的常见反模式。我们总结了七个平台工程团队必须考虑的提升开发者效率的方法。
Kanat-Alexander 是领英的首席软件工程师，也是关于开发者生产力的畅销书《Code Simplicity》和《Understanding Software: The Fundamentals of Software》的作者。后者反映了他围绕软件设计原则和提高组织内开发者效率的自己观察和经验。他还担任过流行的开源缺陷跟踪项目Bugzilla的首席架构师，并且作为顾问处理过许多软件开发流程。在加入领英之前，他是谷歌代码优化小组的技术负责人，帮助塑造了工程师在代码审查和测试方面的实践。
他认为：“开发不仅仅是一个人单独编写代码，进入一个更大的范围时你可能需要知道一些事情。”他是知识系统团队的技术负责人，该团队构建度量和反馈系统以了解如何在领英范围内提高开发者效率和幸福感。
正如我们通过平台工程、知识扩散、文档和发现的研究所了解到的，知识传播是提高开发者效率的关键。
Kanat-Alexander 发现，尽管平台团队真正关心把事情做好，但“经常会有做错的地方可以做得更好”。
现在我们来反思最常出错的地方，并教你如何提高开发者幸福感。
随着平台工程逐渐成为主流，主要挑战不是技术方面，而是让内部开发者信任并采用你的平台及其创造的快捷通道。
“许多开发者效率工程团队陷入这样一种困境：他们觉得正在尽最大努力工作和交付成果，但没人对他们满意。” Kanat-Alexander说，这反过来使管理层在目前紧缩时期不愿为开发者效率团队提供资金。一个问题是平台工程师也是开发者，“你知道所有开发者需要和想要什么。因为你认为所有人的工作方式和你一样。所以，只要解决你自己的痛点，其他所有人就会开心。”
他当然善于讽刺，并认识到即使在同一公司，不同的软件开发团队也不完全相同。一个成功的平台工程和开发者效率策略依赖于持续的开发者反馈，并将平台视为一个产品。
从开发者调研开始。在小组织中，他说，进行一对一访谈。领英、谷歌和Spotify每季度进行大规模开发者调研。
“做好调研很难，” Kanat-Alexander承认，但“任何调研都比没有调研好，即便只发出一个问题‘嘿，评价你的开发体验吧’，然后是一个自由反馈的文本框‘告诉我你认为阻碍效率最多的最重要的事情’。”
任何调研行动都将帮助你与内部开发者建立更緊密的关系。
你的组织可能有几个不同的开发者群体等待倾听，从Java后端开发者和Python开发者，到前端、iOS和Android开发者，以及网站可靠性工程师。如果你只关注使这些群体中的一个更满意，其他人可能会更不满意。
“事实是，不同类型的开发者有不同的工作流程。除非你真正理解这些开发者的需求各不相同并分别服务，否则你仍会造成许多敌意，无法很好地服务开发者。” Kanat-Alexander说。
“需要考虑的是，优先级和要求需要根据工作流类型进行评估，而不仅仅是受影响开发者的数量。” 他解释说，移动团队通常比服务器团队小得多。起初，关注提高最多开发者的效率可能看起来有意义，但平台工程的重点是更快为终端用户交付价值——移动团队最有可能影响这一点。
“改善移动开发者的体验对业务影响可能实际上大于改善后端或Web开发者的影响。” Kanat-Alexander说。当然这取决于你组织目前的痛点和阻碍在哪里。例如，如果移动应用开发者无法在后端交付API更改，那么后端开发者的效率问题正阻碍着移动开发者。
平台团队必须根据你的工具广度在不同类型开发者之间进行优先级排序。如果某个团队有独特的工作流程，他说，DevOps的方式是该应用团队拥有工具链中其独有部分完全有意义的。
康威定律——系统反映沟通结构，在你的平台工程策略中同样至关重要。
如果你的平台团队(以及它所服务的工程部门)足够大，你可以根据角色将该团队分割开来，为每个组提供平台传道者。另一方面，Kanat-Alexander说，一个非常团结的平台团队拥有非常深厚的经验和专业知识可能更有利。
Puppet的2022年DevOps状态报告显示，这是平均公司拥有3到6个平台的原因之一——一刀切的策略很少奏效。
他说，将平台团队的重点分开，“可能会带来好处，因为你正在创建一个专注的产品来帮助那些人”，专注于他们的目的，并提供潜在的卓越的开发者体验。
但是，“如果你未能利用共性，人们就会做许多重复工作。或者，如果你创建了脆弱的工作流程，当你拥有多个平台时，它们无法融合在一起”，这会让开发者不得不从不同团队请求几乎相同的权限，通过人工流程减慢速度，或数据流之间不必要的障碍，又或者让开发者自己想方设法让CI系统与另一个部署系统互操作，因为它们现在拥有两个不同的工件需要协调。
“另一个让开发者效率低下和不快乐的好方法是，每次他们想要做任何事情时，确保他们在做任何事情之前都必须请求其他人的批准。” Kanat-Alexander说。那个人可能需要几天才能回复。更糟的是(变慢了)，你可能会添加各种流程和不同的团队不得不相互交谈。一天的任务可能会拖两个月。
开发者沮丧是2022年安静离职趋势的原因之一，员工只付出最低努力。确实，改善开发者体验可以防止职业倦怠，这是大规模离职的主要原因。此外，研究表明，变更时间越长的组织，离职率越高。
Lesley Cordero在伦敦DevOpsDays上解释说，慢性问题是重复发生和/或持续存在的问题。这些问题往往很难解决，这就是为什么它们会变成慢性问题的原因，但解决这些问题很重要，因为慢性问题实际上反映了组织中更大的问题。
不必要的障碍和审批流程会形成Cordero所说的习得性无助感文化。“这些情况会让人们对你团队保持价值观的能力失去信任。” 无谓地向开发者体验添加阻力会进一步损害动机并增加离职率。
但是，Kanat-Alexander说，大多数人工流程都是对风险的反应。当然并非所有需要人工参与的流程都是不好的。他举了代码审查的例子，作为判断代码简洁性、可理解性和未来可维护性的手段。
另一方面，像“我是否被允许调用这个特别危险的API?”这样的流程不应该需要人工判断，因为计算机应该能通过静态分析为你提供答案。“至少，静态分析应该能拒绝几乎所有情况，然后对需要申请异常的特定情况有详细的解释和理解”，根据确立和编码的异常政策。仍可能需要一个人工关卡，但这应该是异常情况。
任何延长交付时间的事情都会损害动机和创新实验的欲望。
之前，作者曾认为平台团队应该远离创新沙盒，平台应该服务99%的开发者，以免扼杀或限制剩下1%的创新者。但事实证明，没有完善的平台实际上可能会阻碍创新的速度。
“当你有一个平台时，你需要考虑致力于某项事业的长期业主和仅仅想涉足一天或两天的人。” Kanat-Alexander说。“平台团队经常会忽视第二种情况。他们认为，如果一个人需要花一个月来学习执行某个特定任务没问题，因为一旦他们这样做，这可能就是他们未来三年的工作。这不是很好。”
想象一下，他说，一个高级技术负责人每天只有几个小时来编写代码，但随后不得不面对各种权限障碍和等待时间，每次想要完成工作都是如此。
很难预测什么时候某人会想尝试新事物。他称之为创新与承诺开发的问题。如果设置存储库和在生产环境中获取机器需要几周时间，这些人为障碍会阻碍创新。
相反，在特殊安全区域轻松设置机器，具有默认访问权限和无个人身份信息。Kanat-Alexander说，平台团队应在其框架内设置自动化机制和默认模板，以便应用团队可以直接获取基础设施——因为大多数时候这不是他们正在尝试创新的部分。
你不可能处理每一种用例，但最终你可以处理其中约80%的情况，Kanat-Alexander说。“你希望开发者有这样的体验:大多数技术决策已经为他们做出——所有与他们试图实现的业务逻辑无关的决定。”
你必须能够说不。
“这些铺平道路的人必须能够对开发者说不。如果他们不能说不，他们就会变成一个涵盖面广泛的一刀切的庞然大物，满足每个需求，但都不出色。”
但是，通过将平台分层为他称之为“平台原语”的层次——其中一些可以访问内部开发环境、CI系统或构建系统——你可以将请求那些边缘用例的团队指向平台组件，以便他们自己构建它。
这可能是像Airflow或Terraform这样的语言，他说通常不会想让普通开发团队接触，所以你会将它们隐藏在用户界面后面。但是，当UI无法处理那些边缘情况时，你可以给予该团队访问权限来编写自己的代码。
Kanat-Alexander说，错误的解决方案是总是默认容许边缘情况，但是，有时候，“如果这些小众用例对业务真的足够重要，业务应该愿意投资专门的人在该团队或领域从事这些非常小众但很重要的基础设施工作。”
警告：如果你完全不帮助这些边缘情况，你的工程师会自己开发解决方案，这会导致运维扩张，使他们偏离黄金路径。
平台工程团队通常会收到大量需求。做一些临时补丁或仅提供概念验证的诱惑可能很大。但是以“平台即产品”的心态，意味着你要完成已经开始的工作，并致力于提供用户真正想要使用的高质量产品。
平台的成功依赖于基于用户反馈的持续改进。我们已经提到了在平台任务清单中优先考虑开发者需求的必要性。这些调查必须持续进行，以检查您是否满足他们的需求。 将平台指标以及不可避免的后续需求都纳入您的平台策略。
永远不要忘记平台工程的目标之一是实现自助服务。这意味着交付的定义依赖于它是否得到记录，最好是以高度可搜索和自助的方式。交付还意味着始终进行监控和报警，并在事件不可避免发生时进行事后总结。
为了实现所有这些，除了构建新的平台功能之外，你还需要能够与业务利益相关者进行沟通。“向管理层表达做出伟大工程工作的重要性需要非常强大的技能。” Kanat-Alexander说。你可能需要谈判不仅开发闪亮的新功能，还要保护时间来完善旧的功能。“交付”在很大程度上意味着不需要人工参与，“这在实际中是不可能完全实现的，因为团队、需求、工具和环境都在不断变化。然而，在大多数项目中，你可以在实际意义上实现这一点;将所需的人工参与降低到很低的水平，通过花时间打磨平台或工具的粗糙边缘。
平台需要持续致力于质量——你的同事值得你这样做。如果你不致力于提供完整的开发者体验，他们也不会使用它。
平台团队可能会养成“我猜没完成这个东西也没关系，因为这只是一件小事，它有多重要呢?”的习惯。但是Kanat-Alexander继续说，“软件是一个巨大的、持久的对象，通常是由大量人协作构建的。如果没有人监督有多少事情被留未完成，那么最终你可能会陷入相当大的困境。”