AI 交接与值班应急

⏱️ 20分钟

用 AI 写交接包/值班指南/事故通报模板

本章实践目标

01要解决的工作问题

用 AI 写交接包/值班指南/事故通报模板

02完成后带走

一份能用于真实工作的模板，包含真实输入、明确输出格式和人工复核点。

03做到什么算完成

用真实任务跑通一次，核对关键事实，并记录使用前后的时间。

值班（On-call）和交接最折磨人的不是任务多，而是信息碎。AI 在这里的核心角色不是替你做决定，而是帮你从乱七八糟的聊天记录和告警日志中，瞬间抓取关键上下文。

1) 事故通报：从“群聊乱战”到“结构化通报”

当线上出问题时，群里全是“收到”、“我查查”、“重启试试”。作为值班人员，你需要快速给老板和协作团队一个清晰的现状。

🚀 实战技巧：碎片化信息提取

将过去 10 分钟的群聊记录直接复制给 AI：

专家版 Prompt：

你是 SRE 响应专家。请阅读以下原始聊天记录（粘贴记录），提取并输出一份《事故快报》：
1. 【现状】目前受影响的业务模块和影响面。
2. 【进展】已执行的操作（如：回滚、扩容、摘除节点）。
3. 【关键节点】故障发现时间、首响时间、目前的排查阶段。
4. 【下一步】需要谁配合、预计多久给下一次更新。
注意：剔除聊天中的废话和表情包，只保留硬核事实。

2) 智能交接包：不只是写文档

传统的交接文档写完就过期。AI 可以帮你把“脑子里的零散信息”变成“新人的生存指南”。

💡 场景模拟：

你要休假一周，需要把项目交接给同事。

提升 Prompt：

我要休假，请帮我整理一份交接清单。
背景：项目 A 正在灰度，B 功能测试中，C 客户昨天投诉了接口慢。
任务：请输出：
- 【待办优先级】按紧急度排序（High/Medium/Low）。
- 【风险雷达】列出 3 个最可能出问题的地方及对应的“救火手册”（Runbook）。
- 【关系网】谁是核心决策人？出事了找谁最快？
- 【自检项】请新人在接手第一天必做的 3 件事。

3) 避坑指南：安全是红线

风险点	错误做法	专家建议
敏感信息	在 Prompt 里贴入数据库密码或 Token	严禁上传任何真实密钥。使用 `[DB_PASSWORD]` 等占位符。
日志隐私	直接上传包含用户手机号/身份证的日志	先让 AI 写一个 Python 脚本来脱敏，或者手动模糊化关键信息。
过度依赖	照抄 AI 给出的修复命令（如 `rm -rf`）	AI 给出的命令必须经过人工二次确认，严禁在生产环境直接运行 AI 生成的复杂 Shell 脚本。

4) 进阶：自动化 Runbook

你可以让 AI 预先为你负责的模块写好“应急剧本”。

示例： “你是系统专家。如果我的服务出现 HTTP 504 且 QPS 翻倍，请给我列出 5 个排查步骤和对应的命令。”

5) 动手练习

任务：模拟一次“假故障”。

随意写一段 5-8 行的混乱聊天记录。
让 AI 尝试将其总结为一份发给 CTO 的邮件通报。
调整 Prompt，直到 AI 能够准确识别出谁是“解决问题的负责人”。

6) 完整案例：跨时区交接一个未解决事故

悉尼团队下班时，服务错误率仍高于平时，但影响面还没确认。交接目标不是把聊天记录全部复制给下一班，而是让对方能在五分钟内继续行动。

请把以下时间线整理成跨时区交接包。
只使用记录中出现的事实，输出：
1. 当前影响：已确认 / 未确认
2. 已执行动作及结果
3. 当前假设及支持/反对证据
4. 下一班前 3 个动作（owner / 预计完成时间）
5. 必须升级的条件
6. 相关 dashboard、ticket、runbook 链接占位符
密码、Token、客户个人信息一律不写入。

一份可接手的交接记录

区块	必须回答的问题	不合格写法
Current impact	谁受影响、从何时开始、证据是什么	“系统好像不稳定”
Actions taken	做了什么、结果如何、是否可回滚	“已经处理过”
Active hypothesis	为什么怀疑它、还缺什么证据	把猜测写成根因
Next action	谁在什么时候前做什么	“继续观察”
Escalation	什么条件必须叫醒谁	只放联系人姓名

7) 交接接收方的 Read-back

交接不是发送文档就结束。接收方需要用自己的话确认：

当前最重要的影响是什么
下一步由谁执行
哪个动作不能做或需要审批
何时再次同步

如果双方说出的答案不一致，说明交接还没完成。

8) 事故信息的安全边界

日志已移除 Token、Cookie、手机号、邮箱和客户正文
AI 给出的命令先在安全环境验证，再由人批准执行
根因未知时明确写“当前假设”，不制造确定性
外部通报只使用批准过的影响范围和更新时间
每项临时操作都有记录、负责人和回滚方式

9) 常见失败与修正

失败	原因	修正
文档很长，接班人仍不知道先做什么	没有按行动优先级组织	首屏固定放影响、当前状态、前三个动作
AI 把聊天里的猜测当根因	没区分事实与假设	输出分为 confirmed / hypothesis / unknown
联系人很多但升级仍慢	没写触发条件	为每个升级联系人写清“何时找他”
事故结束后记录找不到	没有统一归档	把最终时间线、决定和复盘链接写回知识库

10) 本章交付物

留下一套 Handover Pack：五分钟摘要、详细时间线、下一动作、升级条件和 read-back 记录。事故结束后进入 AI 知识管理，把稳定经验沉淀为可检索的 runbook。