Skip to main content
已发布的策略版本永不更改。编辑策略并重新发布会生成一个新版本，而不会覆盖已部署在机器上的版本。这正是回滚安全可靠的原因：上一个良好版本依然完整保存，回滚操作也不会抹去用于说明问题所在的决策历史。

​
查找版本

前往 Admin → policy editor，打开 library 以比较某个策略的各版本或禁用其中一个。

​
回滚某台机器

  1. 前往 Admin → enforcement，展开受影响的机器，找出其最后一个已知良好的策略集。
  2. 选择 edit，还原这些版本及其效果，然后应用新的部署。
  3. 等待机器签入，再验证上报的部署状态。
  4. 打开 Observe → policy 及受影响的会话，确认有效工作不再被拦截。

​
从所有机器上移除某个策略

每次操作都会在其所影响的每个部署上生成一个新代次。不过，回滚某个代次并不是撤销 disable 的正确方式——rollback 会拒绝引用已禁用策略的代次，而禁用操作之前的所有代次都引用了该策略。fp policies enable 才是正确的恢复途径，它会自行生成一个新代次。

​
回滚策略包

策略包固定在你所安装的发布版本上，因此回滚意味着安装一个较早的版本：
如果不在终端中操作，或使用了 --policy、--category 或 --all 参数，重新添加时会保留你之前选择的子集。若在终端中操作且未附加上述参数，则会打开选择器，并预先勾选作者的默认项，你的勾选结果将替换之前的选择——因此请重新勾选你原来的选项。

​
何时需要回滚

  • 某个策略拦截了预期的生产操作。
  • 匹配量明显高于观测到的灰度发布预测值。
  • 某个策略依赖某些集成未提供的字段。
  • 新版本在预期故障模式之外改变了行为。
回滚后，打开受影响的会话，找出导致误报的条件。发布一个新版本，测试不安全情形和合法情形，在正式执行前再次观察其表现。
failproofai config --pause 仅暂停当前会话的本地策略，对云端托管的策略无效，因此无法用于应对云端部署出现问题的情况。此外，暂停操作会扩大其作用范围内所有策略的暴露面；建议优先回滚出现异常的单个版本。