当开发人员在跨国规模上工作时，手动工作、工具蔓延和缓慢的 DevOps 流程会加速倦怠。 创建“黄金路径”可以加快速度，让每个人都更快乐。
译自 How Platform Engineering Enables the 10,000-Dev Workforce，作者 Jennifer Riggins。
根据一项针对大型和中型组织的开发人员和工程负责人的调查，大约四分之一的开发人员每个月至少有一半时间在加班。
也许并不奇怪，倦怠 是调查中超过一半的开发人员认为同事离职的原因。
即使他们留下来，45% 的开发人员表示他们没有足够的时间学习和发展——这几乎是 DevOps 工具复杂性所要求的。（该研究还发现，开发人员在工作中平均使用 14 种不同的工具。）
2024 年开发者体验状况 报告是由软件交付平台 Harness 进行的一项调查，调查了美国和加拿大拥有 250 名或更多开发人员的公司中的 500 名工程负责人和开发人员。
该报告于 2 月发布，指出了导致开发人员过度劳累的一些常见原因：缺乏针对浪费时间的苦差事的自动化、过多工具选择带来的混乱和缺乏标准化，以及不够成熟的 DevOps 流程。
其结果是，试图构建和交付软件的开发人员遇到了太多令人沮丧的瓶颈。事实上，调查中 60% 的公司表示，他们只在每月或每季度发布一次代码。
对于规模庞大的跨国企业（拥有数千或数万名开发人员的航空公司、银行、电信公司等）来说，这是一个慢得令人痛心的节奏。由于这些组织的规模，所有这些苦差事、复杂性和挫折的成本都呈指数级增长。
在这样的组织中，平台工程 提供了一种引人注目的解决方案，可以通过真正 增强开发者体验（通常称为 DevEx）的方式来提高业务竞争力。例如，报告发现，通过自动化减少不必要的苦差事可以将开发人员的生产力提高 37%。
Harness 的创始人兼首席执行官 Jyoti Bansal 表示，开发人员面临的一个大问题是，他们在对他们和他们的组织最重要的事情上花费的时间不够多。
“如果你看一下数据，大约 40% 的软件开发人员的时间都花在了与编写代码无关的苦差事上，”他告诉 The New Stack。
他说，相反，全球近 3000 万开发人员 都在与“与编写代码之后发生的事情相关的苦差事作斗争——部署、构建、测试、安全、治理、合规”。
开发人员的苦差事是指任何重复的、手动的和/或低价值的工作。DevOps 的支柱之一是自动化。三法则 认为，由于创建可重用内容的难度是其三倍，因此等到你第三次做同样的事情时，再将其自动化或重构。
Bansal 认为，像 Harness 这样的 内部开发者平台 可以自动化和简化开发人员的大部分繁重工作。 “有很多关于如何让开发人员更高效地编写代码的讨论，”Bansal 说，但“在编写代码之后还有很多事情要做。”
而且，正如我们之前写过的，编写代码是开发人员最想做的事情，所以最好专注于优化开发人员角色中其他分散注意力的方面。不幸的是，很多 面向开发人员的生成式人工智能 都专注于 代码生成。
根据 Harness 的报告，企业开发人员的生活中有很多等待时间。
“如果你是一名编写了代码的开发人员，并且你正在等待 40 分钟来构建你的代码，那么这 40 分钟基本上是被浪费了，”Bansal 说。
是的，您可以冒险上下文切换到另一个任务，但如果一个小时后您发现第一个构建出现问题，这可能会导致上下文丢失。Bansal说：“您希望在转向下一个任务之前完成您正在进行的任务。” “那么我们能否将 40 分钟的构建时间缩短到 10 分钟？”
他指出，在部署代码时也是如此。开发人员必须随时待命以进行故障排除，这可能会让他们干坐两个小时或更长时间。最后，这种工具的广度导致高达 97% 的开发人员回应说，他们进行上下文切换是因为他们的工具来自多个供应商。
“如果你看一下数据，大约 40% 的软件开发人员时间是与编写代码无关的苦工，”Harness 创始人兼首席执行官 Jyoti Bansal 在谈到他的公司对开发人员体验的调查时说道。（Jennifer Riggins 摄。）
除此之外，流程状态的中断，开发人员没有足够紧密的反馈循环，并且承受着不断增长的认知负荷。结果是开发人员体验明显不佳。对于新人来说更糟糕：71% 的受访者表示，他们在各自的组织中至少需要两个月的时间才能入职。
除此之外，Harness 进行的同一项开发人员体验调查发现，开发人员学习新的 DevOps 工具需要一周多的时间。大约 60% 的受访者表示，构建内部工具至少需要一周的时间。
平台工程的主要目标之一是通过为开发人员提供有限数量工具的“黄金路径”，来控制开发人员工具的蔓延。
Harness 的研究人员进行了计算，发现通过平台工程策略整合工具，对于一个由 1,000 名开发人员组成的团队，每人年薪 100,000 美元，可能会产生以下影响：
- 开发人员生产力提高 53%。
- 减少 15% 的部署时间。
- 每年可节省 158,000 个工作小时，相当于节省 790 万美元。
这项调查和其他几项开发人员体验调查的结果是要求改进 DevEx。
Bansal 说：“需要做多少工作来改善开发人员体验，这真是令人大开眼界。” “他们的体验对你的底线至关重要。”
除此之外，开发工具的蔓延正在导致组织订阅疲劳，并将您的数据和风险暴露在众多平台上。
复杂性和缺乏自动化减缓了交付软件的整体速度。
在接受调查的公司中，60% 的公司每月或每季度发布一次代码。这些公司在低到中等 DevOps 成熟度 DORA 指标中得分，至少在部署频率方面是这样。
在 Harness 的调查中，开发人员和工程负责人反思了他们目前的雇主，并说明了他们以这种较慢的速度发布代码的原因：
- 44% 的受访者表示，端到端测试代码的速度不够快或效率不够高。
- 42% 的人表示将代码部署到生产环境的速度不够快或效率不够高。
- 67% 的人表示，开发人员需要等待一周多的时间才能完成代码审查。
- 42% 的开发人员认为，如果不在不引入故障的情况下将代码发布到生产环境中，他们就无法做到。
- 39% 的开发人员至少有一半的时间会遇到故障。
- 32% 的公司缺乏较高的单元测试覆盖率。
- 在 28% 的公司中，构建和测试工件至少需要一天的时间。
- 在 67% 的公司中，开发人员仍然手动回滚。
在 Harness 调查的开发人员中，令人担忧的是，有 40% 的开发人员认为他们的组织没有在整个软件开发生命周期 (SLDC) 中实施良好的安全和治理策略。使问题进一步恶化的是：
- 41% 的开发团队没有自动化的安全和治理策略。
- 42% 的开发团队没有强大的 身份和访问管理 策略。
虽然设置路障是为了安全着想，但安全和治理通常被视为减缓功能团队的速度。速度不应以牺牲安全为代价，相反，安全是速度的通道。
渐进式交付 技术通常内置于 Harness 等内部开发者平台中，并限制变更的影响范围。CI/CD、功能标志、弹性测试和安全测试都有助于您更快地失败和恢复。
Bansal 表示，在一个成熟的平台组织中，大多数安全检查应该是自动化的，这样开发人员就不会“因为等待某人批准或审查而被阻塞”。
Bansal 说，让庞大企业中的开发人员提高效率，并不是要求他们更加努力地工作。而是要消除瓶颈，消除或加快低效率。
采用平台工程战略整合工具绝对是解决方案的一部分。
2022 年，美国联合航空公司计划以前所未有的规模扩展业务，目标是将其 80% 的工作负载迁移到 Amazon Web Services，其中包括从单体架构迁移到微服务架构以及从传统工具迁移。
“我们当时正在推动我们的团队迁移到云端，但这有一系列依赖关系，开发人员必须更快地迁移，”美国联合航空公司 IT 总监 Ratna Devarapalli 说。
通过迁移到 Harness CI/CD 平台（包括可重用模板、自动化管道生成和部署优化），该航空公司能够提高自动化和自助部署。
“我们能够向开发人员提供治理策略，并创建我们需要的护栏，”Devarapalli 说。“Harness 为我们提供了一个平台，而不仅仅是一个 DevOps 工具。”
这使得部署时间缩短了 75%，并显著减少了上下文切换。
“如果它是一个完全自动化的管道，其中内置了所有检查和平衡，以及自动回滚和自动验证，那么您就不需要，”等待构建成功与否，Bansal 说。“你希望事情失败。你希望更频繁地部署。但你不希望失败影响到任何事情。”
想知道是什么阻碍了您的开发人员？问问他们！
开发人员的挫败感通常是开始衡量开发人员体验的好地方。但是，当您尝试与成千上万的开发人员一起这样做时，相信他们的直觉可能无法扩展。
人们如何知道他们花了多少时间来完成任何给定的任务？Bansal 问道：“软件工程行业没有很好的方法来衡量事物。”
Harness 有一个软件工程洞察模块，允许团队发现其软件开发生命周期中的瓶颈，评估团队生产力和衡量开发人员体验。此功能具有 200 多个集成，可以从以下来源汇集团队和问题级别的数据：
- Jira 工单
- GitHub 提交
- Jenkins 构建
- Harness CD 部署
- 事件管理工具
Bansal 说，他的平台不是衡量单个开发人员的生产力，而是衡量工程流程的质量。
“一个包含 SDLC 中发生的每一件事的数据仓库，”Bansal 称之为。“您可以获得不同项目、不同应用程序、不同业务部门所有事情的完整时间线。”
在此基础上，该模块通过以下方式提供跨组织的可见性：
- 生产力得分
- DORA 指标
- 敏捷指标
- 投资分析
- 目标跟踪
- 行业基准测试
根据 Bansal 的说法，一些更有趣的开发人员生产力指标包括交付时间，以及从 Jira 中接收工单开始的跟踪。
此时间线跟踪还为错误跟踪提供了上下文。它将产品与工程现实联系起来。
“有人说：我需要这个功能，当开发人员拿起它时，如果需要数周或数月的延迟，”Bansal 说，这可能是一个调查阻塞因素的信号。
“一旦开发人员拿起它，到它构建完成，其中发生的事情是需要多少代码提交，[拉取请求] 审查需要多少东西——开发人员进行更改，然后必须有人审查它。这浪费了两天时间。”
他说，构建很可能可以通过技术来减少，但不要忽视流程。如果同行评审需要两天时间，您是否需要腾出更多高级开发人员？ 他还说，请记住，不要仅仅为了速度而衡量，还要衡量质量和对生产的影响。
Bansal 说，软件开发的社会技术过程并不像我们想象的那么线性，但它是可以衡量的：“你必须把整个叙述从衡量开发者转变为衡量过程，并调整和优化过程。”