本周三凌晨，监控群里弹出一条告警：某IDC机房内一批AI词元服务器上行带宽持续5分钟超过90%。我的第一反应是“带宽不够，赶紧扩容”。但导师说：“先别动，按步骤走。”
第一步：区分“真拥塞”和“假突发”。我登录带外管理口，用iftop -i eth0 -n查看实时流量。发现带宽被一个持续的265MB/s流占满，源端口集中在同一台词元服务节点。这不是均匀增长，而是单点突刺。新手常见坑1：直接看总带宽利用率就下结论，忽略单流分析。
第二步：查AI词元服务的队列与重试。该节点是推理请求转发器，日志显示大量grpc: deadline exceeded，随后客户端疯狂重试。原来上游一个实验性批次推理任务发了超长词元序列（单次请求32k token），导致响应变慢，客户端重试风暴打满带宽。新手常见坑2：只查网络设备，不看应用层重试逻辑。
第三步：临时限流 + 修正客户端退避算法。我们没有扩容，而是用tc对该节点上行做20%限速，同时通知算法同事暂停实验任务。然后在网络软件侧（我们用的Cilium）配置了基于HTTP/2流控的速率限制。一小时后带宽回落至45%。新手常见坑3：扩容会掩盖问题，下次突刺更大。
结合近期讯息：很多IDC正在部署AI词元服务器，这类负载具有“突发长尾”特征，传统带宽扩容思路容易失效。建议新手SRE先建立三步检查清单：1）单流vs聚合流量；2）应用层重试与超时；3）网络软件是否支持L7限流。最后，复盘时把“客户端指数退避+抖动”写入SLA，比买带宽便宜得多。
0 留言