01｜当研发第3次提单“GitHub 拉不动”
别急着加带宽，我通常先反问自己：
“是链路真的不够，还是关键业务流没被‘看见’？”
过去一年，我们处理了27起“网络慢”投诉，其中一半根因不在带宽，而在流量不可视、策略不匹配、架构假设过时。
于是，我整理了一套5层自检清单。每次被投诉，就按图索骥——不仅少背锅，还能在复盘会上用数据说话。
第一层：代码/模型/依赖类流量 —— 最容易被误判的“小流量”
- 研发反馈：
git clone卡住、CI 偶发超时、首次访问极慢 - 表面看：链路带宽充足，丢包率 <0.1%
- 实际可能：
- 跨境 RTT 高 → TCP 拥塞窗口反复收缩
- 防火墙 TCP session timeout 太短 → 长连接被掐断
- 轻微丢包（0.5%）→ 被 TCP 放大成吞吐暴跌
✅ 我的反问：
“我们的 QoS 是否把 git pull 这种交互型小流量，和视频会议归为一类？”
📌 记住：这类流量优先级不该看“带宽大小”，而要看对研发连续性的破坏程度。
第二层：仿真/测试/打流类流量 —— 测试通过≠真实可用
- 研发反馈：测试跑满带宽，但真实业务上不去
- 表面看：iperf 打流 OK
- 实际可能：
- 测试未模拟多线程长连接并发
- 真实业务触发链路拥塞点
- RTT 抖动被应用串行逻辑放大
✅ 我的反问：
“我们验证的是‘峰值吞吐’，还是‘持续并发下的稳定性’？”
📌 记住：测试不出问题，不代表网络能扛住真实研发节奏。
第三层：跨境/跨云回传流量 —— 隐形的带宽杀手
- 研发反馈：海外训练数据回传慢、偶尔卡死
- 表面看：带宽经常跑满
- 实际可能：
- 一条出口同时承载办公、加速、回传、云接入
- 回传流量“单次不大，但7x24持续”
- 与交互流量争抢，无隔离
✅ 我的反问：
“这条跨境链路，到底在为谁服务？”
📌 记住：回传不是“背景流量”，它是沉默的资源吞噬者。
第四层：内部平台/日志系统 —— 心态成本最高的慢
- 研发反馈：页面转圈、刷新才好、问题难复现
- 表面看：系统“没挂”
- 实际可能：
- 调用链路过长（本地 → 云A → 云B → 数据库）
- 小流量被长期挤压至最低优先级
- 网络状态不可追溯
✅ 我的反问：
“如果连我都说不清为什么慢，怎么让研发相信网络没问题？”
📌 记住：这些系统一慢，研发的心态成本会迅速上升。
第五层：终极架构自检 —— 问自己这5个问题
不管你现在用 MPLS、SD-WAN 还是纯公网，都值得定期拷问：
- 当前网络的设计假设，还符合现在的研发模式吗？（比如：是否预设了“主要在国内”？）
- 网络慢时，我能说清是哪类业务流在受影响吗？
- 我能否区分：“链路没断” vs “体验可用”？
- 网络状态是否有管理层能看懂的可视化表达？
- 如果明天研发规模翻倍，最先顶不住的是哪一段？
最后送一句架构师金句：
研发网络的风险，从来不是一次性故障，而是那些被忽略的小波动，在规模、并发和协作复杂度提升后，悄悄演变成系统性效率损耗。
附：自检清单获取方式
如果你觉得这套逻辑有用，
👉 评论区留言“自检”领取完整版《研发网络5层自检清单》PDF
