重新定义可观测性

原创

软件质量保障 2024-05-22 00:36:43 博主文章分类：软件测试 ©著作权

文章标签 大数据 java python 测试用例数据库 文章分类 JavaScript 前端开发

©著作权归作者所有：来自51CTO博客作者软件质量保障的原创作品，请联系作者获取转载授权，否则将追究法律责任

可观测性是一个热门话题，虽然它在软件工程中扮演着越来越重要的角色，但我认为它现有的定义会让部分人觉得不好理解或者说使人误解了其精髓。本文我将介绍目前在工程学科中广泛使用的可观测性定义，然后分享我对可观测性的定义，回顾是什么促使我对其重新定义。

对于那些时间紧迫的读者，我将文章内容提炼成“洞察”，这样你就可以快速浏览这篇文章并找出关键点。

01/可观测性的定义

“可观测性”有两种主要的定义，分别是来自控制论以及认知系统工程。

可观测性:控制理论

Observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs.
可观测性是一种方法，通过系统的外部输出推导出系统内部的状态。
– Rudolf E. Kálmán

这个定义来源于对线性动力系统的研究，并在软件工程中变得突出，主要是通过该领域的思想领袖的努力，将这个概念引入并应用到一个新的领域；Charity Majors被认为是将这一定义引入软件工程主流关注的主要声音之一。

每当工程师谈论可观测性时，这很有可能就是他们心中理想的定义。

可观测性:认知系统工程

Observability is feedback that provides insight into a process and refers to the work needed to extract meaning from available data.
可观察性是指能够深入从现有数据中提取有价值信息的反馈。
– David D. Woods’ and Eric Hollnagel’s Joint Cognitive Systems: Patterns in Cognitive Systems Engineering, (Taylor & Francis, 2006), p. 121.

如果你和认知系统工程领域/弹性工程领域/系统安全工程领域的人讨论这个话题，这是他们最可能想到的定义。

02/可观测性的重新定义

下面是我的定义:

可观测性是指这样一个过程：通过它，个体能够逐步发展出提出有意义问题、获取有用答案，并基于所学知识采取有效行动的能力。

当然，我没有丝毫偏见;这仅仅是一个自然的结果，我认为这是最好的定义。

03/为什么重新定义可观测性?

对我来说，一个概念的良好定义应当具备这样的作用：当你拥有这样一个定义时，它不仅能够作为理解该概念的核心方式，而且还能引导你探索这一概念的方向，并指导你全面把握对该概念探索的所有含义。举个例子，我对控制理论中可观测性定义的一个问题是，它并未提供任何起点、当前位置或如何达到目标的线索。如果你的系统是完全可观测的，并且你知道它是可观测的……那很好，很酷，很有意思。但其余的我们并不知道到底发生了什么，更希望能有一份如何去实现可观测性的路线图。

另一个我对于控制理论中可观测性定义的不满之处在于，它完全忽视了人的因素；虽然并非从字面上将人剔除出去，但在阅读该定义时，你可能根本不会想到与人有关的内容。说实话，你在读到那个定义的时候，是否立刻觉得“啊，这听起来像是个人为问题”？很可能并没有，这就是个问题所在。

洞察: 大多数“可观测性”的实现都失败了，因为它被视为工具问题，而不是策略能力。对可观测性的投资更类似于商业智能和市场研究，而不是基础设施和it建设。

事实上，可观测性常被作为工具兜售给基础设施团队，这种做法通过将其埋没在具体实现中而丢掉了整个概念的本质。没有人购买PowerBI是因为他们需要投资所谓的“超级花哨电子表格生成能力”或其他类似的东西，同样地，你不应该仅仅因为需要一种存储系统诊断信息的方法而去购买可观测性供应商的产品，这简直毫无意义——可观测性并不是一个数据问题。

控制理论对可观测性的定义使得人们很难从人的角度去思考问题，同时也没有给出起点、终点以及如何达成目标的策略。显然，这并不理想，那么认知系统工程领域的定义又如何呢？

坦率地说，我更喜欢认知系统工程的那个定义，我希望我们能更多地推广这个定义而非控制理论中的那个。尽管控制理论的定义有助于指导如何实施有效的可观测性组件，但它实际上并没有帮助实践者理解实际情况。但这并不意味着它已经很完美：从该定义（以及控制理论的定义）中明显缺失的一点是，你为何首先关注这一点的原因。你提到了“为流程提供洞见”和“从这些洞见中提取意义所需的工作”，但说实话，你为何要在乎这些？此外，还有一个问题依然存在，那就是你仍然不清楚自己现在何处、需要去哪里以及如何去判断是否到达了目的地。

