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