一次延迟排查的记录体写作

【文首声明】本文所有 IP、数值与对话为教学示例（结构与方法真实可用），不是某次真实事故的档案。

14:02 —— 客服转来工单：三位东南亚用户反馈「下午开始网站转圈」。第一反应不是查服务器，是先分清「谁慢」：我们自己访问快不快？快。那大概率是路径问题，不是服务挂了。

14:10 —— 服务器上跑第一轮基础测量。ping 用户所在方向的代表性节点：延迟正常、零丢包。奇怪。但 ping 只有五个包，说明不了高峰行为——先记下「空闲时段正常」。

14:25 —— 换 MTR 看全程路径，100 个包。输出里第 6 跳丢了 23%，末跳 0%。心里咯噔一下，差点直接开工单说「第 6 跳有问题」——停。翻出判读纪律：中间跳丢包而末跳正常，多数是那台路由器对 ICMP 限速，不是真丢包。真丢包的样子是「从某跳开始一直丢到末跳」。虚惊一场，但这二十秒的自我纠正值得写下来：工具给了数字，判读靠的是脑子。

15:40 —— 意识到采样时段不对。用户说「下午开始」，而他们的下午是我们的晚高峰前夜。定好三时段采样：现在一轮、20:00 一轮、22:00 一轮，每轮 MTR 100 包存档，文件名带时间戳。

20:15 —— 晚高峰第一轮结果出来了：末跳延迟从空闲时段的 80ms 级涨到 220ms 级，第 9 跳开始 StDev（标准差）明显放大，末跳丢包 4%。这次是真的——从第 9 跳持续到末跳的劣化，国际出口段拥塞的典型画像。

20:40 —— 开工单。按存证规范提交：结论一句话（「晚高峰起第 9 跳 AS 边界后持续劣化，末跳丢包 4%，三时段 MTR 档案附后」），附三轮 MTR 原始文件与时间戳。没有形容词，没有「非常慢」「严重影响」——工程师要的是坐标，不是情绪。

次日 11:00 —— 机房回复：该方向国际出口上周调整了路由策略，晚高峰流量走了较拥挤的转接路径，已切回。复测三轮，末跳劣化幅度回落到空闲时段的 1.3 倍内。工单闭环，档案归档。

── 两条可复用的经验 ──
一、时段是延迟测量的一半：空闲时段的「正常」不能反驳高峰时段的「异常」，采样要覆盖用户抱怨的那个时间窗。
二、工单的说服力来自结构：结论 + 判据 + 原始档案 + 时间戳，比任何紧急程度的形容词都能让问题更快被处理。

用记录体（带时间戳的日志形式）写一篇 800 字左右的网络延迟排查故事：起因是海外用户反馈网站变慢，过程包含 ping/MTR/分时段采样三个工具的使用、一次「中间跳丢包」的误判与纠正、最终定位到晚高峰国际出口拥塞并开工单。要求：技术细节准确、时间戳推进有节奏感、结尾提炼两条可复用的经验。在文首标注「数据为教学示例」。