AWS工程师的反思：为何我坚持博客不用AI写
AWS工程师Marc Brooker明确声明博客全文由人工撰写，拒绝使用LLM生成文本以维护作者与读者的信任契约。他区分了代码与文字的使用场景：代码可完全由AI生成且关注属性而非可读性，但文字需体现深度理解。此外，他反对过度依赖LLM进行编辑，认为这会导致防御性写作，阻碍有效沟通。
Brooker
Brooker.co.za 个人博客。
评论
点赞
收藏为什么用户觉得你的服务很慢？——从“检查悖论”看延迟与故障恢复的真实体验
文章指出服务指标（如平均延迟或平均恢复时间MTTR）往往无法反映用户的真实体验，因为用户感知的是时间加权后的分布（即检查悖论）。长尾事件在用户的时间体验中占比更大，导致用户感知的平均等待或故障时间远高于系统统计的平均值。作者通过模拟示例说明，即使系统MTTR很短，用户实际经历的故障持续时间可能显著更长，强调了关注尾部延迟和恢复时间对用户感知的关键影响。
负载均衡系统中令人惊讶的经济学原理
文章通过排队论模型（M/M/c）分析负载均衡系统的延迟特性。核心发现是：随着服务器数量增加，在保持单服务器负载不变的情况下，请求的平均延迟会渐近地趋近于处理时间本身（即排队等待时间趋于零）。这意味着更大的集群规模能带来更低的延迟和更高的资源利用率，且这种改善在服务器数量较少时就已显著。作者指出这并非仅适用于超大规模服务，而是分布式系统中的一个普遍规律。
现在什么容易？什么困难：编程Agent眼中的软件易难反转
作者提出“反馈循环假说”，认为编程Agent的能力边界主要由反馈的有效性决定。与直觉相反，需要人类主观判断的UI/UX开发因反馈模糊而变难；而规范明确、可自动验证的系统软件（如数据库引擎）因拥有高效反馈闭环，未来对Agent而言反而更容易。文章强调构建自动化测试和形式化验证工具的重要性。
分布式系统不仅仅是为了扩展
文章反驳了“现代单机性能足够强大，无需分布式系统”的观点。作者指出，分布式系统的核心价值不仅在于扩展性（Scale），更在于可用性、数据持久性、资源利用率、降低尾部延迟、组件专业化、隔离性以及简化变更部署。文章强调，简单性是系统层面的属性，而非组件层面的。此外，分布式架构（如微服务）有助于降低组织内部的协调成本，从而支持团队规模的增长。最后提醒工程师应根据业务实际需求选择架构，避免盲目追随技术潮流。
是时候追求“正确”了：Agentic AI的瓶颈在于缺陷率而非能力
AWS工程师Marc Brooker提出假设：Agentic AI的机会大小将主要受限于缺陷率而非能力。文章通过缺陷频率和严重程度的四象限分析，指出低缺陷、低严重性的场景最具普及潜力。作者列举了AWS在Hydro、Cedar、Kiro等工具上的实践，强调构建正确性的重要性，并呼吁行业关注失败模式、建立更全面的基准测试，以及培养从失败中学习的文化，而非仅关注模型的最佳表现。
如何规划你的工作时间？
作者提出通过设定时间预算来解决忙碌但低效的问题。核心方法是将工作时间划分为几个主题（如编码、指导、战略、学习等），并长期严格执行。文章强调定期与管理者校准目标，学会拒绝无关请求，并警惕陷入日常琐事或无效会议。作者分享了个人实践案例，认为这种显性的时间规划能显著提升团队和个人的工作价值。
规范驱动开发并非瀑布流
作者针对“规范驱动开发（Spec Driven Development）是回归瀑布流”的常见误解进行澄清。核心观点指出，规范驱动并非在前期完成所有设计，而是将规范作为版本化、动态迭代的工件，位于实现的上游。与瀑布流不同，该方法论强调规范本身随反馈快速迭代，且特别适用于当前 AI Agent 自主开发的场景：明确的规范能为 AI 提供全局地图，使其能在无人工紧密干预下长期自主运行，从而显著提升交付速度和代码质量。作者认为这是软件工程抽象层级的又一次提升。
初级工程师的未来：从代码工匠到问题解决者
作者认为随着自动化接管编程技艺，初级工程师的优势在于保持初学者心态和快速适应力。传统的学徒式隔离训练正在失效，新人必须更早介入业务、经济和用户场景。核心建议是：尽早承担项目所有权，直接面对客户和现实约束，而非仅仅关注技术实现。这要求初级工程师在深入技术原理的同时，培养解决复杂现实问题的创造力。
我的经验法则错了，现在该怎么办？
文章指出资深工程师和领导者过去积累的经验法则（如关于维护性、API设计、服务边界等）在云原生、SSD、高速网络及新工具环境下已不再适用。作者建议技术领导者在面对这种“规则失效”时，应保持谦逊，承认部分认知过时，并通过亲自动手构建原型、使用新工具来重新验证假设，更新自己的经验常数。真正有价值的领导者是那些能结合好奇心与经验，主动保持思维新鲜度的人，而非固守旧观念者。
随机公平队列：一种简单高效的分布式系统隔离方案
本文深入分析了分布式系统中经典的随机公平队列（SFQ）算法及其变体。作者Marc Brooker指出传统SFQ虽能实现O(1)复杂度隔离噪音邻居，但存在哈希碰撞导致长期服务劣化的问题。为此，他提出结合洗牌分片（Shuffle Sharding）和“二选一”（Best-of-2）策略的新方案：将客户映射到多个队列子集，每次请求选择最短队列处理，并定期扰动映射关系。该方案在保持O(1)时间和空间复杂度的同时，显著增强了抗噪能力和负载均衡效果，为大规模系统架构设计提供了极具价值的工程实践思路。
代码只说它做了什么，没说它该做什么
文章指出代码只能表达实现细节，无法捕捉设计意图，导致维护困难。作者结合分布式系统开发经验，强调设计文档、注释和形式化规范（如TLA+）对于记录“为什么这样做”至关重要。这些文档能帮助团队在修改代码时区分哪些是核心逻辑，哪些是实现妥协，从而降低维护成本并提高系统长期可维护性。
站在十字路口：当编程成本归零，程序员的未来之路
作者认为编写代码和集成服务的成本已趋近于零，这引发了对程序员未来的两种思考。第一种是怀旧与失落，视编程为正在消逝的手艺，虽仍有乐趣但经济价值在下降，部分人会固守旧路。第二种是拥抱新机遇，利用强大的新工具解决遗留的系统性难题（如Amdahl定律中未加速的部分），或在新技术引入的新问题中寻找机会。作者预测，虽然具体方向难料，但软件行业的下半场将比上半场更具经济价值和智力挑战。
智能体安全的关键在于构建外部“隔离盒”
文章提出AI智能体的安全性不能仅靠内部提示词或对齐技术，因为智能体的核心价值在于其灵活性和创造性，这与严格约束相矛盾。作者主张在智能体外层构建一个确定性的、强制执行的“盒子”（如网关），通过外部策略层精确控制智能体能调用的工具和具体行为（如退款金额限制）。这种方式能确保无论智能体如何思考或生成内容，其实际执行的动作都在预设的安全边界内，从而解决侧效应带来的安全风险。
Pass@k 指标大多是误导性的
AWS工程师Marc Brooker指出，AI Agent评估中常用的Pass@k指标存在严重误导性。该指标计算k次尝试中至少成功一次的概率，具有指数级宽容度，容易让低成功率的任务看起来表现良好。作者强调人类用户对Agent的容错率极低，且多步任务要求每一步都成功，因此Pass@k在大多数实际场景中不适用，应谨慎使用或避免。
形式化方法只能解决我一半的问题
作者指出形式化方法（如TLA+）在分布式系统设计中主要解决安全性和活性问题，但无法回答延迟、成本、扩展性等性能指标。文章呼吁形式化验证社区与系统研究社区合作，开发能将形式化模型与仿真结合的工具，以支持更全面的定量设计分析。
为什么分布式系统中总是需要开启 TCP_NODELAY
文章指出在调试分布式系统延迟问题时，作者首先检查是否启用了 TCP_NODELAY。作者回顾了 Nagle 算法和延迟确认（Delayed ACK）的历史背景及其相互作用导致的性能问题，认为在现代数据中心硬件和网络环境下，Nagle 算法已不再必要。作者主张 TCP_NODELAY 应该成为默认设置，并鼓励开发者放心禁用 Nagle 算法以提升延迟敏感型系统的性能。
专为 SSD 设计的数据库长什么样？
作者基于 AWS Aurora DSQL 的工程实践，重新审视了为现代 NVMe SSD 和云网络设计的数据库架构。文章通过五个维度的量化分析得出结论：1. 缓存大小应根据内存与存储的成本比重新计算，而非单纯追求大缓存；2. I/O 传输大小应优化在 32kB 左右以平衡吞吐与 IOPS；3. 持久性应从单机 WAL 转向跨可用区的分布式日志复制；4. 利用高精度硬件时钟实现跨节点强一致性读；5. 核心关系模型和 ACID 特性应保留，但底层存储引擎和恢复机制需彻底重构以适应分布式环境。这是一篇结合理论（如五分钟法则）与一线工程数据的深度技术思考。
论“自然语言编程”的成功：编程即规格说明的循环
作者认为编程的本质正在从实现细节转向规格说明。针对自然语言模糊性的批评，作者指出软件开发本身就是一个通过对话和反馈循环来消除歧义的过程。LLM和Vibe Coding只是将这一过程自动化了。对于高精度要求的场景，可以通过神经符号方法结合人工审查来解决。核心观点是：未来的编程模式不是单次生成代码，而是基于自然语言的持续交互循环，这符合敏捷开发的核心理念。
究竟什么是可扩展性？
作者提出可扩展性的核心定义：在边际成本近似恒定的范围内，系统才是可扩展的。文章对比了单机、多机分片和服务端三种架构的成本曲线，指出单机和多机架构都存在因容量瓶颈导致的成本激增（阶梯状），而Serverless模式虽然消除了向上扩展的峰值，但引入了固定的成本底线。作者强调，真正的可扩展性不仅是技术架构问题，更是商业和单位经济学的问题，建议在设计系统时从整体成本视角评估扩展性。
为什么我们需要强一致性？
作者以AWS早期经历为例，指出最终一致性在分布式系统中给开发带来巨大痛苦。代码层面，读副本可能导致刚创建的资源显示不存在，迫使开发者写轮询逻辑，甚至引发死循环。业务层面，读写混合事务因数据延迟变得极难处理，削弱了读扩展的效果。文章介绍了Aurora DSQL如何通过时间戳机制实现所有读取的强一致性，从而让应用开发者无需关心底层复制延迟，简化了架构设计。
现在该怎么办？大规模系统中的错误处理哲学
文章以 Cloudflare 宕机事件中的 Rust unwrap 代码为引子，指出错误处理不是局部问题，而是取决于系统的整体架构和数据特性。作者提出了三个核心判断原则：故障是否关联、能否在高层处理、以及是否有意义地继续运行。他强调，对于配置类数据可以回退到上一版本，但对于数据库等强一致性场景，崩溃可能比静默继续更安全。最终结论是，正确的错误处理需要结合爆炸半径缩减技术（如 Shuffle Sharding），从设计之初就全局考虑。