📚 课程目录第3章平台治理的基本模型

3. 平台治理的基本模型

平台治理不是一份文档，也不是一次审批，而是一套持续运转的约束与赋能机制。要让这套机制可设计、可落地、可评估，通常把它拆成五个相互咬合的要素：策略（Policy）、标准（Standard）、流程（Process）、工具（Tooling）与度量（Metric）。它们不是并列的清单，而是一条从"为什么管"到"管得怎么样"的闭环链路：策略定义意图与边界，标准把意图翻译成可判定的技术约束，流程规定人和系统在什么时机做什么，工具把流程自动化并嵌入开发者日常路径，度量则回答治理是否真的生效、代价是否可接受。

五要素的核心关系可以概括为：策略是"为什么"，标准是"是什么"，流程是"谁在何时做"，工具是"如何自动做"，度量是"做得对不对"。缺任何一环，治理都会退化成口号或摩擦。

策略：先回答"为什么管"

策略是治理的起点，它回答的是意图问题：我们为什么要对平台施加约束？常见动因包括合规要求（如数据不出境、审计留痕）、安全底线（如禁止明文密钥入库）、成本控制（如限制长期运行的闲置环境）以及体验一致性（如统一服务目录与入口）。策略通常由平台团队与安全、合规、财务等利益相关方共同确认，输出的是原则性声明，例如"所有生产环境变更必须可追溯、可回滚"。

策略的关键在于"少而稳"。策略频繁变动会让下游标准与工具反复返工，开发者也会失去信任。建议把策略控制在个位数条，每条都能对应到明确的动因和责任人。

标准：把意图翻译成可判定约束

标准是策略的技术化表达，必须做到可判定——即给定一个制品或配置，能明确回答"符合/不符合"。例如策略说"变更可追溯"，标准就落成：镜像必须带 git.commit 与 build.time 标签；服务必须声明 owner 与 tier 标签；Kubernetes 工作负载必须设置 resource requests/limits。

标准要避免两种极端：一是过于抽象（"代码要规范"），无法自动检查；二是过于琐碎（规定变量命名到每个字母），引发无谓摩擦。一个可参考的判定粒度是：每条标准都能写成一个返回布尔值的检查函数。下面是一段示意性的策略即代码片段（示例，非实测结果）：

# policy/deployment.rego（示意）
package platform.deployment

required_labels := {"owner", "tier", "git.commit"}

deny[msg] {
  input.kind == "Deployment"
  missing := required_labels - {k | input.metadata.labels[k]}
  count(missing) > 0
  msg := sprintf("缺少必需标签: %v", [missing])
}

deny[msg] {
  input.kind == "Deployment"
  not input.spec.template.spec.containers[_].resources.limits.cpu
  msg := "必须设置 CPU limits"
}

这段规则把"可追溯"和"资源可控"两条策略变成了 CI 阶段可执行的判定逻辑。注意它只做判定与拒绝，不负责修复——修复应交给模板或脚手架，这是工具层的职责。

流程：规定时机、角色与例外

流程回答"谁在什么时机做什么"。治理流程通常覆盖四类时机：准入（新服务上线需通过哪些检查）、变更（日常发布走什么门禁）、例外（确实无法满足标准时如何申请豁免）、下线（服务退役如何清理资源与权限）。

流程设计最容易犯的错误是把所有检查都堆在发布前的人工评审会上。更合理的做法是左移：能在本地或 PR 阶段自动判定的，就不要留到发布评审。人工评审只保留真正需要判断力的部分，例如架构合理性、跨团队影响、例外审批。例外流程尤其重要——没有合法例外通道，团队就会绕过治理，治理形同虚设。

工具：把流程嵌入开发者日常路径

工具是治理能否被接受的分水岭。同样的标准，如果靠文档通知和人工检查，开发者体验会很差；如果做成 CI 门禁、IDE 插件、服务模板、CLI 命令和自助门户，开发者几乎无感就能满足要求。工具设计要遵循两条原则：反馈要快（本地或 PR 阶段就报错，而不是发布时才发现）、信息要可行动（不只说"不合规"，还要给出修复命令或文档链接）。

例如把上面的 Rego 规则接入 CI 后，开发者提交 PR 时会看到类似输出（示意）：

$ platformctl check --path ./deploy
✗ deployment.yaml: 缺少必需标签: {"tier"}
  → 修复: platformctl fix labels --add tier=backend
✗ deployment.yaml: 必须设置 CPU limits
  → 参考: https://platform.internal/standards/resources
2 项不合规，0 项通过

这种"错误 + 修复建议 + 文档链接"的组合，把治理从阻断变成了引导。

度量：验证治理是否真的生效

度量是闭环的收口。它至少要回答两个问题：治理有没有效果（合规率、例外数量、事故中因违规导致的比例），以及治理代价有多大（CI 等待时长、PR 返工次数、开发者满意度、上线周期变化）。只度量前者会导致治理不断加码，最终压垮体验；只度量后者则会让治理失去约束力。

一个实用的做法是同时跟踪一对指标：首次合规率（第一次提交就通过检查的比例）与门禁平均耗时。首次合规率上升说明标准与工具被开发者理解并内化；门禁耗时下降说明工具效率在改善。两者同时向好，才说明治理与体验在协同，而不是此消彼长。

五要素不是一次性建完的。建议按"策略 → 标准 → 工具 → 流程 → 度量"的顺序小步推进：先固化少量策略与可自动判定的标准，用工具跑起来，再补流程与度量。反过来先建流程和度量，往往因为缺少工具支撑而变成纸面治理。

治理与体验的协同关系

治理与体验并非天然对立。对立感通常来自约束被放在了错误的位置：本该由工具自动完成的事，变成了人工评审和文档要求。协同的关键在于分层——策略停留在意图层，标准做成可判定约束，流程尽量左移，工具承担执行与反馈，度量同时盯住效果与代价。当这五层各就各位时，开发者感受到的不是"被管"，而是"平台帮我把该做的事做对了"。

反过来，如果度量显示合规率长期偏低而例外申请激增，通常不是开发者不配合，而是标准过严、工具反馈太晚或流程时机不对。此时应回到策略与标准层重新校准，而不是简单加强处罚。治理的成熟度，最终体现在它能否用更低的摩擦换来更稳定的平台行为。