Chinese translation of a New Stack Article by Jason Bloomberg “为什么会这样做呢?” 这是软件开发人员频繁提出的问题。他们正在开发的应用程序出现了问题。是他们引入了一个错误吗?是同事做了什么改变吗?还是在前端和后端之间出现了某种基础设施问题? 在不好的、过去的瀑布模型时代,开发人员各自独立工作。不仅开发、测试和运维完全分离,就连开发部门内部,前端和后端团队也大部分独立工作。 但现在不同了。在今天的分布式、云原生世界中,每个软件组件都与许多其他组件交织在复杂的依赖关系网络中,工作在这些组件上的团队也是如此。 在这个快速变化、相互连接的环境中,开发人员需要答案,不仅要知道为什么他们的应用程序性能可能不佳,还要知道如何修复它。而为了获得这些答案,他们需要可观测性。 并非你所想的可观测性 在运维领域,可观测性正在风靡一时。装备所有软件以生成遥测数据流,然后使用数十种应用性能管理(APM)、基础设施管理或 IT 运维管理(ITOM)工具来理解所有这些数据。 运维人员和网站可靠性工程师的可观测性工作目标很明确:汇总日志和其他遥测数据,检测威胁,监控应用程序和基础设施性能,检测行为异常,优先处理这些异常,确定其根本原因,并将发现的问题指向其底层负责人。 基本上,运维人员希望保持一切运行正常——这是一个重要的目标,但不一定是开发人员所关心的。 开发人员同样需要可观测性,但出于不同的原因。如今的开发人员对部署的代码成功负有责任。因此,他们需要持续了解他们正在开发的代码在生产环境中的表现。 与以运维为重点的可观测性工具不同,以开发为重点的可观测性专注于开发人员关心的问题,比如文档对象模型(DOM)事件、API 行为、检测糟糕的代码模式和代码异味、识别有问题的代码行和测试覆盖率。 因此,对于开发人员来说,可观测性的含义与运维人员不同,因为开发人员希望以不同的方式查看应用程序遥测数据,以帮助他们解决与代码相关的问题。…