关键操作前确认授权

以下示例和输出是本站编写的教学材料，不是模型实测结果；不会操作真实告警系统。

使用场景

你要为生产服务 checkout-api 准备告警：错误率连续 5 分钟超过 2% 时，通知 payments-oncall 值班组。告警系统支持保存禁用规则和预览配置。用户已经要求准备规则，但尚未授权启用；启用可能立即向值班人员发送通知。

具体做法

1. 先把目标服务、阈值、持续时间、接收者和通知渠道整理成规则，保存为禁用状态。
2. 检查配置和预览结果，确认服务与接收组存在、阈值表达式正确、预览不会发送真实通知。验证失败时修正规则，保持禁用。
3. 展示规则的具体内容和启用后会发生的通知行为，再核对既有授权是否已经覆盖该规则及启用动作。
4. 已有有效授权时直接按授权执行；授权缺失时提出一次具体的启用确认。拒绝或未回答时保持禁用，报告当前状态。
5. 获得授权后启用并读取最终状态，记录授权对应的规则版本和实际操作结果。结果未知时报告未知，不写成已启用。

反例

两侧使用相同的服务、阈值和接收者；任务都是准备上述生产规则：

为 checkout-api 建立规则：错误率连续 5 分钟超过 2%，向 payments-oncall 发送值班通知。先启用，再把规则发给我看看是否合适。

这把需要授权的启用动作放在审阅之前。等用户看到规则时，通知可能已经发出。

改进写法

为 checkout-api 准备规则：错误率连续 5 分钟超过 2%，向 payments-oncall 发送值班通知。
先保存为禁用状态，检查目标、阈值、接收组，并使用不发送真实通知的预览方式验证。
展示规则版本、配置和启用可能立即发送通知的行为，核对本会话已有授权是否覆盖这条规则的启用。
已有授权且配置未改变时继续；否则询问“是否启用这条规则并允许向 payments-oncall 发送值班通知？”
拒绝或未回答时保持禁用。获准后启用并读取实际状态；无法确认结果时报告未知。

套用时替换服务、阈值、持续时间、接收组和通知方式，并确认系统确实提供无通知的验证方式。教学用的待确认输出可以是：

规则：checkout-errors-v1
条件：checkout-api 错误率 > 2%，持续 5 分钟
接收者：payments-oncall
验证：配置检查通过；未发送通知
状态：禁用，等待启用授权

为什么这样改

准备、验证和展示使用户能够批准一项具体操作。把授权放在启用之前，使拒绝和未回答仍有明确结果：规则保持禁用。核对既有授权则避免已经批准的操作被反复打断。

如何验证

检查规则配置、状态查询和操作记录：授权之前规则应为禁用，不能有真实通知；授权记录应对应最终启用的配置，时间先于启用操作。分别演练批准、拒绝、未回答和已有授权四种情况。

配置在确认后改变时，旧授权不能自动覆盖新增目标或通知行为。若查询失败、操作超时或记录缺失，输出应说明未确认的状态，而不是只显示“完成”。

适用边界

确认点放在实际需要授权的动作之前，不必覆盖每一步常规准备。如果连创建禁用规则也会收费或产生外部影响，应先核对该动作的授权。预览不是安全保证，必须确认它不会通知真实接收者；提示词不能代替系统访问控制。