上个月我们在一套用Scale-UP协议组网的内存池化环境里做长距离光链路验证第一个晚上就翻了车。链路能起来速率也跑满但压力测试时FEC纠错计数一直在涨后半夜环境温度降下来问题反而更严重最后拆开面板才发现是一根尾纤被扎带勒出了微弯。这件事给我一个很直接的教训Scale-UP协议把内存语义搬到光上之后可靠性设计的重心根本不在物理层那一点误码本身而在整个协议栈如何应对光链路各种各样的不完备性。这篇文章我打算把光链路可靠性这条主线从头到尾拆一遍先算链路预算和FEC的账再讲训练和快速恢复然后是事务层的重放与端到端校验最后是光模块遥测和系统级冗余以及我们测试中踩过的具体坑。适合做互联架构、硬件研发、固件以及数据中心运维的读者参考尤其是刚准备把光接入内存语义场景的团队。1. 光链路进入Scale-UP协议栈之后可靠性账要重新算Scale-UP协议出现的直接动因是把“内存”从单一主机的私有资源变成一组主机可以共享、池化的块。传统按主机划分内存的做法在AI训练和数据分析场景里造成了大量浪费和搬运开销Scale-UP希望用协议和交换矩阵把分散的内存变成逻辑上统一的池子。这条路一旦走通内存利用率、故障恢复速度都能上一个台阶。但它有个前提距离。内存不只在同一块主板上也不只在一个机柜里它要能够跨越几十米、上百米去连接另一组节点。电链路在这个距离上是撑不住的。我们平时在服务器内部看到的PCIe/CXL走线达到32GT/s之后PCB走线长度要按英寸算铜缆也很难超过两三米。信号完整性问题让你不能简单地把线拉长等化、串扰、介质损耗每一项都在恶化。所以Scale-UP协议走到实际部署阶段时光链路几乎是必选项。单模光纤在1310nm窗口典型衰减只有0.35dB/km上下100米的链路插损约等于可忽略再加上光模块成本逐年下降用光学把内存池挂到几十米甚至几百米外让跨机柜内存池化成为可能。但光链路不是“一根光纤替代一根铜线”那么简单。它把可靠性的账彻底改变了。电链路里信道劣化是一个连续过程眼图慢慢变小误码率慢慢升高然后协议栈通过训练、均衡、重传把问题消化掉。光链路多了一整条光电转换链激光器、驱动器、调制器、探测器、TIA、CDR、连接器、光纤本身。每一个环节都有独立的故障模式而且故障的发展速度可以相差几个数量级。激光器老化是以年为单位的渐变光纤被外力压弯可能几秒钟内就从正常变成完全断链连接器污染则会是间歇性误码温度一高就变严重。于是问题变成怎么在设计阶段就把这些东西兜住。我们在Scale-UP协议栈里通常把可靠性分成四个层次物理层FEC纠错、链路层的保活与重训练、事务层的CRC、序号和重放、系统层级的路径冗余与故障隔离。每一层只处理上一层漏掉的那部分错误不能指望靠某一层单打独斗。内存流量对静默错误几乎零容忍一个翻转的数据位可能直接写脏内存一个丢失的读响应可能让整条路径卡住。所以光链路可靠性设计的本质是把“光器件可能出错”这件事变成协议和系统设计里的一个显式假设而不是一个意外。提示有一句话我们内部反复讲——光链路的可靠性设计不是把误码率做到零而是把“任何一次错误对内存语义的影响”控制到可恢复、可预期、可观测的范围内。2. 先算账再选型目标BER、强FEC与链路预算的真实计算这一节说的都是“为什么”。光链路可靠性设计里最容易犯的错误是直接照搬以太网的FEC方案或者反过来连FEC都不加指望重传兜底。实际上不同场景对BER的要求完全不同必须先把账算清楚。2.1 目标误码率从哪来Scale-UP协议上跑的是一笔一笔内存访问请求和响应。一个典型的数据包/flit大约128字节也就是1024个比特。我们要求的是“端到端不能出现数据损坏”。按工程惯例把链路的残余误码率定在1e-15这个量级这意味着平均约1e12个flit才可能出现一个flit级错误换算成flit错误率大约是1e-12。粗看一下1e-12好像已经很安全了但它还要经受住带宽的放大一条高密度链路每秒要传输数千亿个flit1e-12的flit错误率仍然意味着每秒可能看到几次错误事件。这些事件交给上层重放机制去消化是合理的但绝不能直接把坏数据暴露给主机。光模块本身的输出在高速率下纠前误码率通常在1e-6到1e-8之间具体取决于用的光源类型、速率和温度。这个水平和1e-15的目标之间相差了7到9个数量级靠重传去补是完全不现实的。重传的前提是先能发现错误发现错误靠CRC而一次重传在光链路上带来的时延抖动足以让内存访问超时。唯一可行的办法就是在物理层把绝大多数误码直接消化掉。2.2 为什么选强FEC而不是简单校验以太网在200G/400G时代广泛使用的RS(544,514)码在光链路可靠性设计里是很有代表性的选择。它把数据按10比特一个符号分组544个符号里承载514个符号的数据开销大约6.9%可以纠正最多15个符号的连续突发错误。选这个码型的主要原因是光链路的错误分布比电链路更“暴躁”。电链路的误码多为随机单比特光学路径上则常常出现成串的突发错误连接器上一粒微小的灰尘引起功率塌陷时可能连续打掉一串符号激光器在温度漂移时也会出现短暂的模式不稳定。如果只做随机单比特纠错突发一出现就立刻失守。代价方面RS(544,514)编解码会引入大约几十纳秒的固定时延这个时延在电链路时代是不存在的。但对光链路来说这笔开销几乎是必须的输入BER在1e-6附近时不加FEC的链路上每一兆字节就会碰到一次错误而加上FEC之后输出BER可以稳定在1e-15以下。我们用一组实测数据说明这一点同一个光模块32GT/s速率下不加FEC的纠前BER约3e-7开启RS(544,514)之后24小时跑下来FEC纠错计数累计约几十万次但上层CRC错误为零。没有FEC的话这个测试大概率连10分钟都撑不过去。注意强FEC必须放在物理编码子层完成对协议层透明。设计时要特别注意FEC编解码器与数据流对齐的关系比如码字边界一旦漂移纠错能力会大幅下降训练阶段必须完成好码字同步。2.3 一份可以抄作业的链路预算表选完FEC还要验证光路本身的功率预算够不够。我们以一条100米单模链路、常规1310nm窗口、带FEC的接收灵敏度为例给出一份实际用的预算表项目数值说明发射光功率TX1 dBm典型硅光/CWDM模块接收灵敏度RX带FEC-10 dBm满足目标BER下的灵敏度可用功率预算11 dBTX减去RX连接器插损两端加跳线面板按3对0.9 dB每对按0.3 dB估算光纤损耗100米单模0.04 dB1310nm约0.35dB/km熔接点与现场尾纤0.3 dB每处约0.1 dB温度与老化裕量2.5 dB必须预留合计链路损耗约3.8 dB剩余预算约7.2 dB保守但可行为什么一定要留出2.5dB以上的裕量因为连接器会脏。现场环境里哪怕戴着防尘帽保管良好的跳线插拔几次后插入损耗也会比出厂值高污染通常不是均匀分布的而是间歇性的有时能观测到0.5dB的波动。老化则是另一个来源激光器功率会随使用时间缓慢下降。我们在设计规则里要求任何链路的静态损耗加上裕量不得超过预算的80%剩下至少20%留给突发变化。按这个规则上面算出的11dB预算在3.8dB损耗和2.5dB裕量之后还剩约4.7dB可用预算比例远超20%这才是可以长期稳定运行的状态。这里还想强调一个常见误解链路预算必须把FEC收益一起算进去。同一个模块带FEC和不带FEC的接收灵敏度能差4到5dB。如果拿不带FEC的灵敏度去核算11dB预算会瞬间变成负值然后你会得出一个“光链路根本不可行”的错误结论。所以预算和FEC选型从来都是要放在一起做的。3. 把故障时间压缩到毫秒级训练、检测与快速恢复机制光链路不会永远健康。预算做得再好激光器终会老化光纤终会被人踩到。所以协议栈必须有一套“发现故障、快速恢复”的机制。这个机制设计得好不好直接决定用户看到的是“偶发一次重试”还是“内存池整个离线”。3.1 光链路训练和电链路训练的关键差异PCIe/CXL体系的电链路训练核心思路是两端反复发送训练序列逐步协商速率、宽度和均衡参数。光链路继承了这套基本框架但有几个地方必须改。第一光接收机多了一道“光电信号锁定”过程。CDR要先从模拟信号里恢复时钟这个过程对信号质量有严格要求训练序列本身不能太短要给CDR留出锁定时间。第二光链路的方向独立性非常强。一条双向光链路实际上包含两套独立的光发射机和接收机两端的激光器老化程度、连接器状态可能完全不同训练必须支持两侧分别调优不能假设一条方向上的均衡参数对另一条方向也适用。第三光模块是可以在线更换的现场可更换部件。换一只新模块之后眼图和原来可能差异巨大训练协议要支持一次“彻底的重新握手”而不是沿用旧参数。3.2 故障检测的四个级别我们实践中把链路故障分成四级级别触发条件动作目标时间0级FEC纠错计数持续升高但未超过阈值上报告警不动作不适用1级出现不可纠码字或误码率瞬时飙升快速重训练复用上次收敛系数1ms以内2级LOS/信号丢失、心跳超时完整重训练或降速协商10ms以内3级重训练连续失败判断端口不可用上报Fabric管理层切换路径100ms以内0级是最容易被忽略的级别。很多人只在FEC完全失效时才注意到链路有问题实际上FEC纠错计数的持续上涨是光链路劣化最早、最可靠的信号之一。我们会把每个端口的纠错计数按15分钟窗口做滑动统计如果连续三个窗口都在上涨就触发一次巡检工单让运维去检查连接器和光纤这时候链路通常还能用处理成本最低。3.3 快速恢复的三个关键设计第一保活心跳要快但不能脆。我们在管理通道上每隔1毫秒发一次保活报文连续丢失3次判为链路故障也就是说检测时间大约3毫秒。但心跳报文本身也可能在光路上被瞬时误码打掉所以心跳报文的容错逻辑要单独设计单个心跳丢失不计数只有连续丢失才累计。判断逻辑是对“是否收不到”计数而不是对“是否收到错误”计数。第二快速重训练要复用上一次的收敛状态。完整重训练里耗时最长的部分是均衡系数的搜扫动辄几十甚至上百毫秒。快速重训练的做法是保留上一次成功训练后的系数快照链路抖动时直接从这个快照开始重新锁定只做少量微调这样大部分恢复都能压在1毫秒以内。但快照不能无限复用——光模块温度和偏置的漂移会让旧系数逐渐失效所以每隔一段时间或者每次温度变化较大时要强制做一次完整重训练刷新快照。第三要有降速协商和振荡抑制。如果32GT/s的快速重训练连续失败三次就自动降一档速率重新训练比如32GT/s降到16GT/s。速率降了链路眼图裕量会明显增大很多电域已经救不回来的光损伤在低速率下反而能稳定工作。内存访问会变慢但不会断这是关键。振荡抑制则是防止链路在“成功-失败-重训练-成功-失败”之间反复横跳我们规定在1秒内如果触发超过三次重训练就强制进入完整重训练流程并上报告警必要时由管理面决定是否将端口摘除。4. 事务层端到端防护CRC、序号、重放缓存与顺序纪律物理层FEC再强也不能保证100%覆盖所有错误。RS(544,514)纠不了超过15个符号的突发错误链路还会遇到模块瞬间失锁、交换芯片内部缓存出错这类PHY完全看不到的问题。所以Scale-UP协议栈在事务层必须有一道独立的端到端保护这道保护才是内存语义安全真正的底线。4.1 每个flit都要有CRC和序号我们给每个flit附加一个覆盖完整头部和载荷的CRC校验并为每个方向维护单调递增的序号。接收端发现CRC错误或者序号出现空洞就判定这个flit以及后续所有未确认的flit都不可用立即丢弃并回报发送端。这里的关键是错误检测不能只依赖CRC序号必须参与判断否则数据位翻转恰好没被CRC捕获的残存概率虽然在设计目标内但在长期运行的海量流量下也不能当作不可能事件。CRC和序号的位置也要想清楚。逐跳校验负责在每一段链路上尽早发现错误、尽早丢弃避免坏数据在交换矩阵里广为传播端到端校验则覆盖源端到目的端的完整路径包括中间交换节点的缓冲和调度逻辑。两道校验不能互相替代缺了逐跳坏数据会浪费下游链路资源缺了端到端交换芯片内部错误就可能漏过去。4.2 重放缓存的大小不能只按理论RTT算收到错误报告之后发送端要做的是把从错误点开始的所有未确认flit按原顺序重新发送出去。这就需要一个重放缓存。缓存大小的计算公式是链路往返时间加上交换排队延迟加上FEC编解码延迟乘以链路数据速率再考虑重试期间新到达的流量通常还要留出25%左右的裕量。举一个具体例子。100米光链路的光纤往返延迟大约1微秒交换芯片排队和转发大约0.5微秒FEC编解码和其他流水线处理按0.2微秒算合计约1.7微秒。一个128字节的flit在32GT/s单通道上大约需要8纳秒传输那么1.7微秒内大约能发210个flit。重放缓存如果只按这个数字做210个flit理论上够但实际高负载下排队延迟会抖动我们建议直接按2倍再加25%设计也就是大约500个flit的容量折算成片上存储大约是64KB量级。为这几十KB的SRAM多花不了多少面积但能避免大量链条式的重放超时。4.3 重放必须守住顺序纪律重放最容易被忽略的是顺序问题。内存访问请求对顺序极其敏感同一笔读请求的重放结果必须覆盖原请求同一流的写请求后发不能先到。我们要求重放严格按序号顺序进行不允许为了赶时间跳过一个空洞先重放后面的flit。任何跳跃都可能把内存控制器里的队列顺序打乱轻则额外延迟重则产生错误响应。同时不同逻辑通道需要独立的重放上下文。Scale-UP协议栈里通常会区分请求/响应/数据等不同通道这些通道相互独立如果共用一套重放上下文一条通道上的突发重放会阻塞另一条通道的正常流量造成无谓的抖动。独立上下文之后单条光链路的局部错误只会影响相关通道其他内存访问不受牵连。4.4 不可恢复错误宁可显式失败不能静默吞掉最后一种情况是端到端校验也失败重放也失败比如链路彻底断了还没切走。这时候协议栈绝不能假装数据没问题。我们采用的做法是给该笔事务标记为不可交付向上层返回一个显式的失败响应或超时让内存控制器按既定策略处理。对于内存读这类事务返回错误远比返回一份损坏的数据安全因为内存控制器知道数据是坏的可以走故障处理流程一旦返回一份坏数据故障就被包装成“正常结果”后续所有计算都建立在错误之上。这一点我们在设计评审里反复强调属于可靠性设计里最关键的价值观问题。5. 光模块遥测与预测性维护把单点失效变成可管理失效不管协议栈做得多好光链路最底层的物理实体是光模块和光纤。它们的状态不会像链路训练参数那样“全自动收敛”需要显式地观测。光模块本身提供了大量遥测数据这部分数据在电链路时代是没有的Scale-UP协议栈如果不用起来等于把最便宜最有效的信息白白丢掉了。5.1 哪些遥测参数值得接入管理面一份实用的光模块数字诊断参数表包括参数关注点典型告警发射光功率TX Power激光器输出是否正常、是否老化比基线下降超过1dB接收光功率RX Power链路插损是否增大、是否有污染低于预算灵敏度前3dB激光器偏置电流Bias Current激光器老化的重要指标老化的激光器需要更大偏置比基线升高超过10%模块温度高温是激光器杀手也会引起误码率波动超过规格上限前10度电源电压模块供电是否稳定超出规格范围这些参数几乎每个光模块都会通过管理接口暴露出来格式和字段也基本标准化。真正的问题不是读不到而是读取之后怎么用。5.2 绝对阈值加趋势分析缺一不可只设绝对阈值是不够的。不同链路的光模块基线差异非常大同一个型号、同一批次的模块出厂发射功率可能相差1dB以上。如果拿一个统一阈值去套所有端口你会发现要么误报频发要么等告警出来时链路已经没救了。我们的做法是设备上线时先记录一条基线然后以基线为参照做趋势判断同时用绝对阈值做安全兜底。举个例子。接收光功率的正常基线如果是-3dBm当它下探到-6dBm时按绝对阈值看还很健康但如果这个变化发生在一个小时内那就是明确的劣化信号大概率是连接器污染或者光纤微弯应该马上派单检查。反过来如果接收光功率从-3dBm慢慢降到-6dBm花了半年那可能是模块老化或连接器缓慢脏污可以安排在下一个维护窗口处理。只看绝对值会漏掉前者只看趋势会忽略后者两种方法必须结合起来。采样频率上我们每30秒做一次例行采样收到告警事件时切换到每秒采样方便快速判断是否继续恶化。5.3 遥测和FEC计数交叉验证遥测数据单独看有时会有迷惑性。接收光功率正常但误码率很高问题可能出在发射端、连接器或者光纤反过来接收光功率下降FEC纠错计数却一直很稳定可能只是模块测量校准的偏差链路实际还能用。所以我们把遥测和FEC计数器放在同一个管理模型里看交叉特征现象组合最可能原因建议动作RX功率下降 FEC纠错上升连接器污染或光纤损伤检查物理链路、清洁连接器RX功率下降 FEC纠错正常光模块测量偏差或老化比对备件模块、观察趋势TX功率下降 偏置电流上升激光器老化规划更换模块温度升高 FEC纠错上升散热或环境问题检查风道和改进散热所有参数正常 FEC纠错突增外部干扰或电源噪声检查屏蔽和供电这套交叉判断逻辑我建议直接做成自动化。Scale-UP协议栈的管理平面可以定期拉取遥测和计数跑一遍上述规则命中后自动生成故障工单。人工排查的效率无法应付几十上百个光端口自动化规则只要阈值设得合理准确率能做到相当高。5.4 主动摘除与再调度预测性维护的最终形态是在故障真正造成业务影响之前把这条链路从活动集合里摘除让流量走备用路径然后在维护窗口里从容处理。我们对“即将失败”的判定标准是FEC纠错计数连续三个15分钟窗口上涨且接收光功率接近预算下限前3dB。命中这个条件管理面直接把端口标记为“维护中”触发路径切换同时通知运维人员。整个过程业务面只会看到一次路径切换不会看到任何误码或者超时。做到这一步光链路可靠性就从“故障处理”升级成了“故障管理”这是质的差别。6. 多路径冗余与故障隔离系统级最后一道防线协议栈内部的可靠性设计再完备我们也必须接受一个现实单条链路终有不可用的一天。这时候如果整个内存池只有这一条路可走用户看到的就是服务中断。所以Scale-UP协议组网里系统级的冗余设计是最后的防线也是对前面所有机制的一次总验收。6.1 端口组用多条链路分摊流量我们不会让一个内存池只通过一条链路对外服务。在物理上至少要用两条独立链路组成一个端口组流量按flit粒度分摊到组内的每条链路上。单条链路出现0级或1级故障时不需要做任何切换动作只要把这条链路的权重降为0剩余链路自然承接全部流量。由于分摊粒度足够细重放机制可以快速消化掉故障瞬间丢失的flit业务面几乎无感知。端口组还有一个好处它天然提供了故障演练的通道。想测试某类故障直接把组内一条链路的光纤拔掉观察剩余链路和重放机制的表现完全不影响业务。我们在正式上线前就靠这个办法把训练、重训练、路径切换都验证了好几轮。6.2 路径切换与路由重配置端口组内多条链路同时失效的概率很低但不能假设为零。所以跨端口组、跨交换节点还要有第二条独立路径。这里说的独立是指物理上不共享同一根光缆、同一块交换板卡、同一个供电域。切换发生时故障端口上报管理面管理面从预计算的备用路径表里选出健康路径重新下发路由配置同时更新网络的健康状态视图。切换时间目标我们定在100毫秒以内包含故障检测、上报、路由下发和流量收敛。这个指标在演练中是可以达到的前提是路由下发路径本身不能经过故障端口否则管理面也会跟着“下线”。实际操作中我们会在每个交换节点上预留一条带外管理通道专门用于故障状态下的路径重配置这是很容易被忽视但极为关键的细节。6.3 故障域隔离错误不能穿过边界传播多路径冗余同时带来了一个风险一条链路上的错误如果通过共享资源扩散到其他路径冗余反而成了错误扩散的放大器。所以故障隔离必须做到端口级。具体来说每个物理端口有独立错误计数器、独立链路状态机、独立的失败标记。端口一旦进入失败状态不再参与任何数据转发也不参与路由计算管理面视其为彻底移除。这个状态只能由运维手动清除不允许自动恢复否则一个反复抖动的端口会让路由表不停振荡。数据面上的隔离同样重要。逐跳CRC校验的目的就是让错误在到达目的端之前尽可能早地被丢弃避免坏flit在交换矩阵中广播扩散。我们在设计里还加了一条规矩任何端口检测到无法判定的错误时宁可丢弃并触发重放也不要把可能是坏的数据转发出去。重放可以恢复扩散出去则可能污染多个目标这笔账怎么算都划不来。6.4 一次完整的故障注入测试最后分享一下我们在测试环境里做的一次完整演练。场景是主机通过两段光链路跨两台交换节点访问远端内存池演练内容是拔掉第一段链路中一根主干光纤。整个过程记录如下链路丢失被LOS检测在几十微秒内捕获端口进入级别2故障状态端口组内另一条链路开始接管全部流量同时管理面在30毫秒内收到故障上报备用路径在60毫秒左右完成路由重配置并将健康流量引导过来。业务端看到的是一次重试和一个约90毫秒的时延毛刺没有报错没有丢事务。这个结果说明只要分层机制各司其职从物理故障到业务感知的时间完全可以压到百毫秒以内。7. 光链路可靠性测试中踩过的坑逐个说给你听理论归理论实际部署里总有各种“文档里不会写”的问题。下面这些坑都是我们在真实环境中踩过的有些付出了相当惨痛的调试代价写出来希望大家不要再走一遍。7.1 坑一拿电链路时代的思维设计重传兜底我们团队最初有位同事觉得FEC没必要理由是事务层反正有重放。这个想法在电链路上也许成立因为电链路的原始误码率很低重放事件稀疏。但光链路的纠前误码率比电链路高好几个数量级如果全靠重放遇到轻微的连接器污染重放事件就会爆发式增长重放缓存瞬间被撑满然后触发连锁超时。我们后来测过一组数据同一根污染跳线FEC关闭时上层每秒重放事件达到数万次链路实际不可用FEC开启后上层重放事件降为零。从此团队立了一条规矩光链路必须开强FEC重放只允许作为统计上稀少的兜底手段。7.2 坑二FEC时延没有在架构早期预留FEC编解码会引入几十纳秒固定时延这个数字看起来不大但它会改掉整条流水线的时序预算。我们第一次做整链路时延分析时发现加上FEC之后原本设计好的隔离期和响应超时窗口全部偏紧不得不推倒重来。正确的做法是在架构阶段就把FEC编解码器放进流水线模型里一起评估而不是等RTL快冻结了再补。时延预算要按最坏情况算FEC解码器在处理一个纠错突发时输出可能停顿数个周期这个抖动也要预留。7.3 坑三连接器污染是光链路第一杀手新开箱的光模块和跳线理论上应该是干净的但实际上防尘帽内部、插芯端面都可能残留微粒。我们遇到过一次很典型的案例一条新链路功率预算看起来完全健康但FEC纠错计数一个劲往上涨。拿光纤显微镜一看插芯端面有肉眼几乎看不到的纤维颗粒。清洁之后计数立刻归零。从此我们定了一条硬性规范任何光模块和跳线在插入前必须用一次性清洁器具处理并用检查仪确认端面状态。这个看似多余的步骤省下来的排查时间远超投入。7.4 坑四重训练风暴比断链更可怕劣化的光模块不会干脆利落地断掉而是处于“时好时坏”的临界状态。这个时候如果快速重训练触发条件设得太敏感模块可能在几十毫秒内反复触发重训练形成风暴。我们遇到过一次端口每200毫秒左右重训练一次上层重放持续有整个内存池的访问时延从1微秒不到飙到10毫秒以上。最终靠两方面解决一是给重训练加振荡抑制短时间内多次触发就直接进入完整重训练并降速二是让管理面根据FEC计数趋势提前介入把劣化端口摘除而不是等它在临界点反复折腾。7.5 坑五重放缓存光算理论值不够我们早期的重放缓存设计就是按刚才算过的理论RTT做的结果高负载压测下偶发重放超时。原因不在光链路而在交换芯片排队延迟超出预期突发流量下排队延迟比均值大一个数量级。后来把缓存容量调到理论值的2.5倍问题消失。这个教训也可以反过来用如果你的重放超时频繁先别急着怀疑光模块先查重放缓存容量在高负载下是否足够这个验证比换光模块快得多。7.6 坑六理线理出的间歇性误码这个坑是最难排查的。链路时好时坏白天重负荷时误码明显晚上流量低时又恢复正常。刚开始怀疑光模块温度后来换了模块问题依旧最后用光源加功率计逐段排查才发现是一根尾纤在机柜理线时被扎带勒得太紧弯了一个比推荐半径小很多的弯。光纤微弯在低温下损耗反而降低环境温度升高时光纤和护套的热膨胀把弯曲处的应力加大损耗就上去了这正好解释了白天严重的现象。这个案例告诉我们两条经验理线时必须保证光缆曲率半径排查间歇性误码不能只盯光模块和连接器光纤走向和固定的物理状态同样要查。7.7 坑七遥测告警阈值不能照搬默认值光模块厂家出厂的告警阈值非常宽基本只保证模块不会物理损坏不保证链路可用性。我们用第一套系统时踩过这个坑运维收到的第一个告警就是链路已经断了遥测根本没来得及预警。后来我们把遥测阈值改成按链路预算倒推接收光功率告警点设置在预算下限前3dB发射光功率按基线偏移1dB告警偏置电流按基线偏移10%告警效果立竿见影。这件事也说明遥测的价值不在默认配置而在于你愿不愿意花一个下午把每条链路的阈值调成符合自己预算的样子。我个人现在做任何光链路方案都会养成一个习惯先把预算表和告警阈值列在同一张表上预算的反推结果就是告警阈值。只要这两者能对上链路大概率能安静地运行很久对不上后面一定会有很多深夜加班的故事。Scale-UP协议的光链路可靠性设计说到底就是在这些一环扣一环的细节里做选择没有哪一项是独立的也没有哪一项可以偷懒。