可观测性的过去、现在与未来
本文信息来源：sherwoodcallaway
在我的上一篇文章 Round Two 中，我写到了我的职业生涯、我对开发者工具的热情，以及我决定创办一家专注于可观测性的新公司的原因。
我之前也写过自己对当今可观测性现状的沮丧。为什么这些工具和工作流如此糟糕？为什么感觉要花这么多精力 ？
在今天的文章中，我想通过将可观测性放在历史背景下来拆解这种沮丧。我将通过一个简单的三部分视角来审视可观测性：它的过去、现在和未来。
我的目标是理解并解释：
- 可观测性最初是如何出现的
- 可观测性是如何演变成今天这样一团乱的
- 为什么，尽管我们已经取得了如此多的进展，在 2026 年维护可靠的系统仍然如此之难
走起！
第一部分：可观测性的过去
要理解可观测性，回顾催生它的环境会很有帮助。
在 2010 年代初期，软件工程师面临一场危机：随着云计算、容器和微服务的兴起，应用变得越来越复杂——复杂到任何个人都无法完全理解。
与此同时，CI/CD 变得越来越普及，这意味着部署到生产环境的变更频率大幅提升。结果就是：bug 和故障发生得更加频繁。
我们的传统可靠性作战手册突然失效了。我们无法预测所有边缘场景，更不用说为它们编写测试。故障模式越来越多地源自服务之间复杂的相互作用。在进行根因分析时，日志和基础指标已经不再足够。
幸运的是，行业找到了一个解决方案。
它由两部分组成：一种工具和一种理念。
这种工具是分布式追踪。自 2010 年悄然起步后，分布式追踪在随后的十年中稳步发展，直到几乎无处不在：
- 2010：Google 发布了 Dapper，这是第一篇关于分布式追踪的重要论文。
- 2012 年：Twitter 推出了 Zipkin，灵感源自 Dapper。
- 2015 年：作为最早的托管式 tracing 平台之一，Honeycomb 成立。
- 2016 年：OpenTracing 被 CNCF 采纳。
- 2016 年：Uber 推出了 Jaeger，灵感源自 Zipkin。
- 2017 年：Datadog 推出了 APM，这是其托管的追踪解决方案。
- 2018 年：O’Reilly 出版了《分布式系统的可观测性》。
其核心理念是可观测性。“可观测性”一词最初由一位火箭科学家在 1960 年代提出，并在 2010 年代初期由 Twitter 的工程团队在软件社区中推广开来。它迅速发展成为一个成熟的产品类别和一门工程学科：
- 2013 年：Twitter 发布了《Twitter 的可观测性》。
- 2015 年：Charity Majors（Honeycomb 创始人）开始撰写关于可观测性的文章，正式化了关键概念。
- 2017 年：Peter Bourgon（曾参与 Prometheus 的 SoundCloud 工程师）提出了“三大支柱”。
- 2022 年：O’Reilly 出版了《Observability Engineering》。
总结而言，分布式追踪为工程师提供了一种调试现代应用的方法，这些应用天生基于云并且是分布式的；而可观测性则为他们在这种新的运行环境中思考可靠性提供了框架。
我想表达的是，可观测性并非凭空诞生。它是对现实世界工程挑战的响应。而且它之所以得以延续，是因为在大多数情况下，它确实行之有效。
但随后情况开始急转直下。在早期成果的鼓舞下，工程团队开始在可观测性工具和流程上过度投入。
更多的埋点。更多的仪表板。更多的监控。SLO。错误预算。运行手册。事后复盘。到 2020 年代初，可观测性不再只是达成目标的手段，而是本身变成了目标。
第二部分：可观测性的现状
如今，大多数工程师都会同意：可观测性只是基本门槛。如果你在几乎任何规模下运行生产系统，当问题发生时，你都需要一种方式来检测、缓解并解决它们。
这正是 Datadog、Grafana 和 Sentry 等现代可观测性平台所扮演的角色。
然而，当我思考当前的可观测性现状时，一个问题格外突出：为什么在为更好的工具和流程投入了 10 年以上之后，可观测性仍然这么糟糕？
我是认真的！
思考一下。
埋点需要耗费很长时间。仪表盘总是不断过时。监控频频误报。告警缺乏上下文。值班成为工程生产力的永久税负。事故解决可能需要数小时，有时甚至是数天。
我们的遥测数据比以往任何时候都多，但要在生产环境中形成对应用的准确心智模型仍然是一个重大挑战——不仅是对刚毕业的新人和沉迷氛围编程的 Z 世代而言如此，对经验丰富的工程师同样如此。
这并不是因为缺乏投入。在各种规模的公司中，工程团队都非常重视可观测性，投入了大量时间和精力来实现和维护可观测性系统。
他们为 Datadog 支付高昂费用。他们对一切进行埋点监控。他们采用结构化日志，并强制实施标准化的命名/标签规范。他们创建“黄金”仪表盘。他们精心调校监控项。按照任何合理的标准来看，这些团队都把该做的事情做对了。
然而，仍然存在一个缺口。
我们在可观测性上投入的努力，并未与我们在实现其目标上的进展相匹配：更好的检测能力、更快的根因分析，以及更可靠的应用。
为什么？
这是因为真正的问题不在于数据、工具或流程，而在于我们理解和推理我们已经拥有的数据的能力——或者说缺乏这种能力。
可观测性让我们非常擅长生成信号，但在随后的环节上仅略有提升：解读这些信号、生成洞察，并将这些洞察转化为可靠性。
第三部分：可观测性的未来
的确，可观测性并没有达到人们的预期。但这并不意味着它没有用或不重要。事实上，我相信，可观测性正蓄势待发，将成为未来十年中最重要的技术类别之一。
原因是：软件正在再次发生变化。
在 2010 年代，可观测性作为应对复杂性的解药而出现。到了 2026 年，软件工程师正面临我们有史以来遭遇的最大复杂性危机：AI。
AI 将编写代码的成本降至零。因此，工程团队正在以惊人的速度交付海量功能，代码库也变得越来越庞大。
与此同时，vibe-coding 平台将软件开发带给了大众。今年构建并部署的应用数量将超过以往所有年份的总和。
我们正站在“ 无限软件危机 ”的边缘。
这引出了一个令人不安的问题：我们将如何支持、维护和运营这座不断增长的软件之山？我敢打赌，答案是可观测性。
只是，并不是我们今天所拥有的这种版本……