洞察: 在我看来，当前关于可观测性的定义中一个显著的不足之处，在于无法明确知道应当投入多少资源来构建可观测性这一能力，以及如何有效地投入这些资源。

这就是我最喜欢新定义的原因:

我喜欢那些既抓住本质又能体现其内在动机的概念定义。
对我来说，具有启发性的定义还包含了隐含的方向感。
当我们定义一项能力时，应当将其视为一个无限且渐进的过程。
缺乏行动的学习就不是真正意义上的学习，同样，若一个关于演化的定义中不包含行动步骤，那么这个定义就是不完整的。

04/可观测性走向错误的发展方向

这可能是我对当前可观测性发展方向的最大不满之处。工程领域一直以来都与其他业务部门有些孤立；这是可以理解的，毕竟这是一个充满高度专业化且内部快速发展的关注点的领域，难怪它在其他人看来会显得如此陌生。医学和法律领域也有类似情况，这里举两个例子。然而，工程领域曾拥有过千载难逢的机会：我们面对的是涵盖企业几乎所有商业活动的复杂社会技术系统，并且我们提出了这样一个卓越的理念——“我们需要理解自己正在做什么”。但我们在这样的情况下做了什么呢？

我们通过将可观测性定义为“具有高级搜索功能的超大规模JSON日志解析器”的方式，彻底把这个概念给搞砸了。真的吗？这就是我们选择用来“解决真正严肃的商业问题”的战略吗？

这感觉真是悲剧，浪费了建立跨职能理解和沟通渠道的巨大潜力，真是可惜至极。

05/有意义的问题

抛弃当前的可观测性的概念，让我们认真思考一下：提出有意义的问题意味着什么？

对我来说，一个有意义的问题需要具备以下几个组成部分：

公司中的任何人都应该能够提问。
这个问题对于提问者本人而言必须是有意义的。
“有意义”的概念没有限制、约束或特定领域：只要它是有意义的，就应该能够被提出。

现在深入探讨“有意义”这一部分，因为我认为这一点尤为重要，而大多数人的理解可能过于局限。设想有一群人共同协作来理解一个问题，他们共享的背景知识可以视为多个部分的组合。我们可以将“意义”的构成要素分解为可结合在一起以形成问题综合范围的不同方面：

“垂直”背景，即对齐团队相关的上下文。
“水平”背景，即功能领域的相关背景。
所涉及的小组规模：个人、团队、垂直组织、整个组织、企业、市场等。
时间跨度：过去、现在、未来、六个月内、每月、每次董事会会议时、竞争对手上市时等。
关注的受众：一项服务、一个团队、一个组织、一个客户群体、一个行业、一组服务、一个集群、一台计算机等。

根据关注的内容，还有很多可以添加的元素，但以上内容足以说明问题。

接下来，我们选取问题“我们是否健康”，并将其与不同的综合范围相结合，通过一些具体示例来更清晰地阐述什么是“有意义的问题”。

例子：作为负责服务A1的团队A的一名工程师，服务A1的/health端点在5分钟间隔内成功响应的比例是否达到99.9%？作为负责服务A1、A2和A3的团队A的工程经理，我们的团队在本季度内是否达到了与客户约定的服务级别协议（SLA）？

作为负责团队A、B和C的高级工程经理和高级产品经理，我们在跨职能团队间是否有效沟通，是否相互理解，并且我们构建的产品是否符合我们所在垂直领域OKR以及整个组织的目标？
作为Org ABC的工程总监，我们是否在特性开发与可靠性工作之间做出了正确的权衡，以便在不损害工程健康、员工流动率、客户满意度和财务考量的前提下最大化价值交付？
作为产品经理，在这50个特性中，哪些特性与我们的GTM研究结果最吻合，哪些特性在设计上可以让工程师有空间将可靠性工作融入产品实现，从而最大化产品路线图的推进速度？
作为负责Org ABC客户服务的总监，我们是否正在构建合适的内部工具，既能最大限度地提升客户服务效能，又能获得洞察力以决定哪些类别的客户服务应自动化或主动预防？
作为工程副总裁，我们是否在设计工程技术文化和工程流程时，使其能够最大化生产力，并确保开发工作与公司的战略目标保持一致？
作为CTO，我们是否正在准备架构以应对当前市场的竞争地位，并确保我们建立的能力能支持我们在五年后快速创新？
作为CISO，我们的业务连续性状况如何？风险概况如何？我们与其他部门合作是否有效，是否确保了适当的风险收益平衡以经济高效的方式保持安全？

