这篇文章反思了现代软件为什么在硬件飞速进步的时代反而变得臃肿缓慢。作者以 Java 组件启动 Spark 集群为例指出，工程师习惯性地给内存和 CPU 加上“以防万一”的缓冲，而这些临时补丁很快固化成了默认配置。JVM 会读取容器分配的空闲空间自动扩大堆大小，GC 也随之变得懒惰，资源就这样被浪费掉了。作者认为，硬件变得便宜且容易预配，让“加机器”成了解决问题的默认动作，但真正的问题在于——我们不再追问“这笔开销到底买了什么”。文章提出“资源预算”的思路：为每个组件设定明确的内存、启动时间、容器大小上限，一旦超限就必须解释具体换了什么、换来什么。核心不是让大家穷着过日子，而是让每个 trade-off 显式化，告别“迷信式分配”。推荐给所有在云上跑服务的后端工程师、SRE 和平台工程团队。
OpenTelemetry 正式发布 Blueprints 计划，旨在应对大规模可观测性部署中日益增长的复杂性。该计划提供面向常见场景的预设架构模式、运营最佳实践和分步实施指南，并配套由 Adobe、Mastodon、Skyscanner 等企业贡献的参考实现。文章剖析了可观测性的“必要复杂性”与“偶然复杂性”，指出组织在有机采用 OpenTelemetry 时常因缺乏集中标准而导致遥测管道碎片化、语义约定不一致及上下文传播断裂。Blueprints 不替代现有文档，而是将架构、运营和实现步骤整合为可复用的策略，重点关注 Kubernetes 可观测性、非 Kubernetes 基础设施检测和集中式遥测平台架构。此举标志着可观测性生态从纯模块化工具向更具指导性的运营框架转变，目标是在保持厂商中立与灵活性的同时，降低大规模运维的认知负荷。适合面临可观测性规模化挑战的平台工程、DevOps 和 SRE 团队阅读。