生产交换机端口 CRC 错包持续存在但业务无感：你们怎么判断该修还是该忍？

【背景】 5 年网络工程经验，最近接手一个数据中心 ToR 集群（Cisco N9K 为主，约 60 台）。发现 3 个不同机房的 ToR 端口持续出现 CRC errors / input errors，速率大约每小时 2000~8000 包，已经持续 6 周。业务侧（主要是内部 RPC 调用）P99 没有明显变化，应用团队也感知不到异常。

【现象】

• show interface | include errors 看到 CRC 计数稳定增长，不是突发型；
• 收发光功率在标称范围内（TX 3.2 dBm / RX 2.1 dBm，阈值 -6 dBm），但比同型号其他端口偏低 0.5~1 dB；
• 抓包（端口 mirror）看到偶发整帧丢弃，不是 bit 翻转重传；
• 换过一次光模块后 CRC 降了约 40%，但没有归零，怀疑还有上游光路或 ASIC 的问题。

【已尝试与结果】

1. 换光模块（同型号新件）：CRC 速率从 ~6000/h 降到 ~3500/h，没有根治；
2. 检查光纤跳线：目视无弯折，OTDR 测试衰减正常（0.25 dB/km），排除光纤断裂或宏弯；
3. 对比同 ToR 其他端口：只有这 3 个端口有持续 CRC，其余干净；
4. 查交换机日志：没有 ASIC error / phy error 相关 syslog；
5. 问厂商 TAC：建议换端口（把业务迁移到同 ToR 的另一个 uplink），但没有给出根因判断标准。

【卡点 / 期望得到的答案形态】

1. 判断标准：CRC 速率在什么量级（比如 >100/h vs >10000/h）你们会认为是"必须换硬件"而不是"可以忍"？有没有内部 SLA 或阈值？
2. 根因排查路径：在光模块和光纤都排除后，你们怎么进一步确认是 ASIC 端口级问题 vs 交换机背板/交换芯片问题？有没有用过 debug phy、show hardware 之类的命令拿到更细粒度的错误计数？
3. 业务影响量化：CRC 错包对 TCP 层的实际影响你们怎么量化？（比如：CRC 丢弃 → 重传 → P99 抬升的链路，你们有没有实测数据？）
4. 处理流程：你们内部"该修还是该忍"的决策流程是什么样的？谁拍板？换硬件的窗口期怎么安排（业务迁移 vs 热插拔）？
5. 监控告警：怎么把端口 CRC 速率做成持续监控（而不是靠人肉 show interface）？阈值怎么定？

不用给完美方案，能分享你实际的处理流程 + 关键判断依据就行。