可观测性：每一个技术岗位的必备能力

标题党了点，不过大体逻辑就是如此。可观测性是软件的一个特性，和可用性、可靠性类似的一个特性，每个软件工程师都应该关注，尤其是你需要自证清白的时候。

缘起

今天早上偶尔刷到一篇文章，是 Honeycomb 公司的工程师写的，深有同感，原文地址如下：

https://www.honeycomb.io/blog/observability-every-engineers-job-not-just-ops-problem

我把文章中的一些重要观点摘过来，也结合我自己的理解，做一些补充，和大家做一个探讨。

什么是可观测性

可观测性，顾名思义，指的是系统状态能够被观察与度量的特性。在IT领域，可观测性被精确定义为根据系统生成的输出数据（涵盖日志、指标及跟踪信息等）来测量和理解系统当前状态的能力。

Opentelemetry 网站对可观测性给出了深刻的阐述：可观测性赋予我们从外部视角洞察系统的能力，使我们能够在不了解系统内部工作机制的前提下，对系统提出疑问并寻求答案。它进一步使我们能够轻松应对新出现的问题（即“未知的未知”），并帮助我们深入探究“为何会发生这种情况”。向系统提出问题，本质上意味着我们具备收集系统执行与行为信息，并从中获取洞见的能力。

我们在软件架构设计时，经常会提到可用性、可靠性，随着微服务的发展，可观测性，也应该成为一个重要的设计方面。

从 printf 到可观测性

每个研发人员都是熟知 “print大法” 的，开发过程中，我们经常会在代码中加上打印语句，来帮助我们调试和排查问题，printf 可以看做是最简单的观测工具。随着时代发展，printf 逐渐被 logger 取代，logger 也逐渐演变成了结构化日志，结构化日志可以看作是可观测性的第一步。

姑且不论日志实践做得好不好，研发人员至少不会拒绝打印日志，从可观测性角度，研发打印日志，就是在生产可观测性数据，之后谁来用？研发人员自己+运维人员。除了日志，研发还应该生产其他类型的观测数据，尤其是需要自证清白的时候。

现实中，很多公司都是只有运维人员在推动可观测性的落地，研发人员爱答不理，甚至是抵制的态度。真的是不可理喻。

随着微服务发展，多个服务之间的调用关系越来越复杂，普通日志无法串联整个请求链路，于是就有了链路追踪，链路追踪姑且可以看做是串联各个服务调用的结构化日志。

虽然日志顺手即来，但日志通常是面向“点”的，我们较难从日志中获取全局视角的信息。而全局视角的信息也很关键，比如各个接口的成功率、延迟，整个服务的成功率、延迟等，此时就需要指标上场了。Google 要求所有的服务都必须暴露 /varz 接口，来展示服务的指标数据，可见他们对指标的重视程度。

优秀的软件都具备可观测性

业务研发领域不好举例，我们可以拿开源基础设施软件来举例，比如 Linux、Kubernetes、MySQL、Redis、Kafka，你能想到的优秀的开源软件，都会对外暴露观测数据。虽然大家暴露方式不同，但是理念是一样的，都是想方设法让用户能看到系统的运行状态，帮助用户排查问题。

软件工程的几个最佳实践

我们认为软件工程应具备一些最佳实践，甚至可以称为不可协商的原则：

• 测试
• 可读代码
• 减少内存分配
• 防卫判断
• 等等

在实现需求的同时，把优秀的软件实践落实到位，就可以称之为优秀的程序员。埋点，或称为插桩，是时候作为软件工程的最佳实践之一了。

代码开发中，我提倡遵从“面向交接”的原则，即我们在编写代码时，不仅要考虑当前的需求，还要考虑之后其他人愿不愿意接手你的代码。以己度人，你愿意接手的代码不易阅读、不做防卫判断、漏洞百出、不打日志、不暴露监控指标吗？即便只是为了自己，尤其是为了几个月之后的自己，你也应该遵从“面向交接”的原则。

结语

谨以本文引发大家对可观测性的思考，尤其是研发人员。可观测性真的应该作为软件工程的最佳实践之一了。

监控、可观测性整套体系确实非常驳杂，我们在这个领域做了十年，如果您需要乙方协助构建整套体系，欢迎联系我们： https://flashcat.cloud/contact/