我可以举出数百个这样的例子，但关键在于，“我们是否健康”这个问题在很多层面上都有其意义，以至于对于每个提问的人来说，它都是一个不同的问题，甚至每次提问时都会有所不同。即使你昨天或者一小时前问过同样的问题，由于公司现状、目标、信息及所有条件都发生了变化，所以问题的答案也会不同。

洞察：你永远不会问两次相同的问题。这就是为什么可观测性是一个能力发展过程的原因。

06/有用的答案

如果我们对有意义的问题有了更深入的理解，这固然很好，但如果我们没有关于有用答案的概念，这对业务来说并没有太大的帮助。在我看来，有用的答案也包含几个不同的要素：

答案应当通过具体行动帮助他们接近实现明确或隐含的商业目标。理论上可能有用、或许有用或者“挺有趣”、“也许将来某天会用到”的答案，并不算作真正有用。
答案的实用性不应依赖于其是否“正确”或“事实”。即使某些答案在客观上不准确或非事实，只要它们能推动实际工作进展，就可以视为有用。
虽然问题只需要对某些人有意义，但答案应尽可能地对所有人都有用。

这确实比看起来要难得多。幸运的是，我们有一个救星：抛开追求真实、准确或正确答案的想法。真的，我不是说我们要生活在一个“后真相”的世界里，而是指当我们理解到每个人对世界的背景、理解和解释都不同时，就无法为非绝对客观的情况找到一个既“正确”又“实用”的定义。这可能会让你感到不安，但请拥抱这个观念并从中获得自由。答案之所以有用，在于它能否引导你采取具体的行动——仅此而已。

洞察：如果你正在提出一个有意义的问题，那么这个问题不会有客观的答案；由于意义本身是主观的，因此答案也是主观的。

大家常引用的那个短语“尽管有分歧也要坚决执行”，我并不喜欢。我认为这句话在被频繁地脱离上下文引用和被领导者用来强行推动自上而下的共识时，造成的危害大于益处。原本这句话是用来提醒领导者要信任所雇佣的人。

然而，如果我们保留信任团队成员这一概念，同时摒弃其中对立和强制性的表达方式，就能得到一些很酷的东西：相信人们提出的问题，并利用他们发现的答案。丢掉“尽管有分歧也要坚决执行”的说法，转向“提出有意义的问题，获取有用的答案，并根据所学付诸行动”。作为领导者，你的工作就是帮助尽可能多的答案与业务产生关联，让答案变得有意义。

07/发展过程

我想现在探讨我定义中的另一部分，即我们有一个过程，它是一个通过该过程来培养能力的过程。这意味着什么呢？这意味着在开始时，你可能会非常不擅长某件事，而这其实是一个特点而非缺陷。

回想一下你在工程、营销、销售或职业生涯其他任何部分的第一次尝试。不仅你不擅长是正常的，而且这实际上是一件好事；犯错是学习过程本身必不可少且不可或缺的一部分。正是通过纠正、演变、增强和迭代，你才能培养出许多重要的技能并磨练自己的直觉。如果你没有这个过程，一开始就做出正确的选择，并不是因为你聪明，而是因为你运气好。领导者不喜欢依赖运气是有原因的：运气不可靠，单纯依赖运气是很糟糕的策略。

对于可观察性而言，这意味着在开始时，你提出的问题在广度、深度、范围和细微程度上都会受到严重限制。但没关系！简单的问题仍然是有意义的问题。我发现很多人在这个地方会感到困扰，所以我想在这里强调这一点。

在持续迭代开发过程中，进步本身就是产出。你不可能在没有先提出简单问题的基础上就直接问出复杂问题；事情的发展就是这样的。想象一下，在财务规划会议上，你直接问：“嘿，各个业务部门的折现现金流分析是如何细分的？”而此时大家还在忙于明确每个业务单元需要申报哪些作为资本支出（CapEx）和运营支出（OpEx）。你不仅与大家的话题脱节，扰乱了整个会议，而且由于在掌握基础知识之前就提出这样的问题，你将得到错误的答案，并在未来试图解答类似问题时为失败埋下伏笔。