3. 值班机器人架构：核心组件与高可用设计

值班机器人是事件触发与故障恢复流程之间的自动化桥梁。其架构设计直接决定了告警处理的实时性、可靠性和扩展性。本节深入剖析机器人的三大核心组件、消息中间件的选型对比以及保障服务持续运行的高可用策略。

3.1 机器人核心组件

值班机器人采用微服务理念，将事件处理链路拆分为三个职责清晰的模块：监听器、决策引擎和执行器。三者通过消息中间件异步解耦，形成可水平扩展的流水线架构。

3.1.1 监听器（Listener）

监听器是机器人的“感官”，负责接入各类监控系统的事件流。它需要支持多种协议和数据格式，并将异构事件统一为内部标准事件模型。

• 多源接入：支持 Webhook（Prometheus Alertmanager、Zabbix）、HTTP API 轮询、Syslog、Kafka 直连等。
• 事件标准化：将不同来源的告警字段（如 severity、timestamp、labels）映射为统一的 AlertEvent 结构。
• 去重与聚合：基于指纹（fingerprint）算法在内存或 Redis 中做短时间窗口去重，防止风暴。
• 速率限制：对高频事件源实施令牌桶限流，保护下游组件。

3.1.2 决策引擎（Decision Engine）

决策引擎是机器人的“大脑”，负责根据事件内容匹配预定义的 Runbook 规则，决定触发何种恢复流程。它是整个系统的核心逻辑单元。

• 规则匹配：支持基于标签、严重级别、来源、时间窗口等条件的组合匹配（AND/OR/NOT）。
• Runbook 路由：匹配成功后，从 Runbook 仓库中加载对应的恢复流程定义（YAML/JSON）。
• 上下文注入：将事件中的动态参数（如主机 IP、故障指标值）注入到 Runbook 模板变量中。
• 决策缓存：对高频匹配的规则结果进行本地缓存，减少重复计算。

3.1.3 执行器（Executor）

执行器是机器人的“手脚”，负责实际执行 Runbook 中定义的恢复步骤。它需要具备幂等性、超时控制和结果反馈能力。

• 步骤编排：按顺序或并行执行 Runbook 中的动作（SSH 命令、API 调用、Kubernetes Job 触发）。
• 幂等保障：每个动作都带有全局唯一 ID，支持重试时检测是否已执行，避免重复操作。
• 超时与熔断：单个步骤超时后触发回滚或跳过，连续失败达到阈值则熔断该 Runbook。
• 结果回写：将执行状态（成功/失败/超时）和日志写回事件总线，供后续通知或人工介入。

3.2 消息中间件选型：Kafka vs RabbitMQ

消息中间件是值班机器人架构的“脊椎”，决定了事件的传递可靠性、吞吐量和消费模式。下表从值班机器人场景的关键维度对比 Kafka 与 RabbitMQ。

3.3 高可用设计

值班机器人作为故障恢复的“第一响应者”，其自身必须具有极高的可用性。高可用设计覆盖组件冗余、数据持久化和故障转移三个层面。

3.3.1 组件级高可用

• 监听器多实例：部署至少 2 个监听器实例，通过负载均衡器（如 Nginx/HAProxy）分发事件源请求。实例间无状态，共享 Redis 做去重计数器。
• 决策引擎主备：采用主备模式（Active-Standby），主实例负责规则匹配，备实例通过 ZooKeeper/etcd 监听主节点心跳，超时后自动接管。
• 执行器池化：执行器以 Worker Pool 形式部署，每个 Worker 独立运行，通过消息中间件的消费者组（Consumer Group）实现负载均衡与故障转移。

3.3.2 数据层高可用

• 消息中间件集群：Kafka 使用多 Broker + 副本因子（replication-factor ≥ 3）；RabbitMQ 使用镜像队列（Mirrored Queues）或 Quorum Queues。
• 状态持久化：决策引擎的规则缓存定期快照到分布式存储（如 etcd/Consul）；执行器的执行记录写入 Elasticsearch 或数据库，支持故障后恢复现场。
• Runbook 仓库版本化：Runbook 定义存储在 Git 仓库，机器人本地缓存失效时自动拉取最新版本，避免单点故障。

3.3.3 故障转移与自愈

• 健康检查：每个组件暴露 /health 端点，返回组件状态和依赖项（如消息中间件连接、Redis 连接）的健康状况。
• 自动摘除：负载均衡器或服务发现组件（Consul/K8s Service）定期探测健康端点，连续失败 3 次后自动摘除故障实例。
• 优雅关闭：组件收到 SIGTERM 信号后，停止接受新任务，等待当前任务完成（或超时强制退出），确保不丢失正在处理的事件。

3.4 关键配置示例

以下为决策引擎的规则匹配配置片段（YAML 格式），展示如何将告警事件路由到对应的 Runbook。

# decision-engine-rules.yaml
rules:
  - name: "high-cpu-auto-recovery"
    match:
      alertname: "CPUUsageHigh"
      severity: "critical"
      source: "prometheus"
    runbook: "auto-restart-service.yaml"
    params:
      service_name: "{{ .labels.service }}"
      threshold: "{{ .value }}"
    timeout: 120s
    retry: 2

  - name: "disk-full-notify-only"
    match:
      alertname: "DiskSpaceFull"
      severity: "warning"
    runbook: "notify-oncall.yaml"
    params:
      host: "{{ .labels.instance }}"
      mount: "{{ .labels.mountpoint }}"
    timeout: 30s
    retry: 0