仪表盘全绿、用户却还在等时，该读这本书

设想一个客户反馈“系统太慢了”。仪表盘一片绿，CPU 也正常，终端用户却还在等。这时很多团队会去找资历最老的工程师，因为只有他“懂这个系统”。

Observability Engineering: Achieving Production Excellence 正是为了打破这种习惯而写。三位作者 Charity Majors、Liz Fong-Jones 和 George Miranda 都来自 Honeycomb；O’Reilly Media 于 2022 年 5 月 6 日出版了第一版。如果你的工作是进入一个陌生系统，在几天内查出它为什么慢，这本书值得一读。

这本书讲什么，该读哪一版？

Goodreads 的概括很简短：可观测性是构建、运行和改进复杂的关键业务系统的前提。根据作者自己撰写的系列摘要，各组章节围绕结构化事件、排查用的分析循环、基于 SLO 的告警以及整个团队的协作方式展开。

购买前需要知道一点：Honeycomb 已宣布推出第二版，内容几乎全部重写，篇幅翻倍，新增 27 个全新章节。

第二版增加了面向技术决策者的可观测性治理部分，作者阵容也有变化，加入了 OpenTelemetry 联合创始人 Austin Parker。公告没有给出第二版的发布日期，下单前请先确认在售的是哪一版。

下文的章节编号以第一版为准，因为作者的摘要系列基于第一版。如果你买的是第二版，章节编号会不同。

如果暂时不打算买书，有一条捷径。Honeycomb 博客上的“Authors’ Cut”系列把每组章节的核心概念提炼出来，用更易读的方式重写。这些文章不按章节顺序排列，你可以只挑自己需要的部分。

观点一：每个请求都应讲清自己的经历

全书的基础是结构化事件。在一次关于本书的演讲中，Honeycomb 介绍了如何把结构化事件串联起来，通过分布式追踪跟踪一个请求，从而看清各组件之间的依赖关系。

以一个零售客户的结账流程为例。每个请求都输出一个事件，带上端点、客户 ID、区域、构建版本、所调用数据库的名称和处理时间。“checkout ok, 2300ms”这样的日志只能告诉你它慢了；字段足够的事件则能告诉你慢在哪里、对谁慢。

这一阶段最常见的错误是埋点字段太少。如果结账事件缺少构建版本或客户 ID，之后无论数据多少，都无法按这两个维度拆分慢请求。第二个错误是只记录错误、忽略成功的请求，而客户抱怨的恰恰是那些“成功但很慢”的请求。

因此，到客户现场后的第一件事，是重读一个慢请求的日志，问自己：这些数据足以把慢请求和正常请求区分开吗？如果不够，先修好埋点，再考虑优化。

观点二：靠假设排查，而不是靠记忆

第 8、15、16 章讲核心分析循环，以及工具该自建还是采购。对于“为什么慢”这个问题，这是全书最有价值的部分。作者称这个循环是一种强大且很多人都能上手的工具。

套用到结账的例子：先把慢请求单独拎出来，和正常请求放在一起对比，找出差异明显的字段。

也许所有慢请求都跑在新构建上，也许它们都来自同一个购物车特别大的客户。这时假设来自数据，可以用下一次查询去验证，而不是依赖某人对上次事故的记忆。

日本 Classmethod 的一位工程师在书评中认为，这本书最大的好处是让团队排查问题时不必依赖那些被比作“活字典”的工程师。

这位评论者也明确指出，本书并不否定传统监控。当系统的复杂度和规模开始超出监控能应对的范围时，它提供了一种新的方法。

观点三：告警要针对客户真正关心的事

第 12、13 章讲基于 SLO 的告警。作者的摘要提到，这种方法能帮助团队优先响应对客户和业务最重要的事。对 FDE 来说，这一点非常实际：客户关心的是订单能否顺利完成，而不是 CPU 是否到了 80%。

这也是交付时第三个常见错误：把告警设在 CPU 或内存上。在结账的例子里，CPU 可能一直很低，请求却在等一条很慢的数据库查询，于是值班工程师收不到任何告警，客户却已经感觉到变慢。

书中还指出，推行可观测性不只是给应用埋点，还关乎整个团队如何协作。所以交付时，你留给客户的还应有一种习惯：SLO 写成文档，告警与这些 SLO 挂钩，每个值班的人都知道如何向数据提问。

谁该读，按什么顺序读？

如果你是前线部署工程师（FDE），或者是希望转做 FDE 的后端工程师，先读结构化事件和链路追踪部分，再读核心分析循环，最后读 SLO。第二版的治理部分适合需要说服客户管理层投资工具的人。

求职方面，如果你瞄准的岗位描述提到 OpenTelemetry、分布式追踪或 SLO，应优先复习这几章。

写简历时，与其只写“使用过 Grafana”，不如描述一次具体经历：你用结构化事件给某个流程埋点，把慢请求拎出来并找到原因。一个具体的故事比一串工具名更能体现你的思考方式。

下次客户说“太慢了”，你不必是在场最了解这个系统的人，而应是最知道该向数据问什么的人。