IT运营中的可观察性概念在2020年得到了人们的关注，这是因为IT领导者正在寻找新的方法来控制随着云计算和快速数字化而得到增长的复杂性。
可观察性与IT监控的不同之处在于其侧重于应用程序和丰富工具的开发，以便运营人员可以就软件如何工作或在生产中工作提出有意义的问题。提出新问题的能力使IT部门可以对应用程序行为获得不同的见解，从而优化和改进客户的结果。
考虑可观察性的另一种方法是，它完全以用户角度为基础，这需要以用户为中心的心态和方法。传统的(黑盒)监视提供的指标可以指示系统是否已启动并正在运行，而可观察性则通过显示系统是否真正满足业务和用户要求来进一步提高这一能力。
行动中的可观察性
可观察性通过解决以下问题，与基础设施监视的业务价值建立了更紧密的联系：
- 服务器在线且可用，但是它支持的应用程序出现故障。
- 网络连接正常，但用户的交易可能无法通过，或者网站的行为异常。
- 在一种浏览器中可以正常访问网站，但在另一种浏览器中访问不正常。
在用户开始抱怨或离开企业的网站/应用以获得更好的服务之前，企业的IT组织需要了解这类问题。这些对于客户和员工来说是很糟糕的体验，可能会带来成本高昂并且不安全的影子IT。
无论哪种方式，缺乏可观察性都意味着企业更容易出现用户满意度低和支持成本高的情况。可观察性要求采用现代化的监视方法，而开发人员接受并参与监视活动则更加成功。
以下是一些在2021年加强可观察性实践的想法：
1. 扩展数据
超越传统的资源监控指标，如CPU利用率和网络延迟。包括来自每个基础设施组件的日志、跟踪、度量和警报，以便对应用程序有新的了解。
团队应该有适当的路由和沟通渠道，并能够快速获得对系统进行最佳补救或提供更多环境的访问权限。
2. 将可观察性作为开发原则
可观察性迟早会成为开发人员工作的一部分。开发人员现在不能在编程之后而让运营人员来解决它。应用程序运行状况长期以来一直为IT运营部门所拥有，但从逻辑上来说，真正了解应用程序运行状况的人是开发人员，因为他们构建了应用程序运行状况，并且知道代码应该如何在生产环境中工作。通常，在Sprint周期的后期，有人会提出这样一个问题：“我们如何在生产中监控这项服务?”
开发团队急于寻求可行的解决方案，最后，有人最终在应用服务器上运行了一个开源监视工具实例。通过将可观察性作为持续集成(CI)/持续交付(CD)管道中的关键步骤，而不是事后思考的事项，可以避免这种情况。
3. 采购用于观察的监控工具
APM工具或越来越多的开放源代码监视工具(例如Prometheus)可以帮助衡量操作标准，例如在应用程序正常运行期间可能发生的应用程序、客户端和服务器端错误。综合或数字体验管理工具提供了另一种理解系统输出的方法。这有助于回答以下问题：我的用户是否可以访问这个应用程序，并且在经历过程中是否存在交易失败?有一些强大的利基可观察性工具，但它们可能难以使用，并且需要许多开发人员不具备的原生监视专业知识。组织面要忽略供应商的宣传，在技能水平、资源等方面采用适合组织的工具。它应该易于部署和管理。
4. 简化工具
跨越ITOps和DevOps组织的一个常见陷阱是复制工具的泛滥。这些工具之间的数据通常不是联合的，这使得简单而全面地实现可观察性策略的工作成为一个真正的难题。这就是为什么它是如此难以实现单一控制的原因。大多数情况下，都需要监视和可观察性工具，并将其用于解决紧迫的问题(例如准备发布，对特定的客户端错误进行故障排除等)。随着时间的推移，很容易看到一个组织最终可以使用20多种解决重叠用例的监控工具。组织需要整合保留的内容，并考虑使用平台解决方案来管理和统一所有数据，从而为开发人员和运营商节省时间。
5. 改善最终用户体验
可观察性及其解决的问题不仅对开发人员、工程师和管理员有意义。可观察性工具产生的许多见解可以为可能从事销售、市场营销、支持或专业服务的技术含量较低的同事提供丰富的背景信息。
一些示例包括：
- 在网站的哪一天或一年中的哪个时间看到最多的流量?
- 是否存在用户最常访问的某个网页?
- 启动或更改网页后，是否看到交易量增加?
- 网页加载缓慢吗?如果是，造成的原因是什么?
回答这些问题通常可以桥接非技术团队可以使用的工具，并且需要对应用程序本身有更深入的了解。DevOps和ITOps团队应该与非技术利益相关者合作，以了解可观察性工具可以解决哪些业务问题，以及解决这些问题的最佳方法。
