《怎样解题》与《系统之美》读书笔记：点状的 bug 用四步法，反复发作的病用反馈回路

Mon, 05 Sep 2022 10:00:00 +0800

《怎样解题》与《系统之美》读书笔记：点状的 bug 用四步法，反复发作的病用反馈回路

这是逻辑思维书单合读笔记的第二篇（第一篇：《〈学会提问〉与〈金字塔原理〉》，总纲见《程序员逻辑思维训练手册》）。
这两本放在一起读，因为它们恰好覆盖程序员面对的两类问题：
《怎样解题》管「点状问题」——一个 bug、一道算法题、一次明确的优化；《系统之美》管「系统问题」——为什么同类的坑换个姿势反复出现。

flowchart LR
    Q["问题来了"] --> A{"第一次见？"}
    A -->|"是 点状问题"| P["《怎样解题》<br/>四步解题法<br/>弄清→计划→执行→回顾"]
    A -->|"不 换个姿势<br/>反复出现"| S["《系统之美》<br/>存量流量 + 反馈回路<br/>找结构 不找替罪羊"]
    style P fill:#e8f4e8
    style S fill:#e8f4e8

这个分流判断本身就是两本书合读的最大收获：一个 bug 修三次还没死，它就不是 bug 了，是系统结构在持续生产 bug。

上篇《怎样解题》：波利亚的四步，就是 debug 的标准流程

1. 全书骨架：四步 + 启发法工具箱

波利亚 1945 年写的这本小书，名义上教解数学题，实际上教的是「面对任何陌生问题时的元流程」：

flowchart TD
    S1["第一步 弄清问题<br/>未知量是什么？<br/>已知条件是什么？<br/>条件够用吗？有矛盾吗？"] --> S2["第二步 拟定计划<br/>见过类似的问题吗？<br/>能倒推吗？能简化吗？<br/>能画个图吗？"]
    S2 --> S3["第三步 执行计划<br/>每一步都检查<br/>我能看出这步是对的"]
    S3 --> S4["第四步 回顾<br/>能验证结果吗？<br/>方法能用到别处吗？<br/>这题教会我什么？"]
    S4 -.->|"回顾的产出<br/>变成下次的经验"| S2

映射到 debug 上严丝合缝：弄清问题 = 精确复现现象；拟定计划 = 假设与验证路径；执行 = 二分定位；回顾 = 写复盘、沉淀 checklist。四步里最反常识的是：波利亚认为第四步「回顾」才是能力增长的唯一来源——题解完就走人，等于白做。

2. 启发法工具箱（书中最实用的部分）

倒推法：从期望的结果往回推「要达到它，上一步必须是什么」
特殊化：先解一个简化版（数据量从 1000 万缩到 10 条，并发从 1000 缩到 2）
类比：「这和哪个我解决过的问题像？」
重新表述：换一组词描述问题，经常一换就通

3. 踩坑故事

踩坑故事 #1：没弄清问题就动手，优化了错的接口。 产品反馈「首页慢」，我凭直觉认为是商品列表查询慢，花两天给列表接口加索引、上缓存，上线后首页还是慢。最后用 APM 工具一拉调用链：慢在首页首屏的个性化推荐接口，列表接口根本不是瓶颈。波利亚第一步的原话是「弄懂问题比解决问题更花时间，而这时间是值得的」。我跳过第一步省下的半小时，用两天的无效劳动还了债。

踩坑故事 #2：跳过「回顾」，同一个坑摔两次。 一个时区 bug：存入用本地时间、读出按 UTC 解析，差了 8 小时。修完发版，谁都没写复盘。三个月后另一个同事在另一个模块踩了一模一样的坑——因为第一次修复时没有任何沉淀，知识只存在于当时的聊天记录里。现在团队的规矩：bug 修复的 PR 描述里必须有一节「回顾」：根因一句话、为什么防线没拦住、同类问题怎么预防。 没有这一节，CR 不予通过。

踩坑故事 #3：不会特殊化，在 1000 万数据里捞针。 排查一个「偶发数据错乱」，我盯着生产日志看了半天毫无头绪。带教我的老同事只做了一件事：把并发从 500 缩到 2，把数据缩到 10 条，在本地用脚本循环触发——二十分钟后稳定复现，是个竞态条件。特殊化不是「缩小问题的怂办法」，是把信噪比从 1:10000 拉到 1:1 的工程手段。最小复现 demo 的价值，怎么强调都不过分。

