平台工程规模多大才合适？内部开发者平台的取舍与演进

"左移"和 DevOps 对我们从构思到生产环境实施变更的方式产生了巨大影响，但代价同样不小：认知负荷加重，测试、安全和维护等环节出现了重复性工作。如果一家组织已经运转了数十年，技术债务与文化壁垒带来的摩擦还会让这项工作再上一个数量级。

本文基于 KubeCon EU 2026 大会（阿姆斯特丹）上的一篇文章整理而成，核心话题是"平台规模多大才算恰到好处"。文章从确定开发平台合理规模、为使用平台的工程团队寻找文化契合点这两个维度，探讨了实际面临的挑战，目标是减轻认知负荷、加快变更交付。

平台之始

Wehkamp 开发并运行着大量涉及物流、数据科学和电子商务领域的软件。作为荷兰规模最大、历史最悠久的在线百货公司之一，它既有的业务流程与技术体系参差不齐，这自然带来了部门之间的隔阂与工程工作的重复。由于工作交接的特殊性，没有任何一个团队能够超越自身职责范围做改进或优化，多数努力最终都演变成了相互冲突的标准。

大约十年前，管理层定下了一个明确目标——从每季度发布改为每周发布，以便更快交付功能，真正的突破由此到来。我们成立了一个新部门，逐步整合原有的技术组织，并借助公有云、容器以及"零交接"工程模式，完成了首次重大变革。只要能输出可运行的容器并提交 Git 代码，就没有人会阻碍你交付变更。

如此大的权力（或者说所有权）也意味着更大的责任：团队需要管理资源消耗和运行时扩展，发布失败后还得能回滚到旧版本，或做前向修复。相比单纯交接工作，这种方式也有代价——你必须更深入地理解运行软件的系统，与可观测性系统协同，有时还得实时在生产环境中调试问题。

最初的平台缺少产品思维和抽象设计。我们曾以为，只要搭上"现代技术栈"，大家自然就会熟悉操作流程。但现实是，没有人能通晓一切，不同内容的文档质量也参差不齐。结果，工程师们被迫把精力浪费在繁琐的运维上。有时候甚至让人恍惚：过去某些交接流程虽然迫使大家重复做同样的研发工作，却反而保障了系统的正常运行。

自己成功的受害者

某种意义上，解决一种繁重的工作后，注意力就会转向下一种，就像在复杂系统中消除一个瓶颈，只会让另一个问题取而代之。通常，当收到的需求和工单从基础可用性转向边界情况和新功能时，我们就会察觉到这一点；同时，事件数量减少、成本控制更好，这些也都是信号。更强的责任担当与更合理的职责分配已经成为企业文化的一部分，但随着变更速度加快，我们很快就触及了原有"平台"概念的边界。

传统运维工作的时间占比越来越高：创建数据库、调整磁盘大小、日常资源管理等。这倒不是因为单项任务耗时变长，而是过去只是大型发布中一小块的内容，如今在大量小型发布中成了反复出现的摩擦点。后来，我们开始把冲刺任务拆成"实际"工作和"运维"工作，以确保能有专门时间开发新功能、改进现有系统，从而跟得上用户需求。

随着容器工作负载不断扩展，每周发布次数接近一百次，资源管理往往要推后好几天。这种延迟虽然不算太久，但已经跟不上我们的发布频率。一些团队开始自己写自动化脚本，通常会自动生成拉取请求，有时还会与 Terraform 和 Ansible 这类"基础设施即代码"系统产生少量重复。这种做法还带来了一些不必要的风险：不是每个人都按同一套标准处理标签、访问控制或资源回收；也不是每个团队都有能力选择这条路。

向平台工程迈进

我们必须采取行动，一方面减轻平台团队的负担，另一方面让基础设施的变更频率能随使用量同步提升。最初的步骤简单有效：开发一个聊天机器人，它根据预配置的 Terraform 模块和文本模板，结合用户提供的值，自动生成拉取请求。

图 1：使用可配置模板的自助工作流（图片由作者制作）

