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

> Honeycomb 这本书教你向数据提问，而不是找资历最老的工程师；买前先看版本，第二版篇幅翻倍。

原文: https://fdetimes.net/zh/books-courses/observability-engineering-book-review/

设想一个客户反馈“系统太慢了”。仪表盘一片绿，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”，不如描述一次具体经历：你用结构化事件给某个流程埋点，把慢请求拎出来并找到原因。一个具体的故事比一串工具名更能体现你的思考方式。

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

**本周动手试试:**

- 在你支持的系统里挑一个慢端点，列出每个请求都应携带的字段（构建版本、客户、区域、处理时间），检查现有日志里是否都有。
- 买书之前，先读 Honeycomb 的 Authors' Cut 系列，从核心分析循环那部分开始。
- 为客户最关心的那一个流程写一条 SLO，然后基于这条 SLO 告警，而不是基于 CPU。

## 信源

- [Observability Engineering: Achieving Production Excellence (Goodreads)](https://www.goodreads.com/book/show/61046909)

- [Observability Engineering (Bookshare)](https://bookshare.org/browse/book/6423904)

- [Honeycomb’s O’Reilly Book Observability Engineering, 2nd Ed.](https://www.honeycomb.io/oreilly-observability-engineering)

- [Honeycomb’s O’Reilly Book Observability Engineering, 2nd Ed.](https://www.honeycomb.io/observability-engineering-oreilly-book)

- [Authors' Cut Spark Notes Edition: Jumpstart Your Observability Journey](https://www.honeycomb.io/blog/authors-cut-spark-notes-edition)

- [Structured Events Are The Basis of Observability | Honeycomb](https://www.honeycomb.io/blog/structured-events-are-the-basis-of-observability)

- [【書評】オブザーバビリティ・エンジニアリング | DevelopersIO](https://dev.classmethod.jp/articles/book-review-observabilityengineering/)