题记与说明
标题：Notes on Distributed Systems for Young Bloods
作者：Jeff Hodges（博客 Something Similar）
来源 URL：https://www.somethingsimilar.com/2013/01/14/notes-on-distributed-systems-for-young-bloods/
存档日期：2026-11-03
标签：分布式系统 / 可靠性工程 / 可观测性 / Agent 编排 / 技术写作
这篇讲什么
Jeff Hodges 2013 年写给他想象中"刚入行的分布式系统工程师"的经验清单，共 18 条军规，全部来自生产环境的伤疤而非教科书。开头他就声明：CAP 定理和分布式谬论太抽象，新人需要的是"direct, actionable advice"。文章结尾注明 2016-08-15 作者回填了每节的锚点并修订了协调、数据本地性、feature flag 和背压几节——13 年后仍在维护，足见其生命力。
核心观点
分布式系统区别于单机编程的，不是延迟，而是失败的概率——尤其是部分失败（partial failure）的概率：一台机器的写成功、另一台失败，一致性就碎了。围绕这个事实，全篇展开一组可执行的原则：能不协调就不协调（协调是万恶之源）；全链路实现背压，否则就是级联失败或静默丢消息；主动设计"部分可用"（宁可让一小部分用户完全不可用，也别让所有用户丢数据）；指标是唯一能跨越"你以为系统在做什么"和"它实际在做什么"之间鸿沟的东西，日志会说谎；默认用百分位数（50/99/99.9/99.99）而非平均值——他从未见过延迟服从钟形曲线的系统；基础设施切换用 feature flag 灰度推进，拒绝"大切换"；以及那条带着私人恨意的：把缓存数据写回持久存储是坏的，会让用户名、邮箱、密码哈希"神秘回滚"。
最值得记住的句子
- "What sets distributed systems engineering apart is the probability of failure and, worse, the probability of partial failure." —— 区分这个领域的不是延迟，是部分失败的概率。
- ""It's slow" is the hardest problem you'll ever debug." —— "它变慢了"是你会调试的最难的问题，因为问题陈述里没有任何定位线索。
- "You're not Sherlock unless the metrics or the experiments back up the story." —— 没有指标背书，你从日志里推理出的就不是福尔摩斯，是脑补。
对我的启发
对 Agent 系统最直接：多 Agent 编排本质上就是一个分布式系统——子 Agent 超时、工具调用部分成功、重试导致重复写入，全都是 partial failure 的变体。背压（丢弃或快速失败+指数退避）、部分可用（降级返回部分结果）、feature flag 式灰度切换，可以直接搬进 Agent 工程的可靠性设计。观察 Agent 行为也一样：靠结构化指标，别靠翻日志当福尔摩斯。对知识管理和写作：这篇文章本身就是范本——把事故提炼成"一句断言+一段证据"的清单，每条独立成锚、可单独引用，比长篇综述更耐时间和更可复述。
适合谁读
刚从单机编程跨入多机世界的后端/基础设施工程师；正在做 LLM Agent 编排、需要处理工具调用失败与重试语义的人；以及所有想要一份"不抽象、可执行"的分布式入门第一课的读者。它和 Lamport 的论文构成互补：Lamport 给你理论深度，这篇给你战壕里的常识。