Atlantis 会响应已提交的拉取请求，并规划 Terraform 的变更；操作成功后，这些变更会自动应用到基础设施中，并合并到主分支。整个流程走下来，用户大约一分钟内就能拿到所需资源。这种方式既改善了自助服务体验，又减少了因生命周期策略缺失或标签不匹配这类常见缺陷导致的实现差异。

变体减少还意味着维护更简单、需要学习和记忆的内容更少，这让我们能在更小的范围内积累更深厚的专业知识。它还带来一个附加效果：因为大部分人的操作变得更轻松、更快捷，我们可以开始强制执行一些此前因生产力考虑而未被严格遵守的策略。首先，容器中不允许存在本地状态，应该假设它们随时可能消失。此外，不允许访问计算节点上的 shell。

这些指标本身并非最终目标，而是被当作项目里程碑和质量指引。如果我们能提供一个功能上足够可靠的系统，让这些目标不再构成问题，就说明我们在开发者赋能、稳健的运行时环境以及可预测的结果方面取得了重大进步。

也正是在那时，"平台工程"和 内部开发者平台（IDP）等概念开始流行起来。与我们此前那种"临时抱佛脚、先左移再修复"的路径相比，这些实践和概念的定义要清晰得多。当我们从每周 100 次发布过渡到每天 100 次发布时，这种差异变得更加明显，因为变更速率已经不只是体现在现有服务的发布上。服务的上线和下线也在同样快速增长，资产盘点、资源配置和模板管理逐渐成为最突出的瓶颈。

一个新平台

向更成熟的平台模型转型，主要侧重于技术和产品交付。整个团队都已做好准备，迫切期待看到新成果，因为大家早已通过早期转型亲身感受到更快开发流程带来的好处。他们的期待为我们推进下一阶段工作提供了必要支持。

除了自身资源调配系统的不足，容器编排栈也接近废弃。完全依靠自身完成所有维护工作已经超出我们的能力范围。与此同时，工作负载身份识别和动态扩展等功能所必需的底层基础设施根本不存在，功能需求也变得越来越难实现。现实很直白：我们需要一个新平台。但如此棘手的任务，究竟该从哪里入手？

在最近一次 KubeCon 大会上，我们了解到，其他团队也在面对同样的问题，但解决思路千差万别。例如，在一场题为"组建和扩展平台工程团队"的演讲中，一个团队构建了一个新的多区域键值存储作为平台基础，因为在他们看来，这会极大简化并统一其他团队的数据查询和存储工作。这与 Spotify 的 Backstage 走的路截然不同——后者更侧重可发现性、自助服务和开发者体验。

提前确定要构建何种类型、何种范围的平台，是一项艰巨的任务。你需要先在组织内部明确"平台"的定义，并评估自身构建平台的能力。最初尝试时，我们专注过资源配置、运行时服务，甚至曾在用户界面和流程上耗费整整一个冲刺周期，最终却发现一次性完成所有工作实在力不从心。起步阶段确实很艰难！

如果把上述两个平台案例看成光谱的两端，Wehkamp 希望落在中间地带：

图 2：技术细节与协作之间的平衡（图片由作者制作）

平台具有多重属性，但从这个视角出发，我们可以探讨所关注内容的前半部分——技术实现层面。一方面，平台可以是用户构建应用程序的基础组件库；另一方面，平台也可以不直接提供解决方案，而是通过构建目录和框架系统，推动用户社区贡献自己的构建块。

另一半则是社区因素：平台团队与平台用户之间能否实现双向协作与贡献？有些平台设施本质上确实是自上而下的，但总体来看，我们处在两者之间：

图 3：额外的平衡轴，用于展示自主性与需求之间的关系（图片由作者制作）

如果我们事先能有一张这样的图表，找到属于自己的定位会比实际情况容易得多。我们早期的目标和构想建立在开发与运维之间那种经典割裂之上，而这种割裂与"中间地带"可谓相去甚远。

过去，职责和问责都与各自的孤岛捆绑在一起，共享工具风险很大。如果已经配置好的资源出现问题，构建自动化流程的人就会受到指责——实施方承担了全部风险，却几乎得不到任何好处。

为了摆脱这些固有观念，我们把视角转向基础设施和所有权，将平台资源分为两种治理类型：仅消费型和多方共享型。

