ITOps Agent Platform

主题

第25章 自动修复系统详解 ​

本章导读 ​

学习目标 ​

完成本章学习后，你将能够：

  • ✅ 理解自动修复系统的设计理念和核心架构
  • ✅ 掌握修复策略的创建、配置和执行流程
  • ✅ 理解告警与修复策略的智能匹配机制
  • ✅ 掌握修复执行记录的查看、审批和重试操作
  • ✅ 理解自动修复的安全机制：频率控制、回滚机制、审批流程
  • ✅ 能够独立设计和配置业务场景的自动修复策略

前置知识 ​

  • 已完成第16章（告警中心与通知系统）
  • 已完成第14章（工作流引擎详解）
  • 了解什么是故障修复和回滚

预计学习时间 ​

90-120 分钟

25.1 自动修复系统概述 ​

25.1.1 什么是自动修复？ ​

类比理解：就像人体的免疫系统——当检测到异常（发热、感染）时，自动启动防御机制（白细胞攻击、发烧杀菌）。自动修复系统就是 IT 基础设施的"免疫系统"。

25.1.2 自动修复的价值 ​

  • 缩短 MTTR（Mean Time To Repair）：从人工介入的 30-60 分钟缩短到秒级响应
  • 降低运维成本：重复性故障自动处理，释放运维人员精力
  • 一致性保障：机器执行比人工更准确，避免遗漏步骤
  • 可追溯审计：每次修复均有完整记录，满足合规要求

25.1.3 系统架构概览 ​

告警触发 → 策略匹配 → 执行修复 → 验证结果 → (成功)记录审计
                              ↓ (失败)
                          升级/回滚/人工审批

关键组件：

  • 策略引擎 (remediationService.ts) — 匹配告警与修复策略
  • 执行引擎 — 调用工作流或命令执行修复
  • 审批系统 — 高危操作需人工确认
  • 审计系统 (remediation_audits 表) — 记录每次修复操作
  • 冷却机制 (remediation_cooldowns 表) — 防止过度修复

25.1.4 核心数据表 ​

表名用途
remediation_policies修复策略定义（触发条件、执行模式、验证、回滚）
remediation_executions修复执行记录（执行时间、结果、耗时）
remediation_history修复历史记录（用于趋势分析）
remediation_audits审计日志（审批、验证、回滚操作）
remediation_cooldowns冷却期记录（防止频繁触发）

25.2 修复策略配置 ​

25.2.1 策略数据结构 ​

typescript
interface RemediationPolicy {
  id: number;
  name: string;
  description: string;
  enabled: boolean;
  
  // 触发条件
  trigger_type: 'alert' | 'metric' | 'schedule';
  alert_source: string;
  alert_severity: string;
  alert_pattern: string;  // 正则匹配
  
  // 执行配置
  execution_mode: 'auto' | 'approval' | 'workflow';
  workflow_id?: number;
  command?: string;
  
  // 验证配置
  validation_enabled: boolean;
  validation_command?: string;
  validation_timeout: number;
  
  // 回滚配置
  rollback_enabled: boolean;
  rollback_command?: string;
  
  // 频率控制
  cooldown_seconds: number;
  max_retries: number;
  
  created_at: string;
  updated_at: string;
}

25.2.2 触发条件配置 ​

三种触发模式：

  1. 告警触发（最常用）：基于告警源、级别、标题正则匹配
  2. 指标触发：基于服务器指标阈值（CPU > 90% 持续 5 分钟）
  3. 定时触发：定期执行健康检查和自动修复

匹配规则详解：

  • alert_source: 支持 prometheus, zabbix, generic
  • alert_severity: 支持 critical, warning, info
  • alert_pattern: 正则表达式，用于匹配告警标题或内容

25.2.3 执行模式 ​

模式适用场景安全性
auto低风险操作（重启服务、清理日志）全自动，无需人工干预
approval中风险操作（数据库重启、配置变更）需管理员审批后执行
workflow复杂场景（多步骤修复、跨系统操作）调用预定义的工作流

25.2.4 验证与回滚机制 ​

验证步骤：

  1. 修复执行完成后自动运行验证命令
  2. 验证超时保护（默认 30 秒）
  3. 验证失败自动触发回滚

回滚配置：

  • 回滚命令预定义在策略中
  • 支持自动回滚和手动回滚
  • 回滚操作同样需要审计记录

25.2.5 频率控制（冷却机制） ​

为什么要冷却？

  • 防止同一问题反复修复导致系统震荡
  • 避免在短时间内对同一服务器执行过多操作

冷却逻辑：

策略触发 → 检查冷却期 → (冷却中)跳过执行
                    ↓ (冷却已过)
                执行修复 → 记录冷却开始时间
                    ↓
            cooldown_seconds 后冷却结束

25.3 前端策略管理 ​

25.3.1 策略列表页面 (RemediationPolicies.tsx) ​

核心功能：

  • 策略列表展示（名称、状态、触发条件、执行模式）
  • 启用/禁用开关
  • 按状态、触发类型筛选
  • 分页显示
  • 新增/编辑/删除策略

25.3.2 策略编辑页面 (RemediationPolicyEditor.tsx) ​

表单结构：

策略基本信息
├── 名称
├── 描述
└── 启用状态

触发条件配置
├── 触发类型（告警/指标/定时）
├── 告警源
├── 告警级别
└── 匹配模式（正则）

