排障之前，先把现场留下来

先写清楚，究竟是什么没有发生

“服务挂了”很难成为一条有用的记录。它可能指页面没有打开，也可能指登录失败、某个接口变慢，或者后台任务没有按时完成。第一份记录应当尽量贴近能观察到的现象：从哪里发起请求，访问哪个入口，预期得到什么，实际得到什么。

把“连接没有建立”和“连接后返回错误”分开，也把“这一次失败”和“持续失败”分开。这样做不会让问题立刻消失，却能让下一次判断少带一点猜测。

给每个样本加上时间和来源

一条日志里的时间，只有在知道时区以后才有意义。记录时可以保留带时区的完整时间，同时注明执行命令的机器、使用的网络和工具版本。不同来源的测试各自保存，不要把它们拼成一条看似连续的成功记录。

下面是一份很小的现场目录。命令本身并不复杂，重点是让结果在离开终端之后仍然找得到。

mkdir -p ./diagnostics
date -Iseconds > ./diagnostics/checked-at.txt
curl --version > ./diagnostics/tool-version.txt

一轮只改变一个能解释的变量

如果同时换了域名、端口、客户端和网络，即使最后恢复，也很难知道哪一步起了作用。更有用的比较是保留一条固定的参照，在相近时间交替测试，把每次的成功和失败都写下来。

需要修改配置时，先保存原文和回退步骤。复测结果出现差异后，再检查差异是否足以支持最初的猜想。不要只留下最后一次成功的截图。

把事实、判断和下一步分开写

一份便于接续的记录，可以用三个很短的段落收尾：目前确认了什么，哪些原因还只是推测，下一次检查能排除什么。后来接手的人就不必从所有终端输出里重新寻找起点。

排障记录的价值，不是证明当时判断得多快，而是让后来的人看得清楚：结论由哪些证据支持，哪些边界还没有验证。