大多数可观察性堆栈都非常擅长回答一个问题：发生了什么？
他们在下一个问题上表现较弱：我们在哪里解决这个问题？
这个差距就是事件响应速度减慢的地方。团队查看错误率、打开跟踪、读取日志、检查部署时间线，然后仍然必须手动搜索代码库。
熟悉的事件
想象一下，一个 API 在部署后开始间歇性返回 500 秒。仪表板显示峰值。跟踪指向结账服务。日志包含验证错误，但该消息是通用的。
那时，团队不需要另一张图表。它需要方向：
- 拥有 checkout 的存储库
- 连接到失败路由的处理程序
- 最近的提交改变了验证行为
- 应审查修复的个人或团队
这就是代码上下文。
为什么代码上下文很重要
没有代码上下文的可观察性会产生意识。代码上下文的可观察性创建了修复路径。
差异很小，但在操作上很重要。跟踪可以告诉您请求失败于 邮寄/结账。代码上下文可以指向验证分支、昨天更改的文件以及通常审查该区域的所有者。
该映射可以节省许多事件的第一个小时。
最小有用上下文
您不需要将整个调查附加到拉取请求中。审稿人通常需要一组紧凑的事实：
- 生产症状
- 受影响的服务
- 可能的文件或函数
- 最近的部署或代码更改
- 所有者或审阅者
- 提议的下一步行动
更多的内容应该支持这些事实，而不是掩盖它们。
仪表板停在哪里
仪表板用于查看系统行为。拉取请求用于更改系统行为。健康的修复工作流程将这些世界连接起来，而不是要求工程师每次都手动桥接它们。
如果信号找不到代码，则警报将成为另一个队列项目。如果信号可以找到代码，团队就可以决定是否修补、回滚、打开待办事项或进行更深入的调查。
建设目标是什么
实际目标不是更大的可观测表面。这是一条较短的路径：
生产信号 -> 代码上下文 -> 可审查的操作
该操作可能是拉取请求。这可能是 Jira 问题。这可能是一条说明，表明该问题属于上游提供商。关键是，团队不应该在每次生产说话时都从空白调查开始。
可观察性表明失败。代码上下文给了失败的地方。
