BGP 流量工程手册：在稳定边界内做可验证的导流优化

BGP 流量工程（TE）最容易陷入两个极端：要么过于保守，只能被动承受路径劣化；要么过于激进，追求短期最优导致长期震荡。真正可持续的 TE，不是“把流量挪到更便宜或更快的链路”，而是建立一种在故障、变更和业务高峰中都能稳定运行的调度系统。

本文给出一套实践框架，核心原则是：

先定义稳定边界，再优化效率。
先保证可回滚，再扩大放量。
先做观测闭环，再谈自动化决策。

一、TE 目标体系：四目标并行，不做单指标最优

建议把 TE 目标拆成四组：

可用性目标：关键业务不中断或快速恢复。
体验目标：核心地域时延和抖动可控。
成本目标：带宽成本在预算区间。
稳定性目标：路径切换频率和收敛时延受控。

这四组目标必须同时进入验收。仅优化某一项，往往会在另一项透支，例如成本下降但故障恢复变慢。

二、出口 TE：优先用 LocalPref 做主控制

出口流量（我们到外部）最可控，推荐用 LocalPref 作为主杠杆：

关键业务走高可靠出口。
普通业务按区域与时段做弹性调度。
成本业务放到低优先出口并限制占比。

关键点是“档位化”而非“自由调值”。档位化可以显著降低策略冲突与人为误改。

三、入口 TE：MED、Community、Prepend 组合使用

入口流量（外部到我们）更难控，通常需要多策略组合：

MED：在同一对端 AS 多互联点场景下提示入口偏好。
Community：调用对端已约定的流控语义。
AS_PATH prepend：做温和偏置而非精确均衡。

入口 TE 的难点是“对端可控性有限”，因此必须先做协商矩阵。不知道对端怎么处理你的属性，调优动作很可能没有效果。

四、策略链设计：把 TE 从命令集合变成流程系统

建议按以下链路组织 TE 策略：

flowchart TD
    A["业务意图输入: 稳定/时延/成本"] --> B["前缀分层: 关键/普通/批量"]
    B --> C["安全门禁: RPKI/角色/max-prefix"]
    C --> D["出口策略: LocalPref 档位"]
    C --> E["入口策略: MED/Community/Prepend"]
    D --> F["灰度发布: 单区域到全网"]
    E --> F
    F --> G["联动观测: 控制面+业务面"]
    G --> H{"达标?"}
    H -- 否 --> I["自动回滚与冻结"]
    H -- 是 --> J["归档并更新基线"]

这条链路强调两个词：门禁和回滚。没有门禁的 TE 是冒险，没有回滚的 TE 是赌博。

五、收敛稳定：把切流速率控制在系统承载范围内

很多 TE 事故来自“短时间切太多”。建议设置四个速率约束：

单次可切换前缀数量上限。
单窗口可切换总流量占比上限。
连续两次切换最小间隔。
单区域并发变更上限。

这些约束看似保守，却能显著减少更新风暴和重算压力。

六、路由泄露防护：TE 期间安全策略必须刚性执行

TE 往往发生在业务压力期，此时更不能放松安全策略：

启用 RFC 8212：无策略默认拒绝。
启用 RFC 9234：邻居角色与 OTC 限制传播。
启用 max-prefix 分级阈值。
启用 RPKI Origin Validation 分流。
异常更新自动隔离到观测域。

将安全门禁置于 TE 策略之前，是防止“优化动作触发安全事故”的关键。

七、观测体系：至少要有“网络+业务+治理”三维看板

网络维度

会话状态与 flap。
Update/Withdraw 峰值。
Best-path 重算耗时。
RIB/FIB 收敛差值。

业务维度

关键交易成功率。
关键地域 P95/P99 延迟。
丢包与重传指标。

治理维度

发布批次与版本号。
告警数量与关闭时长。
回滚触发次数。

若没有治理维度，团队无法知道“是策略本身有问题，还是执行流程有问题”。

八、维护窗口治理：把 TE 发布流程产品化

建议每次 TE 变更遵循固定步骤：

需求评审：确认目标优先级和影响面。
离线仿真：验证路径变化与潜在冲突。
风险评级：决定灰度批次和观察窗时长。
执行发布：按批次推进并实时打点。
门禁判定：网络+业务双达标才继续。
回滚处理：触发阈值立即回退。
复盘归档：更新策略字典与阈值。

流程化的意义，是让不同班次执行结果更一致。

九、典型实战模式

模式 A：白天稳定优先，夜间成本优化

白天锁定关键业务在高可靠出口。
夜间对普通流量降一档 LocalPref。
每日回看业务指标与成本收益。

