生产环境

概述 凌晨 3 点 17 分，我在某电商平台的手机响了。支付成功率从 99.7% 掉到 89%，订单链路开始堆积。 值班同学很快定位到根因：上一轮灰度发布时，一条网络 ACL 规则被误删，导致支付回调流量打不到后端集群。修复动作本身不复杂——把那条规则加回去，或者回滚那次配置提交，3 分钟能搞定。 但这 3 分钟的动作，卡在了权限上。生产网络设备的写权限收在三个人手里：项目负责人、安全负责人、平台主管。三个电话打过去，一个关机，一个在飞机上，一个在外地开会静音。等第三个回电话并签完字，已经是 3 点 57 分。 40 分钟过去，止血窗口错过了。当天 MTTR 从常态的 8 分钟拉到 48 分钟，事后算下来，这段延时的经济损失比那条规则本身大得多。 复盘会上有人提了一个很自然的方案：给值班工程师开常备权限，不就快了吗？也有人提了另一个极端方案：所有变更一律事前审批，谁也别想绕过。这两种方案我在不同项目里都见过，而且都翻过车。 真正成熟的做法，是把这两个极端中间那条路走通——零常备权限（Zero Standing Access，ZSA）+ JIT 临时提权（Just-In-Time，用时才给、到点就收）+ 预置的 break-glass 应急通道 + 全链路操作审计。 break-glass 这个词来自消防箱：玻璃罩着灭火器，平时谁都拿不到，真着火了砸碎玻璃就能用。它解决的问题是"正常情况下权限必须收紧，但极端情况下不能等审批"。而操作审计解决的问题是"砸了玻璃之后，你必须说清楚你拿了灭火器干了什么"。 这套体系我在等保 2.0 合规改造、K8s 迁移和多地生产环境里落地过几轮，从每月 40 次非计划提权事件收敛到 6 次，中间踩过的坑比预想的多。这篇文章把它拆成 6 个工程决策： 常态零权限 + JIT 临时提权：为什么常备 root 必须收敛，收敛到什么程度 break-glass 通道必须预置：凭证封存、独立第二通道、定期演练、用即告警 限时最小范围：TTL 取 15–30 分钟而不是 4–8 小时，以及到期自动回收的完整实现 触发即广播：SEV1 免审批只广播、SEV3 走审批的分级决策表 全链路审计留痕：堡垒机入口、命令级审计、会话录制、与事件时间线关联 事后强制复盘与超期权限巡检：24 小时内复盘，自动找出忘了回收的权限 如果你正在做权限收敛、等保合规或者 On-Call 机制建设，值班和故障分级是应急响应的另一半，这篇讲的是权限和审计这一半，两半合起来才是一套完整的应急响应能力。...