晚上 10 点 17 分，订单接口开始间歇性超时。
开发同事在故障群里发来一句：“先给我生产库全权限，查完马上还。”
这句话很难接。拒绝吧，群里每一分钟都有人追问损失；答应吧，“马上还”常常会在故障恢复以后，和那杯冷掉的咖啡一起被忘在桌上。更麻烦的是，全权限并不会自动让排障更快。它只是把查数据、改数据、改结构、管账号这些完全不同的能力，塞进了同一把钥匙。
数据负责人此时要做的，不是把审批流程搬出来挡在路中间，也不是凭信任放行。
他要在 15 分钟内把一句模糊的“给全权限”，拆成一个够用、限时、能回收、能复盘的授权包。
这里的 15 分钟，指的是完成授权判断和发出可执行方案，不保证 15 分钟解决故障。故障本身愿不愿意讲道理，是另一回事。
最小权限不是“尽量少给”，而是“刚好够完成这次任务”
“只给只读”听起来很安全，却不一定叫最小权限。
如果同事要终止一条堵塞队列的会话，只读权限不够；如果他只需要核对 30 笔异常订单，给整库读取又太多；如果必须修复一条错误配置，允许任意 UPDATE 也远远超过任务。
最小权限真正要回答五个问题：
- 做什么任务：验证假设、导出证据、终止会话，还是修改数据；
- 碰哪些资源：哪个环境、实例、数据库、schema、表、行或存储过程；
- 允许什么动作：连接、查询、执行、更新，还是变更结构；
- 能用到什么时候：30 分钟、2 小时，还是故障结束即回收；
- 怎样留下证据：谁申请、谁批准、执行了什么、结果如何。
美国国家标准与技术研究院在 NIST SP 800-53 的 AC-6 控制中，把最小权限概括为：只允许完成被分配任务所必需的访问。AWS 关于临时提权的说明也强调，请求应对应特定任务、特定时段，并能被审批、跟踪和撤销。
这些原则并不新鲜。真正难的是电话响着、群消息滚着的时候，团队能不能把它们翻译成一张当场可用的单子。
前 3 分钟：先把“我要查一下”改写成一个可验证的任务
故障里最浪费时间的问题，是问：“你到底要什么权限？”
申请人通常只会再说一遍：“生产库权限，越快越好。”
更有效的问法是四连问：
| 要问的内容 | 现场问法 | 合格答案示例 |
|---|---|---|
| 当前假设 | 你准备验证什么？ | 怀疑订单状态回写任务从 21:50 起出现阻塞 |
| 所需证据 | 你必须看到或执行什么？ | 查 21:50 后失败订单、锁等待和任务运行记录 |
| 最小对象 | 具体到哪些库表或过程？ | orders、job_runs 两张表和只读锁视图 |
| 下一步动作 | 查到以后准备怎么做？ | 先确认阻塞会话；需要终止时另走一次确认 |
这四个答案决定授权边界。
如果申请人连要看哪类证据都说不清，直接给全权限不会帮助他更快定位。更稳妥的办法，是让熟悉数据结构的人先陪同查询，或者由数据库管理员代跑第一组诊断语句。
有时真正需要的不是“登录生产库”，而是一份查询结果。比如核对 30 个订单状态，可以让数据值班同事在受控环境执行已审核 SQL，把结果放进故障记录。这样既拿到了证据，也没给排障者开一条可长期进入生产库的路。
任务先清楚，权限才有可能小。
第 4—7 分钟：把权限分成读取、执行、变更三档
我建议团队预先准备三类授权包。名字可以不同，关键是不要把它们混成一个“生产权限”。
第一档：只读排查
适合核对数据、查看执行计划、读取监控视图和导出有限证据。
默认边界可以是：
- 只允许连接指定生产实例；
- 只允许访问指定 schema 或白名单表；
- 默认不给个人信息、支付明细等敏感列；
- 对大表设置查询时长、扫描量或并发限制；
- 导出受控，结果进入故障目录而不是个人网盘；
- 禁止写入、建表、改结构和管理账号。
“只读”也不是零风险。一条无条件全表扫描，照样可能让本来就喘不过气的数据库再吃一记重拳。因此只读包里要带查询保护：只允许从只读副本排查，或限制语句超时、并发和扫描范围。
第二档：受控执行
适合终止阻塞会话、重新执行一个任务、调用已经审核的修复过程。
这类授权不必给任意写权限。可以只开放：
- 执行某个存储过程；
- 终止满足条件的指定会话；
- 重跑某个任务实例；
- 修改一个明确的运行参数。