运维与恢复 / 调查与恢复
English

调查与恢复

找到证据，止损，恢复受影响的流程和记录。

更新于 2026年11月5日查看 Markdown
本页内容

1. 弄清情况

场景： 用户反馈今天早上开始收不到 OTP 验证码。

较差的 prompt
OTP 挂了。重启短信 worker，把发送失败的重试一遍。
更好的 prompt
调查 [环境] 中 [开始时间] 到 [结束时间，含时区] 之间的 [症状和受影响的流程]。已知标识：[应用版本、ID，或未知]。
用已批准的只读权限，沿着任务、外部调用和错误追踪这次尝试，并和已部署的代码、最近的改动做对比。
给出时间线，每一项附上证据出处；列出有证据支持的假设、缺少的证据或权限，以及下一步最值得做的检查。
不要发消息、重放操作、绕过检查、重启服务，也不要修改生产数据或设置。

原因： 重启会抹掉证据，重试可能把付费短信发两遍。先只读地找到流程断在哪里，再让人动手。

  • 从发布与收尾里的发布记录和没通过的上线后检查入手；和发布无关时，从上报的症状入手。
  • 指定一位事故负责人，下一步怎么做由负责人决定。拉上 PM 和 QA；PM 按项目的事故流程对接客户。
  • 重大节假日期间，由值班工程师和 PM、QA 一起查日志。值班安排写在项目的 runbook 里。
  • 让 agent 引用匹配的记录，不要粘贴整段日志。用操作 ID、请求 ID 或任务 ID 关联事件；时间戳接近，不能证明两个事件有关联。
  • 对比的对象是已部署的 artifact，不是当前分支。给事件排序之前，先写明时区换算。
  • 重启或修改配置之前，先保存日志和记录，除非这样会耽误止损。密钥和个人数据要脱敏。
  • 每条结论都要注明证据：日志行、记录或操作 ID。没有证据的解释只是假设，不管 agent 说得多肯定。
示例OTP 调查记录 · 尝试 A-17

用户反馈一直没收到验证码。范围：生产环境，应用 4.12.0，09:40–09:45 UTC。

证据 观察 能说明什么
09:41:02 · 客户端诊断 C-17 用户点了“发送验证码”，人机验证开始。 流程已经启动；验证结果未知。
后端日志搜索 Q-17 没有 A-17 的匹配记录。 暂时说明不了什么：采样、缺 ID 或查错日志源都可能是原因。
09:41:03 · 错误事件 E-17 人机验证回调之后，客户端处理 token 时抛出异常。 是应用出了错；人机验证本身未必失败。
与 E-17 对应的已部署应用源码 异常发生在发起后端请求之前。 这次尝试根本没到后端。

结论：这次尝试停在了应用里，所以暂时不用去短信服务商那边查。下一步检查：用合成账号在应用 4.12.0 中复现这个回调，并确认没有别的路径会到达后端。

2. 止损

Prompt
[环境] 出了 [事故]。提出能止住 [损害] 的最小可逆操作。
从当前生效的配置里读出账号、环境和目标，并报告出来。给出确切的命令或设置、预期效果、会耽误哪些正常业务，以及怎么撤销。
不要执行它，也不要修改生产数据或设置。
  • 选能止损的最小可逆操作：暂停受影响的任务、关掉功能开关，或者用奖励发放或付费发送的 kill switch。说明它会耽误哪些正常业务。
  • 写明确切的目标、操作、预期效果和撤销方法。生产环境操作和破坏性操作需要有人明确同意；同意读日志不等于同意写入。
  • 临执行前，再核对一遍账号、环境和目标。
  • 回滚发布按它的恢复计划执行。回滚能阻止新的损害，但撤销不了已经造成的影响。
  • 密钥泄露时，按访问、密钥与数据处理：先吊销，再查它被怎么用过。

3. 恢复流程并核对受影响的操作

Prompt
[事故] 发生在 [开始时间] 到 [结束时间，含时区] 之间。列出受影响的用户流程、待处理或失败的操作、改动过的数据和外部影响；外部服务有记录的，拿我们的记录和它对比。
提出恢复方案，写明确切的目标、预期效果和验证方法，并列出未解决的事项和负责人。
只用读权限。不要重放操作、修改记录，也不要发起会产生实际影响的调用。
  • 先恢复并测试受影响的用户流程，再核对待处理和失败的操作。页面能用，不代表队列里的任务已经完成。
  • 检查外部影响，比如已发出的消息和已创建的订单；回滚撤销不了这些。
  • 结果未知时，重试之前先用原操作的标识查询；查清之前保持待处理状态，并指定负责人。见后台任务与外部调用。
  • 更正余额时，新记一条分录指向原来那条，不改历史记录。
  • 恢复数据库按这个服务的 runbook 操作。弄清恢复点，以及恢复会丢掉哪些数据；先恢复到一个单独的实例，保留受损现场，重新开放写入之前核对外部操作。
  • 恢复要让受影响的用户流程重新可用，并核对受影响的操作。对照现有记录，检查待处理和失败的操作、改动过的数据和外部影响，必要时也要看服务商那边的证据。每个未解决的事项都要有负责人和下一步检查。
失败案例 · 示意

把失败的都重试一遍

导出 worker 写完文件，还没记录完成状态就崩溃了。agent 用新的任务 ID 把所有待处理的导出重新入队，客户因此收到了重复的文件和重复的通知。如果先查原来的操作和已有的文件，就能知道哪些已经做完了。

4. 关闭事故

Prompt
为 [事故] 起草事故记录：时间线、原因、采取的措施、证据引用，以及仍未完结的操作和负责人。
从 [基础分支] 拉一个分支，写一个在原始故障上会失败的回归测试，并展示它在 [修复前的 commit] 上失败。
列出误导了人或 agent 的说明和文档，以及没能找到的证据。
先不要 push 或开 PR。
  • 确认损害已经止住，积压的任务已经处理完。挑一个恢复后的操作，从头到尾跟一遍。
  • 在项目存放事故记录的地方写一份简短记录：时间线、原因、采取的措施、证据，以及仍未完结的操作和负责人。
  • 把这次故障写成回归检查，并证明原故障存在时它会失败。改正误导了人或 agent 的说明。
  • 生产环境等不到下一个版本时，把正式修复作为紧急修复发布。
  • 查不到的证据，逐一建 ticket。缺失的操作 ID 或日志行，就是下一次事故的盲区。
  • 每次事故都要留下一个回归检查，原故障存在时它会失败。正式修复走正常评审；再紧急也不能跳过。