1.2 软件危机与现代失效模式

经典的“软件危机”描述的是项目延期、超预算、不可靠、难维护。工具已经变了，但模式没有消失。现代系统的失败更分布式、更快速，也更不明显。

今天的一次故障，可能同时来自产品假设、API 契约、依赖升级、缺失告警、仓促迁移、困惑的用户流程，以及模糊的团队边界。

现代失效模式

真实团队里常见这些模式：

• 隐藏耦合：两个模块看起来独立，却共享时序、数据形状、缓存行为或业务含义。
• 延迟集成：每个团队本地都成功，组合后的系统失败。
• 环境漂移：开发、预发布、生产环境行为不同。
• 可观测性薄弱：用户已经受影响，仪表盘还一片绿色。
• 大批量发布：太多变化一起上线，诊断和回滚都变难。
• 责任边界模糊：大家都能看到问题，但没人明确拥有修复责任。
• 伦理盲区：系统完全按需求工作，却伤害用户或剥夺真实选择。

无责不是没有后果

无责复盘的意思是：我们研究系统，而不是把会议变成找人羞辱。它不代表忽略严重性，也不代表没有责任。

有价值的复盘会区分：

• 发生了什么。
• 谁受到了影响，影响了什么。
• 哪些假设是错的。
• 哪些反馈来得太晚。
• 哪个边界、测试、监控或发布实践需要改变。

目标是更早学习

好的工程不会承诺零缺陷。它努力让缺陷更小、更早、更清晰、更容易恢复。

这也是代码评审、CI、功能开关、金丝雀发布、日志、指标、链路追踪、运行手册、事故复盘这些实践在使用得当时并不是官僚流程的原因。它们是在把学习移动到更接近决策发生的地方。