平台工程已成为软件组织中讨论最多的学科之一，而且理由充分。在经历了十年的”你构建，你运行”DevOps文化后，许多公司发现了一个令人不安的真相：赋予每个团队完整的运营责任并没有让他们变得更快。反而让他们把一半的时间花在与基础设施的斗争上，而不是构建产品。
平台工程的承诺是通过构建一个内部开发者平台(IDP)来解决这一问题——这是一个精心策划的自助服务层，它抽象了基础设施的复杂性，同时保留了DevOps所承诺的自主性。但是，构建一个平台与构建一个团队实际使用的平台之间存在巨大差距。本文是一份实用的指南，帮助您弥合这一差距。
平台工程与DevOps：澄清混淆
平台工程不是DevOps的替代品。它是解决DevOps扩展问题的一种演进。
DevOps打破了开发和运营之间的壁垒，但它通过将运营知识分散到每个团队来实现这一点。在一个50人的初创公司，这种方法效果很好。但在一个拥有40个产品团队的500人组织中，它创造了另一个问题：每个团队都在独立解决相同的基础设施挑战，做出不同的选择，并积累不同的运营债务。
平台工程将共同的基础设施关注点集中到一个专门的团队中，该团队构建和维护共享平台。产品团队通过自助服务界面使用平台，而不是提交工单或阅读运行手册。关键区别在于：
- DevOps是一种文化和实践，强调开发和运营之间的协作。
- 平台工程是一门学科，它构建产品（内部平台）使DevOps实践可扩展。
平台团队不取代运营团队。它取代了每个团队之前独立进行的无差异化的繁重运营工作。
内部开发者平台的组成部分
一个有效的IDP不是单一工具。它是多种能力的组合，共同提供连贯的开发者体验。核心组件包括：
服务目录
服务目录是您平台的前门。它提供了每个服务的统一视图，包括其所有权、依赖关系、部署状态、文档和运营健康状况。没有服务目录，开发者无法找到已存在的内容，导致重复和不一致。
一个好的服务目录能回答以下问题：谁拥有这个服务？它依赖什么？上次部署是什么时候？它现在健康吗？文档在哪里？它暴露了哪些API？
黄金路径
黄金路径是针对常见任务的意见化、预配置模板。需要创建新的微服务？黄金路径提供了一个模板，其中已设置 CI/CD 配置、可观测性工具、安全扫描和部署清单。需要配置数据库？黄金路径提供了一个自助服务流程，可以处理配置、备份设置和访问控制。
关键词是”意见化”。黄金路径编码了组织最佳实践。它们不是强制执行的——团队在有充分理由时可以偏离——但它们让正确的事情变得简单易行。
# 示例：黄金路径模板清单（简化版）
apiVersion: platform.company.com/v1
kind: ServiceTemplate
metadata:
name: rest-api-service
spec:
language: go
framework: chi
infrastructure:
database: postgresql
cache: redis
queue: rabbitmq
observability:
tracing: opentelemetry
metrics: prometheus
logging: structured-json
ci:
pipeline: github-actions
stages: [lint, test, security-scan, build, deploy]
deployment:
strategy: rolling
environments: [dev, staging, production]自助基础设施
自助基础设施让开发者能够配置和管理资源，而无需提交工单或等待平台团队成员。这通常意味着通过 UI 或 CLI 提供的 Terraform 或 Pulumi 模块，并带有护栏来强制执行安全策略、成本限制和命名约定。
目标不是让开发者直接访问云控制台。而是提供经过策划的、符合政策的资源配置，它比提交工单更快，但比无限制访问更安全。
开发者门户
开发者门户是将所有内容联系在一起的用户界面。它为服务管理、文档、API 探索、环境管理和平台自助服务流程提供了单一视图。
工具生态：Backstage、Port 和 Cortex
已经出现了多个平台来加速 IDP 的构建。每个平台都有不同的权衡：
Backstage (Spotify)
Backstage是这个领域的开源巨头。最初由 Spotify 构建以管理其庞大的微服务架构，它提供了一个基于插件的开发者门户框架，包含服务目录、文档系统（TechDocs）和软件模板。
优势：庞大的插件生态系统，强大的社区，完全可定制，无供应商锁定。劣势：显著的设置和维护负担，需要专门的工程投入，基于 React 的 UI 可能感觉难以扩展。Backstage最适合有能力投入定制化和持续维护的组织。
Port
Port 采用无代码/低代码方法构建开发者门户。它提供了灵活的数据模型，您可以通过可视化界面定义”蓝图”（如服务、环境、部署等实体）和”操作”（自助服务工作流）。
优势：快速实现价值，无需前端开发，灵活的数据建模，内置 RBAC。劣势：仅限 SaaS 模式（某些组织对数据驻留有顾虑），对于高度特定的 UX 需求，可定制性不如 Backstage。Port 适合希望快速获得功能完善的内部开发者平台（IDP）而不愿组建专门团队进行门户开发的组织。
Cortex
Cortex 专注于工程成熟度和运营卓越。除了标准的服务目录和评分卡外，它还提供”计划”——推动整个组织采用标准的活动，例如迁移到新版本的 Kubernetes 或采用安全扫描工具。
优势：强大的评分卡和成熟度跟踪，计划管理，良好的 Kubernetes 集成。劣势：对于自定义工作流，不如 Port 或 Backstage 灵活，主要专注于运营健康而非完整的 IDP 功能。Cortex 适合主要痛点是团队间运营成熟度不一致的组织。
衡量开发者体验
无法衡量就无法改进，而开发者体验指标 notoriously 难以准确获取。平台工程社区已经形成了几种方法：
DORA 指标
四个 DORA 指标——部署频率、变更前置时间、变更失败率和平均恢复时间——仍然是衡量交付性能的黄金标准。一个运行良好的 IDP 应该随着时间的推移显著改善这些指标。
SPACE 框架
SPACE 框架由微软、GitHub 和维多利亚大学的研究人员开发，通过测量五个维度提供更细致的视角：满意度和幸福感、绩效、活动、沟通与协作、效率和流畅度。平台团队应该跟踪每个维度至少一个指标。
开发者调查
量化指标告诉您发生了什么，而调查告诉您原因。定期的开发者体验调查（至少每季度一次）帮助平台团队识别仅靠指标无法发现的痛点。关键问题包括：部署新服务有多容易？获取开发环境需要多长时间？您日常工作中最令人沮丧的部分是什么？
首次部署时间
最具启发性的指标之一是新员工首次将变更部署到生产环境所需的时间。这个单一数字捕捉了整个开发者入职体验，从文档质量到环境设置，再到 CI/CD 管道的可用性。领先的平台组织追求的是小时级别，而不是天或周。
避免”建了也没人用”的困境
内部平台的坟场里堆满了技术上出色但无人使用的系统。采用是平台工程中最难的问题，需要将你的平台视为拥有内部客户的产品。
从用户研究开始
在构建任何东西之前，先与你的开发者进行访谈。跟随他们工作一天。找出实际的痛点，而不是你假设他们有的痛点。最常见的错误是构建一个解决平台团队感兴趣的问题，而不是开发者实际面临问题的平台。
发布 MVP，而非愿景
你的第一个版本应该出色地解决恰好一个痛苦的问题。如果开发者需要花四个小时为新服务设置 CI/CD，就构建一条黄金路径，将其缩短到 15 分钟。在扩展范围之前展示价值。
让采用变得轻而易举
如果使用平台需要阅读 50 页的指南，你已经输了。最好的平台之所以被采用，是因为它们明显比替代方案更简单。自助工作流程应该有合理的默认设置。模板应该开箱即用。文档应该易于发现且简洁。
培养拥护者，而非强制规定
强制团队采用平台会引起反感。相反，应该找出早期采用者，为他们提供白手套支持，并放大他们的成功故事。当其他团队看到他们的同行使用平台发布得更快时，采用就会自然发生。
保持反馈循环
应该以对待面向客户问题的同样紧迫性来对待平台用户的错误报告和功能请求。对内部反馈的缓慢响应是扼杀平台采用的最快方式。
平台工程的团队拓扑
平台团队的组织结构与技术同样重要。Matthew Skelton 和 Manuel Pais 的《团队拓扑》框架为此提供了有用的术语：
平台团队作为赋能团队
在早期阶段，平台团队应该作为赋能团队运作——嵌入产品团队，了解他们的工作流程，并构建消除摩擦的能力。这个阶段是关于学习和关系建立。
平台团队作为平台团队
随着平台逐渐成熟，团队转型为真正的平台团队，提供自助服务能力，最小化直接互动。平台团队与产品团队之间的界面变成了平台本身，而不是会议和Slack消息。
团队配置
高效的平台团队是跨职能的。你需要了解Kubernetes和云平台的基础设施工程师，但同样需要能够构建良好用户界面的软件工程师，能够创建清晰文档的技术文档撰写者，以及理想情况下将平台视为产品的产品经理。
一种常见的反模式是仅用基础设施专家配置平台团队。这会产生技术复杂但用户体验糟糕的平台——这与没有平台无异。
常见陷阱
- 过度构建抽象层。 隐藏过多复杂性的抽象层会成为开发者不信任的黑盒。当出现问题时，他们需要了解底层发生了什么。
- 忽视逃生舱口。 每个平台都需要在用例确实需要时，让团队能够偏离黄金路径的方式。没有逃生舱口的平台会导致影子IT的产生。
- 将平台视为基础设施。 平台是一个产品。它需要路线图、用户研究、UX设计和定期发布。将其视为”仅仅是基础设施”必然导致采用率低下。
- 低估维护工作。 构建第一版令人兴奋。而维护它、保持与上游变更的兼容性以及支持用户，才是真正工作的开始。
结论
平台工程不是银弹，内部开发者平台也不是你可以直接安装的东西。它是你需要构建、迭代并根据工程组织需求持续改进的东西。
在这一领域取得成功的组织具有共同特征：他们将平台视为产品，从小处着手并根据已证明的价值进行扩展，在用户体验和技术能力上投入同等重视，并且他们不通过基础设施的复杂性来衡量成功，而是通过开发者的生产力和满意度。
如果你的工程组织已经超越了”每个团队管理一切”的模式，并且准备好构建平台，从一个棘手的问题开始，好好解决它，然后在此基础上扩展。策略很简单，真正的技巧在于执行。