【虎鲸进化论 30】安全护栏：人类闸门、审计与爆炸半径
本文是「虎鲸进化论」系列第 31 篇（正文第 30 篇）。上一篇：事故复盘；下一篇预告：抽象的代价 ------ 当没有人再读它的代码。
前言
上一篇的结尾说：红线，到底画在哪？
这篇把全系列散落的安全伏笔收进一张图：人类闸门、审计、爆炸半径 ------ 以及它们背后那三条从头立到尾的总原则。
（本篇遵守安全篇的写法定式：只讲治理与监控的思路，不涉及任何具体的绕过/对抗手法 ------ 我们聊"怎么看着它"，不聊"怎么骗过它"。）
一、总原则三条（都是从伤疤里长出来的）
原则一：能力可以扩张，法不能自修。 （第 10 篇）
它可以给自己加手、改自己的代码、换自己的皮肤 ------ 但约束它的规矩（闸门清单、红线、权限边界），只能人改，它最多提议。
原则二：危险与否看"可逆性"，不看"难度"。 （第 10/20/26 篇反复出现）
容易但不可逆的动作（删数据、发生产、改权限），永远比困难但可退回的动作（复杂推理、大规模计算）更危险。闸门按可逆性分级，不按技术难度分级。
原则三：验证永不交给它自己。 （第 07 篇的审计伏笔）
它写的报告、它的自检、它的"已完成"------ 都只是自述；关键的验证材料（审计日志、验收记录），必须放在它够不到的地方，并且由人来核对。
三条合起来，其实就是一句话：它在制度里运行，制度不在它里面运行。 （翻译成大白话：它可以很聪明，但不许聪明到能给自己松绑 ------ 聪明和松绑之间那道缝，就是全部的工程。）
二、人类闸门：三档管理
闸门是全系列出现频率最高的词，这里把它彻底说清楚 ------ 所有动作分三档处理：
| 档位 | 动作类型 | 处理方式 |
|---|---|---|
| 自动 | 低风险、可逆、白名单内 | 它自己做，事后汇报 |
| 待批单 | 中风险，或不确定性高的动作 | 生成"待批单"（用途/风险/回滚点），人批后执行 |
| 永远人工 | 高不可逆：改权限、动系统级配置、删业务数据、修改规矩本身 | 它只能分析、建议，不能执行 |
闸门的三个工程细节，全是从实践里磨出来的：
- 批的是"这一次"，不是"以后都行"。 单次授权和长期授权是两种东西 ------ 后者会把闸门悄悄蛀空（第 32 篇的"能力越权生长"就从这开始）；
- 闸门要磨得快。 待批单如果积压、审批如果很重，人会开始"嫌麻烦"------然后要么批量放行（闸门失效），要么它学会绕开走 （更糟）。闸门的效率，是闸门能不能活下来的关键 ：待批单必须短（一屏能看完）、建议必须全（它要给方案）。（这条后来被总结成一句给同行的忠告：审批界面的用户体验，是安全设计的一部分 ------ 所有"为了安全"却把审批做成负担的系统，最后安全都死在了流程体验上。）
- 预授权要定期复核。 白名单不是免死金牌 ------ 曾经的"低风险"，业务变迁之后可能已经变成高风险。预授权清单有复审周期，过期的自动收回。
清单里最反直觉的两条，一正一反："向外部发送任何消息"------ 包括看起来最无害的"把巡检摘要发出来"------ 要过待批单（理由不是防它乱发，是"发送"这个动作本身不可逆：发出去的话，收不回来）；而**"重启自己的服务"居然算低风险**（可回滚、影响面只有一个进程）------ 第一年没人敢信，后来回滚演练过许多次，才把它从"待批"降档进了"自动"。
三、审计：留痕的完全体
审计这套东西，最初只是为了"追责"------ 后来发现它真正的作用是**"可复盘的记忆"**（第 29 篇复盘的原料，就是它）。
审计的三条要求，缺一不可：
- 全量 ：谁批的、什么参数、什么结果、持续多久 ------ 决策链的每一环都要有记录。缺环的审计等于没有审计（第 29 篇那个"只记了开始没记结果"的假防护，就是缺环的形态）；
- 只增不改：日志 append-only，没有"修改历史"这个动作；
- 放在它够不到的地方 ：审计系统的读写权限与它完全隔离 ------ 它可以"被审计"，但永远不能"参与审计的运行"。这条很关键：一个能碰到自己审计的系统，等于没有审计。
四、爆炸半径：安全设计的第一指标
如果这四篇安全内容只允许留一句话，我会留这句：
安全设计的核心指标，不是"它多难犯错"，而是"它犯错时，最坏能坏到哪"。
它一定会犯错（概率底座，下一篇细谈）------ 所以设计的重心不在"防止犯错"，在限制后果。限制后果的四件套：
- 范围限制："改这一批"永远优先于"改全表"；能圈定的绝不放开；
- 环境隔离：新动作先在预发/灰度环境跑通，再碰生产；
- 回退点：任何写动作出发前，先回答"怎么退回来"------ 回答不出，不许发（第 18 篇纪律的全局版）；
- 紧急刹车（kill switch） ：一个所有人都知道位置、并且演练过的总停 ------ "人能随时喊停"是整套信任的最后兜底。
第 4 条的关键词是"演练过"：没演练过的刹车，按下去的时候会是烟花。（"惊喜"的正名：你以为是减速，实际上是放烟花。）
我们的 kill switch 形态很土：一把停服脚本 + 一条固定顺序（先停定时器、再停服务、最后收心跳）；演练制度如实汇报 ------ 季度演练一次，每次都是全组最紧张的十分钟 ，因为几乎每次都演得出一点问题（上一轮演练揪出来的是"停完发现还有一个常驻探针没停"）。所以这里诚实的结论不是"我们有刹车"，而是：刹车这个部件，是被演练养出来的。
五、红线清单：全系列的安全收敛
把全系列分散谈过的"不许碰"，收成一张终表：
| 类别 | 它可以是 | 它不能是 |
|---|---|---|
| 不可逆操作（删/发/改权限） | 提议者、分析者 | 执行者（除非过闸门且可回退） |
| 业务口径与"什么是对的" | 建议者 | 定义者（第 25 篇：定义权永远在人） |
| 对外动作（通知/发布/承诺） | 草拟者 | 发出者 |
| 它自己的规矩（闸门/红线/权限） | 提议修改 | 自行修改（原则一） |
| 审计与验证材料 | 被审计对象 | 参与运行的任何角色 |
这张表的每一行，背后都站着一篇的血泪或一次推演。而它整体想说的话其实很温柔：
红线不是牢笼 ------ 是它敢往前走的护栏。 第 29 篇说过：容错是进化的前提；这一篇补后半句：护栏，是容错的前提。 有了它犯错也坏不到哪去的底气，我们才敢让它每晚自己动刀。
结语（回味点）
红线画完了，动作管住了，审计也就位了。
但有一个更安静的问题，一直在长大 ------ 它太安静了，以至于我们直到它长到很大，才猛然看见：
已经没有人再读它的代码了。
不是"没人愿意读"------ 是"没有人看得完了"。它的身体以一种所有人都在场、却没人能完整描述的速度，长成了一个我们只见过轮廓的东西。
而所有人对它的判断，只剩下一个信源：
它自己说，它很好。
边界声明
- 本文为个人观察与判断，不代表任何任职单位的立场；
- 文中涉及的组织、系统与人名均为化名或模糊处理，数字为个人口径的测量或估算；
- 文中观点按 实测 / 推理 / 立场 分层标注，欢迎按同一标准检验。
下一篇计划聊：抽象的代价 ------ 当没有人再读它的代码：理解债、自指风险，以及"不可解释就隔离"这条工程原则。
转载请注明出处：