运维体系（Ops / SRE Platform）
目标：让系统“可发布、可回滚、可治理、可恢复”
P0（基础运维）
├── CMDB
├── 容器平台（K8s）
├── 发布平台
├── 配置中心
P1（稳定运行）
├── 服务治理（Service Mesh / Dubbo / SpringCloud）
├── 运维工具集
P2（事件驱动）
├── 事件中心（告警 / 事件 / 变更）
├── 灰度平台（Feature Flag）
├── 变更管理平台
P3（可靠性工程）
├── 自动化运维 / 自愈
├── 容量 & 成本管理
├── 运维审计 / 合规
运维审计 / 合规（Ops Audit & Compliance）
下面我从“可追责、可证明、可持续合规”的视角，对 **运维审计 / 合规（Ops Audit & Compliance）进行一次**企业级、平台化、强治理的系统性拆解。
重点不是“查日志”，而是：如何在高频变更、高度自动化的系统中，持续满足内控、合规与安全要求。
一、运维审计 / 合规的本质定位
1️⃣ 一句话定义
运维审计 / 合规，是对“谁在什么时间、以什么权限、对哪些生产资源、做了什么、结果如何”的全链路、不可抵赖记录与持续验证体系。
核心关键词：
- Traceability（可追溯）
- Non-repudiation（不可抵赖）
- Continuous Compliance（持续合规）
2️⃣ 审计 vs 合规（不要混）
| 维度 | 审计（Audit） | 合规（Compliance） |
|---|---|---|
| 关注点 | 事实记录 | 规则符合性 |
| 时间 | 事后 | 事前 + 事中 + 事后 |
| 问题 | 发生了什么 | 是否被允许 |
| 输出 | 审计证据 | 合规证明 |
一句话：
审计回答“发生了什么”，合规回答“能不能这样发生”。
二、运维审计的核心对象（必须统一）
1️⃣ 人（Who）
- 运维人员
- 系统账号
- 自动化系统（机器人）
2️⃣ 权限（With What Authority）
- RBAC / ABAC
- 临时授权
- 最小权限
3️⃣ 资源（On What）
- 主机
- 集群
- 应用
- 数据
4️⃣ 行为（Did What）
- 登录
- 操作命令
- API 调用
- 自动化执行
5️⃣ 结果（With What Result）
- 成功 / 失败
- 影响范围
- 变更结果
三、运维审计平台的核心能力模块
1️⃣ 身份与访问审计
- 登录审计（人 / 机器）
- MFA 记录
- 异常登录检测
2️⃣ 操作行为审计（重中之重）
常见审计对象
- Shell 命令
- K8s 操作（kubectl）
- CI/CD 操作
- 自动化 Runbook
高级能力
- 命令回放
- 敏感操作标记
- 实时阻断
3️⃣ 变更审计
- 发布记录
- 配置变更
- Feature Flag 开关
📌 没有变更审计，合规是空谈。
4️⃣ 自动化 / 自愈审计
- 谁定义的规则
- 何时触发
- 执行了什么动作
- 是否自动回滚
5️⃣ 数据与日志不可篡改
- WORM 存储
- Hash 校验
- 时间戳签名
四、合规能力（从“检查清单”到“持续验证”）
1️⃣ 合规规则建模
- 安全基线
- 操作规范
- 变更流程
规则示例：
生产环境
→ 禁止直接登录
→ 必须经堡垒机
→ 必须有审批
2️⃣ 合规检查方式
| 类型 | 示例 |
|---|---|
| 配置合规 | 安全参数 |
| 行为合规 | 是否绕流程 |
| 权限合规 | 是否越权 |
| 时间合规 | 是否在冻结期 |
3️⃣ 持续合规（非常关键）
- 定期扫描
- 实时校验
- 自动纠偏
五、与周边平台的强耦合关系
1️⃣ 与 IAM / RBAC
- 权限审计
- 访问控制
2️⃣ 与堡垒机
- 操作记录
- 会话回放
3️⃣ 与变更管理
- 合规门禁
- 审计证据
4️⃣ 与自动化 / 自愈
- 自动化行为审计
- 风险限制
六、典型合规场景（企业必备）
1️⃣ 生产操作合规
- 禁止直连
- 全程留痕
2️⃣ 发布合规
- 审批链完整
- 可回溯
3️⃣ 权限合规
- 临时授权
- 自动回收
4️⃣ 审计取证
- 事故取证
- 外部审计
七、常见失败模式（真实踩坑）
- 日志太多，没人能用
- 自动化行为无审计
- 合规靠人工抽查
- 审计影响效率
八、成熟度演进模型
L1：日志留存
- 被动记录
L2：集中审计
- 可检索
L3：规则合规
- 自动校验
L4：持续合规
- 实时监控
L5：合规即代码
- Policy as Code
九、一句话总结（非常适合对内 / 对外）
运维审计与合规，不是为了“限制人”，而是为了：让系统在高速变化中，依然能够被信任。
