# 第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章 安全机制深度解析

**延伸阅读**：

- [AUTO_REMEDIATION_DESIGN.md](../AUTO_REMEDIATION_DESIGN.md)
- 源码：`backend/src/services/remediationService.ts`
