3. 系统架构总览：自动化自愈系统的分层架构
自动化自愈系统并非单一模块，而是一个具备闭环控制能力的多层架构。每一层承担独立的职责，通过标准化的数据接口与指令通道协同工作，最终实现从“故障发现”到“业务恢复”的完整自愈闭环。本章将系统拆解为监控层、决策层、执行层、反馈层四个核心层次，并阐述其交互逻辑与设计要点。
3.1 四层架构总览与职责划分
下表从输入、输出、核心组件与关键指标四个维度，对比各层的职责边界：
| 层次 | 输入 | 输出 | 核心组件 | 关键指标 |
|---|---|---|---|---|
| 监控层 | 基础设施/应用指标、日志、链路追踪 | 结构化告警事件、指标快照 | Prometheus + Alertmanager、ELK、SkyWalking | 告警延迟 < 30s，数据采集覆盖率 > 99% |
| 决策层 | 告警事件、限流状态、历史自愈记录 | 自愈指令（Runbook ID + 参数） | 规则引擎、CMDB、拓扑依赖图 | 决策耗时 < 5s，误判率 < 0.1% |
| 执行层 | 自愈指令、限流阈值、变更脚本 | 操作结果、限流生效/解除信号 | Ansible/SaltStack、限流网关、K8s Operator | 执行成功率 > 99.5%，回滚时间 < 60s |
| 反馈层 | 执行结果、业务指标恢复状态 | 自愈报告、策略调优建议、混沌实验触发 | 自愈仪表盘、事件总线、混沌平台 | 反馈闭环时间 < 2min，策略迭代周期 < 1d |
设计原则：四层之间通过事件驱动方式解耦。监控层产生告警事件后写入消息队列，决策层订阅消费，执行层接收指令后异步执行，反馈层通过监听执行结果与业务指标完成闭环。这种设计避免了层与层之间的强依赖，提升了系统的可扩展性与容错能力。
3.2 分层架构交互流程（SVG）
下图展示了四层架构在一次典型自愈流程中的完整交互路径：
3.3 各层内部组件与关键设计
3.3.1 监控层：多维数据采集与告警降噪
- 数据源：基础设施（CPU/内存/磁盘）、中间件（Redis/MySQL/Nginx）、业务指标（QPS/错误率/响应时间）。
- 告警降噪策略：基于时间窗口的聚合（5分钟内同一指标连续触发3次才生成告警）、依赖关系抑制（下游故障时自动屏蔽上游告警）。
- 输出格式：统一告警事件结构体，包含
alert_id、metric_name、current_value、threshold、timestamp、labels。
3.3.2 决策层：规则引擎与拓扑感知
- 规则匹配：基于告警标签（如
service=order、severity=critical）匹配预定义的Runbook模板。 - 限流联动判断：当告警指标为“请求量突增”或“响应时间飙升”时，决策层自动附加限流参数（如限流阈值、限流时长）。
- 冲突检测：同一资源同时收到多个自愈指令时，按优先级（P0 > P1 > P2）与时间戳排序，避免操作覆盖。
3.3.3 执行层：Runbook编排与限流保护
- Runbook原子步骤：每个Runbook由多个原子操作组成，例如
检查限流状态 → 下发限流规则 → 验证限流生效 → 执行扩容 → 解除限流。 - 限流保护机制：执行层在操作前先读取当前限流水位，若已触发限流则跳过扩容操作，直接进入“限流保护”模式，防止系统过载。
- 回滚能力：每个原子操作都包含回滚脚本，执行失败时自动触发回滚，恢复至操作前状态。
3.3.4 反馈层：自愈效果验证与混沌注入
- 效果验证：执行完成后，反馈层持续监控业务指标（如QPS恢复率、错误率下降），若在指定时间内未恢复，则触发升级流程（通知人工介入）。
- 策略调优：记录每次自愈的决策路径与执行结果，通过离线分析生成策略优化建议（如调整限流阈值、修改Runbook步骤顺序）。
- 混沌实验触发：当自愈系统稳定运行一段时间后，反馈层可自动触发混沌实验（如注入延迟、模拟节点故障），验证自愈流程的鲁棒性。
3.4 分层架构的限流保护联动细节（SVG）
下图聚焦于“限流保护”这一关键场景，展示四层架构如何协同完成限流策略的自动下发与解除：
架构设计要点：
- 解耦性：每层只依赖下层提供的标准接口，不关心内部实现。例如决策层不关心执行层是用Ansible还是K8s Job执行Runbook。
- 可观测性：每层都暴露关键指标（如决策耗时、执行成功率、反馈延迟），便于监控自愈系统本身的健康状态。
- 安全边界：执行层对限流操作进行“熔断保护”，当连续3次执行失败时自动暂停该Runbook的执行，防止错误扩散。
3.5 分层架构的容错与扩展设计
| 场景 | 容错策略 | 扩展方式 |
|---|---|---|
| 监控层数据丢失 | 本地缓存告警事件，网络恢复后重传 | 增加采集节点，水平扩展Prometheus实例 |
| 决策层规则引擎宕机 | 主备切换，备节点从消息队列重新消费告警 | 引入规则缓存，支持离线决策 |
| 执行层操作超时 | 设置全局超时时间（默认30s），超时后自动回滚 | 将Runbook拆分为更细粒度的原子操作，支持并行执行 |
| 反馈层验证失败 | 触发升级流程，通知SRE值班人员 | 引入多维度验证指标（业务指标 + 基础设施指标） |
常见误区：不要将决策逻辑直接写在监控层的告警规则中，这会导致监控层与决策层耦合，难以维护和扩展。始终通过事件驱动的方式将告警传递给独立的决策层进行处理。