📚 课程目录第1章 Platform Engineering 审计概述

1. Platform Engineering 审计概述：定义、目标与价值

先聊个实际场景。几年前我在一家中型互联网公司带队做内部平台，团队吭哧吭哧干了半年，交付了一个自认为「完美」的开发自助平台。结果呢？上线第一周，业务线抱怨流程反而变长了；第二周，安全团队发现权限模型有漏洞；第三周，SRE 说平台自身的可观测性几乎是盲区。

说白了，当时我们犯了一个典型错误——只关注了「平台功能」的交付，完全没有考虑「平台本身是否健康、安全、高效」。问题出在哪？缺少一个系统性的审计机制。

你想想看，平台工程的核心是「抽象复杂性，提供自助服务」。但这个抽象层如果本身出了问题，影响是灾难性的。一个错误的资源模板，可能让一百个服务同时踩坑。一个失控的成本池，可能让一个季度的预算瞬间超支。

这就是为什么要引入审计——不是找谁背锅，而是确保平台这个「黑盒子」是可信任的。

我个人习惯把平台工程审计定义为：对平台基础设施、服务目录、自服务能力、成本模型及治理流程的系统性检查和持续评估。

它不同于传统的 IT 审计。传统审计更像是一次性体检，查完出报告就结束了。平台工程审计更像一个健康监测系统——持续采集指标，实时发现异常，甚至能预测潜在风险。

核心区别： 传统审计是「点状检查」，平台工程审计是「网状持续评估」。

举个例子。传统审计会检查云账号的权限配置是否合规。平台工程审计不仅要检查这个，还会验证：自助服务门户上的权限申请流程是否真实落地了合规策略？开发者通过平台申请资源时，有没有绕过审计节点？平台自身的操作日志是否完整且不可篡改？

所以，我给的定义里强调三个关键词：

我把它归纳为四个核心目标，你可以理解为四个「要确保」：

目标	说明	我遇到的典型案例
可观测性	平台运行状态、调用链路、资源使用对审计方透明	曾有平台没有记录「谁在什么时候创建了K8s集群」，出问题时根本没法回溯
合规性	平台行为符合内部策略与外部监管要求	金融客户要求所有资源创建必须附带业务审批单号，平台如果没这个字段就算不合规
安全性	平台自身的身份、权限、数据保护机制健全	一次审计发现平台的API 直接硬编码在配置文件中，毫无防护
效率性	平台是否真的提升了交付速度，有没有引入不必要的摩擦	某个平台要求开发者填15个字段才能部署一次，结果大家全部绕过平台手动操作

嗯，这里要注意，这四个目标是相互关联的。比如可观测性做不好，合规性和安全性基本是空谈。反过来，如果平台效率极高但完全不合规，那它就是公司的一颗定时炸弹。

聊完了目标，咱们看看价值。说白了，审计不是花钱找麻烦，而是帮平台团队省事、省心、省钱。我个人总结了三层价值：

降低运营风险——提前发现问题，而不是等故障报告来了才补救。我曾经见过一个平台，因为没有审计预算模型，一个开发人员一次性创建了500台高配虚拟机，直到月底账单出来才被发现……
提升平台信任度——当业务团队知道平台有审计机制，他们会更放心地使用自助服务，而不是什么事都找平台团队手动操作。信任本身就能降低协作成本。
驱动持续改进——审计数据是最好的反馈。哪些流程被频繁绕过？哪个资源模板错误率最高？这些数据能帮你把平台越做越好。

避坑提示： 我曾经踩过一个坑——第一次做平台审计时，想把所有指标一次性覆盖全。结果数据量太大，根本分析不过来。后来学乖了，从「高风险、高频率」的维度切入，比如先审计权限变更和资源创建流程，再逐步扩展。

这一章是开篇，我觉得有必要把整个审计知识体系画出来。方便你脑子里先搭个框架，后面每个章节往里填内容。

下面这张图是我梳理的「平台工程审计核心架构」，你可以看到审计不是孤立的，它围绕着平台的自助门户、基础设施、成本、治理、安全几大模块运转，最终输出可信度与价值。

再补充一个分层视角，方便你理解审计应该从哪入手。我习惯把平台工程审计分成三个层次：

这三个层次不是串行的，而是并行的。我建议你在设计审计方案时，三个层次各自选两三个指标先行试点，跑通之后再逐步丰富。

注意： 不要一开始就把审计做成「合规警察」。我见过有团队一上来就定了几十条审计规则，结果开发者怨声载道，平台团队自己也被审计规则拖垮了效率。审计要渐进，先保核心风险，再谈全面覆盖。

这一章我主要铺垫了平台工程审计的「为什么」和「是什么」。你只需要记住几个关键点：