对于开发者来说，可观测性意味着不同的东西，因为他们希望查看应用程序的遥测数据，以帮助他们解决与代码相关的问题。
翻译自 Why Developers Need Their Own Observability 。
“为什么会这样做呢？”
这是软件开发人员频繁提出的问题。他们正在开发的应用程序出现了问题。是他们引入了一个错误吗？是同事做了什么改变吗？还是在前端和后端之间出现了某种基础设施问题？
在不好的、过去的瀑布模型时代，开发人员各自独立工作。不仅开发、测试和运维完全分离，就连开发部门内部，前端和后端团队也大部分独立工作。
但现在不同了。在今天的分布式、云原生世界中，每个软件组件都与许多其他组件交织在复杂的依赖关系网络中，工作在这些组件上的团队也是如此。
在这个快速变化、相互连接的环境中，开发人员需要答案，不仅要知道为什么他们的应用程序性能可能不佳，还要知道如何修复它。而为了获得这些答案，他们需要可观测性。
在运维领域，可观测性正在风靡一时。装备所有软件以生成遥测数据流，然后使用数十种应用性能管理（APM）、基础设施管理或 IT 运维管理（ITOM）工具来理解所有这些数据。
运维人员和网站可靠性工程师的可观测性工作目标很明确：汇总日志和其他遥测数据，检测威胁，监控应用程序和基础设施性能，检测行为异常，优先处理这些异常，确定其根本原因，并将发现的问题指向其底层负责人。
基本上，运维人员希望保持一切运行正常——这是一个重要的目标，但不一定是开发人员所关心的。
开发人员同样需要可观测性，但出于不同的原因。如今的开发人员对部署的代码成功负有责任。因此，他们需要持续了解他们正在开发的代码在生产环境中的表现。
与以运维为重点的可观测性工具不同，以开发为重点的可观测性专注于开发人员关心的问题，比如文档对象模型（DOM）事件、API 行为、检测糟糕的代码模式和代码异味、识别有问题的代码行和测试覆盖率。
因此，对于开发人员来说，可观测性的含义与运维人员不同，因为开发人员希望以不同的方式查看应用程序遥测数据，以帮助他们解决与代码相关的问题。
由于今天的开发人员在复杂的分布式应用程序上工作，他们需要能洞察这类应用程序行为的可观测性。特别是，开发人员需要：
- 端到端的追踪能力：开发人员必须能够追踪用户交互或其他事件从前端到后端的过程。
- 对 API 行为的可见性：API 是支撑现代软件的粘合剂。因此，构建 API 是开发人员的核心任务。API 的行为良好与否取决于暴露 API 的代码以及使用 API 的软件。开发人员需要同时了解这两方面的情况。
- 事件追踪，也称为“面包屑”：解决问题可能像解谜一样。通过跟踪导致问题的事件，可以确定问题的原因并找到解决方法。
- 版本更改和责任方：在许多情况下，出现的问题是其他开发人员的工作结果。追踪谁在做什么以及他们的更改如何影响软件现状是至关重要的。开发人员希望快速评估问题，并将其解决或指向负责人。
- 发布跟踪：开发人员需要跟踪每个发布的新问题和回归。他们还必须跟踪问题的解决情况并监控应用程序的健康状况。
- 测试覆盖率：开发人员还需要测试用例来确保他们的代码是可靠的。此外，如果某些代码片段从未运行过，就无法进行测试。这样的代码存在也会暴露出一些逻辑错误，阻止代码的运行。
- 对预发布和发布后行为的可见性：开发人员通常在预发布环境中编码和测试。他们需要预发布的可观测性来确保应用程序在此环境中正常工作。只有在这之后，他们才会将代码推向生产环境。之后，他们仍然需要监控和观察应用程序，以确保它在发布后能正常运行，因为其他开发人员继续推送可能影响他们自己的代码的代码。
显然，开发人员的可观测性需求与运维人员的需求相当不同。如果没有以开发人员为重点的可观测性带来的好处，开发人员的工作效率将降低，整体代码质量也会较差。
最糟糕的是，如果没有足够的可观测性，开发人员将像在黑暗中行走一样遇到问题——这些问题将会绊倒他们，影响到开发人员需要良好工作的创造力流程。
##Intellyx 观点
我们都遇到过加载缓慢的页面和其他性能问题，以及可怕的 HTTP 500 内部服务器错误——一个指示出现了问题的空白网页。
没有人希望看到这样的错误——尤其是开发人员。他们缺乏信息，而紧急修复的需求却迫在眉睫。
如果没有开发人员可观测性工具提供的可见性，开发人员将处于黑暗中。这样的工具应该在每个开发团队的购物清单上。
不幸的是，购买一个以开发人员为重点的可观测性工具可能会很棘手。APM 和 ITOM 是明确定义的类别，有着提供成熟产品的已建立供应商。但对于以开发为重点的可观测性，情况并非如此。
在这个领域，少数几家供应商正在开创先河，其中之一就是 Sentry ，但单一供应商并不能构成市场。然而，考虑到开发人员可观测性的重要性，其他供应商很快就会涌入这个重要的领域。