4.7 技术风险与止损
一句话
风险管理的产出不是一张风险清单，而是事先写好的止损条件：风险 = 概率 × 损失，处置只有四种（规避 / 减轻 / 转移 / 接受）；而止损的前提是——触发条件必须可观测，否则它只是决心。
先算期望损失，再决定处置
| 处置 | 典型手段 | 代价 | 什么时候选 |
|---|---|---|---|
| 规避 | 不引入这个技术 / 不做这个需求 | 放弃收益 | 期望损失 > 收益，且损失不可承受 |
| 减轻 | 灰度、限流、降级、双跑、多活 | 工程成本 + 复杂度 | 概率降得下来（多数场景） |
| 转移 | 买 SLA、供应商责任条款、保险 | 溢价 | 损失由别人承担更便宜（合规、赔付型） |
| 接受 | 登记 + 监控，不额外投入 | 0（但要占监控位） | EL 低，或减轻成本 > EL |
排序用年期望损失 EL = 概率 P × 单次损失 L，和 4.2 成本-收益分析 里避险类项目的算法同一套：P = 0.2/年 × L = 300 万 → EL = 60 万/年。EL 小于减轻成本时，正确动作是 “接受 + 登记”，不是 “再排一个整改项目”。
🔑 全对冲 = 全不投。 把所有风险都减轻，等于把所有预算都花在 “不出事就看不见收益” 的地方；按 EL 排序是唯一能同时回答 “该花多少” 和 “先花在哪” 的方法。
技术风险八类：先有清单，才谈识别
| 类别 | 典型表现 | 早期信号（可观测） |
|---|---|---|
| 选型风险 | POC 通过，生产长尾不达标 | 灰度后 P99 比基线劣化 > 30% |
| 人才风险 | 只有 1 人能改核心模块 | bus factor = 1；关键路径只有 1 个 CODEOWNER |
| 锁定风险 | 数据导不出、API 无替代 | 导出功能缺失 / 只能走厂商工单 |
| 规模风险 | 10 倍数据量下方案失效 | 单表月增 15%，且无分区方案 |
| 维护风险 | 上游停更、issue 无人回 | 6 个月无 release；中位响应 > 7 天 |
| 供应链风险 | 传递依赖爆漏洞 / 投毒 | SBOM 中未知来源组件 > 20% |
| 合规风险 | 数据出境、留存超期 | 法务口径变化、新增审计要求 |
| 成本风险 | 账单随流量线性上涨 | 单位请求成本连续两季度上升 |
其中 “锁定风险” 与 “维护风险” 若选择继续承担，要按 58.2 技术债管理 的格式登记本金与利息，否则它会以 “一直都能跑” 的形式消失在视野里。
清单的作用不是 “列全”，而是让讨论从 “我感觉有风险” 变成“你指的是哪一类、信号是什么”。八类里，前四类必须在选型阶段就过一遍——它们决定了项目的形态；后四类可以进登记册，按季度看。
止损线：四要素，缺一个就只是口号
| 要素 | 合格写法 | 不合格写法 |
|---|---|---|
| 可观测指标 | “订单接口 P99（5 分钟窗口）” | “系统变慢” |
| 阈值 + 时间窗 | “连续 3 天 P99 > 500ms” | “效果不好就停” |
| 预设动作 | “切回方案 B；冻结新功能上线” | “再评估” |
| 执行人 | “交易域 TL 有权直接切，事后 24h 内通知” | “大家一起判断” |
止损单与决策记录是同一次决策的两个侧面：决策记录写 “为什么这么选、什么条件下失效”，止损单写 “失效时怎么观测、谁按按钮”，字段与台账见 4.6 决策框架与决策记录。
# stoploss/D-2026-041.yaml —— 止损单：决策落地时一起写，不另开会
decision: D-2026-041（订单库分库分表）
scope: 订单写入链路（占交易域 70% 流量）
signals:
- metric: order_create_p99_ms
window: 5m
trigger: 连续 3 天 > 500ms # 阈值 + 时间窗
- metric: shard_hotspot_ratio
window: 1d
trigger: 单分片承载 > 35% 写入
actions: # 触发后做什么，按序执行
- 切回单库写入（双跑期内 ≤ 2 小时可回）
- 冻结新分片迁移任务
- 24h 内召回复盘，更新决策记录
owner: 交易域 TL # 谁有权拍下这个按钮
review_at: 2027-Q1
🔑 止损线写不进监控，就只是决心。 落地验收标准：
trigger里的每个指标都能在告警系统里点到，且有人收到过测试告警。
可靠性上其实早就有同构的东西：35.2 SLA / SLO / SLI / 错误预算 的 “错误预算烧完就冻结变更”，就是一条组织级的止损线——预定阈值、预定动作、预定执行人，唯一区别是它按季度算，技术风险按项目算。
退出方案：四问 + 一次真演练
| 问题 | 合格答案 | 常见的不合格答案 |
|---|---|---|
| 数据能不能导出？ | 全量导出脚本 + 耗时（例：50 亿行 6 小时） | “应该可以” |
| 依赖能不能替换？ | 替换点清单 + 工作量估算 | “接口是标准 SQL” |
| 回滚要多久？ | ≤ 一个发布窗口，且演练过 | “改回去就行” |
| 谁签字执行？ | 具名 + 授权范围 | “运维会处理” |
四个问题的判据与 4.3 技术选型的评估维度 的 “退出成本” 同源：换回来要多久、要谁配合、数据能不能导出。
锁定的止损方式是演练，不是合同条款。 每半年做一次 “把主链路切到备用实现” 的演练：不需要真迁走，但要证明 “能迁”。演练不做的退出方案，在出事当天会退化成聊天记录。代码与数据侧的回滚设计见 55.3 回滚设计。
沉没成本：止损只算边际
止损失败几乎从来不是算不出来，而是算错了分母：
| 错法 | 后果 |
|---|---|
| “已经投了 6 人月，不能白费” | 用过去决定未来，继续投 12 人月去救 6 人月 |
| “再给它一个季度” | 每季度都这么说，触发条件永远不满足 |
| “换方案等于承认失败” | 把技术决策变成面子问题，风险被隐藏而不是被处置 |
正确算法只有一句：比较 “继续投的边际成本” 与 “继续投的边际收益”，已投入的部分与这个比较无关。这件事靠人性做不到，所以要靠机制：把止损条件写在启动时（那时没人觉得会失败），而不是写在下坡路上（那时每个人都在找理由）。
Pre-mortem：开会先假设它已经失败
Gary Klein 提出的 pre-mortem（前瞻性后见，HBR 2007）把一个团队从 “预测成功” 切换到 “解释失败”，10 分钟就能问出常规评审问不出的东西：
| 步 | 做什么 | 时长 | 产出 |
|---|---|---|---|
| ① | 假设 “12 个月后这个项目惨败”，每人独立写 3 条原因 | 5 分钟 | 15–20 条原因 |
| ② | 聚类 + 按 P × L 排序 | 10 分钟 | 前 3 条 |
| ③ | 给前 3 条各写一条早期信号 + 一条止损动作 | 10 分钟 | 进止损单 |
独立写是关键：先发言的人会锚定全场，先写再念才能拿到分歧。
第 ③ 步产出的 “早期信号 + 止损动作” 里，凡是要占用工程的减免项，按 58.4 演进路线图 的分波方式排进下一波，并写清 “这一波没做完时，风险由谁承担”。
反模式
| 反模式 | 后果 |
|---|---|
| 风险登记册只登记不触发 | 表越来越长，没人知道哪个该动了 |
| 止损条件写成 “效果不好就停” | 无法判定，等于没写 |
| 止损指标没接监控 | 触发靠人感知，通常晚 2–4 周 |
| 退出方案没演练 | 出事当天才发现导不出数据 |
| 用 “已投入” 当续投理由 | 沉没成本放大损失 |
| 只做规避不做接受 | 预算全花在低 EL 项，真正的风险没覆盖 |
| 风险负责人写成 “团队” | 触发时没人有权停 |
| 事故后才补风险清单 | 清单只覆盖上一次事故的形态 |
三条铁律
🔑 止损条件在启动时写、写进监控、指定执行人；三件事缺一件，止损就只是表态。
🔑 只算边际，不算沉没：继续投的决策只看 “再投多少、还能拿回多少”。
🔑 退出方案必须演练过；没演练过的退出方案，与没有退出方案等价。
自检
Q1 团队说 “这个新数据库的风险我们评估过了，可控”。你要追问哪三样，才能把这句话变成可执行的止损？
▸ 答案：① 信号（哪个指标、什么窗口、阈值多少）；② 动作（触发后切回什么、多久内切完、谁有权拍）；③ 复核（谁在什么日期回看）。三样齐了才算止损线；只说 “可控”，等于把风险交给运气——而它的 EL 也没算过（P × L 多少、减轻成本多少）。
Q2 一个项目已投入 6 人月，现在发现方案在新的数据量下不达标。为什么 “不能白投” 是错的论证？
▸ 答案：因为 6 人月是沉没成本，无论继续还是停止都不会回来。唯一相关的是 “再投 X 人月，能拿回多少”——若再投 3 人月只能挽回 20% 的目标，而换方案需 4 人月能达成 100%，正确选择是换。这个计算与已投入无关；把它写成 “已投入” 的形式，是在用过去绑架未来。
Q3 供应商锁定风险的 “止损” 为什么是演练，而不是合同条款？
▸ 答案：因为合同只能事后追责，不能恢复服务。锁定的真实损失是 “迁移不出去” 的时间，而时间只能靠 “证明能迁” 来压缩：导出脚本跑过、替换点清单存在、切换演练过。条款写得再漂亮，若没人跑过一次导出，出事当天仍是从零开始。
Q4 风险清单上 30 条都是 “高”，该怎么排？
▸ 答案：用 EL = P × L 算成钱再排，而不是用 “高/中/低” 三档贴标签。30 条全高说明两件事：① 没有量化（P 和 L 都没估）；② 处置预算没有上限约束。算出 EL 后通常会发现前 3 条占 80% 的期望损失——剩下的要么接受（登记 + 监控），要么排进后续季度，而不是同时开工。
Q5 Pre-mortem 与普通风险评审有什么不同，为什么它更有效？
▸ 答案：普通评审问 “可能有什么风险”，答案受 “社会赞许” 影响（说 “应该没问题” 更安全）；pre-mortem 先设定 “它已经失败了”，把任务变成解释一个既定事实，心理负担从 “唱衰” 变成 “分析”，于是能说出真话。加上 “独立写再汇总”，避免第一个发言的人锚定全场。
- 下游：4.8 外包与供应商评估
关联
- 前置：4.3 技术选型的评估维度、4.6 决策框架与决策记录
- 并列：4.2 成本-收益分析、35.2 SLA / SLO / SLI / 错误预算、58.2 技术债管理
- 下游：55.3 回滚设计、58.4 演进路线图