为什么软件团队很难尝还监控债务？

【编者按】本文探讨了监控债的问题，以及为什么软件团队很难偿还这种债务。作者指出，尽管现在有更多的监控和可观察性工具可供选择，但团队却在积累监控债的速度上超过了他们偿还债务的能力。

原文链接：https://stackoverflow.blog/2023/02/16/monitoring-debt-builds-up-faster-than-software-teams-can-pay-it-off/

未经允许，禁止转载！

作者 | Jean Yang       译者 | 明明如月

责编 | 夏萌

出品 | CSDN（ID：CSDNnews）

你可能会认为全行业的软件团队都已经掌握了最先进的监控和可观测性实践。在潜在问题影响到客户之前，这些监控就能得到预警，并通过精美的仪表板来追踪和解决问题。

然而，根据我过去几年的经验，实际上只有少数软件团队达到了这样的监控水平。我接触的大部分团队都承认他们的应用监控覆盖度并未达到预期。许多初创公司在几乎没有任何监控的情况下仍然取得了显著的进展。对于那些正在努力掌握监控基础的团队，不用担心，还有很多团队和你一样。

现在，对生产环境中的软件进行监控比以往任何时候都更简单。我们有着比以往更多的监控和可观测性工具可供选择，同时行业内对监控和可观测性最佳实践的理解也在日益深化。那么，为什么我们的监控实践与理想状态之间还存在这么大的差距呢？

事实上，团队所积累的监控债远超过他们的偿还能力。在这篇文章中，我将讨论何为监控债，为何团队越来越可能走向监控破产，以及如何解决这个问题。

何为监控债？

许多软件工程师都非常了解“技术债”这个概念。这是一个隐喻，用来理解技术权衡的长期影响。当人们谈论技术债时，通常会从重构、重新设计或重写的成本，以及如何让团队能够更快地发布产品的视角来考虑。与财务债务类似，技术债可以谨慎地产生并有责任地偿还。

在某些方面，监控债与技术债相似：团队可以选择在发布代码时减少对监控的投入，然而代价是将来需要重新投入资源进行监控。从技术角度看，处理监控债的行为与处理技术债相似。清理成本更高，需要对系统有深入的理解，这可能超出了开发人员常规的切换上下文的范围。而这仍然是基于同一开发者负责偿还债务的前提。

然而，监控债的代价更为隐晦。当团队选择在没有全面监控的情况下发布代码时，会立即产生以下成本：

• 团队需要接受自身在客户发现问题前察觉问题的能力有限，客户变成了他们的监控系统。这对某些产品或许行得通，但可能会消耗付费客户的耐心。

• 团队放弃了在问题出现时快速定位问题的能力，这意味着他们无法迅速解决问题。这就导致客户可能需要等待数小时甚至数天才能解决他们的问题。

更为糟糕的是，偿还监控债通常比偿还技术债更具挑战性，因为这既需要深入理解代码（知道什么行为是正常的，什么是需要优先监控的），又需要熟悉监控工具的使用（知道如何使用工具的功能来定位和解决问题）。

通常，团队选择承担监控债的原因，如专业知识缺乏，时间紧迫，反而会让他们陷入更深的债务。

现在的团队比以往任何时候都更容易陷入监控债的困境

接下来，我将介绍一些导致团队陷入监控债的几个原因。

监控是一项高技能活动

监控一个系统需要掌握对被监控系统的了解，以及如何使用工具进行监控的知识。

• 建立监控和可观测性需要对底层系统有所了解。即使你使用像 Datadog APM 这样的工具，可能会认为只需引入一个库即可，但实际上，还经常需要更新其他依赖项。即使在我们大约一年前的代码库中，只有三个微服务，也需要一位非常资深的工程师花上一周的时间在多种语言中追踪这些依赖关系。即使我们完成了设置，我的开发人员也没有足够的时间来设置所有需要使用这些数据的仪表板。我们一直处于滞后状态！

• 工具本身具有学习曲线。许多工具需要一些了解如何使用工具的知识，包括执行工具的方式和自定义图表的方法。使用 OpenTelemetry 需要一定的学习曲线，因为它要求你学习如何实现跨度，而这些框架没有提供自动检测支持。其他可观测性工具鼓励开发人员编写代码来预期将使用日志或跟踪，这要求开发人员对其有一定的理解和自我控制。需要自定义仪表板的工具通常要求开发人员了解如何获取所需的数据以及哪些阈值表示问题。与自动挡汽车相似，大多数监控和可观测性工具都以易用性为代价，以换取更多的控制和灵活性。使用这些工具需要一些设施和对清晰的监控目标以及底层监控机制的基本理解。

