解决什么问题
故障测试不能随便拔一根线就结束。你测试的故障必须对应设计里声称覆盖的故障。否则报告写的是单桥故障，测试却只断了非关键链路，结论就不成立。
本节解决故障注入设计问题：测试要覆盖你声称覆盖的故障。
背景与直觉
消防演练如果只测试办公区撤离，却声称覆盖机房火灾，就不匹配。网络故障注入也是一样。故障模型和测试动作要一一对应。
怎么解决
可以按三阶段设计：故障前、故障中、恢复后。
| 阶段 | 要观察什么 |
|---|---|
| 故障前 | baseline 延迟、同步、计数器 |
| 故障发生 | miss、丢包、切换时间、告警 |
| 故障持续 | 备用路径是否满足 deadline |
| 故障恢复 | 重复、乱序、状态回收 |
| 结束后 | 配置和计数器是否回到可解释状态 |
故障类型可以包括断链、端口 down、桥设备重启、grandmaster 切换、配置下发失败、背景流量突发、FRER 主路径恢复等。
带来了什么新问题
故障注入测试可能破坏业务，因此要明确测试环境、时间窗口和回滚方案。某些故障很难在生产中测试，就要在实验环境或仿真环境中补证据，并在报告中写清限制。
故障注入还会产生大量日志和抓包，需要提前规划采集点。故障发生的一瞬间往往最关键，事后再开抓包通常已经晚了。
检查点
- 如果设计声称覆盖单桥故障，你会怎样设计故障注入动作？
- 为什么恢复阶段可能比故障发生瞬间更容易暴露 FRER 重复消除问题？