可观测性的过去、现在和未来
Source: Hacker News
2026年1月5日
在我的上一篇文章《Round Two》中，我写到了我的职业生涯、对开发工具的热情，以及决定创办一家专注于可观测性的公司。
我还写到了我对当前可观测性的沮丧。为什么工具和工作流如此糟糕？为什么感觉要做很多工作？
在今天的文章中，我想通过历史视角来剖析这种沮丧。我将通过一个简单的三部分视角来审视可观测性：它的过去、现在和未来。
我的目标是理解并解释：
- 可观测性最初出现的原因
- 可观测性如何演变成今天的混乱局面
- 为什么即使我们已经取得了所有进展，2026 年仍然如此难以维护可靠的系统
让我们开始吧！
PART 1: OBSERVABILITY’S PAST
要理解可观测性，先回顾一下促成它出现的环境。
在 2010 年代初，软件工程师面临一场危机：随着云计算、容器和微服务的兴起，应用变得日益复杂——复杂到任何个人都难以完全掌握。
与此同时，CI/CD 越来越普及，这意味着变更部署到生产环境的速度加快。结果是：故障和宕机更频繁。
我们的旧可靠性手册突然失效。我们无法预测所有边缘情况，更别说为它们编写测试了。故障模式越来越多地来源于服务之间的复杂交互。进行根因分析时，日志和基础指标已经不够用了。
幸运的是，业界找到了答案。它分为两部分：工具 和 理念。
工具：分布式追踪
在 2010 年悄然起步后，分布式追踪在接下来的十年里稳步发展，最终几乎无处不在：
- 2010 – Google 发布 Dapper，首篇关于分布式追踪的重量级论文。
- 2012 – Twitter 推出 Zipkin，受 Dapper 启发。
- 2015 – Honeycomb 成立，成为首批托管追踪平台之一。
- 2016 – OpenTracing 被 CNCF 采纳。
- 2016 – Uber 推出 Jaeger，受 Zipkin 启发。
- 2017 – Datadog 发布 APM，其托管追踪解决方案。
- 2018 – O’Reilly 出版 Distributed Systems Observability。
理念：可观测性
“可观测性”一词最初由 1960 年代的火箭科学家提出，随后在 2010 年代初被 Twitter 的工程团队在软件社区中推广。它迅速发展为完整的产品类别和工程学科：
- 2013 – Twitter 发布《Observability at Twitter》。
- 2015 – Charity Majors（Honeycomb 创始人）开始撰写可观测性相关内容，正式化关键概念。
- 2017 – Peter Bourgon（曾在 SoundCloud 工作并参与 Prometheus）提出“三大支柱”。
- 2022 – O’Reilly 出版 Observability Engineering。
总结，分布式追踪为工程师提供了调试现代云原生应用的方法，而可观测性则为他们在这种新运行环境中思考可靠性提供了框架。
我的观点是，可观测性并非凭空出现。它是对真实工程挑战的回应，并且在大多数情况下能够奏效，所以得以持续发展。
但随后情况恶化了。早期的成功鼓励了工程团队在可观测性工具和流程上过度投入：
- 更多的仪器化
- 更多的仪表盘
- 更多的监控、SLO、错误预算
- 运行手册、事后分析
到 2020 年代初，可观测性不再是达成目标的手段，而变成了目标本身。
PART 2: OBSERVABILITY’S PRESENT
今天，大多数工程师都会认同：可观测性已成为基本要求。如果你在几乎任何规模上运行生产系统，都需要一种在问题发生时检测、缓解和解决问题的方式。
这正是现代可观测性平台（如 Datadog、Grafana 和 Sentry）的作用。
然而，当我思考可观测性的现状时，有一个问题格外突出：在投入了十多年改进工具和流程之后，为什么可观测性仍然糟糕？ 我是认真的！
症状
- 仪器化耗时极长。
- 仪表盘经常过时。
- 监控误报。
- 警报缺乏上下文。
- 值班成为对工程生产力的永久性税负。
- 事故解决可能需要数小时，有时甚至数天。
我们拥有比以往更多的遥测数据，但要在生产环境中获得准确的应用心理模型仍是一个重大挑战——这不仅对新毕业生和“随性编码”的年轻人是难题，对有经验的工程师同样如此。
这并非因为缺乏努力。各类公司都非常重视可观测性，投入大量时间和精力来实现和维护可观测性系统：
- 为 Datadog 花钱。
- 对 所有 内容进行仪器化。
- 采用结构化日志并强制执行标准化的命名/标签约定。
- 创建 “黄金” 仪表盘。
- 精心调校监控规则。
按任何合理的定义，这些团队都在做正确的事。
差距
我们在可观测性上投入的努力 并未 与我们在实现其目标方面取得的进展相匹配：更好的检测、更快的根因分析以及更可靠的应用。
为什么？ 因为真正的问题不在于数据、工具或流程，而在于我们对已经拥有的数据的理解和推理能力——或者说缺乏这种能力。
可观测性让我们非常擅长产生信号，但在随后要做的事上仅稍有提升：解释这些信号、生成洞察，并将洞察转化为可靠性。
第三部分：可观测性的未来
的确，可观测性并未达到预期。但这并不意味着它没有用或不重要。事实上，我相信可观测性有望成为未来十年最重要的技术类别之一。
… (the rest of the future section continues)
End of cleaned markdown segment.
原因
软件再次在变化。
在 2010 年代，可观测性出现，成为应对复杂性的解药。到了 2026 年，软件工程师面临有史以来最大的复杂性危机：AI。
AI 正在把编写代码的成本降至零。因此，工程团队正以惊人的速度交付海量功能，代码库也越来越庞大。
与此同时，vibe‑coding 平台让软件开发走向大众。今年将构建和部署的应用数量将超过所有往年之和。
我们正站在一个“无限软件危机”的边缘。
这提出了一个令人不安的问题：我们将如何支持、维护和运营这座日益庞大的软件山？我敢打赌答案是可观测性——只不过不是我们今天所拥有的版本……