运维体系（Ops / SRE Platform）
目标：让系统“可发布、可回滚、可治理、可恢复”
P0（基础运维）
├── CMDB
├── 容器平台（K8s）
├── 发布平台
├── 配置中心
P1（稳定运行）
├── 服务治理（Service Mesh / Dubbo / SpringCloud）
├── 运维工具集
P2（事件驱动）
├── 事件中心（告警 / 事件 / 变更）
├── 灰度平台（Feature Flag）
├── 变更管理平台
P3（可靠性工程）
├── 自动化运维 / 自愈
├── 容量 & 成本管理
├── 运维审计 / 合规
自动化运维 / 自愈（Automation Ops / Self-Healing）
下面我从“运维范式升级”而不是“脚本自动化”的角度，对 自动化运维 / 自愈（Automation Ops / Self-Healing）做一次企业级、体系化、可治理的系统性拆解。重点回答三个问题：自动化什么？如何自愈？什么时候不该自愈？
一、自动化运维 / 自愈的本质定位
1️⃣ 一句话定义
自动化运维 / 自愈，是让系统在可控边界内，对已知、可判定、可回滚的问题进行自动诊断与处置，从而减少人工介入的运行模式。
关键词非常重要：
- 可判定
- 可控
- 可回滚
📌 不是“AI 自己修系统”，而是：系统代替人执行“已经被证明正确的动作”。
二、自动化运维 vs 自愈（不要混）
| 能力 | 自动化运维 | 自愈 |
|---|---|---|
| 触发方式 | 人触发 / 定时 | 事件驱动 |
| 是否闭环 | 不一定 | 必须闭环 |
| 风险等级 | 低~中 | 中~高 |
| 是否需要验证 | 可选 | 强制 |
一句话区分：
自愈 = 自动化运维 + 自动判断 + 自动验证 + 自动回退
三、自动化运维的核心能力
1️⃣ Runbook 自动化（基础）
- 重启服务
- 扩容实例
- 切流
- 清理缓存
📌 Runbook 是自愈的最小单元。
2️⃣ 自动化执行引擎
- 支持 API / Script / Workflow
- 幂等性
- 超时 / 重试
3️⃣ 权限与审计
- 谁定义
- 谁触发
- 谁执行
四、自愈系统的核心闭环（非常重要）
1️⃣ 标准自愈闭环
Detect
↓
Diagnose
↓
Decide
↓
Act
↓
Verify
↓
Rollback / Close
2️⃣ 每一步对应能力
| 步骤 | 能力 |
|---|---|
| Detect | 告警 / 事件 |
| Diagnose | 规则 / 拓扑 / 历史 |
| Decide | 策略 / 风险 |
| Act | 自动化执行 |
| Verify | 指标校验 |
| Rollback | 回退策略 |
📌 没有 Verify 的自动化，不允许进入自愈。
五、常见自愈场景（成熟系统都在用）
1️⃣ 基础设施级
- Pod Crash → 重建
- 节点 NotReady → 驱逐
2️⃣ 应用级
- QPS 激增 → 自动扩容
- RT 异常 → 限流 / 降级
3️⃣ 配置 / 流量级
- 错误率升高 → 回滚配置
- 新版本异常 → 切回旧版本
六、自愈决策的三大控制原则
1️⃣ 风险分级
| 场景 | 自愈策略 |
|---|---|
| 单实例异常 | 自动 |
| 多实例异常 | 半自动 |
| 核心链路 | 人确认 |
2️⃣ 自愈边界（Kill Zone）
- 最大执行次数
- 最大影响范围
- 冷却时间
3️⃣ 失败兜底
- 自动停止
- 升级为 Incident
- 人介入
七、与周边平台的深度协同
1️⃣ 事件中心
- 事件触发自愈
- 自愈结果回写事件
2️⃣ 变更管理平台
- 自愈 = 特殊变更
- 强制审计
3️⃣ 灰度平台
- 自愈只影响部分流量
- 控制 blast radius
4️⃣ CMDB
- 影响面评估
- Owner 定位
八、从“自动化”走向“智能自愈”
1️⃣ 规则驱动（起步）
- if / then
- 阈值
2️⃣ 经验驱动
- 历史事故
- 成功 Runbook
3️⃣ 数据驱动
- 相似度
- 成功率
4️⃣ 预测驱动
- 异常趋势
- 提前止血
📌 AI 的角色是“推荐与评分”，不是“直接执行”。
九、常见失败模式（血的教训）
- 自动化脚本无校验
- 自愈反复触发造成雪崩
- 自愈掩盖问题根因
- 无人敢关自愈
十、成熟度模型
L1：脚本自动化
- 人触发
L2：事件触发
- 半自动
L3：闭环自愈
- 自动 + 校验
L4：SRE 化
- Error Budget 门禁
L5：智能化
- 预测自愈
十一、一句话总结（非常适合对内）
自愈不是让系统“不出问题”，而是让问题在可控范围内“自己停下来”。
