DevOps和ITOps团队与非技术性涉众协作，以了解业务问题可以通过可观测性工具来解决

2020年，IT运维中的可观测性概念得到了人们的认同，IT领导者正在寻找新的方法来控制随着云计算和快速数字化而有机增长的复杂性。

可观测性与IT监控的不同之处在于，它关注于应用程序和丰富仪表的开发，以便运维人员可以就软件在生产中如何工作提出有意义的问题。提出新问题的能力使IT部门能够从不同角度了解应用程序的行为，从而进行优化和改进。

另一种思考可观测性的方式是，它完全是关于用户视角的，这需要以用户为中心的思维方式和方法。虽然传统的(黑匣子)监控提供了指示系统是否已启动和运行的指标，而可观测性通过显示系统是否真的能够满足业务和用户需求，进一步说明了这一点。

可观测性的作用

可观测性通过解决以下问题，与基础设施监控的业务价值建立更紧密的联系

——服务器在线且可用，但其支持的应用程序出现故障

——网络已启动，但用户的交易可能无法进行，或者网站行为异常

——你的站点在一个浏览器中运行良好，但在另一个浏览器中运行不正常

在用户开始抱怨或离开你的网站/应用程序以获得更好的服务之前，IT组织需要立即了解这些问题。这对用户留存和员工来说都是可怕的，它可能会导致成本高昂、不安全的影子IT。

无论哪种方式，缺乏可观测性意味着你的组织很容易用户满意度低和支持成本高。可观测性需要一种现代的监控方法，当开发人员接受并参与监控活动时，它会更成功。

以下是一些加强可观测性的建议：

扩展数据

不限于传统的资源监控指标，如CPU利用率和网络延迟。还包括来自每个基础设施组件的日志、跟踪、指标和警报，以便对应用程序有新的了解。

团队应该有适当的路由和沟通渠道，以便在事件发生时，快速访问能够最佳补救的系统，或者提供额外的上下文。

将可观测性作为开发原则

这迟早会成为开发人员工作的一部分。应用程序运行状况长期以来一直是IT运维部门的事，但从逻辑上讲，真正了解应用程序运行状况的人是开发人员，因为他们构建了应用程序运，并且知道代码应该如何在生产环境中工作。通常，在开发冲刺的后期，会有人提出这样一个问题：“我们如何在生产中监控这个服务？”

开发团队争先恐后地寻找一个可行的解决方案，最终有人在应用服务器上运行了一个开源监控工具的实例。这种情况并不少见。通过将可观测性作为CI/CD管道中的一个关键步骤，而不是事后考虑，可以避免这种情况。

采购用于可观测性的监控工具

APM工具或越来越多的开源监控工具(如Prometheus)可以帮助度量运维指标，如应用程序、客户端和服务器端错误(应用程序正常运行期间可能发生的)。综合或数字体验管理工具提供了另一种理解系统输出的方法。这有助于回答以下问题：用户是否可以访问应用程序，以及体验中是否存在任何事务性失败？有一些功能强大的、小众的可观测性工具，但它们可能很难使用，并且需要许多开发人员不具备的监控专业知识。请忽略供应商的嗡嗡声，采用在技能水平、资源等方面适合你的组织的工具。它应该易于部署和管理。

简化工具

跨越ITOps和DevOps组织的一个常见陷阱是复制工具的泛滥。这些工具之间的数据通常不是联合的，这使得简单而全面地实现可观测性策略的工作成为一个大难题。

最常见的情况是，监控和可观测性工具受到追捧，并用于解决紧迫的问题(如准备发布、排除特定客户端错误等)。随着时间的推移，很容易会有20多个监控工具来解决重叠的用例。该做的是，整合、集成，并考虑一个平台解决方案来管理和统一所有数据，为开发人员和运维人员节省时间。

围绕改善最终用户体验而努力

可观测性及其解决的问题不仅对开发人员、工程师和管理人员有意义。观测工具产生的许多洞察可以为从事销售、营销、支持或专业服务的同事提供丰富的背景。

一些例子包括：一年中哪一天或哪一时间网站流量最大？是否有某个用户最常访问的网页？在启动或网页更改之后，我们是否看到了交易的增加？网页加载速度慢吗？如果慢，是什么原因造成的？

回答这些问题通常会涉及非技术团队可以访问的工具，并且需要对应用程序本身有更深入的了解。DevOps和ITOps团队应该与非技术性涉众协作，以了解哪些业务问题可以通过可观测性工具来解决，以及解决这些问题的最佳方法。