最好在早期进行监控

一个软件在没有监控的情况下存在的时间越长，进行监控就越困难。首先，对于不完全更新和重构过的系统来说，连接监控工具更加困难。任何需要使用库的监控系统都可能存在兼容性问题，至少需要有人去更新库。更强大、需要修改代码的工具更加难以使用。回到旧代码进行任何更新已经很困难了，而将其切换回追踪同样具有挑战性！

其次，消费“旧”的监控数据也非常棘手。即使你可以依赖你的框架自动生成日志或添加仪器，但是对于一个系统来说，被视为“正常行为”的可能已经随着时间的推移而改变，或者随着过去的团队成员离开公司。

最后，随着软件团队比以往任何时候都更年轻化，并且离职率比近年历史上更高，不同的、更年轻的开发人员可能会被指派来处理技术债。这些开发人员需要更长的时间来理解代码库及其需求。期望他们在重打日志和追踪语句到代码库的同时，快速掌握监控和可观测性的技能，这是一个巨大的挑战。

更好的工具使得承担监控债更为容易

最后，SaaS 和 API 的兴起使得监控系统变得更加复杂。现在的监控不再仅仅观察你自己的系统在做什么，而是观察你的系统如何与各种其他系统进行交互，包括第三方支付 API 和数据基础设施。还有一些遗留子系统，团队中没有任何人完全理解。传统的监控和可观测性实践对于完全受一个组织控制的单体和分布式服务是有意义的，但是对于包含了团队无法控制的组件的分布式系统，如何适应这些实践尚不清楚。

团队需要偿还监控债所需的资源

我的建议是：我们需要新的工具。但与此同时，我们也需要重新思考我们的实践。

如今的监控工具是为那些开发了可管理容量和良好结构的系统，并能够在整个系统中实现高精度日志记录的开发人员设计的。然而，我们生活在一个软件服务带来各种新行为的世界，软件工程更像是考古学或生物学。监控工具需要适应这种变化。

为了满足现代软件开发的需求，监控工具需要宽容对待技术债。我提出的改进建议包括：

• 简化建立监控和可观察性黑盒的过程。我知道，普遍的智慧是要尽可能了解底层系统的内部运行方式，以寻找和解决问题。但如果底层系统的代码庞大到无法实现这一点呢？或者某些部分的代码太古老或太脆弱，以至于无法深入并添加新的日志记录？让我们使人们能够进入系统并进行监控，而无需触碰代码甚至更新库。特别是在旧代码上设置新监控成为可能，我们需要一种不需要改变代码、不需要 SDK 的即插即用解决方案。随着越来越多的系统交互变得可见，例如通过网络 API 和其他明确定义的接口，黑盒监控正在成为现实。

• 使团队更容易发现问题，而无需全面了解正确答案。现今的监控工具旨在让了解系统运行方式的人能够准确地采取必要措施来修复错误。团队不应该需要理解延迟阈值应该设置为多少，或者错误率应该是多少，才能开始理解系统的工作方式。未来易于使用的监控和可观察性工具应该帮助软件团队填补这方面的知识空白。

在监控和可观察性方面，我们拥有强大的工具，但我们需要的是什么“不”？这是我们整个行业都需要共同思考的问题，以下是一些初步的想法：

• 我们不是为了优化极限性能而构建工具。他们的目标是确保在负载高时系统不会崩溃。回答诸如“是否有错误？”和“是否有任何耗时过长的操作？”这类基本问题通常不需要精确的机械设备。

• 准确跟踪请求和响应在系统中大有裨益，但通常并非必需。以一个例子来说明：我有个朋友在类似 FAANG 的公司工作，他们的追踪工具只有不超过五个主要工程师使用。

• 我们需要的最少监控信息是什么？在查找问题根源时，仅仅知道问题来自哪个进程的唯一标识符是否足够？我很愿意看到更多关于在寻找和解决问题时“最小可行信息”的讨论。

进一步讨论这些问题的答案可以帮助我们建立对使用现有工具进行监控的最低标准，而不是理想标准。

削减债务

为了帮助团队偿还监控债务，我们需要改变开发者工具的思维方式。我们需要更多能够在技术债务、监控债务和对底层系统或工具的理解很少的情况下使用的工具。

今天，一个新的初级人员加入一个团队并成功处理一个事故是一件非常了不起的事。但是我们已经在新闻中看到了这样的例子，而且技术工作场所的动态意味着我们应该预料到更多这样的事情会发生。为什么不让一个初级开发者更容易地处理任何事故呢？

对于监控债，你怎么看？

推荐阅读：