可观察性驱动开发，探索未知之地-白红宇

可观察性驱动开发，探索未知之地

阅读量：5890 次

发布时间：2019-06-19

本文共 3911 字，大约阅读时间需要 13 分钟。

可观察性驱动开发与监控有什么不同？随着我们的分布式系统变得越来越复杂，随着我们对DevOps测试、自动化和效率的追求，筒仓的打破，为了了解代码中未知的未知，ODD作为一种超级监控而出现。本文包括Honeycomb创始人Charity Majors的见解。

本文要点

随着微服务和容器使系统变得更加分散和复杂，未知的未知也在增加。

只在发布后进行监控是不够的，你只有在完全了解系统的潜在故障时才能获得成功。

可观察性驱动开发（ODD）通过工具和开发人员的结合来观察系统的状态和行为，通过这种方式你可以更多地了解系统的缺陷模式。

监控通常由运维人员在发布后完成，而可观察性则是生产环境中的事件优先测试。

可观察性，就像整个DevOps运动一样，是关于成为一个更好的软件管理员，为接下来的开发人员留下线索，向他们说明你为什么在产品中这样做。

毫无疑问，系统越分散就越复杂。这使得24/7监控和随叫随到的轮流值班对大多数公司来说都至关重要。但是，可观察性是如何影响我们越来越短的DevOps反馈循环的呢？本文概括介绍了从创始人和可观察性的强烈支持者那里了解到的关于可观察性驱动开发的经验。

用DevOps重新激发开发人员的活力

在伦敦举办的上，Majors说：“起初，反馈回路是，当你造成了破坏，人们会对你大喊大叫，然后，当你修好它的时候，他们就会称赞你。但后来，互联网出现了，我们的系统变得更加复杂。”

Majors回忆说，我们都是从拥有自己的软件开始的——因为谁还会拥有它——但是，当我们距离拥有它越来越远的时候，我们就失去了判断错误的能力。筒仓让开发人员越来越远离代码的运行，DevOps运动是“一种回归优雅、回归良性反馈循环状态的尝试，”Majors这样说道。

每个开发人员都需要拥有自己的代码，从编写到部署，再到调试和再次部署。Majors认为，少了任何东西就不是完全的DevOps：

它使软件变得更好，调试人员在软件运行期间进行调试时可以获得最相关的上下文信息。

她接下来介绍了Charity的DevOps原则：

编写代码的人可以也应该部署他们的代码并在生产环境中提供支持。

DevOps自动化的目的不仅仅是为了提高速度，它还是为了将开发人员从非创造性的、乏味的修复工作中解放出来，重新激发并利用开发人员的内在动机和创造力：

让我们感到满足和欣慰的东西全和自主性、感觉被授权以及构建一些重要的东西并关心它是否被完成好有关。

当然，这与Dan Pink提出的知识型员工的相一致：自主性、精通性和目的性。

然而，开发人员一次又一次地发布在本地设置中看起来没有问题的代码，而一旦部署，各种问题就接踵而至。发现问题可能就需要几天时间，就更不用说解决问题了。Majors警告说：

分布式系统的第一个教训是，你的系统永远不会全无问题——任何时候都存在许多灾难性状态。

然而，一旦你运用了可观察性驱动开发，使用了合适的栈、工具，特别是可视化，你就可以更快地发现和解决相同的系统缺陷，通常是几个小时甚至几分钟。

可观察性驱动开发如何帮助开发人员了解他们的系统

什么是可观察性开发？它利用工具和有实际经验的开发人员观察系统的状态和行为，让你可以更多地了解该系统，包括缺陷模式。实际上，ODD是在查询系统，而监控只是为系统设置阈值并进行测量。

Majors认为，测试驱动开发——编写测试，然后编写通过该测试的代码的过程——现在已经准备好发展成可观察性驱动开发。两者都属于行为驱动开发的范畴，但ODD对行为表现出了更好的理解。

Majors说，你还可以通过可观察性驱动开发过程实现随时待命。可观察性是的一部分，该理论研究如何控制复杂的分布式系统。

仅通过询问系统的话，你能知道你的系统、你的代码里发生了什么。如果不提供新代码，你能够回答新问题吗？

Majors强调，这关乎实现恰当的抽象级别，而不是生成更复杂的代码库：

当你有一个可观察的系统时，你的团队将在没有先验知识的情况下快速可靠地跟踪任何新问题。他们会理解代码和缺陷的用户体验、行为以及原因。