仅消费型资源通常指服务所有者使用但无需自行定义的资源，例如公有云基础设施或可观测性系统。多方共享型资源则主要涵盖横切关注点，比如消息传递和流量。这类资源需要所有参与方直接参与，而且只有当所有参与方都遵循同一套规则时，才能正常运作。

把治理模型与上图结合后，我们就可以开始厘清平台和工程关注点该归属何处：

图 4：将各种实例映射到我们选定的治理模型上（图片由作者制作）

如果某项能力位于图表顶部附近，平台应该直接提供它，尤其是在左上角区域——那里的治理模式是"仅消费"。相比之下，内部 SDK 之类的功能既由工程团队提供，也由其消费。这种模式同样适用于 Apache Kafka 这类系统：主题和消息牵涉多方，但代理和存储仅供消费，所以它落在图表右上角。

当前模型

由于无法支持所有可能的资源及其全部配置组合，我们定下两条基本规则。第一，稳固的基础有助于你达成目标（黄金路径）。第二，要么遵循规则，要么给出合理解释——你可以采取其他做法，但必须有充分的理由。

这种方法既不会阻止局部变体或实验，也不会让这个过程毫无阻力；你必须统筹协调跨团队协作、预算资源与专业技术能力，或者通过其他可行方式证明你的需求确实可落地。

图 5：随着选择路径的分化，所需的努力和必要性证明逐渐增加（图片由作者制作）

这是一种逐步加强的趋势：解决方案定制化程度越高，为构建它所需的故事和资源就必须越出色。反过来也一样，如果你足够贴近黄金路径，几乎可以不费吹灰之力就立即获得所需的一切。

为了实现这一目标，我们首先从那些以应用交付为核心的功能入手。不这样做的话，即使投入大量精力，也无法为业务端带来差异化优势：

• 你需要一个 Git 存储库
• 存储库中的软件需要构建
• 软件构建完成后，需要打包和存储
• 打包后的软件需要一个运行环境
• 软件运行期间，需要监控运行结果
• 软件要真正发挥作用，可能还需要一些依赖项，比如 HTTP 流量、对象持久化以及 Kafka 消息传递和队列

这些看似抽象的需求都有具体的实现方式和支撑技术。只要满足这些需求，大多数应用程序原型都能从头到尾构建完成，不需要提交工单，也不需要等别的团队动手。

自助服务和资源配置与我们之前的流程类似，但不再用文本聊天界面，而是直接与图形用户界面（GUI）集成，上手速度更快：

图 6：使用更高层次的构建块界面（图片由作者制作）

作为平台用户，你可以从菜单里选择常见的构建块，这些构建块几乎可以实时部署，不再需要像过去那样手动运行 Terraform、访问 GitHub 或打开云控制台。系统仍会将更改提交到 Git，并由 Atlantis 负责处理 Terraform 以及分支合并。

这并非管理基础设施或具体应用依赖的唯一（或最佳）方式，但它允许我们在流程的任何环节"打破玻璃"（即进行干预），并复用已有的知识和经验。Git 提交可以手动完成，基础设施工具可以手动执行，如有需要，配置本身也可以手动编写。

随着应用程序演进，资源可能需要调整，这可以借助相同的底层 GitOps 工作流来实现。这类调整并不频繁，而且很少阻塞变更交付，所以没必要为此专门开发自定义 GUI 功能和复杂的后端服务。配置存储在 Git 中，改动只需提交一个拉取请求。资源范围限定在应用程序及其负责团队之内，影响面有限，所以只需要一次审核，Terraform 就能自动应用变更。

本质上，这是一个自助式脚手架系统的精简实现，构建基础是我们内部一系列广为人知的应用类型（如 API 服务、CronJobs、数据处理服务和微站点）。它依然支持我们早期提出的"你提供容器，其余由我们负责"这一理念，但认知负荷更低。同样的理念也应用于这些工作负载的部署或构建产物：如果容器暴露了标准遥测数据和健康状态，我们便用标准化的 Helm 图表和 ArgoCD ApplicationSets 部署你的应用，保持其正常运行、弹性扩展、报告健康状况并提供运维洞察。

