带宽利用率超过70%就要开始筹备扩容，但这只是底线，真正决定动手时机的是连续观测数据与业务峰值预判，而不是某一天的瞬时峰值。
先看哪个指标：出口利用率比设备端口利用率更重要
很多运维同行有个习惯,每天打开监控面板看一眼交换机的端口流量，看到峰值超过60%就紧张，看到平均值不到20%就觉得安稳，这个判断方式在业务单一的时期够用，但现在流量模型早就变了。
你真正要盯的指标,是一个方向上的出口带宽利用率，而不是所有端口流量的平均值，举个例子：你是做视频站点的，用户下行流量占绝对主导，那你要看的是下行出口方向的带宽利用率，而不是服务器上联口的双向总和，反过来，你是做文件上传备份业务的，上行方向才是核心。
行业共识认为,出口带宽利用率才是判断扩容时机的第一依据，设备端口的CPU占用率、丢包率只能作为辅助参考，因为端口利用率高，有可能是广播风暴或者环路导致，不代表真实业务带宽吃紧。
这里有个常见的误判场景：某天下午3点，你的出口带宽利用率瞬间冲到85%，持续了30秒又掉回40%，如果这时候你急着找IDC机房扩容，大概率是浪费钱。持续时间短于5分钟的突发峰值，不构成扩容条件，除非这种突发出现频率极高，比如每小时都来几次。
带宽利用率多少需要扩容：分三层判断
判断扩容时机不能用一个绝对数值拍脑袋,要分三个层次去看。
第一层：持续平均值超过65%-70%
这是最基础的判断线,衡量方式是看连续14天的出口带宽利用率平均值，而不是某一天的峰值，统计工具可以用Prometheus配合Grafana，或者直接用Zabbix的趋势报表，把日平均利用率和周平均利用率拉出来。
如果你看到的是连续15天以上日平均利用率稳定在65%-70%区间，说明业务增长已经吃掉了你预留的安全缓冲区间，这时候可以启动扩容流程的立项申请，因为IDC带宽采购、专线开通、设备升级都有周期，一般在1-4周不等。
第二层：峰值持续突破85%的时间变长
比平均值更敏感的信号是峰值的持续性,假设你的峰值带宽设计在10Gbps，过去高峰期只会短暂冲到8.5Gbps左右，维持十几分钟就回落，现在趋势变成
高峰期冲到8.5Gbps以上能维持1-2小时，这就是明确信号用户行为正在变化，原来的波峰时段延长了。
这种情况不扩容会有什么后果？TCP拥塞控制会主动降速，用户端体感是网页加载变慢、视频缓冲时间变长，你可能在服务器端看不到丢包，因为TCP重传机制在替你兜底，但用户已经感知到卡顿了。
第三层：TCP重传率开始抬头
很多运维不关注这个维度,但它往往比流量数值更早暴露问题，当你的出口带宽利用率超过80%时，TCP重传率会从正常的小于0.1%开始显著爬升。
在Linux服务器上执行ss -s查看重传队列，或者用netstat -s | grep -i retrans看TCP重传计数，如果重传率连续三天翻倍增长，即使带宽利用率数字还没到阈值，也要考虑扩容，因为重传意味着链路质量在恶化，根子就是拥塞。
带宽扩容方案对比：小心冲动扩容带来的成本陷阱
当你确认需要扩容,下一步动作不是立刻加带宽，而是先做方案对比，这直接关系到年度预算和架构稳定性。
-
方案A：直接升级物理带宽
适合业务增长稳定的情况，联系原来的IDC或运营商，把带宽从10G升到20G，优点是操作简单，半天内可完成；缺点是合同期容易被绑定，价格谈判空间小。 -
方案B：新增第二链路做负载均衡
适合多线机房或双运营商接入的场景，比如原来只接了电信单线，现在增加联通线路，通过BGP或策略路由分流，优点是业务容灾能力同步提升；缺点是成本直接翻倍，需要网络工程师配合调路由策略。 -
方案C：上CDN或对象存储做流量卸载
适合静态资源占比高的站点，先把图片、视频、下载包迁移到CDN，至少能降低源站出口带宽消耗的40%-60%（视业务类型而定），如果CDN缓存命中率能到90%以上，带宽扩容压力会大幅缓解。 -
方案D：错峰调度
适合有定时任务或离线计算场景的业务，把大文件传输、数据备份等任务切到凌晨低峰期执行，削峰填谷后，出口带宽利用率能降10-15个百分点，这个方案接近零成本，但需要业务部门配合。
动手扩容前的三张清单
确认方向后,按以下清单执行，少走弯路。
先验证瓶颈真的在出口带宽
- 登录入口交换机,执行
display interface查看各端口错包和丢包计数 - 用
iftop或nload实时监控带宽占用，按IP段排序找出消耗大户 - 排查是否有异常流量,比如被DDoS或爬虫刷量，这类情况扩容等于白花钱
跟IDC确认冗余条件
- 问清楚上层接入设备是否支持平滑扩容,是否产生割接窗口
- 确认合同中的带宽计费模式是95计费还是峰值带宽计费，这直接决定你对利用率上限的容忍度
- 提前了解同机房同设备扩容的价格,避免临时报价被抬价
算清扩容后的安全水位
扩容不是从85%降到40%就结束了，你要规划的是扩容后预留30%-40%的缓冲空间用于业务增长和突发流量，如果你现在用10G带宽，峰值已经打到8.5G，扩容到15G比扩容到12G更有意义，因为12G很快又会摸到85%的红线，届时二次割接的成本更高。
带宽利用率监控的傻瓜式操作路径
如果你暂时不想上复杂监控系统,用现有工具也能做到有效监控。
- 在核心出口路由器上用SNMP采集接口流量,结合Cacti或Mrtg生成周报
- Prometheus用户直接用
node_exporter加blackbox_exporter，通过rate(node_network_receive_bytes_total[5m])计算实时速率 - 配置告警阈值：平均值超60%告警一次，峰值超85%告警一次，分别对应关注级和危险级
监控的目的是为了发现趋势,不是追求数据精准到小数位，你只要保证趋势线是平滑可预测的，扩容决策就有依据。
夜间业务与白天业务的带宽利用率的差别处理
不同业务形态对利用率的要求差异很大,如果是面向普通用户的互联网应用，晚8点到11点是高峰期，白天的利用率可能只有晚上的三分之一，这类业务看的是晚高峰时段的持续利用率。
如果你做的是企业级服务或API接口调用,流量模型更分散，没有明显的波峰波谷，那就看
全天平均利用率更合理。
这里给一个经验参考值：晚高峰型业务，利用率可以容忍到75%-80%；全天均衡型业务，建议维持65%以下，因为均衡型业务的持续高水位会加速设备老化，电信设备长时间工作在70%以上负载，故障率会明显增加，据工信部相关网络运行监测通报和业内专家指出，设备长期高负荷运行是引发链路闪断的重要因素之一。
带宽利用率与成本之间的年度规划
带宽采购是有节奏的,别把扩容当成救火动作，每年做预算时，根据过去12个月的带宽增长曲线，预估下一年度同期的增长率，如果过去一年从5G涨到了8G，增长60%，那明年按同样增速，年中就要再扩一次。
成熟的做法是按季度做带宽容量评审，每个季度末拉一次趋势数据，对下一季度的峰值做预判，不用买太多冗余带宽，但要保证下单后供应商能在7天内完成交付，这是保护业务连续性和资金效率之间的平衡点。
Q&A：带宽扩容时机常见疑问
问：带宽利用率日平均在50%，但每天高峰期都冲到90%以上，要不要扩容？
答：要，如果高峰期持续时间超过1小时，说明用户体验已经受损，日平均数据只是业务整体负载的反映，高峰期打满会直接导致丢包和延迟增加，不符合典型互联网应用的服务质量标准。
问：带宽扩容时，是单纯加带宽还是增加IP地址更划算？
答：分清场景，如果是出口带宽拥塞，增加IP地址不解决问题，如果是连接数或并发会话数受限于公网IP数量导致的性能瓶颈，才考虑加IP，两者解决的问题不同，带宽扩容解决流量容量问题，IP扩容解决连接数规模问题。
问：监控数据波动很大，今天利用率30%，明天利用率80%，怎么判断该不该扩容？
答：先看波动周期，如果波动有规律，比如只是在特定推广活动或数据备份期间突高，优先做流量调度，还是性能瓶颈出现在链路聚合的负载均衡不均上，如果波动无明显规律，且高峰频率每周超过两次，建议直接扩容，波动型业务对资源冗余的要求更高。