可观察性驱动开发与监控有什么不同？随着我们的分布式系统变得越来越复杂，随着我们对DevOps测试、自动化和效率的追求，筒仓的打破，为了了解代码中未知的未知，ODD作为一种超级监控而出现。本文包括Honeycomb创始人Charity Majors的见解。
本文要点
随着微服务和容器使系统变得更加分散和复杂，未知的未知也在增加。
只在发布后进行监控是不够的，你只有在完全了解系统的潜在故障时才能获得成功。
可观察性驱动开发（ODD）通过工具和开发人员的结合来观察系统的状态和行为，通过这种方式你可以更多地了解系统的缺陷模式。
监控通常由运维人员在发布后完成，而可观察性则是生产环境中的事件优先测试。
可观察性，就像整个DevOps运动一样，是关于成为一个更好的软件管理员，为接下来的开发人员留下线索，向他们说明你为什么在产品中这样做。
毫无疑问，系统越分散就越复杂。这使得24/7监控和随叫随到的轮流值班对大多数公司来说都至关重要。但是，可观察性是如何影响我们越来越短的DevOps反馈循环的呢？本文概括介绍了从Honeycomb创始人和可观察性的强烈支持者Charity Majors那里了解到的关于可观察性驱动开发的经验。
用DevOps重新激发开发人员的活力
在伦敦举办的CloudNative 大会上，Majors说：“起初，反馈回路是，当你造成了破坏，人们会对你大喊大叫，然后，当你修好它的时候，他们就会称赞你。但后来，互联网出现了，我们的系统变得更加复杂。”
Majors回忆说，我们都是从拥有自己的软件开始的——因为谁还会拥有它——但是，当我们距离拥有它越来越远的时候，我们就失去了判断错误的能力。筒仓让开发人员越来越远离代码的运行，DevOps运动是“一种回归优雅、回归良性反馈循环状态的尝试，”Majors这样说道。
每个开发人员都需要拥有自己的代码，从编写到部署，再到调试和再次部署。Majors认为，少了任何东西就不是完全的DevOps：
它使软件变得更好，调试人员在软件运行期间进行调试时可以获得最相关的上下文信息。
她接下来介绍了Charity的DevOps原则：
编写代码的人可以也应该部署他们的代码并在生产环境中提供支持。
DevOps自动化的目的不仅仅是为了提高速度，它还是为了将开发人员从非创造性的、乏味的修复工作中解放出来，重新激发并利用开发人员的内在动机和创造力：
让我们感到满足和欣慰的东西全和自主性、感觉被授权以及构建一些重要的东西并关心它是否被完成好有关。
当然，这与Dan Pink提出的知识型员工的三个关键内在动机相一致：自主性、精通性和目的性。
然而，开发人员一次又一次地发布在本地设置中看起来没有问题的代码，而一旦部署，各种问题就接踵而至。发现问题可能就需要几天时间，就更不用说解决问题了。Majors警告说：
分布式系统的第一个教训是，你的系统永远不会全无问题——任何时候都存在许多灾难性状态。
然而，一旦你运用了可观察性驱动开发，使用了合适的栈、工具，特别是可视化，你就可以更快地发现和解决相同的系统缺陷，通常是几个小时甚至几分钟。
可观察性驱动开发如何帮助开发人员了解他们的系统
什么是可观察性开发？它利用工具和有实际经验的开发人员观察系统的状态和行为，让你可以更多地了解该系统，包括缺陷模式。实际上，ODD是在查询系统，而监控只是为系统设置阈值并进行测量。
Majors认为，测试驱动开发——编写测试，然后编写通过该测试的代码的过程——现在已经准备好发展成可观察性驱动开发。两者都属于行为驱动开发的范畴，但ODD对行为表现出了更好的理解。
Majors说，你还可以通过可观察性驱动开发过程实现随时待命。可观察性是控制理论的一部分，该理论研究如何控制复杂的分布式系统。
仅通过询问系统的话，你能知道你的系统、你的代码里发生了什么。如果不提供新代码，你能够回答新问题吗？
Majors强调，这关乎实现恰当的抽象级别，而不是生成更复杂的代码库：
当你有一个可观察的系统时，你的团队将在没有先验知识的情况下快速可靠地跟踪任何新问题。他们会理解代码和缺陷的用户体验、行为以及原因。
可观察性并不否定监控，监控仍然是DevOps范畴的一个重要部分。但据专业人士称，在过去的里，监控并没有跟上时代的步伐，仍然主要适用于内部需求。
它会把过去中断时的残余信息转换为那些指示板需要表达的东西——只有大约2%的软件工程师理解这一点。
Majors引用自动化工具Sensu工程副总裁Greg Poirier的话说：“监控已死”。Poirier认为，随着时间的推移，对系统及其组件的行为和输出进行观察和检查的行为——这是对可观察性驱动开发的良好定义——使得对复杂系统进行监控成为一种过时的模型。
Majors说，“很重要的一点是，要构建对人们有意义的工具，让他们生活在同一个现实中。”他谈了清晰的、跨组织的仪表盘的必要性。
对于Majors来说，可观察性就是确保“已知的未知”大于或等于“未知的未知”。
有些问题只有你找到方法才能看出来。你必须收集细节信息，这样才能找到其中的任何一个。
Majors将可观察性称为寻找异常值的游戏——如果你有十几个故障案例，根据收集到和查询到的数据，它们有什么共同之处？她说，你应该关心每个请求是否能够成功，以及是否能够让资源端到端地工作。
分布式系统面临着巨大的挑战，因为它们实际上更类似于一个相互连接的系统网络，其中许多系统超出了我们的控制范围。因此，无法直接观察它们。
监控是监控，而观察是生产环境中事件优先的测试
Majors指出，“架构的每个部分都是独一无二的，所以你必须测试它。你必须在生产环境中测试它，因为在进入生产环境之前，你只能测试这么多。”她解释说，部署代码不是一个只有开/关状态的二元开关。
当然，你可以在部署到过渡环境之前和部署到生产环境之后进行测试，但这可能会耗尽通常有限的工程资源。Majors建议接受这样的现实，无论你是否打算在生产环境中进行测试，并建议使用类似于金丝雀测试这样的技术作为保障，帮助你实现可观察性。
她将可观察性称为缺失的环节，它允许软件所有者在生产环境中进行测试，提供软件的事件优先视角，软件是如何被使用的，以及它对这种使用的反应如何。
Majors说，良好的自动化监控包括以下最佳实践：
许多可操作的活动检查和警报
主动通知工程师故障和告警
维护一个运行手册，保证生产系统的稳定性和可预测性
对紧密耦合的系统集群同时崩溃有预期
但是，对于微服务，它变得更加复杂，有更多“未知的未知”。
有太多的组件和存储系统，你无法在头脑中对整个系统建模。系统的健康并不重要——每个请求的健康才是最重要的。
TDD只覆盖了已知的未知，这成为了一个支持问题。这些都是可预测的，可以在可预测的时间框架内进行处理，并且可以在仪表板上进行监控。
“未知的未知”仍然是一个工程问题。通常，在修复的过程中，这些问题是没有预期结论的，需要对系统进行探索和创造力。这是开发者应该花时间去做的事情。可观察性解决了这个巨大的未知。
可观察性是寻找未知和发现事件
Majors说，要想正确地观察事物，你应该在考虑构建什么东西的时候就把它加入进来，让它成为你开发过程中固有的一部分。
她说，这是关于寻找未知，从内到外进行系统微调。它是关于成为下一个用户的优秀软件管理员，即使那个用户六个月后想知道你为什么会做出那样的选择。
进入软件的内部，向你自己和天真的用户说明这个软件——找到那些线索，留下它们，这样，未来的你就可以追溯到它的源头。
监控主要与度量有关，而可观察性则与事件有关。Majors建议首先致力于调试高基数事件——重要但通常是唯一的信息，如标识号、用户名和电子邮件地址——因为它们涉及大量上下文和跟踪信息。
她说，事件讲述的故事可以帮助你发现来龙去脉和异常值，从而帮助你找出问题所在。她继续说，带宽和成本限制了你随时存储“所有数据”的能力，但“因为这是我们大脑的工作方式，这是我们代码的工作方式”，所以构建聚合数据日志是至关重要的。
根据Majors的说法，创建仪表板并不是答案：“它是以往故障的产物。它会跳到答案，而不是从一个问题开始，”Majors主张什么都要实时，而不是掌握趋势。她继续解释说，可观察性要求能够从采样数据一直深入到原始请求。聚合不起作用，因为你永远无法再次展开以前合并在一起的数据。但是，抽样可以让你保留足够的细节，以便以后提出更多问题。可观察性是关于问一个问题并追踪答案。然后问一个新问题。重复这个循环，直到发现“未知的未知”。
服务所有者而不仅仅是运维者
服务确实需要所有者，而不是运维者，它们需要所有者在编写一行代码之前就关心可观察性。
在一个永远在线的DevOps新世界中，这意味着开发人员需要具有更高的运维素养，并且能够流畅地编写自己的代码。Majors说，要达到这种熟练程度并真正理解“异常”是什么样子，开发人员需要观察他们的代码在生产环境中的运行。Majors表示，这将使生产事件减少80%。
她认为，在将来的某个时候，人工智能和机器学习将使软件达到能够感知环境和自我修复的水平。
关于Majors的看法，有一个重要的前提，就是适当的可观察性将大幅减少呼叫告警，只有延迟问题会被标记出来。
关于作者
Jennifer Riggins是一位科技故事讲述者和作家，在这个领域，数字变革与文化交汇，她希望能使世界变得更美好。感兴趣的读者可以关注她的推特（@jkriggins）。
查看英文原文：[Observability-Driven Development for Tackling the Great Unknown](
