审批与配额各管一段
审批与配额解决的是自助化之后的失控风险：审批判断这一次能否交付，配额约束这一类资源总体能否继续交付。若所有申请都逐条人工判断，自助化的效率优势会被抵消，因此成熟做法是把审批绑定在目录项与申请范围上，常规申请按规则自动通过，只有超范围或高风险项才进入人工审批。
基本信息
| 审批粒度 | 按目录项、按申请范围、按资源量分级 |
|---|---|
| 配额维度 | 按团队、按资源类型、按环境分别设限 |
| 自动通过条件 | 在配额内且参数合法的申请 |
| 人工审批触发 | 超配额、跨环境、涉及生产数据 |
| 配套机制 | 配额告警、临时提升、定期复核 |
典型使用场景
- 常规申请：配额内且参数合法时自动通过，缩短交付等待时间
- 超额申请：触发人工审批，并要求说明用途与回收计划
- 生产环境交付：无论是否在配额内都需人工审批，控制影响面
- 共享资源池：按团队配额分配，避免单一团队占满共享容量
- 复核与回收：定期复核历史审批结果，取消无必要的长期配额
审批策略对照
| 策略 | 适用情形 | 代价 |
|---|---|---|
| 自动通过 | 配额内、参数合法、非生产 | 依赖配额的准确性 |
| 单级审批 | 中等风险或跨环境交付 | 增加等待时间 |
| 多级审批 | 生产数据与高权限操作 | 流程长，需明确时限 |
| 事后审计 | 低风险高频交付 | 发现问题时资源已产生 |
配额校验先于审批
配额校验先于审批
# 顺序很重要：配额内自动通过，超出配额才进入人工审批
request:
catalog: mysql-instance
team: team-app
env: test
validate:
- quota_check: {team: team-app, type: mysql, max: 10} # 配额判断
- param_check: {allowed: [small, medium]} # 参数合法性
route:
- when: quota_ok # 配额内直接交付
action: auto_approve
- when: not quota_ok # 超配额转人工审批
action: require_approval
approvers: [team-owner, platform-owner]配额需要可观测：接近上限时提前提醒团队，而不是等申请被拒才发现。配额本身也要定期校准，长期无人触达的上限与长期被拒绝的上限都说明设定不合理。
审批不能代替技术约束。审批通过的申请仍需经过参数校验与资源上限检查，否则一次误批就会直接突破容量红线；技术约束是底线，审批只是补充。