1. 题目与使用场景
平台团队需要修改防火墙规则、支付限额或服务路由。提交者不能批准自己的变更，审批必须针对确切版本，执行失败不能留下半更新状态。系统的目标是把“有人说可以”变成可验证、可审计、可恢复的流程。
2. 面试官考察点
- 是否能区分提案、审批、执行和回滚状态。
- 是否保证审批人独立、审批内容不可被静默替换。
- 是否处理并发审批、重复请求、超时、撤销和权限变化。
- 是否在控制风险的同时提供小范围试运行和稳定回退路径。
NIST SP 800-128 要求配置变更由独立于请求者的授权人员审查；Google SRE 强调配置版本应进入代码审查，并在新配置不通过检查时继续使用旧配置。设计应把这些原则落实到数据和状态机。
3. 回答前需要澄清的问题
- 哪些资源和字段属于高风险，是否按环境或租户区分？
- 审批是单人、多人任一通过，还是必须达到人数和角色门槛？
- 执行是全量切换、分批发布，还是需要目标实例确认？
- 回滚目标是上一个已知版本，还是提交者指定的版本？
4. 30 秒回答框架
用“提案快照—策略匹配—审批隔离—执行器—回滚审计”回答：
我把每次变更冻结成不可变版本，策略根据资源、风险和环境选择独立审批人。审批记录版本摘要和策略版本，提交者不能满足审批门槛；达到门槛后由幂等执行器分批应用，并在每批做健康检查。任何失败都停止扩散、切回上一个已验证版本，所有状态和决定写入不可篡改的审计日志。
5. 分步骤深入解答
第一步：定义核心实体与状态机
配置提案包含资源、差异、作者、版本摘要、目标环境和过期时间；审批包含审批人、角色、决定、时间、策略版本和提案摘要；执行记录包含批次、目标、结果和回滚版本。状态可为 DRAFT、PENDING_APPROVAL、APPROVED、EXECUTING、SUCCEEDED、FAILED、REVOKED 或 EXPIRED，状态转移只能由服务端规则触发。
第二步：实现独立且绑定版本的审批
策略服务计算所需角色、人数、是否禁止自批和审批有效期。审批人看到的差异摘要必须与执行版本哈希一致；提案被修改就自动失效并重新审批。权限在审批和执行时都重新检查，避免审批后角色被撤销仍能执行。
第三步：用幂等执行器控制发布
执行器为每个提案和目标生成幂等键，记录外部系统回执。按小批次应用，先做语法、依赖和安全检查，再观察健康指标；重试只处理未知结果，不能盲目重复非幂等操作。队列或工作流负责超时、重试和并发限制。
第四步：安全回滚与审计
发布前保存上一个已验证版本，失败时停止后续批次并恢复该版本。回滚本身也要记录操作者和原因，必要时触发紧急审批。审计日志至少包含提案摘要、审批链、执行批次、配置版本、失败原因和回滚结果，并限制删除和修改权限。
6. 高质量示范回答
我会把系统拆成提案 API、策略服务、审批服务、执行队列、配置适配器和审计存储。提案写入不可变版本，包含资源差异、环境、作者和过期时间；策略服务根据风险等级计算所需角色和审批人数，并排除作者本人。
>
审批人看到版本摘要和差异，审批记录绑定提案哈希与策略版本。提案任何修改都会回到待审批状态。达到门槛后，执行器用提案 ID 加目标 ID 生成幂等键，先做静态检查，再按小批次应用并读取健康信号。重复请求读取已有执行结果，未知结果进入人工复核。
>
每个提案保存上一个已验证版本。某批次失败时暂停后续批次，恢复旧版本并记录原因；高风险紧急回滚仍需独立审批。审计事件写入只追加存储，包含谁在何时批准了哪个摘要、哪些目标已执行以及是否回滚。这样既满足 separation of duties，也避免审批通过后配置被悄悄替换。
7. 常见错误
- 审批只绑定资源 ID，不绑定具体差异和版本摘要。
- 作者可以用第二个角色自批，破坏独立性。
- 直接把批准结果写入配置库，没有执行状态和回执。
- 失败后继续扩大批次，或对非幂等操作无限重试。
- 回滚没有版本、权限和审计记录。
8. 追问及应对
追问一：审批人批准后提案作者离职怎么办？
审批结果绑定不可变提案，不依赖作者在线；执行权限由服务账号和当前策略决定，撤销作者不会删除有效审计链。
追问二：如何防止两个审批流程同时执行同一资源？
按资源和环境建立互斥锁或租约，并在执行前再次检查当前配置版本；冲突时让较新的提案重新计算差异和审批。
追问三：紧急变更能否跳过审批？
可以定义受限的 break-glass 流程，但仍需双人授权、最小权限、短时效、事后复核和完整审计，不能把紧急通道变成日常捷径。