Charity Majors 对于系统运营结果的可观测性与理解的论述

本文要点

• 当前开发软件的最佳实践的方法（诸如使用微服务、容器、原生云、调度器和无服务器）应对的都是更为复杂的系统。但是，我们的监控方法并没有跟上这一发展趋势。
• Majors 认为系统的健康不再重要。我们已经进入了一个新时代，真正重要的是单独事件的健康、个人用户的体验、或人们对购物车的体验（或其它更大基数的个体事件）。
• 现在工程师们正在谈论的是可观测性而不是监控，或者说谈论的是未知的未知事件而不是已知的未知事件。
• 数据库和网络曾经是系统专家的最后两个神圣领地。曾几何时，它们拥有自己专门的工具、内部语言和专家，并且在那个时候它们还不属于工程组织。现在来看，那个时代已经结束了。
• 工程师有责任了解我们正在构建的运营结果和故障模式，在我们能修复的地方就自动修复，在修复不了的地方，也要优雅地退出，并让具有核心处理能力的供应商，尽可能多地承担运营负载。
• 不要试图“监控一切”，你做不到的。工程师经常浪费很多时间来做这件事，这让他们无法追踪关键路径，重要的警报淹没于大量不相关的信息中。
• 未来将会愈发混沌，我们都在朝着这个方向发展，到那时你必须要有规程，这样才能避免过多的警报分页。

Charity Majors 建议说，很多人没有大型分布式系统方面的问题，如果你能避开单体架构、LAMP 堆栈和一些监控检查，那么你绝对应该按照我的建议来行事。

InfoQ 最近采访了 honeycomb.io 的 CEO 兼《数据库可靠性工程》合著者 Charity Majors （与 Laine Campbell 合著），讨论了可观测性和监控。

InfoQ：你好，Charity，今天你接受 InfoQ 的访谈，我表示万分感谢。你方便介绍一下自己吗？同时你可以分享一下你在监控系统方面尤其是数据存储技术方面的经验吗？

好的！我是 honeycomb.io 的运维工程师与联合创始人，我还机缘巧合地担任了首席执行官。17 岁起，从大学到 Second Life、Parse，再到 Facebook 的一系列经历，让我开始接触互联网的各个领域。我一直倾向于运营，这是因为我喜欢混沌和数据，因为我有上帝情节。在材料很关键、不可预测且高风险时，我反而会把工作做得最好。实际上当我这么说的时候，也许我注定必定成为创业公司的 CEO。

我从来都不喜欢监控，我一直设法去避开它。我会使用原型或构建一个 v1 版本的系统，或者去深入挖掘、调试、校正某个系统，但是我会避开从事构建指标和控制面板、进行监控检查等乏味的工作。一涉及到可视化和图形，我就会变得毫无招架之力。

InfoQ：你能否介绍一下过去五年来运营监控和基础设施监控的发展情况？云、容器和新（旧）模块化架构是如何影响监控的？

在过去五年里，技术变革的浪潮势如破竹。微服务、容器、原生云、调度器、无服务器……所有这些都是应对更复杂系统的方法，而摩尔定律、移动离散和技术产品平台化等因素造就了更复杂的系统。全才软件工程师正在成为今天的主角，他们正在研究用于内部服务和第三方服务的所有 API。在这场风暴的中心以外，制作一款可用的软件，正是他们的一项工作。

有趣的是，监控并没有真正改变。在过去的 20 年都没有改变。

你仍然得依赖指标、控制面板和日志，这些东西实际上也有了长足的进步。但是，监控有一套非常稳定的工具和技术、大家熟知的极端例子和最佳实践，它们全部面向监控并旨在确保系统仍然处于已知状态。

但是，我认为系统的健康不再重要。我们已经迈入了一个重要的时代，真正重要的是单一事件的健康、个人用户的体验、或人们对每台购物车的体验（或其它更大基数的个体事件）。对于分布式系统，你不用关心系统的健康状况，而应关心事件或 slice 的健康状况。

这就是为什么人们在谈论可观测性而不是监控，在谈论未知的未知而不是已知的未知，以及在谈论分布式追踪、honeycomb 和旨在向外部观察者描述系统内部状态的其他事件级工具。

InfoQ：请重点谈谈数据存储技术以及你与 Laine Campbell 合著的那本新书《数据库可靠性工程》，在过去的几年中，对这些技术进行监控的方法是如何发生改变的？

数据库和网络是系统专家的最后两个神圣领地。曾几何时，它们拥有自己专门的工具、内部语言和专家，并且在那个时候它们还不属于工程组织。现在来看，那个时代已经结束了。现在出现了诸如“DBRE”（数据库可靠性工程师）这样的职位，拥有这种职位的人不但具备深厚的专业知识，同时也有能力从事持续集成 / 持续部署、代码审查和基础设施构自动化等工作。