随着时间推移，越来越多的功能可以作为开箱即用能力提供。有时这些功能来自此前未默认包含、却又反复出现的自定义设置，例如密钥管理和外部 TLS 身份验证。从技术上讲，任何人都可以构建自己的实现，但这会带来额外的认知负担和分布式维护问题——如果每个重复实现都依赖一个团队甚至一个人，成功的可能性将大大降低。反过来，如果你确实需要构建一些特殊功能，只要手里有维护计划，完全可行。

这种方法也让我们能推行全组织范围的标准和默认设置，比如默认不向任何流量暴露服务，但同时支持用户自行配置。你无法绕过 Web 应用防火墙（WAF）或双向传输层身份验证（mTLS），也不能使用任意的完全限定域名（FQDN）；但你可以启用不同的流量类别——面向消费者的请求、第三方集成或内部经过身份验证的请求，并采用安全默认设置（如过滤掉可能更改数据的 HTTP 动词）。前端微站点可能只需要 GET 和 HEAD 方法提供页面和资源，但如果开发人员的工作负载需要（比如购物车或愿望清单 API），也可以启用 PUT、POST 和 DELETE 这些"不安全"方法。这种模式让包含写入操作的服务暴露成为一种显式选择，而非意外情况。

门户网站已基本实现

到目前为止描述的系统和服务，都是随着时间推移逐步构建起来的，并且根据使用情况、指标和用户反馈不断调整。多年来，我们创建并淘汰了各种平台功能：从 Mesos 迁移到 Kubernetes，从自建流量网关和代理迁移到开源服务网格 Istio。配置管理也从多种命令式来源，转变为使用 Terraform 和 Kubernetes 配置文件支持所有工作负载的单一声明式标准，这才走到了今天。但这些变化并非线性发生。

起初，我们并不清楚给平台团队或其他团队造成最大工作负荷和阻力的到底是什么，只能粗略区分运营工作与其他工作，并收集关于资源配置和变更周期的反馈。团队与团队之间情况差异很大，对平台的体验也各不相同。有些团队掌握了足够知识，能自行处理遇到的各种技术平台细节。

早些时候，我们曾以为每个人都想管理底层技术细节，构建自己的模块、模板、管道和仪表盘。为了确保这种模式既安全又高效，我们觉得需要一个功能全面的门户，包含复杂的质量控制机制和严格的基于角色的访问控制（RBAC）矩阵。这样各团队就能按自己的节奏实现所有技术细节。但现实是，这种设计并没有减轻任何认知负荷。

当我们意识到这条路并非真正所需时，便转向了完整的内部开发者门户思路。我们曾多次尝试实施 Backstage，却没有意识到它的维护工作和我们之前的运维驱动型冲刺非常相似。在那种模式下，能否成功取决于其他团队的协作，需要他们主动贡献、分担维护人力。这样的设计实际上走不通。

从更宏观的角度看，真正的价值仍然在于能够推送大量变更，并且能在不了解每个细节的情况下基本自主地开展工作。这并不总需要一个内部开发者门户（IDP），也不需要用于构建应用程序的自定义底层系统和基础架构，更简单的工具和实践往往就能实现。

小结

平台工程的重点并非构建最全面的内部开发者平台，而是构建组织真正需要的那个平台。合适的范围取决于组织的工程文化、交付瓶颈，以及构建和维护共享组件的能力。

第一步，消除那些最严重阻碍软件交付的摩擦源，投资于能有效解决常见问题的、立场鲜明的"黄金路径"。不要屈从于把每个边界情况都自动化的诱惑，也不要仅仅因为其他组织有某些功能就盲目开发。每项平台能力都伴随持续的维护成本，只有当复杂性能为开发者体验和交付性能带来可衡量的提升时，它才物有所值。

最成功的平台会随着其所服务的团队共同发展。工程实践日趋成熟时，可以在能创造明确价值的地方添加新功能；同时，对于真正有不同需求的团队，仍然保留定制化解决方案的空间。把平台视为一种在标准化与灵活性之间持续演进的产品，可以减轻认知负荷、提升软件交付效率，并构建一个在组织和技术不断变化的背景下仍然可持续的平台。这类关于平台工程边界与演进的讨论，在 云栈社区 上也一直很活跃。

原文链接： https://www.infoq.com/articles/rightsizing-platform-engineering/