复现是排障的地图
能稳定复现的故障才有资格谈根因。复现的价值不在「重现一次」，而在把触发条件固定下来：什么源、什么目标、什么协议与参数、多长时间出现一次。条件一旦可重放，就可以做对照实验——改一个变量看现象是否变化，这是把猜测变成结论的唯一路径。复杂度要往下压，直到剩下一条可复制的命令。
基本信息
| 必须记录的要素 | 时间、源、目标、协议端口、参数、频率与影响面 |
|---|---|
| 目标 | 让故障在几分钟内可重放，而非「偶尔出现」 |
| 产物 | 一条可复制的最小复现命令，附失败率统计 |
| 原则 | 一次只改一个变量，改前留基线 |
| 不可复现时 | 长时低干扰监测 + 分卷抓包 + 日志留档，等待复现 |
典型使用场景
- 用户报「偶尔打不开」：先用循环请求把偶发变成可测量的失败率
- 修改疑似相关配置后验证：同一复现命令前后对比成功率
- 与厂商或云平台交涉：给出对方能照做的复现步骤，比描述现象有效
- 跨环境差异分析：同一命令在正常环境与异常环境各跑一遍
- 为复盘与回归测试留素材：复现脚本本身就是验证用例
复现记录与循环触发（Linux）
复现记录与循环触发（Linux）
for i in $(seq 1 20); do # 20 次连续触发，统计失败率
curl -s -o /dev/null -w "%{http_code} %{time_total}\n" --connect-timeout 5 https://<目标>/
sleep 0.5
done
# 分离阶段耗时，区分 DNS、建连、首字节：
for i in $(seq 1 10); do
curl -s -o /dev/null -w 'dns=%{time_namelookup} conn=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} code=%{http_code}\n' https://<目标>/
done
# 复现同时抓包留证（分卷防止写满磁盘）：
tcpdump -i eth0 -nn -s 0 -C 50 -W 10 -w /tmp/repro.pcap 'host <目标IP> and tcp port 443'复现记录要素
| 字段 | 写什么 | 为什么 |
|---|---|---|
| 触发动作 | 完整命令与参数，不用「访问页面」这类描述 | 别人要能照着做一遍 |
| 失败率 | 20 次中失败几次、失败时的耗时分布 | 区分偶发与必现，量化改善 |
| 环境 | 系统版本、客户端与目标地址、是否经代理 | 换环境不复现时能解释原因 |
| 时间窗 | 精确到秒的开始与结束，附抓包文件名 | 事后与日志、抓包对齐 |
无法复现时退一步：用监控与长时日志「等待复现」，同时挂上低频抓包（-C 分卷限制总量）长期取证，别在生产上高频重试。
复现要控制影响面：优先在单台客户端、单个实例上做；高频循环请求本身可能触发限流或重试风暴，把偶发故障放大成事故。