Tags archive: observability

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