考虑可观察性的另一种方法是，它完全以用户角度为基础，这需要以用户为中心的心态和方法。传统的(黑盒)监视提供的指标可以指示系统是否已启动并正在运行，而可观察性则通过显示系统是否真正满足业务和用户要求来进一步提高这一能力。

行动中的可观察性

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

• 服务器在线且可用，但是它支持的应用程序出现故障。
• 网络连接正常，但用户的交易可能无法通过，或者网站的行为异常。
• 在一种浏览器中可以正常访问网站，但在另一种浏览器中访问不正常。

在用户开始抱怨或离开企业的网站/应用以获得更好的服务之前，企业的IT组织需要了解这类问题。这些对于客户和员工来说是很糟糕的体验，可能会带来成本高昂并且不安全的影子IT。

无论哪种方式，缺乏可观察性都意味着企业更容易出现用户满意度低和支持成本高的情况。可观察性要求采用现代化的监视方法，而开发人员接受并参与监视活动则更加成功。

以下是一些在2021年加强可观察性实践的想法：

1. 扩展数据

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

团队应该有适当的路由和沟通渠道，并能够快速获得对系统进行最佳补救或提供更多环境的访问权限。

2. 将可观察性作为开发原则

可观察性迟早会成为开发人员工作的一部分。开发人员现在不能在编程之后而让运营人员来解决它。应用程序运行状况长期以来一直为IT运营部门所拥有，但从逻辑上来说，真正了解应用程序运行状况的人是开发人员，因为他们构建了应用程序运行状况，并且知道代码应该如何在生产环境中工作。通常，在Sprint周期的后期，有人会提出这样一个问题：“我们如何在生产中监控这项服务?”

开发团队急于寻求可行的解决方案，最后，有人最终在应用服务器上运行了一个开源监视工具实例。通过将可观察性作为持续集成(CI)/持续交付(CD)管道中的关键步骤，而不是事后思考的事项，可以避免这种情况。

3. 采购用于观察的监控工具

APM工具或越来越多的开放源代码监视工具(例如Prometheus)可以帮助衡量操作标准，例如在应用程序正常运行期间可能发生的应用程序、客户端和服务器端错误。综合或数字体验管理工具提供了另一种理解系统输出的方法。这有助于回答以下问题：我的用户是否可以访问这个应用程序，并且在经历过程中是否存在交易失败?有一些强大的利基可观察性工具，但它们可能难以使用，并且需要许多开发人员不具备的原生监视专业知识。组织面要忽略供应商的宣传，在技能水平、资源等方面采用适合组织的工具。它应该易于部署和管理。