没有人再知道发生了什么
Source: Dev.to
介绍
我们拥有前所未有的可观测性。那为什么每一次事故仍然以混乱开始？
上周二下午 2:47，我们的 API 延迟飙升。
这不是小幅波动——而是一次让整个团队警醒的激增。
我们拥有你们预期的一切：
- Grafana 仪表盘显示延迟增加
- Datadog 跟踪指向慢速数据库查询
- CloudWatch 指标显示 CPU 和内存正常
- PagerDuty 在错误率上触发警报
- Slack 被图表和截图塞满
让我惊讶的不是事故的发生。
而是 每个工具都按设计完美运行，但我们仍然无法回答唯一重要的问题：
到底发生了什么？
我花了大约 18 分钟才拼凑出一个部署改变了我们批处理请求的方式。这稍微增加了每个请求的延迟，触发了重试逻辑，进而导致数据库被大量重复查询冲击。
数据全部在那儿，只是我看不出其中的故事。
我们解决了错误的问题
在过去的十年里，可观测性工具在数据收集和可视化方面变得非常出色。
- 你几乎可以对任何东西进行仪表化。
- 你几乎可以绘制所有内容的图表。
- 你可以追踪跨整个分布式系统的请求。
但我们基本上止步于此。
我们构建了能够回答以下问题的工具：
“这个指标在做什么？”
但没有：
“实际发生了什么？”
这两个问题不同。
- 第一个是一个 数据问题。
- 第二个是一个 推理问题。
Source: …
我们实际调试事故的方式
下面是事故响应在实际中的常见做法。
-
打开若干浏览器标签页：Grafana、Datadog、日志、云控制台、你的服务仪表盘，甚至是几个月前某人创建、从未更新过的笔记本。
-
开始提问：
- 最近有什么改动？
- 这是什么时候开始的？
- 同一时间段还有什么其他改动？
- 这些事情可能有什么关联？
你并不是在阅读指标，而是 从碎片中重建叙事。
“部署在 2:30 进行……延迟在 2:32 跳升……是哪项服务……那次部署改了什么……是否影响了重试……等等，重试量明显高于正常水平……”
这才是事故响应的真实认知工作：把图表转化为理解，而不是单纯地阅读图表。
Source: …
歧义问题
让人难以判断的是，同样的信号可以支持截然不同的解释。
想象你观察到：
- 14:30 进行一次部署
- 14:32 延迟开始上升
- 随后错误率上升
- 重试量激增
- 基础设施指标保持正常
到底发生了什么？
故事 1
部署引入了一个 bug。延迟因代码错误而上升，随后出现错误。回滚。
故事 2
延迟触发了重试，进而放大了下游负载。基础设施并未耗尽，但重试放大导致间歇性故障。调整重试行为。
故事 3
部署改变了请求特性，导致模型服务层的有效吞吐量下降。你不是 CPU 受限，而是吞吐受限。修复批处理或预热行为。
相同的数据。不同的视角。不同的解决方案。
区别不在于信号本身，而在于提出的问题。
我正在探索的内容
我已经思考这件事有一段时间了——不仅仅是这一次的事件，而是背后的模式。
我们一直期待人在事故发生时在脑中进行叙事构建。这样既费时又容易出错，且随着系统变得更加分布式，这种做法会变得更加困难。
如果把“把信号转化为叙事”当作一个工程问题来处理会怎样？
这并不是要取代人的判断，而是帮助完成一些繁重的工作：
- 识别时间上的关联
- 建议可能的因果关系
- 展示多种合理的解释
- 将歧义明确化
我把这次探索称为 Coherence。
目前还没有成熟的工具，这只是早期的想法。我还不知道这是否能干净利落地实现，亦或在真实世界的噪声中就会崩溃。这种不确定性正是我感兴趣的原因。
为什么这可能是个坏主意
这里确实存在真实的风险。
- 它可能会产生错误的自信。 生成的叙述即使错误，也可能听起来权威。
- 它可能会隐藏重要细节。 任何形式的摘要都会丢失信息——有时恰恰是最关键的信息。
- 它可能在解决错误的问题。 也许真正的问题不是解释，而是我们的系统本身过于复杂，根本无法彻底理解。
- 人们可能不信任它。 当你在调试生产事故时，依赖自动化解释是一个很大的跨越。
我对这些担忧没有明确的答案。
为什么我仍然认为值得探索
因为当前的方法——把一堆数据交给人类，并要求他们在压力下完美推理——无法扩展。
- 系统的复杂性不断增加。
- “这是你的数据” 与 “这就是发生了什么” 之间的差距在不断扩大。
我们可能需要在推理层面上运作的工具，而不仅仅是可视化。
即使这个具体想法失败，问题本身也值得投入时间。
如果你也有这种痛感——或者你认为这种框架有误——我真诚地想听听你的想法。
到底是什么帮助你从“inciden