“左移”和 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/