执行配置
├── 执行模式（自动/审批/工作流）
├── 关联工作流（仅workflow模式）
└── 执行命令

验证配置
├── 启用验证
├── 验证命令
└── 验证超时

回滚配置
├── 启用回滚
└── 回滚命令

频率控制
├── 冷却时间（秒）
└── 最大重试次数

25.3.3 策略工作台 (RemediationWorkbench.tsx) ​

  • 实时展示修复系统运行状态
  • 策略执行统计（成功率、平均耗时）
  • 活跃告警与策略匹配情况
  • 快捷操作入口

25.4 修复执行与审计 ​

25.4.1 执行流程（后端源码解析） ​

typescript
// remediationService.ts 核心执行流程
async function executeRemediation(policy, alert): Promise<ExecutionResult> {
  // 1. 检查冷却期
  if (isInCooldown(policy, alert.server)) {
    return { status: 'skipped', reason: 'cooldown' };
  }
  
  // 2. 检查执行模式
  if (policy.execution_mode === 'approval') {
    return { status: 'pending_approval' };
  }
  
  // 3. 执行修复
  const result = await executePolicy(policy);
  
  // 4. 验证结果
  if (policy.validation_enabled) {
    const valid = await validateResult(result);
    if (!valid && policy.rollback_enabled) {
      await executeRollback(policy);
    }
  }
  
  // 5. 设置冷却期
  setCooldown(policy, alert.server);
  
  // 6. 记录审计
  await logAudit(result);
  
  return result;
}

25.4.2 审批流程 ​

审批操作：

  • 管理员在 RemediationExecutions.tsx 页面查看待审批任务
  • 支持通过/拒绝操作
  • 审批通过后自动触发执行
  • 审批记录进入审计日志

25.4.3 执行历史与审计 ​

执行记录包含：

  • 策略名称和 ID
  • 触发告警信息
  • 执行时间、耗时
  • 执行结果（成功/失败/跳过）
  • 验证结果
  • 回滚记录

审计维度：

  • 审批审计：谁审批的、审批时间、审批意见
  • 执行审计：执行了什么命令、输出结果
  • 验证审计：验证命令和验证结果
  • 回滚审计：是否回滚、回滚原因、回滚结果

25.4.4 重试机制 ​

  • 失败任务支持手动重试
  • 重试次数受 max_retries 限制
  • 每次重试独立记录审计日志
  • 支持查看失败原因和错误堆栈

25.5 实战案例 ​

案例 1：磁盘空间自动清理 ​

场景：服务器磁盘使用率超过 85% 时自动清理日志

策略配置：

  • 触发条件：告警源 = prometheus，级别 = warning，正则匹配 disk usage.*high
  • 执行模式：auto
  • 执行命令：find /var/log -name "*.log" -mtime +7 -delete
  • 验证命令：df -h / | awk 'NR==2{print $5}'
  • 回滚命令：（无需回滚）
  • 冷却时间：3600 秒（1 小时）

案例 2：服务异常自动重启 ​

场景：关键服务（如 Nginx）宕机时自动重启

策略配置：

  • 触发条件：告警源 = zabbix，级别 = critical，正则匹配 service.*down
  • 执行模式：auto
  • 执行命令：systemctl restart nginx
  • 验证命令：systemctl is-active nginx
  • 回滚命令：（无需回滚）
  • 冷却时间：600 秒（10 分钟）

案例 3：数据库连接池告警 ​

场景：数据库连接池满，需人工确认后进行优化

策略配置：

  • 触发条件：告警源 = prometheus，级别 = critical，正则匹配 connection pool.*exhausted
  • 执行模式：approval
  • 关联工作流：数据库连接优化工作流（包含杀空闲连接、调整参数等步骤）
  • 冷却时间：1800 秒（30 分钟）

25.6 最佳实践与注意事项 ​

25.6.1 策略设计原则 ​

  1. 最小影响原则：修复操作应该影响最小，避免大规模操作
  2. 可验证原则：每个修复操作都应该有明确的验证方式
  3. 可回滚原则：高危操作必须定义回滚步骤
  4. 频率控制原则：合理设置冷却时间，避免系统震荡

25.6.2 安全建议 ​

  • 审批策略：涉及数据库、网络、存储的核心操作使用审批模式
  • 冷却时间：不要设置过短的冷却时间，建议至少 300 秒
  • 审计日志：定期检查审计日志，发现异常策略行为
  • 定期演练：定期测试策略的回滚机制是否正常工作

25.6.3 常见错误 ​

错误原因解决方案
修复循环冷却时间过短或未设置增加冷却时间，检查修复是否真正解决问题
验证超时验证命令响应慢或网络延迟增加验证超时时间，优化验证命令
误触发正则匹配过于宽泛精确化正则表达式，增加过滤条件
回滚失败回滚命令定义错误测试回滚命令，确保正确性

25.7 本章回顾 ​

关键知识点：

  1. 自动修复系统的核心组件和数据表
  2. 策略配置的触发条件、执行模式、验证和回滚
  3. 频率控制和冷却机制的原理
  4. 审批流程的执行步骤
  5. 审计日志的多维度记录

相关章节：

  • 第14章 工作流引擎详解
  • 第16章 告警中心与通知系统
  • 第20章 安全机制深度解析

延伸阅读：

基于 MPL-2.0 许可证发布

Copyright © 2025-2026 谭策 | IT Online