运维手册 Runbook 怎么写提示词（告警处置步骤：值班同学半夜也能照着做）
给某个告警或常见故障编写处置手册时用：把老员工脑子里的排查经验整理成「先确认什么、再看什么、怎么止血、什么时候升级」的步骤文档，每一步有可复制的命令和判断标准，新人值班也能处理。
通用大模型 对话模型通用
请帮我为下面的告警编写一份运维处置手册（Runbook）。读者是半夜被叫醒、可能不熟悉这个系统的值班工程师，所以每一步都必须具体到可以照做。 - 告警名称与触发条件：[告警名称与触发条件]（例：订单服务 5xx 错误率超过 5% 持续 3 分钟） - 涉及的系统与架构简述：[涉及的系统与架构简述]（例：K8s 部署，依赖 MySQL 和 Redis） - 老员工的排查经验（口述整理即可）： [排查经验] - 可用的工具与平台：[可用的工具与平台]（例：Grafana、Kibana、kubectl、云控制台） - 升级联系方式与时限：[升级联系方式与时限]（例：15 分钟未恢复联系后端负责人，写角色不写个人电话） 手册结构： 1. 概述：这个告警意味着什么、对用户的影响、严重程度。 2. 首先确认（2 分钟内完成）：是否误报；影响范围有多大；最近有没有发布或变更（给出查询变更记录的方法）。 3. 排查步骤：按「最常见原因优先」排序，每一步写清： - 要执行的命令或要打开的面板（命令放在代码块里，可直接复制，变量部分用大写占位符并说明怎么取值）； - 看到什么结果说明是这个原因，看到什么结果说明不是、继续下一步。 4. 止血措施：每种原因对应的快速恢复办法（回滚、扩容、切流、重启），写明操作命令、预期效果、风险和是否需要先请示。有破坏性的操作（删除数据、清空缓存、强制重启数据库）必须标注「需负责人确认」。 5. 升级规则：什么情况下、多长时间内没恢复，要通知谁（写角色）。 6. 恢复后的确认：看哪些指标确认已经恢复、要观察多久。 7. 事后：需要记录的信息，用于后续复盘。 经验里没有提到、但你认为必要的检查步骤，标「建议补充，需团队确认」。手册中不要出现密码、密钥和个人联系方式。
高亮处换成你自己的内容：[告警名称与触发条件]、[涉及的系统与架构简述]、[排查经验]、[可用的工具与平台]、[升级联系方式与时限]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[排查经验] 可以直接录一段老员工的口述转成文字贴进来，比如「一般先看是不是数据库连接池满了，满了就看有没有慢查询……」。AI 会把这些经验整理成有判断标准的步骤。
常见坑：
- 步骤写成「检查数据库状态」这种笼统的话，值班的人根本不知道该敲什么命令、看哪个数字。每一步都要有具体命令和「看到什么说明什么」。
- 止血手段没有标风险。半夜慌乱时，有人会直接执行清空缓存、重启数据库，造成更大的事故。
- 手册写完就过时。每次事故复盘后，都要回来更新对应的 Runbook。
追问技巧：手册写完后追问「如果按这个顺序排查，最坏情况下要多久才能找到原因？有没有可以并行或提前的步骤」；也可以让 AI 把手册改写成一张一页纸的速查表。
示例输出
示例，仅供参考（节选）
3.2 检查数据库连接池是否耗尽
bash
kubectl logs -n prod deploy/order-service --since=10m | grep -c "Connection is not available"- 结果大于 0，且持续增长：连接池耗尽，进入 3.3 查找慢查询；
- 结果为 0：不是连接池问题，进入 3.4 检查 Redis。
4.1 止血：回滚最近一次发布（适用于告警开始时间与发布时间吻合）
bash
kubectl rollout undo deploy/order-service -n prod
kubectl rollout status deploy/order-service -n prod预期 3 分钟内错误率回落到 1% 以下。风险：回滚会撤销本次发布的所有功能，无需请示，但须在值班群告知。
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～