不是写几条规则就叫治理：聊聊平台治理里策略、合规与可观测的“闭环”

作者：Echo_Wish

做平台运维久了，你会发现一个很有意思的现象：

很多公司嘴上都在说 “平台治理”，
但实际干的事情却是：

• 写几条 YAML 规则
• 加几个审批流程
• 再挂个 Dashboard

然后就宣布：

“平台治理体系上线了。”

说实话，这种做法大概率只能撑三个月。

因为真正的治理从来不是 规则本身，而是：

策略 → 执行 → 观测 → 反馈 → 再优化

换句话说，治理不是一个功能，而是一个 闭环系统。

今天咱就聊聊一个运维人绕不开的话题：

平台治理：策略引擎、合规与可观测的闭环管理。

一、平台治理的本质：让系统自动“自律”

很多人理解治理的时候，总会想到：

• 审批
• 限制
• 风控

但从工程角度来看，治理真正要解决的问题只有一个：

让系统自动遵守规则，而不是依赖人记住规则。

举个例子。

假设公司规定：

所有 Kubernetes 服务必须设置资源限制。

如果靠人记：

• 有人会忘
• 有人会偷懒
• 有人会乱配

结果就是集群资源被打爆。

所以治理的正确方式应该是：

在系统层面阻止不合规的行为。

比如通过策略引擎。

二、策略引擎：治理体系的“大脑”

在云原生世界里，最常见的策略引擎其实是：

OPA（Open Policy Agent）

策略通常写成 Rego 规则。

比如限制 Kubernetes 必须设置资源限制。

package kubernetes.admission

deny[msg] {
  input.request.kind.kind == "Pod"
  container := input.request.object.spec.containers[_]
  not container.resources.limits.cpu
  msg := "Container must set CPU limit"
}

这个规则的意思很简单：

如果 Pod 没有 CPU limit
就直接拒绝创建。

这样一来：

开发再怎么手滑，也绕不过平台治理。

再看一个更真实的例子：

限制镜像仓库来源。

package kubernetes.admission

deny[msg] {
  container := input.request.object.spec.containers[_]
  not startswith(container.image, "registry.company.com/")
  msg := sprintf("image %s not allowed", [container.image])
}

很多安全事故其实就来自：

乱拉 Docker Hub 镜像。

策略引擎的价值就在这里：

把安全要求变成代码。

三、合规：不是审计，而是持续验证

很多公司理解合规的时候，会做一件事：

一年做一次审计。

然后整理一堆 Excel 表。

但现实是：

系统每天都在变化。

如果合规靠 年度审计，那基本等于：

事故发生之后才知道不合规。

所以更合理的做法是：

持续合规扫描。

比如用 Python 写一个简单的 K8s 合规检查器。

from kubernetes import client, config

config.load_kube_config()

v1 = client.CoreV1Api()

pods = v1.list_pod_for_all_namespaces()

for pod in pods.items:
    for c in pod.spec.containers:
        if not c.resources or not c.resources.limits:
            print(
                f"[WARNING] Pod {pod.metadata.name} "
                "has no resource limits"
            )

这段代码的思路其实很简单：

• 遍历所有 Pod
• 检查资源限制
• 输出不合规资源

如果你把它跑成一个 定时任务，那就变成：

持续合规检测系统。

四、可观测：治理体系的“眼睛”

策略能执行，合规能检测。

但如果看不到结果，治理还是不完整。

所以第三个核心能力就是：

可观测。

很多团队现在已经在用：

• Prometheus
• Grafana
• Loki

但问题在于：

治理指标往往没有被纳入监控体系。

举个例子。

我们可以把策略违规次数做成指标。

from prometheus_client import Counter

policy_violation = Counter(
    "policy_violation_total",
    "Total policy violations",
    ["policy"]
)

def record_violation(policy_name):
    policy_violation.labels(policy=policy_name).inc()

当策略触发时记录：

record_violation("image_registry_policy")

Prometheus 采集之后就能看到：

• 哪条策略被违反最多
• 哪个团队违规最多
• 哪段时间问题最多

这才是治理真正的价值：

数据驱动改进。

五、闭环管理：治理不是规则，是系统

很多人搭平台治理时最大的问题就是：

系统是割裂的。

常见情况：

策略系统一套
审计系统一套
监控系统一套

互相之间没有联系。

真正成熟的治理体系通常长这样：

策略定义
   ↓
策略执行
   ↓
违规记录
   ↓
监控指标
   ↓
告警通知
   ↓
自动修复

举个简单例子：

如果发现 Pod 没有资源限制。

平台可以：

1️⃣ 记录违规
2️⃣ 发告警
3️⃣ 自动修复

自动修复脚本甚至可以很简单。

def auto_fix_pod(pod):
    for c in pod.spec.containers:
        if not c.resources:
            c.resources = {
                "limits": {
                    "cpu": "500m",
                    "memory": "512Mi"
                }
            }

当然生产环境会复杂得多，但思路是一样的。

六、一个很多人忽略的现实

做了这么多年运维平台，我有个很深的体会：

治理最大的阻力从来不是技术。

而是：

组织。

很多开发会觉得：

“你这个规则限制了我的效率。”

很多团队会觉得：

“治理就是在找麻烦。”

所以平台治理一定要注意一件事：

不要一上来就“封死”。

更合理的路径是：

1️⃣ 先观测
2️⃣ 再提醒
3️⃣ 最后强制

技术可以很硬，但方式一定要柔。

七、写在最后

如果让我用一句话总结平台治理，我会这么说：

治理不是为了限制人，而是为了保护系统。

策略引擎是 大脑
合规检测是 免疫系统
可观测是 眼睛

三者结合，才是一个真正健康的平台。

否则所谓的治理，很可能只是：

一堆写在 Wiki 里的规则。

而系统，依然在悄悄失控。