量什么，平台才会变好
一句话总结
DORA 四项指标用于衡量部署流水线的健康状况，而不是平台是否成功。平台应另外通过采用率、交付周期和认知负荷衡量，平台自身也必须拥有 SLO。
为什么需要它
平台团队汇报成果时，最常见的错误是罗列“我们做了什么”。“12 种 CI 模板、30 个 chart、40 个仪表板。”这些是产出（output），不是成果（outcome）。那 12 种模板可能根本没人使用。
衡量成果必须从用户一侧观察，而用户就是其他开发团队。
它如何工作
DORA 四项指标及其局限
| 指标 | 含义 |
|---|---|
| 部署频率（Deployment Frequency） | 向生产环境发布的频率 |
| 变更交付周期（Lead Time for Changes） | 从提交到进入生产环境所需的时间 |
| 变更失败率（Change Failure Rate） | 部署导致故障的比例 |
| 服务恢复时间（MTTR / Failed Deployment Recovery Time） | 从失败中恢复所需的时间 |
前两项代表速度（throughput），后两项代表稳定性（stability）。DORA 研究的核心发现是二者并不冲突——速度快的组织通常也更加稳定。
其局限也很明确。
- **容易被操纵。**把部署拆得更细，频率就会上升；缩小失败定义，失败率就会下降。
- **抹去团队语境。**用同一标准比较需要监管审查的支付服务与内部仪表板，会得出错误结论。
- **无法直接展示平台贡献。**交付周期缩短时，仅凭指标无法判断是平台带来的效果，还是团队规模缩小的结果。
- **可能偏离开发者真实痛苦。**某个组织部署很快，但搭建本地开发环境需要两天，DORA 指标却仍然全绿。
因此，DORA 应当作为告警装置，平台成果则需要单独衡量。
平台专属指标
- 采用率（adoption）——在非强制状态下有多少团队使用。可以衡量活跃使用团队数，以及通过黄金路径创建的服务比例。
- 首次部署时间（time-to-first-deploy）——新团队或新服务从一无所有到完成生产部署所需的时间，最直接地衡量平台的核心承诺。
- 支持工单的数量与类型——数量下降表示自助服务正在发挥作用；持续增加的工单类型，就是下一条黄金路径的候选。
- 认知负荷调查——虽然是定性指标，却是唯一直接衡量目标的方式。每季度以相同形式询问“找到所需内容有多容易”“你预计这项工作需要几天”等问题，并观察趋势。
这里常见的陷阱是：**调查只做一次毫无意义。**绝对值无法解释，只有趋势才有意义。
平台也必须拥有 SLO
当其他团队开始依赖平台时，平台可用性就成为他们的可用性。但许多平台团队仍然没有 SLO。
平台 SLO 示例包括：
- 部署流水线成功率与 P95 耗时
- 自助资源配置请求的完成时间，例如 95% 的新命名空间在两分钟内完成
- 内部 API 与门户的可用性
- 黄金路径脚手架成功率
有了 SLO，就会产生错误预算；有了错误预算，就能用数字而不是感觉决定“本季度应发布新功能，还是应投入稳定性工作”。这相当于平台团队把 SRE 方法应用到自己身上。
多租户隔离级别
平台会让多个团队共享资源。隔离选项大致如下。
| 级别 | 隔离 | 成本 | 运维负担 |
|---|---|---|---|
| 命名空间 | 逻辑隔离，通过 RBAC、配额与 NetworkPolicy 区分 | 最低 | 低 |
| 独立节点池 | 每个租户使用独立节点，通过 taint/toleration 调度 | 中等（会产生闲置资源） | 中等 |
| 独立集群 | 连控制平面也相互隔离 | 高 | 高（需要逐集群升级） |
| 独立账号或订阅 | 隔离到云边界 | 最高 | 最高 |
选择标准是“租户之间的信任关系如何”以及“是否存在监管要求”。同一家公司的团队往往使用命名空间就足够；如果外部客户会运行代码，至少需要节点隔离，通常还需要集群隔离。考试会涉及软多租户（受信任租户）与硬多租户（不受信任租户）这组术语。
FinOps——成本也是开发者体验
成本不应只是事后账单，而应成为反馈信号。核心实践有三项。
- 成本归属（showback/chargeback）——通过标签和命名空间把成本映射到团队。不知道资源属于谁，就不会有人优化。showback 只展示费用，chargeback 则实际收取费用。
- 请求量与实际使用量的差距——Kubernetes 成本中最大的浪费来自过高的 requests。仅向团队展示请求量相对实际使用率，就能减少相当一部分浪费。
- 把适当规模调整纳入黄金路径——如果默认模板中的请求值合理，即使没人额外关注，也能节省成本。
实际现场中的表现
作者的家庭实验室使用 kube-prometheus-stack 与 Grafana（10.0.0.203）实现可观测性，待办事项中还列有：“观察控制平面负载——4C/14GB 迷你 PC 能承受多少 etcd + apiserver 负载”。这就是平台 SLO 思维的缩影。控制平面变慢，其上的所有团队都会变慢，因此平台资源余量并非平台自己的问题，而是所有用户的问题。
同一集群也直接体现了隔离问题。GPU 分为 24GB、32GB 和两块 8GB，规格各不相同；如果不采取措施，大型训练任务可能被安排到小显卡上。这既是性能问题，也是公平性问题：一个租户独占大显卡，会增加其他租户的交付周期。因此，我们通过 gpu.homelab/tier 标签与 nodeSelector 制定了调度规则。隔离不仅关乎安全，也关乎可预测性。
该集群反复证明了“状态 Ready 与实际能够工作是不同命题”，这一经验也完全适用于衡量。即使组件健康检查全部为绿色，用户体验仍可能很差。平台指标必须从用户旅程衡量，而不是从组件状态衡量。
下一份测验将检查什么
本模块以测验结束。可以回顾上一模块创建的 CRD、配额与黄金路径脚手架如何关联到这里的指标。例如，配额和 LimitRange 默认值会直接影响成本指标。