这也适用于监控和可观测性工具。工具创造了储料仓。如果你希望工程团队具有跨职能的能力，如果你需要一个共享的值班轮转……那么和处理其余堆栈一样，你必须使用同样的工具来调试和了解你的数据库。这就是为什么说，为了获取数据，honeycomb 和其他下一代服务会专注于提供与软件无关的接口。你可以把任何内容变成一个数据结构，我们可以帮助你进行调试和探索。对于工程团队来说，这是一个巨大的飞跃。

InfoQ：随着 AWS RDS 和 Google Spanner 等 DBaaS 技术的普及，你认为监控数据库技术的重要性是上升了还是下降了？另外，这会给最终用户 / 操作者带来什么影响？

监控不是真正的重点。我的大部分监控工作都外包给了 AWS，效果不错！虽然数据库本身非常好，但是在 honeycomb，我们还是使用 RDS 和 Aurora，因为数据库不是我们的核心竞争力。如果 AWS 出现性能下降，就让它们分页吧。

我不在行的领域是可观测性、仪表和架构。我们已经构建了自己的系统，以便可以应对包括 AWS 可用区减少在内的尽可能多的问题 。我们测试了代码，并且从 MySQL 中收集了大量的内部性能信息，这样我们可以提出关于堆栈（包括数据库）的任意问题。这种自检和仪表的丰富生态系统，并没有依照传统监控堆栈，去特别关注可操作警报和中断。

工程师有责任了解我们正在构建的运营后果和故障模式，在我们能修复的地方就自动修复，在修复不了的地方，也要优雅地退出，并让具有核心处理能力的供应商，尽可能多地承担运营负载。坦率讲，数据库只不过是另一个软件。在将来，你希望尽可能像处理无状态服务以及其余的堆栈一样处理数据库（从具体操作的角度来说，数据库并不能完全无状态化）。

InfoQ：从业务和运营的角度，你认为 QA/ 测试人员对系统的监控和可观测性起什么作用？QA 团队是否应该参与 SLO（服务水平目标）和 SLA（服务水平协议）的定义？

我从未与 QA 或测试人员合作过。我感觉 QA 在十年前就失去机会了，并且 QA 确实也未能与时俱进。我非常喜欢运维工程专业，而且我正在努力确保运维不会重蹈 QA 的覆辙。运维专家总会有其一席之地…但是我们的角色越来越小众，对于大多数人来说，我们将处于 API 的另一边。

开发人员将拥有并运维自己的服务，这是件好事！作为运维专家，我们的作用是赋予他人能力并扮演教育者的角色，并成为他人的“能力放大器”。我们的职能还有构建庞大的世界级平台，让开发人员用它们来构建组合式基础设施栈和流水线，比如 AWS 和 honeycomb。

InfoQ：从数据存储和应用程序的角度来看，最常见的监控反模式是什么？你能推荐一些方法来避免这些问题吗？

“监控一切”。哥们，你做不到。你做不到。工程师经常浪费很多时间来做这件事，这让他们无法追踪关键路径，重要的警报淹没于大量不相关的信息中。未来将会愈发混乱，我们都在朝着这个方向发展，到那时你必须拥有相关规程，这样才能避免出现过多的警报分页还有请求率、延迟、错误率、饱和度，或者是一些强调关键性能指标（KPI）的代码路径的端到端检查。

人们在分页上耗费了大量时间，因为它们的可观测性很糟糕，他们不相信工具可以让他们进行可靠的调试以及诊断问题。所以他们注重利用数十个或数百个警报来进行过度分页，这些警报通过模式匹配来寻找根本原因的线索。他们大部分工作都是盲目的，因为他们不安于只探索生产中所发生的事情，他们需要尽可能满足自己的好奇心。我过去也是那样，所幸我们编写了 honeycomb，因此我们不必再走回头路了。

InfoQ：再次感谢提供宝贵时间与我们进行交流。你还有什么要与 InfoQ 读者分享的吗？

我所说的一切都不应该被视为标准。很多人不存在大型分布式系统这方面的问题，如果你没有这些问题，那么你可以无视我的任何建议。如果你能避开单体架构、LAMP 堆栈和一些监控检查，那么你绝对应该按照我的建议行事。终有一天，你可能会达到一个临界点，如果没有微服务和可探索事件驱动的可观测性，你要实现目标会变得越来越困难和复杂，但是你还是应当尽力推迟这一天的到来。尽可能让你的构建工作变得简单些。

受访者简介

Charity Majors 是 Honeycomb.io 的联合创始人和工程师，该公司主要从事将时间序列速度与丰富的事件原始力相结合的工作，这项工作可为复杂系统提供交互式迭代调试。她先后在 Facebook、Parse 和 Linden Lab 等公司担任过系统工程师和工程经理，不过每次到最后她总被安排兼管数据库。她喜欢自由言论、“自由软件” ，平时也爱小酌一杯上乘的泥炭口味单麦芽威士忌。

查看英文原文： https://www.infoq.com/articles/charity-majors-observability-failure