Runbook 触发

把每个告警链接 runbook，并在首步确定时自动触发可执行 runbook。

为什么

无 runbook 的告警是花 15-20 分钟"这是什么意思？"才开始调查的 page。把告警链接 runbook 把这压到 30 秒阅读，且若 runbook 首步确定（重启 pod、故障转移 DB、清缓存），你可自动执行并在人读完 page 前砍 MTTR。runbook 触发是监控与行动的桥：它把"缓存层 CPU 高"从模糊症状变"这是一键清膨胀键的脚本，以及若不工作查什么"。接 runbook 触发的团队报 40-60% MTTR 降因为常见事件在人登录完前自解。

何时使用

在你有告警和 runbook 之后。当 runbook 首 1-2 步安全、确定、可逆时加自动触发。

如何做

1. 确保每个告警链接 runbook
   - 告警注解：runbook_url；paging 系统在 page 中展示它
   - 无 runbook = 无告警（告警规则代码审查强制）

2. 为自动化结构化 runbook
   - 步 1-2：确定、安全、可逆（重启、清缓存、故障转移读副本）
   - 步 3+：需判断（查日志、决定回滚）— 仅人
   - 标记哪些步可自动执行

3. 为安全步接自动触发
   - 告警触发 → runbook 步 1-2 自动执行（经 webhook → job）
   - 人并行 page；人确认时步 1-2 可能已解
   - 若自动步失败 → 升级严重性（简单修没工作）

4. 记每次自动执行
   - 跑了什么、改了什么、成功/失败、与告警关联
   - 这是你的审计轨迹和"自动修复有帮助吗？"数据集

5. 测影响
   - "自动修复解决的事件" / 总数 → 常见告警目标 30-50%
   - "自动修复更糟"率 → 须 <1%；更高则降为仅人

示例

# 带 runbook + 自动触发 webhook 的告警规则
- alert: CacheHitRateLow
  expr: cache_misses / (cache_hits + cache_misses) > 0.5
  for: 10m
  labels: { severity: ticket, team: platform, runbook: "https://rb/cache-low-hit" }
  annotations:
    auto_remediate: "https://ops/api/runbook/cache-clear-bloated"

# ops/api/runbook/cache-clear-bloated（可自动执行、安全、可逆）：
#   1. 按驱逐识别 top 10 键（只读、安全）
#   2. 检查是否匹配已知膨胀键模式（安全）
#   3. 是 → DEL 那 10 键（可逆：是缓存，会重填充）
#   4. 记日志：哪些键、前后命中率、correlation_id
#   5. 命中率恢复 → 解告警；否则 → 升级到人
# 人 runbook（步 3+）：https://rb/cache-low-hit
#   - 若自动清没帮 → 查新部署是否改访问模式
#   - 是 → 回滚（runbook：rollback-platform）

常见问题

⚠不可逆的自动修复 — 删数据或删表的脚本无法撤销；自动触发限安全可逆行动。
⚠SEV1 无人在环自动触发 — 若自动修错，你更快把宕机搞更糟；总并行 page 人。
⚠无自动执行审计日志 — 宕机变糟时你不知是否自动修复导致；每行动带关联 ID 记日志。
⚠runbook 是过期文档而非可执行脚本 — 链接指向 2 年前最后编辑、不再匹配系统的 Confluence 页。

最佳实践

✓代码审查强制"无 runbook = 无告警"使每告警有可行动链接；仅此每事件砍 MTTR 15-20 分钟。
✓仅自动触发安全可逆步（重启、清缓存、故障转移读副本）；绝不自动触发毁数据行动。
✓总与自动修复并行 page 人；若自动修失败或更糟，人已在调查。
✓每自动执行带关联 ID 记日志并测"自动修复更糟"率；>1% 则降该 runbook 为仅人。