可观察性是种文化|可靠性|应用程序|观察性

为了利用可观察性，我们需要对包含整个公司并超越工具的企业文化进行重大转变。

每日分享最新，最流行的软件开发知识与最新行业趋势，希望大家能够一键三连，多多支持，跪求关注，点赞，留言。

我对将“调试”一词应用于几乎任何事情感到内疚。我孩子的乐高不适合，让我们调试一下。可观察性是为数不多的真正保证这个绰号的学科之一：它是调试。但是传统的调试并不真正适合可观察性实践。我通常将其称为“预认知调试”。我们需要提前大致了解我们的调试过程将是什么样子，以进行有效的可观察性故障排除。

请注意，这不适用于开发人员可观察性，这是一种特殊情况。这是一个更动态的过程，更类似于典型的调试会话。这是关于更传统的监控和可观察性：我们需要首先检测系统并添加日志、指标等以涵盖我们需要的信息，因为我们稍后将调查这个问题。

我之前写过关于过度伐木的祸害。这同样适用于可观察性指标，随着我们收集越来越多的数据，保留和处理的成本会迅速超过可观察性的好处。我们最终会遇到一个更大的问题。我们需要选择我们的战斗，记录“正确的数量”并监控“正确的数量”，不多也不少于我们需要。为此，我们需要了解我们正在处理的风险并尝试最大化重叠在我们的调查中。

混沌工程作为灵感

按照混沌工程的传统，我们会组织一场由“灾难大师”精心策划的“游戏”来练习灾难准备。这是一个很棒的练习，也是构建“肌肉”的好方法。它不适合可观察性架构，因为可观察性处理的是细微差别而不是“火”。

可观察性需要一个类似的游戏，但需要一个深思熟虑的游戏，我们的团队在其中竞争寻找我们的系统可能失败的方式。把它想象成宾果游戏。一旦我们有一个充满潜在故障的电子表格，我们需要将故障映射到我们希望对每个潜在故障具有的可观察性。例如，在黑客入侵的情况下，我们希望在访问任何受限资源时记录用户 ID。

一旦我们绘制了所有这些愿望，我们就可以审查它们，并尝试统一一些指标和日志。然后，我们可以实现它们，这样我们的可观察性就可以回答我们追踪问题所需的一切。

我们会错过一些事情吗？

明显地。这是过程的一部分。我们将需要迭代和调整它。可能需要减少一些昂贵数据点的容量以保持成本合理。毫无疑问，我们会遇到可观察性未涵盖的问题（或者其可观察性覆盖范围不明显）。在这两种情况下，我们都需要一些帮助。

我们需要专家吗？

一些可观察性爱好者认为我们不再需要领域经验来调试问题。给定一个适当可观察的系统，我们应该能够在不了解系统的任何情况下理解问题。

尽管我同意调试专家可能比领域专家更快地解决问题，但我仍然有疑问。在十年的时间里，我是一名顾问，我会去使用分析器、调试器等的公司。作为那项工作的一部分，我发现了比我更专业的领域专家所无法解决的问题。因此，这种说法背后有一些优点。

但是调试需要对我们试图理解的系统有一定的了解。这就像通过 Google 进行诊断一样。我们可能偶尔会比我们的全科医生更好地找到原因，但可能不比专家更好。显然，规则有例外，但根据我的经验，经验对于任何类型的调试都很重要。

我们自己的仪表板

我经常看到的一件事是公司中通用的“一刀切”仪表板。Grafana 是一款出色的工具，具有非凡的灵活性，但有些人将其可视化显示为单个公司仪表板。应用程序应该至少有三个仪表板：

高级别： CTO/VP研发级别；这侧重于业务指标、用户、可靠性、成本
DevOps： 关于环境的底层信息
开发人员：特定于应用程序的指标和平台信息

那里有很多重叠，但我们需要自定义仪表板。仪表板的整个想法是在一个地方查看所有重要的内容。一般来说，容器上的 CPU 利用率可能对我来说很有趣，但更有可能的是，这只会分散注意力。我想知道授权系统是否存在问题，因为用户在登录时遇到的错误率增加。这些指标应该是最重要的。

当我在浏览器中打开一个新选项卡时，我看到了 Grafana。这应该是每个团队成员的主页。我们系统的“健康”观点应该铭刻在我们的脑海中，这样我们就可以立即注意到环境中的微小偏差并采取相应的行动。

与可观察性一起成长

随着系统的增长，我们需要在引入功能的拉取请求中包含可观察性和指标。在第一天没有可观察性，任何事情都无法启动。它应该蚀刻到代码审查过程中，并且应该与测试覆盖率要求相提并论。

与测试覆盖率不同，我们没有可以依赖的指标来验证可观察性是否足以满足快速发展的需求；所以在这个时候，这是审稿人肩上的重担。但还有一个更大的负担：成本。随着我们的成长，这些变化会影响成本，这可能会突然飙升至引发破产的高度。成本并不总是容易监控，但它是我们应该每天查看的衡量标准。通过跟踪该指标并尽早发现成本峰值，我们可以在不放弃成本效益的情况下保持系统稳定和可管理。