runbook

运维手册 — 创建或加载运维手册

使用主题调用时（例如，/runbook ARI management group）：

1. 在 runbooks/ 中搜索与主题匹配的现有运维手册
2. 如果找到，加载并显示该运维手册
3. 如果没有找到，使用此模板创建一份：

# Runbook: {{title}}

## Purpose
[One sentence — when and why to use this]

## Prerequisites
-

## Steps
1.

## Verification
- [ ]

## Troubleshooting
| Symptom | Cause | Fix |
|---------|-------|-----|

## Last Tested
{{date}}

使用 kebab-case 文件名保存到 runbooks/。

---

注意事项

• 过时的运维手册比没有运维手册更糟： 最后一次测试是在 18 个月前的运维手册，会自信地给出错误的命令标志、仪表板 URL 和回滚路径。对于 Last Tested 超过 90 天的内容，应视为可疑，并在事故压力下依赖之前重新验证。
• 未经测试的回滚步骤只是摆设： 如果从未在当前状态下执行过“运行 terraform destroy”，就不能确定它是否有效。回滚步骤必须至少在非生产副本上演练过一次，而不能只是写下来。
• 缺少先决条件会导致运维手册在凌晨 2 点失效： “只要运行脚本”这句话默认你已设置 kubectl 上下文、VPN、堡垒机上的 sudo 权限，以及有效令牌。请列出每项先决条件及其准确的验证命令——值班工程师并不是那个已经打开终端的你。
• 复制粘贴曾经成功的步骤不等于操作流程： 从正常工作会话中记录的 kubectl patch 命令可能会硬编码 Pod 名称、时间戳或特定资源版本。对于每次执行时可能变化的内容，都要使用参数，否则第二次执行就会失败。
• 没有命令的验证复选框只是空想： “验证服务运行正常”不算一个步骤，curl -fsS https://x/healthz | jq .status 才算。每条验证说明都应包含可直接复制粘贴的命令，并注明预期输出。
• 系统变更时，运维手册会悄无声息地失效： 重命名部署、轮换密钥保管库名称或更改入口主机，都会使运维手册失效，却不会发出任何信号。请在系统的 IaC 仓库中链接每份运维手册，以便基础设施变更触发运维手册审查。