Runbook 归属

给每 runbook 分负责人和团队；季度审查使 runbook 不腐。

为什么

无主 runbook 是孤儿 — 系统变时（新部署工具、服务改名、迁移 DB）无人更新 runbook，下次事件找到告诉值班跑已不存在命令的 runbook。这是 runbook 腐，是 runbook 真实事件中失败的最常见原因。负责人（团队非人 — 人会走）负责系统变时保持 runbook 当前，季度审查抓漏的腐。审查便宜：每 runbook 在 staging 过步骤；命令失败或链接 404 则修。这样做的团队报 95% runbook 事件中首次工作；不做的报 40% — 失败的 60% 每个花 15 分钟困惑调试。

何时使用

runbook 写时。季度审查所有 runbook；系统变时立即审查其 runbook。

如何做

1. 给每 runbook 分负责人（团队）和主作者
   - 负责人 = 拥有 runbook 所涉系统的团队
   - 存 runbook 前置元：owner: @team-payments，author: @alice
   - 负责人负责保持当前非作者

2. 使 runbook 更新成系统变更清单一部分
   - "服务改名？更新所有引用旧名的 runbook。"
   - "迁移 DB？更新所有 DB runbook 的新连接串。"
   - 代码审查：若变更坏 runbook，要求同 PR 更新 runbook

3. 跑季度 runbook 审计
   - 每 runbook：在 staging 过步骤
   - 每命令成功？每链接解析？验证仍工作？
   - 修或删失败的 runbook；坏 runbook 比无 runbook 更糟

4. 跟踪 runbook 新鲜度作指标
   - "过去 90 天更新的 runbook / 总数" — 目标 >80%
   - 一年未触的 runbook 几乎肯定腐了

5. 删已删告警的 runbook
   - 若删告警（告警疲劳），也删其 runbook
   - 孤 runbook 累积并混淆审计

示例

# runbook/checkout-slo-burn.md（前置元）
---
owner: @team-payments      # 负责保持当前的团队
author: @alice             # 原作者（历史）
last_reviewed: 2026-01-15  # 季度更新
alert: CheckoutSLOBurnRateFast
---

# 季度审计脚本（在 staging 跑）：
for rb in runbooks/*.md; do
  owner=$(yq '.owner' "$rb")
  last_reviewed=$(yq '.last_reviewed' "$rb")
  age=$(( (today - last_reviewed) / 30 ))
  if [ $age -gt 3 ]; then
    echo "过期：$rb（负责人：$owner，最后审查：$last_reviewed）"
  fi
done
# 输出：
#   过期：runbook/db-failover.md（负责人：@team-platform，最后审查：2025-08-01）
#   → @team-platform 审查 db-failover.md，在 staging 过步骤，更新或删

# 指标：过去 90 天更新 runbook / 总数 = 42/50 = 84% ✅（目标 >80%）

常见问题

⚠无负责人 — 系统变时无人更新 runbook，下次事件找到跑已不存在命令的 runbook。
⚠负责人是已离团队的人 — runbook 成孤儿；归属分团队非个人。
⚠无季度审查 — runbook 静默腐，runbook 首测是真实事件，这是发现它坏的最坏时。
⚠已删告警的 runbook 留 — 作孤儿累积、混淆审计、浪费审查者时间。

最佳实践

✓在前置元给每 runbook 分团队负责人（非人）；负责人在系统变时保持当前。
✓使 runbook 更新成系统变更清单一部分；代码审查拒绝坏 runbook 而不更新的变更。
✓跑季度审计：在 staging 过每 runbook 步骤，修或删失败 — 坏 runbook 比无 runbook 更糟。
✓跟踪"过去 90 天更新 runbook / 总数"作指标；目标 >80%，删告警时删 runbook。