审计范围界定：基础设施层、应用层、流程层
做平台工程审计，第一个要解决的根本问题就是：你到底要审什么？
这听起来像句废话，对吧？但我见过太多团队，一上来就铺开几百个检查项，最后审计报告写出来，别人根本不知道哪些问题是基础设施的、哪些是应用的、哪些是流程的。说白了，审计范围界定不清，后面所有工作都是在打乱仗。
我个人习惯，在启动任何一次平台工程审计之前，先把范围切成三大块：基础设施层、应用层、流程层。三层之间有关系，但边界必须清晰。今天我们就来拆解这三层的审计范围到底该怎么定。
基础设施层审计范围
基础设施层，说白了就是承载平台运行的"硬件+软件底座"。它包括但不限于计算、网络、存储、容器编排这四个核心域。你想想看，如果这一层出了安全问题或者配置漂移，上层应用跑得再欢也没用。
我建议你在界定基础设施层审计范围时，重点关注以下四个方面：
- 计算资源审计：包括节点状态、CPU/内存/GPU利用率、节点池扩缩容策略、资源配额（Resource Quota）配置。我在项目中遇到过，因为节点池的扩缩容阈值没设对，导致大促时集群直接 OOM，那叫一个惨。
- 网络资源审计：包括网络策略（NetworkPolicy）、防火墙规则、DNS 配置、负载均衡器（Ingress/Service）的 TLS 终止策略。嗯，这里有个坑——很多团队的 NetworkPolicy 只建不审，规则越积越多，最后谁也看不懂。
- 存储资源审计：包括 PV/PVC 状态、StorageClass 配置、数据备份策略、卷的快照与恢复机制。我建议你特别关注"孤儿 PV"，就是那些 PVC 删了但 PV 还挂着的，白白占用存储。
- 容器编排审计：包括 K8s 版本、集群 RBAC 配置、PodSecurityPolicy / OPA 策略、调度器配置。我亲自见过一个集群因为 RBAC 配得太松，一个测试账号就能删生产命名空间，啧，想起来都后怕。
应用层审计范围
应用层审计，很多人容易跟基础设施层搞混。其实分清楚很简单：基础设施层管"跑在哪"，应用层管"怎么跑"。应用层的核心审计对象是业务服务本身，以及服务运行时依赖的所有配置和可观测性数据。
我通常把应用层审计范围拆成三个维度：
- 应用配置审计：包括环境变量、ConfigMap、Secret、启动参数、JVM 参数。我曾经因为一个 Secret 没做版本管理，回滚后配置和代码不匹配，线上故障整整 40 分钟。从那以后，我要求所有配置变更必须走 GitOps。
- 服务依赖审计：包括服务网格（Istio/Linkerd）的 mTLS 策略、API 网关的路由规则、服务间通信的鉴权方式、外部依赖（数据库、缓存、消息队列）的连接配置。说白了，你要搞清楚你的应用到底依赖了谁，依赖关系是否安全。
- 可观测性审计：包括日志是否全量采集、监控指标是否覆盖核心业务、告警规则是否合理、链路追踪（Tracing）是否完整。我见过一个项目，监控指标配了 300 多个，但真正触发过告警的不到 10 个——这就是典型的"监控疲劳"，审了等于没审。
流程层审计范围
流程层，是很多人做审计时最容易忽略的一层。但说实话，流程问题造成的故障，往往比技术问题更难修复。流程层审计关注的是"人怎么用平台"，而不是"平台本身长什么样"。
我建议你从以下三个方向切入：
- CI/CD 流程审计：包括流水线定义是否代码化、制品仓库权限控制、部署策略（蓝绿/金丝雀/滚动）是否合理、是否强制了代码扫描和镜像签名。我遇到过最离谱的情况是，一个团队的生产部署还靠运维手动在 Jenkins 上点"构建"，没有任何审批流——这要是点错了，谁来背锅？
- 变更管理审计：包括变更审批流程、变更窗口、回滚预案、变更记录的可追溯性。我个人习惯是，每审一个项目，先看最近 3 个月的变更记录。如果变更描述全是"fix bug"、"update config"这种模糊写法，那这个团队的变更管理基本等于没有。
- 合规与治理审计：包括 Policy as Code（OPA/Kyverno）的策略覆盖度、安全扫描（Trivy/Clair）的触发频率、合规检查（CIS Benchmark）的执行记录。说白了，你要确认"平台是不是真的在按规矩运行"，而不只是墙上贴了一堆制度文件。
三层审计的协同与边界
三层分清楚了，但你不能把它们完全割裂。实际上，平台工程中的很多问题都是跨层的。我举个例子：一个 Secret 过期了，它的配置定义在应用层，存储方式在基础设施层，轮换策略在流程层。三层合在一起，才能形成一个完整的审计闭环。
下面这张图，展示了我常用的三层审计范围框架，以及它们之间的协同关系。
看完这张图，你应该能感受到：三层之间不是简单的"上下级"关系，而是一个相互反馈的闭环。基础设施层的问题会暴露在应用层，应用层的问题会追溯到流程层，而流程层的改进又会反过来优化基础设施和应用配置。我在做审计的时候，每一个发现项都会打上"所属层"标签，然后看它是否跨层——跨层的问题，优先级自动提升一级。
三层审计范围对比
为了方便你在实际项目中快速界定范围，我整理了一个对比表格。你可以把它作为团队内部审计启动会的参考模板。
| 审计维度 | 基础设施层 | 应用层 | 流程层 |
|---|---|---|---|
| 核心对象 | 节点、网络、存储、编排 | 服务、配置、依赖、观测 | 流水线、变更、策略、合规 |
| 常见问题 | 节点配置漂移、RBAC 过松 | Secret 未轮换、监控盲区 | 变更无审批、合规策略缺失 |
| 审计证据 | 集群资源清单、网络策略快照 | ConfigMap/Secret 版本记录 | CI/CD 日志、变更工单记录 |
| 主要工具 | Prometheus、kubectl、Trivy | Grafana、Jaeger、Kiali | ArgoCD、OPA、Backstage |
| 跨层关联 | 为应用层提供运行环境 | 暴露基础设施层配置问题 | 驱动基础设施和应用改进 |
最后再说一个很多人会问的问题："这三层有没有优先级顺序？"我的回答是：看你的平台成熟度。如果你的 K8s 集群还经常出节点故障，那就先把基础设施层审扎实；如果你的服务已经能稳定运行，但每次上线都提心吊胆，那就重点审流程层。说白了，审计范围界定不是一成不变的，它应该随着平台的发展动态调整。审一次，迭代一次，越审越精准。