解决什么问题
Qcc 让配置更集中，但集中不等于没有失败。上线过程中可能出现某台设备超时、某个端口拒绝参数、某条链路状态变化、某个 GCL 版本没有切换。此时网络可能处在最危险的中间态：看起来已经更新，实际只有一部分更新。
本节解决部署与回滚问题。自动化配置也必须有失败路径。
背景与直觉
数据库迁移需要事务和回滚，网络配置也需要类似思维。TSN 更敏感，因为端到端一致性依赖多台设备共同成立。
怎么解决
一次 TSN 配置上线至少包含这些阶段。
| 阶段 | 动作 |
|---|---|
| pre-check | 拓扑、设备能力、现有状态、时间同步 |
| stage | 下发但不立即生效，准备未来 base time |
| activate | 在计划时间切换配置 |
| verify | 检查 applied state、抓包和计数器 |
| rollback | 失败时恢复旧版本或进入安全状态 |
| report | 记录版本、结果和异常 |
安全状态不一定是继续转发。有时拒绝新流、降级到 best effort、关闭某条关键流或回滚旧表，比半成功配置更可解释。
带来了什么新问题
回滚本身也要验证。旧配置是否仍然可用？新旧配置的数据结构是否兼容？设备是否能在运行中回退？这些都需要提前设计，而不是故障发生后临时决定。
同时，自动化配置带来权限和审计问题。谁可以触发变更，变更依据是什么，失败后谁负责确认，这些都影响工程可靠性。
检查点
- 为什么“部分设备更新成功”比“全部失败”更危险？
- 一次 Qbv/Qcc 配置上线后，你至少要用哪些证据确认它真的生效？