一次延遲排查的記錄體寫作

【文首聲明】本文所有 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/分時段採樣三個工具的使用、一次「中間跳丟包」的誤判與糾正、最終定位到晚高峯國際出口擁塞並開工單。要求：技術細節準確、時間戳推進有節奏感、結尾提煉兩條可復用的經驗。在文首標注「數據爲教學示例」。