踩坑故事 #4：倒推法救了一次订单状态机改造。 订单状态迁移改造，正着推「从待支付出发能到哪」越推越乱。换成倒推——从终态「已完成/已关闭」往回推「谁有资格流转进来」，状态机的约束条件一次就清晰了。波利亚说的倒推，在状态机、数据血缘、接口依赖分析里屡试不爽。

4. 实践方法论：两份可抄的模板

模板 A：debug 四步卡（贴在工位）

【弄清问题】现象是什么？期望 vs 实际，精确到字段/时间/用户。
          100% 复现还是偶发？偶发的触发条件有什么共性？
【拟定计划】假设是什么？（写下来！）怎么证伪？
          能缩小范围吗？（二分 / 缩数据量 / 缩并发）能倒推吗？
【执行计划】每一步验证都记录，不许「改一下试试」。
【回顾】根因一句话。为什么防线没拦住？同类问题 checklist +1。

模板 B：算法题/技术方案四步（同理可套，重点是把「回顾」写成题解/方案文档的固定一节）

思考与感悟之一：波利亚这本书最让我震动的是它对「聪明」的祛魅。会解题的人不是脑回路不同，而是手里有一套启发法清单，在卡住的时候逐条试。卡住时不是「我不行」，是「我的清单还没试完」。清单可以学，天赋不能学——这对自评「逻辑弱」的人是最大的好消息。

下篇《系统之美》：别找替罪羊，找结构

1. 全书骨架：存量、流量、反馈回路

梅多斯的这本书只给你三个概念，但这三个概念能解释线上事故的半壁江山：

flowchart TD
    subgraph 基础["两个基础概念"]
        ST["存量 Stock<br/>池子里的水：队列长度<br/>连接数 在途订单 技术债"]
        FL["流量 Flow<br/>水位变化率：请求速率<br/>消费速率 需求涌入速度"]
        FL -->|流入/流出| ST
    end
    subgraph 回路["两种反馈回路"]
        B["调节回路<br/>让系统回到目标<br/>如: 自动扩容 限流"]
        R["增强回路<br/>自我强化 滚雪球<br/>如: 重试风暴 谣言传播"]
    end
    D["时延 Delay<br/>反馈总是迟到的<br/>多数振荡的元凶"] -.-> B
    D -.-> R

一句话版本：看任何系统，先问「池子（存量）是什么、进出水管（流量）多粗、有没有回路、反馈迟到多久」。 时延是隐藏主角——调节回路配上长时延，就会从「稳定器」变成「振荡器」。

2. 踩坑故事：三个概念解释三个事故

踩坑故事 #5：重试风暴——增强回路的教科书。 下游服务响应变慢，我们的客户端配置是「超时 3 秒，失败重试 3 次」。下游越慢 → 超时越多 → 重试越多 → 下游请求量放大 4 倍 → 更慢。典型的增强回路，三十分钟内把一个「有点慢」滚成了「全站挂」。解法书上写得明白：增强回路必须靠回路外的力量打断——我们加了熔断（连续失败直接拒绝）+ 指数退避 + 重试预算（每分钟最多重试 N 次），等于在回路上装了一个「断路器」。没读过这本书之前，我们的复盘结论写的是「下游不稳定，下次注意」——注意是没用的，结构不改变，回路下次照样滚起来。

踩坑故事 #6：缓存雪崩——调节回路被同时失效。 一批缓存 key 设了同样的 TTL，凌晨同一时间集体过期，请求全部打到数据库；数据库变慢 → 请求堆积（存量暴涨）→ 连接池耗尽 → 更多超时。本应是调节回路的「数据库兜底」在流量尖峰面前完全失效。解法是给 TTL 加随机抖动（错开过期时间）+ 热点 key 永不过期用异步刷新 + 数据库前加请求合并。教训：凡是「大家一起同时做同一件事」的设计，都是定时引爆的雪崩——TTL、定时任务、证书过期，全都要加抖动。

踩坑故事 #7：告警阈值节节高——目标侵蚀回路。 某接口错误率告警最初定在 0.1%，老是误报，调成 0.5%；又吵，调成 1%……半年后错误率日常 0.8%，没人觉得有问题，直到一次资损复盘才发现它早就烂了。这是书中「目标侵蚀」陷阱的标准形态：系统表现差 → 下调标准 → 表现更差 → 再下调，温水煮青蛙。对策：阈值变更必须走评审并记录理由，且只允许绑定到「误报率治理动作」上，不允许单独上调。

