风险评估与应对策略
一、识别技术、业务与组织风险
风险不限于「技术会不会挂」：技术风险（新栈、性能、单点、依赖服务）、业务风险（需求变更、上线时机、合规）、组织风险（人力、协作方、决策链）都会影响项目成败。识别时要按类别列一列，避免只盯技术而忽略「人」和「事」。
与系统、选型、实现相关的风险。
- 新技术/新组件不熟、坑未知
- 性能/容量未验证
- 单点、依赖服务不可用
与需求、时机、合规相关的风险。
- 需求变更或范围蔓延
- 上线窗口与业务节点冲突
- 合规、审计未通过
与人力、协作、决策相关的风险。
- 关键人离职或投入不足
- 依赖其他团队排期与质量
- 决策慢、多头指挥
二、概率与影响评估
识别后要对每个风险做粗略的概率（多大可能发生）和影响（发生后的后果有多严重）。不必追求精确数字，可用「高/中/低」或 1～5 分；目的是排出优先级：高概率 × 高影响优先应对，低概率且低影响可接受或监控。
三、应对策略：缓解、转移、接受、应急计划
对每个（或每类）风险要选一种或组合的应对策略：缓解（降低概率或影响）、转移（让第三方承担部分，如保险、SLA）、接受（明知有风险但选择承担，需记录）、应急计划（发生时的预案，如回滚、降级、值班）。不应对的高风险要显式说明「我们选择接受」并留痕，避免事后扯皮。
通过设计或行动降低发生概率或减轻影响。例如：压测与演练、去掉单点、增加监控与告警。
把部分风险转给第三方。例如：用托管服务 SLA、买保险、合同约定责任与赔偿。
明知有风险但选择不额外投入应对，需记录原因与责任人。例如：低概率低影响、成本不划算。
风险发生时的预案：回滚、降级、熔断、值班与升级路径。要可执行、事先演练过。
四、在架构评审中系统化谈风险
架构评审不应只讲「方案多好」，还要留出时间讲风险与应对：列出了哪些风险、概率与影响如何、打算怎么应对、哪些接受、应急计划是否就绪。可以固定一个环节：例如「风险与假设」一页，或评审清单里必含「Top 3 风险 + 应对」。
评审中可用的风险检查项
- 是否列出了主要技术/业务/组织风险？
- 每个高优先级风险是否有应对策略（缓解/转移/接受/应急）？
- 接受的风险是否记录原因与责任人？
- 应急计划（回滚、降级）是否可执行、是否演练过？
- 依赖与单点是否识别清楚，是否有监控与告警？
五、已知未知与黑天鹅
已知未知（Known Unknowns）：我们知道「有可能发生但不确定」的事，可以列成风险、估概率与影响、做预案。例如「新组件可能有性能坑」「依赖方可能延期」。黑天鹅（Black Swan）：极难预测、发生后才被广泛认识的事件，如突发政策、极端故障、全球性事件。对已知未知要尽量识别并应对；对黑天鹅无法穷举，重点是弹性与恢复能力（冗余、降级、快速恢复）、而不是试图预测每一种可能。
能想到但不确定是否发生。可列成风险、估概率与影响、定缓解或应急。例如：依赖延期、新组件有坑、流量超预期。
极难预测、发生后才被广泛认识。无法穷举，重点放在弹性与恢复能力：冗余、降级、快速恢复、事后复盘改进。
要点： 风险要提前识别、显式评估、有应对。技术/业务/组织都要看；概率与影响用来排优先级；缓解、转移、接受、应急四类策略选准并落实；评审里固定谈风险；已知未知做预案，黑天鹅靠弹性与复盘。
反例：评审只讲方案优点，风险未列未应对，事后背锅。
某次架构评审，主讲人只介绍了新方案的技术亮点，没有单独讲风险。会上有人随口问「如果依赖的 XX 服务挂了怎么办」，主讲人说「一般不会挂」。上线后该依赖真的出过一次长时间故障，系统雪崩，业务受损。复盘时被问「当时有没有识别这个依赖风险、有没有降级方案」，拿不出记录。若评审时有一页「风险与应对」：依赖 XX 服务，概率中、影响高，应对为「熔断 + 降级到缓存 + 值班升级」，并留下文档，事后就不会变成「没人说过」的罗生门。风险不写下来、不分配应对，就等于没管。
小结： 要识别技术、业务与组织三类风险，做概率与影响评估并排优先级。应对策略有缓解、转移、接受、应急计划四种，选准并落实、接受类要记录。在架构评审中系统化谈风险，用检查项保证不遗漏。已知未知尽量列风险做预案，黑天鹅靠弹性与恢复能力、事后复盘改进。
六、小结
风险评估与应对策略是减少「事后背锅」和「措手不及」的基础。识别技术、业务、组织风险，做概率与影响评估；用缓解、转移、接受、应急计划四类策略应对；在架构评审中系统化谈风险；区分已知未知（做预案）与黑天鹅（靠弹性与复盘）。下一章讲演进式设计：拥抱变化，在过度设计与欠设计之间找平衡。