把平台当成产品看，是什么意思
一句话总结
平台工程的目标不是配备更多工具，而是降低流对齐团队的认知负荷（cognitive load）。因此，平台不是项目，而是产品；用户是其他开发团队；成功指标也不是部署次数，而是自愿采用率。
为什么需要它
随着“You build it, you run it”流行起来，许多组织把运维责任推给开发团队。初衷很好，结果却是开发者需要掌握的知识爆炸式增长：语言与框架、领域逻辑，再加上 Kubernetes、Helm、Terraform、CI 语法、Secret 管理、可观测性栈、网络策略和成本优化。
Team Topologies 把这种现象称为认知负荷超载。认知负荷分为三类。
| 类型 | 内容 | 应对方式 |
|---|---|---|
| 内在负荷（intrinsic） | 语言、数据结构等基础能力 | 通过培训与招聘解决 |
| 外在负荷（extraneous） | 按顺序编写八份 YAML 的流程 | 平台必须消除的对象 |
| 相关负荷（germane） | 领域问题本身 | 应让大脑专注于此 |
平台工程的工作，是吸收外在负荷，为相关负荷腾出空间。因此，“我们的平台做得好吗？”不能用工具数量回答，而应问：开发者有多少时间用在领域问题上？
它如何工作
作为产品的平台
把平台当成项目时，流程通常是：收集需求，花六个月建设，部署，然后解散团队。把平台当成产品则完全不同。
- **它有用户。**用户是内部开发者，而且如果不愿意，他们可以不使用。
- **它有路线图。**也会明确决定哪些事情不做。
- 它有入门文档与支持渠道。
- **它有版本和弃用策略。**昨天能用、今天却损坏，会让信任消失。
- **它有成功指标。**采用率、首次部署耗时、支持工单数量。
最重要的判断标准只有一个：**在人们没有被强制要求的情况下，他们仍然会使用吗？**依靠公司规定强制达到 100% 的平台，测量的不是采用率，而是服从率。服从率高而满意度低，说明平台正在失败，只是指标掩盖了事实。
Team Topologies 的四种团队类型
CNPA 会直接考查这一分类。
| 团队类型 | 职责 |
|---|---|
| Stream-aligned | 端到端负责一条价值流（产品、功能或用户旅程），应构成组织的大多数团队 |
| Platform | 提供流对齐团队可自助使用的内部服务 |
| Enabling | 临时弥补其他团队的能力差距，不会常驻，完成后会离开 |
| Complicated-subsystem | 负责需要深厚专业知识的部分，如视频编解码器、支付结算、数学引擎 |
此外还有三种交互方式：Collaboration（暂时紧密合作，共同发现问题）、X-as-a-Service（边界明确的消费关系）和 Facilitating（完成教学后退出）。平台团队的正常状态是 X-as-a-Service。如果平台团队长期与所有流团队保持 Collaboration，说明平台尚未真正实现自助服务。
DevOps、SRE 与平台工程
三者不是竞争关系，只是关注重点不同。
- DevOps 是文化与原则：消除开发和运维之间的壁垒。它不是团队名称。如果组建“DevOps 团队”代替其他团队完成部署，只是给原本要消除的壁垒换了一个名字并重新建立起来。
- SRE 是把可靠性作为工程问题处理的具体实践，包括 SLI/SLO、错误预算、减少 toil 和无责事故复盘。它关注的是服务可靠性。
- 平台工程 把这些实践包装成自助服务产品，使其能够交付给众多团队。它关注的是开发者体验。
三者有很大重叠。平台也应拥有 SLO（SRE 的方法），平台团队也应自行运维自己的平台（DevOps 的原则）。真正的分界是“为谁优化”：SRE 优化最终用户体验，平台工程师优化内部开发者体验。
实际现场中的表现
作者的七节点家庭实验室是这个故事的缩影。Cilium 1.20 eBPF CNI、MetalLB L2（10.0.0.200-215）、Harbor 镜像仓库（10.0.0.202）、Gitea（10.0.0.200）、Argo CD（10.0.0.201）、kube-prometheus-stack 与 Grafana（10.0.0.203）、CloudNativePG、管理 4 块 GPU 的 GPU Operator、KubeVirt、csi-driver-nfs——只看技术栈清单，它像是一个出色的平台。
但安装各组件时发生的事故，才真正展示了平台的价值。Gateway API 需要 CRD v1.6.1，使用 v1.2 时控制器拒绝启动。KubeVirt 的组件状态全部为 AllComponentsReady，VM 却无法启动，原因是 virt-launcher Pod 缺少卷挂载。containerDisk 路径存在缺陷，只能绕行 DataVolume（PVC）路径。
这些知识全都是外在认知负荷。想要开发服务的开发者没有理由了解它们。平台团队的工作，是亲自踩过这些陷阱，然后把成果包装成“一条黄金路径”，避免其他人再次踩坑。同一个集群第三次验证了**“状态 Ready”与“实际工作”是不同命题**，这也说明平台要提供的不是安装结果，而是经过验证的路径。
接下来阅读什么
下一篇阅读将梳理平台成熟度阶段，以及内部开发者平台（IDP）的组成部分。再下一个模块会在真实集群中使用 CRD、CR、ResourceQuota 与 RBAC，亲手构建如何将 Kubernetes API 扩展为平台 API。