踩坑故事 #8：加机器治不了慢查询——杠杆点选错。 接口变慢，第一反应是扩容。机器翻倍，延迟纹丝不动——因为瓶颈是一条全表扫描的 SQL，流量（请求）再大，存量（未优化的工作单元）处理能力没变。书中最反直觉的一章是「杠杆点」：在错误的地方用力，越努力越糟。扩容改的是流量侧的参数，建索引改的是系统结构——后者才是杠杆点。

3. 实践方法论：系统问题分析清单

遇到「反复发作」的问题，别急着修，先画一张图：

存量是什么？（队列、连接数、在途任务、技术债——先找到那个「池子」）
进/出流量各由什么决定？（谁往里灌？谁在消费？瓶颈在哪一侧？）
有没有增强回路？（A 导致更多 A？——重试、挤兑、恐慌都算）
调节回路为什么失效了？（兜底被打穿？阈值被侵蚀？容量跟不上？）
反馈时延有多长？（监控多久才发现？扩容多久才生效？）
如果只能改一处，改参数、改结构、还是改目标？（杠杆点从大到小：目标 > 结构 > 参数）

思考与感悟之二：读完这本书我改了一个用词习惯——复盘时不再说「谁的问题」，改说「什么结构持续产生这个问题」。个人的失误是一次性的，结构的缺陷是生产性的：不重试风暴的锅给「下游不稳定」，下次换个下游照样风暴。把「人」换成「回路」，复盘才真正开始有产出。

合读：什么时候用哪本

flowchart TD
    P["问题出现"] --> F["先走波利亚四步<br/>弄清→计划→执行→回顾"]
    F --> R{"回顾时问:<br/>这类问题出现过几次？"}
    R -->|"第一次"| D["修完收工<br/>checklist +1"]
    R -->|"三次以上"| S["切换《系统之美》<br/>画存量流量图 找回路<br/>改结构 不是改人"]
    style S fill:#e8f4e8

两本书的分工一句话说清：波利亚教你把单个问题解干净，梅多斯教你看出哪些问题根本不是「单个」的。「回顾」这一步恰好是两本书的接口——波利亚让你在回顾时问「这题教会我什么」，系统之美接着问「这类题为什么总出现」。

思考与感悟之三（收尾）：程序员的成长里有个隐形分水岭——从「解决问题的人」变成「改造产生问题的系统的人」。波利亚的书把你送到分水岭，梅多斯的书带你翻过去。翻过去之后你会发现，最好的修复往往不在代码里：一个加了抖动的 TTL、一个装在回路上的熔断器、一份不许跳过的回顾模板。

附：落地清单（贴工位版）

《怎样解题》侧——解单个问题时：

问题弄清了吗？（期望 vs 实际，精确到可复现）
假设写下来了吗？验证方式写下来了吗？
卡住了？试启发法清单：倒推 / 特殊化 / 类比 / 重新表述
回顾写了吗？（根因一句话 + 防线为什么没拦住 + checklist +1）

《系统之美》侧——问题反复发作时：

池子（存量）找到了吗？
有增强回路吗？断路器装在哪？
调节回路为什么失效？
反馈时延多长？振荡是时延造成的吗？
我在改参数、改结构，还是改目标？（别在参数层用力过猛）

怎样解题 on 方糖猫Blog

《怎样解题》与《系统之美》读书笔记：点状的 bug 用四步法，反复发作的病用反馈回路

《怎样解题》与《系统之美》读书笔记：点状的 bug 用四步法，反复发作的病用反馈回路

上篇 《怎样解题》：波利亚的四步，就是 debug 的标准流程

1. 全书骨架：四步 + 启发法工具箱

2. 启发法工具箱（书中最实用的部分）

3. 踩坑故事

4. 实践方法论：两份可抄的模板

下篇 《系统之美》：别找替罪羊，找结构

1. 全书骨架：存量、流量、反馈回路

2. 踩坑故事：三个概念解释三个事故

3. 实践方法论：系统问题分析清单

合读：什么时候用哪本

附：落地清单（贴工位版）

上篇《怎样解题》：波利亚的四步，就是 debug 的标准流程

下篇《系统之美》：别找替罪羊，找结构