1. 背景：我们为什么要升级复盘思维？
在日常的技术复盘或故障分析中，我们是否常听到这样的声音？
- 怪环境： “那时候是晚高峰，流量太大了，所以挂了。”
- 怪资源： “服务器内存只有 4GB，太小了，没办法。”
- 怪运气： “碰巧那个用户的数据是个特例。”
这种归因方式被称为 “浅层归因陷阱”。虽然这些原因客观存在，但它们无法指导我们规避下一次风险。如果只停留在表面，我们永远在“救火”，而不是在“防火”。
为了彻底解决这一痛点，正式引入基于“系统思维 + 抽象阶梯”的 “二维复盘模型”。通过套路化的思维工具，强迫我们 “向深处挖”（找根因）和 “向宽处看”（找规律）。
2. 核心全景图
我们将认知问题的过程拆解在一个二维坐标系中：
- 纵轴（Y）：深度维度 —— 从 表层现象 到 深层本质。
- 目标： 解决由什么导致的这个问题？（Causality）
- 横轴（X）：广度维度 —— 从 具体实例 到 抽象规律。
- 目标： 这是一类什么样的问题？（Generalization）
-
① 显形事件 (左上)： —— [表层 + 具体]
- 定义： 我们直接观察到的现象，此时此刻发生的事情。
- 典型语言： “系统崩了”、“接口超时了”、“某人提交了脏数据”。
- 应对模式： 反应 (React) —— 也就是通常说的“救火”。
-
② 趋势与模式 (右上)： —— [表层 + 抽象]
- 定义： 把时间轴拉长，这些事件是否反复发生？有什么规律？
- 典型语言： “最近每逢大促都会超时” 、“每次某某人修改代码都会引入 Bug”。
- 应对模式： 预测 (Anticipate) —— 我们可以预判下次何时发生，但还没解决问题。
-
③ 系统结构 (左下)： —— [深层 + 具体]
- 定义： 是什么样的 可被工程化的机制、架构或流程设计，导致问题反复出现？
- 典型语言： “因为没有熔断机制”、“因为 Code Review 流程缺失”、“因为数据库索引设计不合理”。
- 应对模式： 设计 (Design) —— 这里是技术人最擅长的领域，通过改代码、改流程来解决。
-
④ 心智与原则 (右下)： —— [深层 + 抽象]
- 定义： 不是“写在文档里的规范”，而是 “为什么我们会写出这样的规范”
- 典型语言： “我们潜意识认为上线速度比质量重要”、“我们假设用户量永远不会超过 10 万”。
- 应对模式： 重塑 (Transform) —— 改变认知，从源头杜绝问题。
一个完美的复盘，就是从左上角的“事件”，通过纵向挖掘走到左下角，再通过横向抽象走到右下角的过程。
3. 纵向思维（深度）：从表层到深层
目标： 拒绝“环境论”，找到导致本次问题的 最根本 原因。
工具： 漏斗式思考法 (Filter & Drill)，正确的路径是：列举 -> 问“最”收敛 -> 问“为什么”下钻。
3.1 核心逻辑：用 “最 + 5 Whys” 穿透现象
3.2 案例演示：线上服务 OOM (内存溢出)
我们用一个 OOM 故障来演练这套逻辑。
【现象描述】
周五晚上 19:00，交易服务突然发出报警，JVM 内存溢出（OOM），服务重启。
第一轮：从现象到具体原因 (剥离干扰)
- 列举因素 (List)： 为什么会 OOM？
- A. 晚上 19:00 是流量高峰，请求量激增。
- B. 容器配置较低，只有 4GB 内存。
- C. 代码里有一个导出 Excel 的功能，一次性加载了大量数据。
- 问“最” (Ask The Most)： 哪个是最主要的原因？（如果解决了它，问题是否大概率消除？）
- 分析 A (流量)： 流量是业务增长的好事，系统应该承载流量，而不是怪流量。❌
- 分析 B (配置)： 其他同样的微服务也是 4GB，运行很稳定，说明 4GB 本身不是原罪。❌
- 分析 C (代码)： 如果不加载这么多数据，4GB 扛得住吗？扛得住。流量大能扛住吗？也能。
- 结论： C (代码一次性加载大对象) 是“最”核心的直接原因。
第二轮：从具体原因到系统结构 (寻找逻辑漏洞)
- 问“为什么” (Why)： 为什么代码会一次性加载这么多数据？
- 因为数据库查询没有做分页，直接
findAll或者 limit 很大。
- 因为数据库查询没有做分页，直接
- 问“最” (Ask The Most)： 为什么这行代码破坏力这么大？
- 因为这个表历史数据一直在增长，以前数据少没问题，现在数据量破 10 万了，全部加载就爆了。
- 结论 (结构层)： 缺乏对集合数量的限制机制 (Limit/Pagination) 是结构性缺陷。
第三轮：从系统结构到抽象心智 (挖掘根因)
- 问“为什么” (Why)： 为什么开发这段代码时，没有加分页限制？
- 开发人员说：“当时觉得这个表数据量不会很大。”
- 问“最” (Ask The Most)： 这种想法反映了什么深层问题？
- 是技术能力不行？不完全是。
- 是忘记了？可能是。
- 最本质的是： 开发人员做出了一个 “错误的假设”（假设数据量永远可控），且缺乏 “防御性编程” 的意识（即：无论数据量多少，系统都不能挂）。
- 结论 (心智层)： 团队缺乏“防御性编程”原则，过度依赖“理想情况假设”。
4. 横向思维（广度）：从具体到抽象
目标： 不要只修复这一个 Bug，要通过解决这一类问题，把经验变成团队资产。
工具： 三步归纳法 (Instance -> Pattern -> Principle)。
4.1 核心逻辑：用 “三步归纳法” 提取公因式
在技术领域，抽象 (Abstraction) 的本质就是 “提取公因式” 和 “去情境化”，我们需要进行三次 “变量替换”。
- 具体 (Concrete): 包含所有细节，不可迁移。例如：“修复了
UserService.java第 45 行的空指针异常。” - 抽象 (Abstract): 剥离了具体业务细节，只保留结构，可广泛复用。例如：“修复了一个由未经验证的外部输入导致的空指针问题。”
4.2 案例演示：继续用“OOM”案例
当我们找到了“没加分页”和“缺乏防御意识”的根因后，复盘并未结束，我们看看如何通过 横向移动，把一个具体的 OOM 故障，变成团队通用的技术资产。
Level 1: 具体实例 (The Concrete Instance)
现象： “周五晚上，导出 用户列表 时，因为 Excel 数据量超过 10 万条，导致 UserExportService 内存溢出。”
- 特征： 全是具体名词（用户列表、Excel、UserExportService、10 万条）。
- 局限： 只有负责用户模块的人会看一眼，负责订单模块的人觉得“雨我无瓜”。
Level 2: 归类 (Categorization) —— 动作：变量替换
思考方式： 把具体的名词替换为变量。
- “用户列表” --> “任意大数据集”
- “Excel” --> “I/O 传输”
- “UserExportService” --> “应用服务”
抽象描述： “应用服务在进行大数据集 I/O 传输时，因内存不足导致溢出。”
- 进步： 现在订单组的人开始听了，因为他们也有 I/O 传输。
Level 3: 模式识别 (Pattern Recognition) —— 动作：提取结构
思考方式： 这种事情的本质结构是什么？
这是一个典型的 “无界集合 (Unbounded Set)” 问题。即：我们在有限的容器（内存）里，放入了理论上无限的东西（数据库记录）。
抽象描述： “这是一个 无界集合加载 (Unbounded Collection Loading) 的模式问题。”
- 进步： 这不再是一个 Bug，而是一个 反模式 (Anti-Pattern)。
Level 4: 建立原则/模型 (Principle/Model) —— 动作：定立法则
思考方式： 针对这个模式，有没有放之四海而皆准的公理？
抽象原则： “资源有界性原则 (Resource Boundedness)” —— 任何涉及集合返回的接口，在设计时必须显式声明边界（Limit/Page/Batch）。
- 最终成果： 这一条被写入《团队 Java 开发规范》第一章。
5. 总结：完整的思考路径演示
现在，我们将之前的 “纵向挖掘” 和现在的 “横向抽象” 结合，就拥有了 完整上帝视角。以 OOM 案例为例，
| 步骤 | 思考方向 | 思考内容 | 产出物 |
|---|---|---|---|
| 0. 起点 | 💥 现象 | 导出用户列表导致 OOM。 | Bug 单 |
| 1. 纵向 | 👇 深挖 (Why) | 为什么？因为没有分页限制。为什么没限制？因为缺乏防御意识。 | 根因分析报告 |
| 2. 横向 | 👉 抽象 (Abstract) | 这不仅仅是用户表的问题，这是 “无界集合” 的通用问题。 | 架构设计原则 |
| 3. 结合 | 🏁 终局 | 未来所有 List 查询（横向范围），都要强制通过 Lint 工具检查是否包含 Limit（深层机制）。 | 自动化扫描工具 |
6. 落地话术 (Cheat Sheet)
为了让这套方法论落地，请大家在后续的复盘会、技术评审中使用以下“灵魂提问”：
👇 纵向挖掘（用来找根因）
-
当大家在争论环境/运气时：
“大家停一下。环境是客观的。我想知道，在现有环境下，导致问题的 ‘最’核心的代码逻辑 是什么？”
-
当大家找到直接原因（如没加分页）时：
“好，没加分页是直接原因。但 为什么我们的流程/机制允许‘没加分页’的代码上线？ 是 Review 漏了，还是根本没这个检查项？”
-
当最后总结时：
“这次修复不仅仅是改这几行代码。我们需要修正一个 认知：以后写任何 List 查询，脑子里都要弹出一个警报——‘如果没有 Limit，系统会不会挂？”
👉 横向抽象（用来定规范）
在技术分享或 Review 代码时，使用以下三个 “灵魂提问” 来强迫大脑进行抽象：
技巧一：剥洋葱法 (Context Stripping)
话术：
“如果我们把‘用户’这个业务属性去掉，把‘周五’这个时间去掉，这就变成了一个什么样的技术问题？”
- 效果： 引导大家关注代码结构，而不是业务逻辑。
技巧二：举三反一 (Rule of Three)
话术：
“除了用户导出，我们系统里还有哪些地方 也是‘一次性查全表’的？订单有没有？日志有没有？”
- 效果： 通过横向枚举，发现共性，从而定义模式。
技巧三：如果-那么 (If-Then Modeling)
话术：
“能不能总结一句话，以后遇到任何‘集合查询’，我们必须遵守什么规则？”
- 效果： 将经验固化为规则（Checklist）。
7. 结语
复盘不是为了追责，也不是为了写一份报告。复盘是为了 “在这个错误上只跌倒一次”，并让团队的所有人都能绕过这个坑。请大家运用好这个工具，让每一次故障都成为我们技术资产积累的台阶。