复核要挡住什么
双人复核（四方眼）针对的是「一个人判断失误就可能造成不可逆后果」的操作：批量删除、数据销毁、权限提升、密钥与证书操作、生产环境变更。它解决的不是技术风险，而是单点判断风险。因此复核必须是另一人在执行前独立确认，确认对象是具体的操作内容与影响范围，而不是申请理由。若复核人只看到工单号与一句描述，复核就退化成流程装饰。
基本信息
| 适用操作 | 批量删除、数据销毁、权限与密钥变更、生产批量变更、配额调整 |
|---|---|
| 角色划分 | 申请人、复核人、执行人，至少申请人不得同时是复核人 |
| 时点要求 | 复核必须在执行之前完成并留痕 |
| 复核对象 | 变更预览、对象清单、影响范围、回滚方式 |
| 例外处理 | 紧急场景允许事后补审，但必须说明原因并纳入复盘 |
典型使用场景
- 生产批量删除：复核对象清单与影响主机数量，确认无保护名单命中
- 权限提升与授权：复核授权范围、有效期与批准依据
- 密钥与证书操作：复核影响的服务、切换顺序与回滚方案
- 数据库结构变更：复核变更语句、锁表影响与执行窗口
- 配额与额度调整：复核调整依据与成本影响，避免无据放宽
复核重点与走形式的表现
| 操作类型 | 复核重点 | 走形式的表现 |
|---|---|---|
| 批量删除 | 对象清单、保护名单、影响范围 | 只看工单号不看清单 |
| 权限提升 | 授权范围、有效期、依据 | 申请人自己复核自己 |
| 密钥与证书 | 影响服务、切换顺序、回滚方式 | 无回滚方案仍通过 |
| 生产变更 | 变更窗口、验证步骤、回滚预案 | 把复核当成审批签个字 |
| 配额调整 | 额度依据、成本影响 | 无依据直接同意 |
复核流程要素
复核流程要素
review_flow:
- step: 提交变更预览 # 含对象清单、影响范围、回滚方式，只给结论不予复核
- step: 独立复核 # 系统强制 reviewer != requester
require: reviewer_ack_scope # 复核人须显式确认影响范围，不是简单同意
- step: 执行 # 仅复核通过后解冻执行权限
- step: 结果核对 # 执行结果与预览比对，差异需说明
on_emergency: 允许先执行后补审，48 小时内完成并记录原因 # 紧急通道要有边界与复核复核有效的前提是「可预演」：提供变更预览与差异，复核人才能判断。看不到具体改动内容的复核，本质上无法阻止误操作。
自己复核自己的操作不构成复核。系统层面必须强制申请人、复核人分离，否则留下的是签名字段而非控制措施。