安全加固和「出事能恢复」常常打架，你们怎么排优先级？

先抛个背景。做了 10 年分布式，最近在给几个团队做安全加固复盘，被同一个问题反复卡住：安全做扎实了，往往让「出事之后的恢复」变难。这不是理论，是具体到每一处的拧巴：

• 字段级加密（卡号、手机号）：排障要看明文，但明文一落日志/落库就是泄漏源；
• 静态加密 + 密钥托管在 KMS：冷备份恢复直接变成「先拿到密钥」的前置依赖，密钥服务一抖，连备份都救不回来；
• 最小权限：DBA 跨库做数据修复要走一长串审批，而故障窗口往往只有十几分钟；
• 删除/脱敏不可逆：合规要求「删了就是删了」，但审计又要求可追溯、可回滚。

常见分歧，我大概看到三派：

1. 安全优先派：恢复可以慢、可以重，但绝不给「恢复」开后门；宁可不可恢复，不可泄露。
2. 可恢复优先派：安全手段要为恢复留「受控后门」——加密但密钥留底、宽权限兜底、可逆删除。
3. 分层派：对外/高敏数据走安全优先，内部运维/备份走可恢复，靠角色与流程隔离。

我的倾向：第三派，但反对拍脑袋分层。 我更愿意把两端都量化，再相乘排序：

• 安全侧用「这条数据一旦泄露的业务代价」打分（监管罚单 / 赔付 / 品牌）；
• 恢复侧用「恢复概率 × 恢复代价」打分（多久能恢复、恢复要动多少人）；
• 谁的乘积高，谁定这一层的默认值。这样「安全水位」就不是口号，而是能写进 runbook 的数字。

想听大家在几个具体场景下怎么选：

1. 金融 / 内容 / 工具类，你们的安全基线水位是怎么定的？谁拍板？
2. 字段级加密，你们怎么在「排障要看明文」和「不落明文」之间折中？（影子字段？按需解密+审计？）
3. 备份恢复演练多久一次？「恢复成功率」你们到底怎么度量、谁来验收？
4. 最小权限之下，数据修复的 SLA 你们定多少？和故障窗口冲突时听谁的？

我倾向把「安全水位」和「恢复 SLA」都写成可验收的数字，而不是形容词。你们团队现在卡在哪一端？