---
title: AIOps 告警排障 Runbook
keywords: [AIOps, 告警, HighCPUUsage, SlowResponse, payment-service, system-metrics, application-logs]
summary: 面向 AIOps 告警诊断的排障步骤，覆盖 Prometheus 活动告警、CLS 日志主题和处理建议。
category: troubleshooting
---

# AIOps 告警排障 Runbook

## 1. 告警输入处理原则

AIOps 诊断入口有两种触发方式：

- **有告警 payload**：将 payload 视为已触发告警，围绕 `alertName`、`service`、`severity`、`timeRange` 查询指标、日志和知识库。
- **无告警 payload**：先调用 `queryPrometheusAlerts` 获取当前 firing 告警，再选择 P0/P1 或持续时间最长的告警进入诊断。

最终报告必须基于工具证据，不得凭空编造指标、日志或处理结果。

## 2. Mock 告警与日志主题映射

| 告警名 | 典型服务 | 优先日志主题 | 推荐查询 |
|---|---|---|---|
| HighCPUUsage | payment-service | system-metrics | `cpu_usage:>80 AND service:payment-service` |
| HighMemoryUsage | order-service | system-metrics, system-events | `memory_usage:>85` |
| SlowResponse | user-service | application-logs, database-slow-query | `duration:>3000 OR slow request` |
| ServiceUnavailable | 任意核心服务 | application-logs, system-events | `level:ERROR OR container crash` |

## 3. HighCPUUsage / payment-service 排障步骤

### 3.1 现象确认

先确认 Prometheus 活动告警中是否存在：

- `alert_name = HighCPUUsage`
- `service = payment-service`
- CPU 使用率超过 80%
- 状态为 firing

如果 payload 已经提供该告警，也仍需通过指标或日志工具验证。

### 3.2 指标与日志取证

推荐工具调用顺序：

1. `queryPrometheusAlerts`：确认当前活动告警。
2. `queryLogs(region=ap-guangzhou, logTopic=system-metrics, query=cpu_usage:>80 AND service:payment-service)`：确认 CPU 使用率、实例和持续时间。
3. 如报告中提到 Redis、数据库或下游依赖，再查询 `application-logs` 或对应主题交叉验证。

### 3.3 根因判断

可接受的根因结论必须至少满足一项：

- system-metrics 显示 payment-service 实例 CPU 使用率持续高于阈值。
- application-logs 显示与 CPU 飙高同时出现的慢请求、线程池耗尽或依赖超时。
- 告警持续时间与日志时间线一致。

如果只有活动告警，没有日志或指标明细，应输出低置信结论并建议人工确认。

## 4. 处理建议

### 临时止血

- 对 payment-service 做水平扩容，优先扩容受影响实例所在 Deployment。
- 对高耗时接口开启限流或降级非核心功能。
- 如果近期有发布，检查变更窗口并准备回滚。

### 根因修复

- 分析 CPU 热点线程、慢请求接口和依赖调用耗时。
- 检查连接池、线程池、缓存穿透和批量任务是否导致 CPU 飙高。
- 补充针对 `payment-service` 的 CPU、P95/P99 延迟、错误率和依赖超时联动告警。

## 5. 报告要求

告警分析报告至少包含：

- 活跃告警清单。
- 告警根因分析。
- 使用过的工具证据：Prometheus 告警、system-metrics 日志、application-logs 或知识库。
- 已执行或建议执行的处理方案。
- 置信度说明：哪些结论有直接证据，哪些需要人工进一步确认。