运维 · 排查路径

网络故障现场证据如何保留

故障现场的快速恢复很重要,但如果缺少结构化的证据记录,事后分析会停留在猜测层面,无法防止再次发生。

排查步骤

查看、判断、复查

  1. 01

    立即抓取时间戳化日志:DNS 解析日志、服务器访问日志、应用日志和 CDN 边缘日志。

  2. 02

    在受控位置保留必要的网络层记录与响应时间;curl -v 等输出可能含凭据,分享时另取最小脱敏副本。

  3. 03

    截图或导出监控面板数据(Grafana、CloudWatch、Sentry)的故障窗口期指标。

  4. 04

    按时间线排序所有证据,标注已确认事实和待验证假设,写入事故报告的可复现阶段。

跟着示例核对

示例内容用于说明方法,非本站探测记录。复核于 2026-09-06。

以下全部为模拟数据,不是本站观测:
环境:release-example / 同一浏览器 / UTC+08:00
任务:查看示例列表;路径 GET /api/example(已移除查询参数)
09:00 对照样本:200,显示示例条目,关联号 sample-ok
09:05 失败样本:504,列表未显示,关联号 sample-failed
未知:上游执行是否完成、数据库耗时、其他客户端是否受影响
共享材料:Authorization、Cookie、用户正文均未附带
下一步:用时间和经过审查的关联号查网关与应用记录

怎样解释结果

事实是两次样本结果不同;时间接近并不能证明环境和依赖完全相同。504 只提供网关等待上游的线索,根因和影响范围仍未知。记录缺失也不等于请求未到达;若日志未采集或已过保留期,应明确写出这个限制。

不符合预期时

先记录恢复动作与时间,避免覆盖唯一证据。原始日志仅保存在受控位置,分享前另做最小副本,删除令牌、Cookie、查询参数、个人数据和不必要的标识;删除部分字段不保证匿名。优先用虚构输入复现,不能复现时保留差异条件。

修改后复查

在同一任务下记录预期、实际、采取的修改及再次观察时间;把成功对照与失败样本分别保留。需要人工反馈时使用空白复现模板,逐项填写未知项;若问题涉及页面旧版本,再按缓存与迁移指南核对响应头和正文版本。