模式 B：多地域入口均衡

按互联点设置 MED 梯度。
结合对端 Community 语义做区域导流。
对单点热点做小步 prepend 微调。

模式 C：故障时快速导流

先应用应急 LocalPref 档位。
冻结非必要 TE 策略。
故障结束后按计划回收应急标签。

十、自动化建议：从“脚本执行”升级为“策略引擎”

自动化 TE 不应只有“下命令脚本”，还要有决策约束：

变更前自动做冲突检测。
变更中自动比对实时指标与门禁阈值。
异常时自动执行分层回滚。
变更后自动归档并生成复盘草稿。

自动化的目标不是更激进，而是更可预测。

十一、跨团队协同：TE 需要业务共同验收

网络团队常见误区是“网络恢复就算完成”。实际上，业务层体验才是最终验收。建议建立联合验收机制：

网络确认收敛与稳定。
业务确认关键链路体验。
共同决定是否继续放量。

这能显著减少“网络视角已恢复、业务视角仍异常”的争议。

十二、演练体系：用演练验证门禁而不是验证勇气

季度演练建议覆盖四类场景：

计划切流演练。
故障导流演练。
泄露叠加演练。
回滚失败预案演练。

每次演练都记录：检测时延、收敛时延、业务恢复时延、人工介入时长。连续追踪后，才能知道 TE 体系是否真的在进化。

十三、落地检查表

是否建立了多目标优先级。
是否完成入口/出口策略分层。
是否把安全门禁前置。
是否配置了三维观测看板。
是否具备自动回滚能力。
是否制度化季度演练。

如果这六项都满足，TE 才算从“战术调流”升级为“工程能力”。

十四、组织收益：为什么这套方法值得长期投入

当 TE 成为工程系统后，组织会获得三类长期收益：

风险收益：重大变更事故概率持续下降。
运营收益：值班处理效率和确定性明显提升。
业务收益：体验、可用性、成本之间更容易平衡。

这也是很多团队从“靠高手救火”转向“靠系统稳定交付”的分水岭。

十五、TE 变更评分模型：发布前先算“风险分”

为了避免凭经验决定放量节奏，建议引入一个简单评分模型。每项 0 到 3 分，分数越高风险越大：

影响前缀规模。
影响地域数量。
是否涉及关键业务前缀。
是否叠加安全策略变更。
是否跨多个 RR 集群同时执行。
是否有近期同类失败记录。

总分建议对应放量策略：

0-5 分：可按标准两批灰度。
6-10 分：至少三批灰度并延长观察窗。
11 分以上：必须先演练，再进生产窗口。

这套模型不追求绝对精确，目的是统一团队对风险的语言。

十六、回滚后的再发布策略：避免“反复横跳”

TE 变更回滚后最容易出现两种错误：

立刻重试原策略，导致重复触发同类异常。
完全停摆，长期不再优化，问题持续累积。

更稳妥的方式是“降阶再发布”：

先把目标缩小到单业务域或单区域。
把原先一步到位的档位调整改成两步。
补充缺失监控后再尝试下一轮。
在同类问题连续两次达标后，才恢复原发布节奏。

这能避免策略在“激进与保守”之间来回摆动，帮助系统稳定迭代。

十七、实操提醒：三类“看起来正常”但高风险的信号

在 TE 发布中，有三类信号经常被忽略：

指标短时变好但波动幅度变大，这通常意味着系统处于不稳定边缘。
单区域效果很好但跨区域复制后退化，说明策略依赖局部拓扑特征。
网络指标达标但业务投诉上升，说明观测口径与真实体验脱节。

遇到这三类信号时，建议暂停继续放量，先补充验证。 “看起来可用”不等于“可以规模化复用”。

十九、流量工程收益归因补充

TE 变更后常见争议是“到底是策略起作用，还是业务流量自然波动”。要避免误判，建议建立收益归因方法：按前缀、区域、时段设置对照组，确保有可比样本；将策略变更时间点与成本、时延、成功率曲线做对齐；对同时发生的外部事件（运营商故障、业务发布）做标注剔除。归因报告至少回答三点：收益是否稳定、收益是否可复制、收益是否以稳定性代价换取。若结果显示收益只在低峰有效，应回到策略层做分时段或分业务细化，而不是直接全网扩展。把收益归因做扎实，TE 才能从“经验调流”升级为“可审计的经营能力”，并为后续自动化决策提供可靠训练样本。

建议把收益归因报告纳入月度经营评审，固定展示“收益持续性、风险代价、可复制范围”三项结论。只有经营视角与技术视角同时成立，TE 策略才值得扩大；否则应保持在受控范围内继续验证。