可观察性并不否定监控，监控仍然是DevOps范畴的一个重要部分。但据专业人士称，在过去的20年里，监控并没有跟上时代的步伐，仍然主要适用于内部需求。

它会把过去中断时的残余信息转换为那些指示板需要表达的东西——只有大约2%的软件工程师理解这一点。

Majors引用自动化工具工程副总裁的话说：“监控已死”。Poirier认为，随着时间的推移，对系统及其组件的行为和输出进行观察和检查的行为——这是对可观察性驱动开发的良好定义——使得对复杂系统进行监控成为一种过时的模型。

Majors说，“很重要的一点是，要构建对人们有意义的工具，让他们生活在同一个现实中。”他谈了清晰的、跨组织的仪表盘的必要性。

对于Majors来说，可观察性就是确保“已知的未知”大于或等于“未知的未知”。

有些问题只有你找到方法才能看出来。你必须收集细节信息，这样才能找到其中的任何一个。

Majors将可观察性称为寻找异常值的游戏——如果你有十几个故障案例，根据收集到和查询到的数据，它们有什么共同之处？她说，你应该关心每个请求是否能够成功，以及是否能够让资源端到端地工作。

分布式系统面临着巨大的挑战，因为它们实际上更类似于一个相互连接的系统网络，其中许多系统超出了我们的控制范围。因此，无法直接观察它们。

监控是监控，而观察是生产环境中事件优先的测试

Majors指出，“架构的每个部分都是独一无二的，所以你必须测试它。你必须在生产环境中测试它，因为在进入生产环境之前，你只能测试这么多。”她解释说，部署代码不是一个只有开/关状态的二元开关。

$\"\"$

当然，你可以在部署到过渡环境之前和部署到生产环境之后进行测试，但这可能会耗尽通常有限的工程资源。Majors建议接受这样的现实，无论你是否打算在生产环境中进行测试，并建议使用类似于金丝雀测试这样的技术作为保障，帮助你实现可观察性。

她将可观察性称为缺失的环节，它允许软件所有者在生产环境中进行测试，提供软件的事件优先视角，软件是如何被使用的，以及它对这种使用的反应如何。

Majors说，良好的自动化监控包括以下最佳实践：

许多可操作的活动检查和警报

主动通知工程师故障和告警

维护一个运行手册，保证生产系统的稳定性和可预测性

对紧密耦合的系统集群同时崩溃有预期

但是，对于微服务，它变得更加复杂，有更多“未知的未知”。

有太多的组件和存储系统，你无法在头脑中对整个系统建模。系统的健康并不重要——每个请求的健康才是最重要的。

TDD只覆盖了已知的未知，这成为了一个支持问题。这些都是可预测的，可以在可预测的时间框架内进行处理，并且可以在仪表板上进行监控。

“未知的未知”仍然是一个工程问题。通常，在修复的过程中，这些问题是没有预期结论的，需要对系统进行探索和创造力。这是开发者应该花时间去做的事情。可观察性解决了这个巨大的未知。

可观察性是寻找未知和发现事件

Majors说，要想正确地观察事物，你应该在考虑构建什么东西的时候就把它加入进来，让它成为你开发过程中固有的一部分。

她说，这是关于寻找未知，从内到外进行系统微调。它是关于成为下一个用户的优秀软件管理员，即使那个用户六个月后想知道你为什么会做出那样的选择。

进入软件的内部，向你自己和天真的用户说明这个软件——找到那些线索，留下它们，这样，未来的你就可以追溯到它的源头。

监控主要与度量有关，而可观察性则与事件有关。Majors建议首先致力于调试高基数事件——重要但通常是唯一的信息，如标识号、用户名和电子邮件地址——因为它们涉及大量上下文和跟踪信息。

她说，事件讲述的故事可以帮助你发现来龙去脉和异常值，从而帮助你找出问题所在。她继续说，带宽和成本限制了你随时存储“所有数据”的能力，但“因为这是我们大脑的工作方式，这是我们代码的工作方式”，所以构建聚合数据日志是至关重要的。

根据Majors的说法，创建仪表板并不是答案：“它是以往故障的产物。它会跳到答案，而不是从一个问题开始，”Majors主张什么都要实时，而不是掌握趋势。她继续解释说，可观察性要求能够从采样数据一直深入到原始请求。聚合不起作用，因为你永远无法再次展开以前合并在一起的数据。但是，抽样可以让你保留足够的细节，以便以后提出更多问题。可观察性是关于问一个问题并追踪答案。然后问一个新问题。重复这个循环，直到发现“未知的未知”。