遥测和测量的艺术

本篇内容是根据2020年2月份#117 Telemetry and the art of measuring what matters音频录制内容的整理与翻译

遥测技术上手很困难。您应该跟踪哪些指标？哪些指标很重要？它们会帮助您预测并避免潜在的问题吗？什么时候开始比较好？你应该把它推迟到以后吗？在本集中，我们将与 Snapt 的嘉宾 Dave Blakey 讨论一些要收集的常见指标、如何开始遥测以及更多内容。

过程中为符合中文惯用表达有适当删改, 版权归原作者所有.

Johnny Boursiquot: 大家好，欢迎收听本期的 Go Time。我是 Johnny Boursiquot，今天和我一起的有 Jon Calhoun、Jaana Dogan，以及特别嘉宾 Dave Blakey。欢迎，Dave。

Dave Blakey: 谢谢，谢谢邀请我来。

Johnny Boursiquot: Jaana，很高兴你回来了。感觉你最近在全世界到处旅行...

Jaana Dogan: 不是这样的...！

Johnny Boursiquot: 不是真的？

Jaana Dogan: 我只休息了一周，真的。

Johnny Boursiquot: 好吧好吧...不过看你发的照片，我还以为你在旅行呢。

Jaana Dogan: 不过下周我可能会去伦敦，如果到时候我和 Mat 同时从一个房间加入，也别惊讶。

Johnny Boursiquot: 哦，那感觉会很酷。不过你确实在世界各地跑啊。过去一个月你去的地方比我这一年都多。虽然，今年才刚开始啊，哈哈。Jon，你怎么样？

Jon Calhoun: 我挺好的。

Johnny Boursiquot: 你最近很忙啊，发布了好多课程、培训什么的。

Jon Calhoun: 是的，最近确实很忙...其实一直都很忙，只不过最近所有事情都刚好完成了，所以看起来特别忙。

Johnny Boursiquot: 能上线是件好事。干得漂亮。Dave，我们对你了解不多，但今天我们会好好了解一下。我们知道你做什么工作，也知道你在哪家公司，或者说为谁工作...不过今天的节目我们要讨论一个特别的主题，这也是我作为云工程师特别关心的话题---遥测（Telemetry），不过你得原谅我的口音，法语有时会蹦出来...Telemetry...你可以纠正我发音。

Dave Blakey: 我觉得你发得很好。

Johnny Boursiquot: 好，谢谢。遥测是我们在做云运维工作时非常依赖的东西，但它并不仅限于此。遥测的用例非常广泛，而你正在从事的工作涉及大量这一方面的内容。不过在深入讨论之前，我想我们先来统一一下概念，聊聊什么是遥测，它的用途是什么，谁最适合利用它。

Dave Blakey: 当然可以。正如你所说，遥测是一个非常广泛的概念。我们可以把它缩小到计算领域，尤其是现代计算的范畴。遥测的核心其实是从远端传感器或设备中收集并存储数据。我认为它不仅仅是收集和存储，还要利用这些数据，虽然不一定每次都会用到。它可以是你家热水器用了多少电或天然气，也可以是你某个 API 后端的响应时间。这都是关于获取信息的过程。

最近，它更多地被应用在构建应用程序的过程中添加遥测数据的技术与领域。大家都知道，当系统开始扩展时，如果你还没加入遥测，那时候再加就太晚了。

Johnny Boursiquot: 这确实是那种在项目开始时可能不觉得重要，但一旦需要时，你会希望一开始就加入的东西，对吧？

Dave Blakey: 完全正确。有时候你甚至不知道自己需要它，直到问题已经积累到无法忽视的地步。你会遇到瓶颈，或者其他问题...这是遥测最传统的用例，但现在它在安全性、扩展性等方面的作用也越来越大。系统已经不是静态的了，遥测在这些方面的应用也比单纯解决“网页为什么慢”的问题要广泛得多。

Jaana Dogan: 是不是因为缺乏足够成熟的实践？我看到很多公司，特别是刚起步时，他们并不太关心生产环境的优秀性，或者 SRE（站点可靠性工程）实践，遥测其实是其中很重要的一部分。他们可能认为这是可以放到后面再考虑的事情，结果到最后发现工作量太大，感到非常压抑。

Dave Blakey: 没错。情况往往会越来越糟，因为你开始随意地加一些遥测数据，而没有真正解决问题。其实最好的方式是尽量采集所有重要的组件数据，甚至包括一些你现在觉得不重要的部分。目的不是为了立刻解决问题，而是为了在未来能够更好地了解整个系统。

很多时候，如果你问“为什么我的网站慢了？”一个简单的解决办法可能是“我需要更多的 Web 服务器。”但问题可能出在数据库服务器上。这是一个常见的例子，类似的情况有很多。问题的根源可能并不是一开始就显而易见的，而你收集的数据越多，越容易找出真正的问题所在。这还只是关于可扩展性方面的问题。

Jaana Dogan: 那从规划的角度来说，什么时候开始考虑遥测是最好的？应该在设计阶段就开始考虑吗？

Dave Blakey: 绝对是的。我觉得如果你是在启动一个大型项目，可能大家都会考虑这个问题。但我觉得现在更有必要讨论的是那些中小型项目。显然，如果你只是为五个人的小团队做一个内部 Wiki 系统，那可能不是什么大问题。但如果你在构建一个项目，我认为从第一行代码开始就应该考虑遥测。这可以很简单---你可以在系统中加入一个类，随时可以发送一些随机的指标或度量数据。只要把这个过程做得足够简单，就可以开始往代码里加这些东西。

在我们公司，我们有一个所谓的“代码契约”，里面有九条规则，其中一条是所有代码都必须使用我们添加的遥测助手，因为我们知道迟早会遇到问题。而这其实并不需要太多的开发工作。

Jaana Dogan: 是的，我见过很多人为了收集什么数据、怎么收集而争论不休。我觉得大家对于哪些数据对项目成功至关重要，可能还有点迷茫。所以你必须从整体上考虑可用性、可调试性等多个方面，才能更好地理解你想要收集什么数据，以及如何利用这些数据。

很多时候，小公司因为启动得太晚而失败。所以在项目的早期阶段就开始考虑这些问题非常重要。

Dave Blakey: 完全同意。我更愿意看到你收集了一些无用的数据，或者数据格式不是最优的情况，也不愿看到你什么都没收集，或者因为觉得工作量太大而迟迟不开始。最终，我的建议是根据项目和业务的需要，确保你在做些什么，这个过程会逐渐演变和完善。

Johnny Boursiquot: 我想深入探讨一下这个话题。Jaana，你提到要跟踪重要的东西。当我想到对我来说重要的事情时，作为一个负责基础设施的人，我关心的和后端开发人员或前端开发人员关心的东西肯定不同。而最终用户，他们使用我们提供的产品，关心的又是另外的东西。

我猜遥测在所有这些领域都有用，但最终，业务最关心的是用户体验。那么，当你组建团队并准备开始工作时，什么时候开始划分对不同团队和不同利益相关者来说重要的内容？

Dave Blakey: 我认为这个过程是迭代的。对于一个非常大的项目来说，这可能会是设计决策的一部分，从一开始就内置在系统中，并且会有一个非常复杂的遥测方案，因为项目需要它。但对于中小型项目---这里的“中型”也可能是一个很大的项目。我认为我们的产品属于中型项目，代码量有六百万行。在这种类型的项目中，我认为你可以通过迭代的方式进行。

我们首先确保从代码的角度来看，开发人员正在存储他们认为重要的指标，之后可以再增加更多的内容。我们还会从性能和系统可扩展性的角度确保存储我们认为重要的数据。然后，当我们遇到问题时，哪些地方缺少遥测数据或哪些地方需要遥测数据就会变得显而易见。这也是遥测的有趣之处，你并不总是知道你会遇到什么问题。

比如说，你作为云工程师，可能会说“我的遥测数据显示，我的十个云实例的 CPU 使用率达到了 80%，我可能需要再增加 20 个实例。”但你可能没有注意到，失败的登录次数比平常多了 200% 或 2000%... 其实你遇到的是一次暴力攻击。如果你有所有这些指标---这可能有点超前了，但我认为最好的遥测系统是存储尽可能多的数据，并让某种机制来检测异常。

如果你有这样一个系统，它会告诉你“这在统计上是个异常”，当你去查看问题时，如果某些东西弹出来了---比如某个国家的请求突然暴增，登录失败次数激增---你很快就会意识到问题并不是你一开始以为的那样。或者你找不到问题，必须深入挖掘，然后才会为未来建立跟踪这种情况的机制。

Jon Calhoun: 如果你刚开始接触遥测，不知道从哪入手，比如你之前从来没做过遥测，你会建议他们先尝试哪些基本指标？

Dave Blakey: 我认为可以分为三个领域。第一个领域是你的服务器。无论是云实例、虚拟机、容器，还是其他，实际承载你的系统的服务器---大多数人没有意识到他们在遥测这条路上已经走了多远... 因为他们可以知道 CPU 使用率、内存使用情况，或者服务器是在线还是离线。这些都是数据点，对吧？比如服务器是否工作。你开始监控这些基本的内容，你就会对你的服务器有一些基本的理解。

第二个是网络。这是大多数扩展和遥测数据变得非常有用的地方。网站或 API 的上线下线已经是过去的事情了，但如果你的网站或 API 的平均响应时间是 200 毫秒，而昨晚的部署后变成了 400 毫秒，这就是非常重要的信息。简单的 HTTP 响应时间和状态码，比如 200、400、500 状态码的数量。光是发现错误响应的比例从 0.1% 增加到 5%，就可以帮助你快速识别问题。

最后一个也是最关键的遥测领域，就是应用程序本身。你开始跟踪对你来说重要的东西。如果你有一个用于缓存的键值存储，跟踪一下缓存命中率。如果缓存命中率急剧下降，你就知道可能会出现问题。数据库的响应时间如何？你存储了多少缓存？有多少用户登录？所有让你的网站正常运行的组件，你都可以开始跟踪。这其实非常简单... 你只需要调用一个函数，比如 stats.Gauge(10) users.Total，然后下次调用时是 stats.Gauge(12) users.Total。你只要开始跟踪这些东西，你会发现这其实不难实现。更难的部分是如何对这些数据负责并真正利用它。不过这一步可以慢慢来。第一步是存储数据，让它随时可用，并且理解它如何影响你的服务或应用程序。

Johnny Boursiquot: 那么，谁应该对这些数据负责呢？是运维团队，还是开发团队，还是产品经理，又或者是所有人？

Dave Blakey: 在传统的架构中，通常 IT 运维、安全和开发是分开的部门。越是分离，它们各自关注的领域就越不同。这正是遥测的关键所在，因为正如我之前提到的，如果你看不到整个全貌，你可能无法发现问题。例如，如果你只是在 IT 运维部门，你可能会增加十台服务器，而不是意识到你其实有一个安全问题。

我们主要与一些更现代化的部署类型合作，比如 Kubernetes 相关的内容，云原生应用等。这里的使用场景有很大的不同。虽然我不太喜欢这个词，因为它被滥用了，但这有点像 DevOps 的角色。对我来说，DevOps 是指关心整个应用程序的人，他们不单单关注代码、服务器、云平台、防火墙或负载均衡器，而是关心整个应用程序的运行。而这个团队通常负责遥测、监控等工作，至少在我们的经验中是这样。

Jaana Dogan: 我认为另一个问题是，你提到了一些异常情况，或者有些团队和组织更喜欢设定一些 SLO（服务水平目标），当某些指标超出边界时会生成警报。我认为每个组织都有不同的策略。有些组织喜欢监控团队或 SRE 团队对警报做出反应，然后将问题升级或委派给其他团队，比如一线响应团队等。这与组织的运作方式有很大关系，对吧？

Dave Blakey: 你说得很对，因为我之前更多是从“出了问题，看看遥测数据”的角度出发，但正如你所说的，下一步自然就是让数据在检测到异常时呈现给相关人员。是的，企业越大，通常会有专门负责这类工作的团队。但这并不意味着小公司不能使用开源的免费工具，来实现类似的结果。

Jaana Dogan: 我们谈了很多关于指标的内容，你特别提到我们的系统变得越来越庞大，组件越来越多。最近，尤其是过去的五年，分布式跟踪和日志记录变得越来越流行，尤其是与跟踪 ID 或请求 ID 相关联的日志记录。至少有些组织将它们作为另一种遥测信号来源，你对此怎么看？

Dave Blakey: 是的，我认为对于大公司来说，这是至关重要的。我之所以谨慎用词，是因为在早期项目中或添加到现有项目中实现这一点会非常困难。你经常会发现，对于小型公司，甚至中型公司来说，这种程度的监控是很有挑战性的。我们自己可能在一个客户那里有 50 台设备，每台设备每秒生成 10 万行日志... 对于一个公司来说，存储这些信息通常超出了他们的能力。但如果你已经搭建好了获取这些信息的钩子，当你需要它时，你可以逐步扩展。

Johnny Boursiquot: 我对当前的遥测领域很感兴趣... 你提到在 Snapt 公司，你们正是从事这个业务，所以你可能对这一领域有一定的了解。我们听说过一些项目，但并不清楚它们如何定位。我想到一些项目，比如 OpenTelemetry、OpenTracing、OpenCensus... 有很多开源项目似乎在试图解决相似的问题，但它们之间似乎存在重叠。对我来说，似乎有些团队决定采用 OpenCensus，然后去寻找客户端、服务器端，做他们的事情... 但如果将来有标准，我们是否需要重新适配所有东西？感觉目前这个领域有很多变化... 你能帮我们梳理一下吗？

Dave Blakey: 是的，确实有很多变化。这和 DevOps 的情况很相似，很多情况下人们都在自己构建东西。我不是说构建整个堆栈，但确实有很多工具和定制工作，都是为了让事情按照他们想要的方式运行。我们见得最多的是人们使用像 Prometheus 和 Grafana 这样的工具来创建仪表板和可视化数据... 因为我们合作的大多数公司，他们的信息收集和传输能力大多是内部的。因为这些数据来自不同的应用程序、不同的技术栈，可能有些数据来自微软的服务器，有些来自容器，有些来自亚马逊... 但他们通常会有一个统一的仪表板、报告和分析来源，通常是像 Prometheus 这样的工具，然后他们可以自动化异常检测和数据可视化等工作。

Jaana Dogan: 作为一个在这个领域有一些经验的人 --- 我曾经参与过 OpenCensus 的工作，我认为我们可能太过于努力地试图统一各种方法；统一导出的数据格式，或者统一库的空间，或者试图建立标准... 但似乎这个领域非常拥挤，也许这并没有多大意义，因为归根结底，组织最关心的就是如何把数据传输到仪表板上，并能够利用这些数据。

Dave Blakey: 很多情况下，他们甚至不关心数据传输的可靠性，这是这个领域面临的挑战之一。如果你每秒钟或多次每秒钟收集遥测数据，丢失其中的一部分通常没有太大影响。比如我们记录 API 的响应时间，我们通过 UDP 流式传输这些数据，甚至不检查目的地是否接收到这些数据... 因为如果某个节点的数据在五分钟内没有被记录下来，那也没关系。如果某个数据包丢失了，在大多数情况下，这对遥测来说不是个大问题。这通常是内部开发的，用来获取数据的方式... 而标准更多的是体现在数据的展示和检测上。

Jaana Dogan: 是的，也有很多预打包的软件和云平台可以导出大量遥测数据，但并没有关于它们导出到哪里、使用何种数据格式的标准... 有个标准会很好，这样我们可以与这些开源项目或者云提供商进行对话，要求它们开箱即用地导出一些遥测数据... 因为当你有一个预打包的东西，或者一个供应商解决方案时，一切都是一个黑盒，对吧？

Dave Blakey: 没错，我们的产品也面临这个问题……我们为自己的服务器和系统做了仪表板，但当我们最终想让人们将其集成到他们的 DevOps 工具或环境中时，问题就来了：我们该如何将这些信息导出呢？于是你提供了一个 REST API，然后再提供一个 webhook URL……因为你试图找到一种方式融入他们的操作流程，但并没有一个标准……你说得完全正确。

Johnny Boursiquot: 如果你在这个领域待过一段时间，你很可能会经常听到“可观测性”这个词，对吧？我们知道，遥测是其中的一部分，但它往往占据了很大的比重。我听过人们谈论可观测性的支柱，比如指标、追踪、日志记录等等……当我说我想要可观测性时，我到底是在问什么？遥测如何帮助我回答这些问题？

Dave Blakey: 我认为“可观测性”这个词---正如你所说，它有支柱，有各种各样的东西……但对我来说，它最近的流行更多是因为我们刚才提到的“黑盒效应”。让我举个例子，在我们的世界里……你有一个运行 API 的 web 服务器，然后你需要扩展它，现在你有了两个。然后你继续扩展，假设你扩展到 30 个，并且它们在多个数据中心分布开来……一切都通过某个负载均衡器，有人告诉你“哦，每次我在南美使用安卓手机登录时，都会出现 500 错误。”对我来说，这就是可观测性。这就像大海捞针。当一切都通过一个点然后分散到不同的方向时，问题变得更加复杂。

我认为可观测性的兴起实际上源自于试图解决问题，试图调试问题，却看不到问题……这时遥测发挥了作用，你说“好吧，你知道你有问题。让我看看整体系统的健康状况，以便找到应该集中注意的地方。”

如果你在寻找这个问题，也许你会注意到 Azure 数据中心有 5% 的请求出错，而亚马逊的数据中心只有 0.2%。所以你知道“嗯，似乎我的 Azure 数据中心发生了一些问题”，然后我就可以开始深入调查。而这就是可观测性的其他部分发挥作用的地方，比如你的日志有多准确；你能否实际查看该数据中心的所有 500 错误，然后找到具体的 web 服务器并深入研究……？

但在我看来，可观测性的核心就是能够透过那层面纱，真正看到正在发生的事情，看看流量是什么样的，有效请求是什么，无效请求是什么，哪里出了问题，而不是被云服务、防火墙或负载均衡器等东西遮蔽。它几乎是对现在运行的复杂系统的一种简化。

当你涉及 Kubernetes 这样的东西时，情况会更糟糕，因为你试图查看的 pod（出错的那个）可能已经被销毁了，数据也消失了……这真的变得很难。但我认为这就是可观测性---就是能够以尽可能简单的方式看到正在发生的事情……因为你要么想防止问题发生，要么正在试图发现问题所在。

Jaana Dogan: 是的，我听到的一个定义是“可观测性更多是关于回答那些你未准备好问的问题。”对于典型的指标等，我们基本上知道我们在看什么。我们事先计划好，所以围绕它收集指标，或者随着时间的推移，我们逐渐了解“哦，这些是一些失败模式，因此我们可能应该围绕它收集更多的指标。”

可观测性是一种更广泛的方法，能够利用你收集到的任何数据，以回答你没有准备好回答的问题。

Dave Blakey: 完全正确。我开始举的简单例子是你不需要更多的服务器，你需要阻止暴力破解登录攻击---这是一种对系统的全面可见性……因为你认为有问题的地方可能并不是实际问题所在。如果你能看到所有的移动部件和组件，那么你就有希望看到系统上真正发生的事情，理想情况下可以预防问题，但也能调试问题。

Johnny Boursiquot: 我们再深入一点……如果我是一个 Go 开发者---显然，我们的播客有很多 Go 听众；我不知道你是否意识到这一点……他们会想了解，不仅仅是“嘿，我是一个 Go 开发者。我该如何开始使用遥测？我该测量什么？Go 是否让这更简单还是更复杂？”他们有这些顾虑……但在我们所有的共同经验中，Go 是否让收集或发射（或我们在项目中围绕遥测所做的任何事情）变得更难？我很好奇……

Dave Blakey: 我不这么认为。我们的技术栈大约有 50% 是 Go。我们正是按照我向你描述的方式使用它，并为客户开发产品以同样的方式使用……我认为这实际上相当容易。非常容易以一种高效的方式获取这些数据。显然，这是最容易、最好的事情之一---你可以轻松地导出数据，而不用担心它影响你的程序性能；当你看遥测时，这也是非常好的……因为你不希望遥测最终成为平台中的瓶颈。这就是为什么我说 UDP 非常流行的原因，因为你可以“发射并忘记”。而使用 Go 你很容易做到这一点。

但 Go 本身在各个方面都有遥测。当你看遥测时，我们经常会想“好吧，这是围绕非常具体的应用程序的非常高级的测量”，但你的垃圾回收就是遥测；你释放了多少内存，你分配了多少内存，你的当前使用情况如何……所有这些东西都是遥测，一旦你开始监控这些东西，你就会开始想到你可能还想要的东西。

我们有一个客户端服务器应用程序，所以我们从我们的 Go 服务器系统输出数据；那么现在有多少人连接？这个数字在变化吗？这些人每秒产生多少请求？而这一切都只是简单的遥测；我们甚至不使用第三方库或其他任何东西……我们只是“发射并忘记”一个 UDP 发送。

所以在我看来，我觉得这很容易做到，但我认为在任何语言中都很容易做到。我肯定不认为 Go 会让事情变得更难，而且它很容易以一种对性能敏感的方式做到这一点。

Jaana Dogan: 我个人希望有一种更简单的方法来导出……如果运行时默认写入一个 UDP 端口，那就会更简单。很多时候，人们是在后来才开始关心遥测，正如你所说，如果他们能简单地打开某个开关并在生产环境中收集这些数据，那将非常有意义，或者在他们需要的时候收集这些数据。

围绕标准已经有很多讨论了，我认为主要是出于这个原因，因为我们希望能够解决“哦，如何让人们在后来打开遥测收集，并尽可能多地收集并在用户需要时加以利用”的问题。

所以我认为这是我们可能在长期内需要解决的一件事，就是能够在后期进行收集。

Dave Blakey: 这很难……因为我同意你所说的一切，但同时，这是一个难以解决的问题，因为一个应用程序中的重要指标在另一个应用程序中完全不同。但我同意，如果有一个非常简单、易于访问、文档齐全的---你知道，这个项目的代码行数可能很少……但一个文档齐全的资源，告诉人们从 Go 应用程序中应该存储什么，以及你应该从哪些基础开始……我认为这会鼓励人们不必像你说的那样事后再回去添加这些东西。

Jaana Dogan: 是的，我修改了一下 golang.org/doc/diagnostics 页面，但这从来不是人们在将东西推向生产环境之前会阅读的文档……所以也许我们应该更好地解释与生产相关的所有问题。

Dave Blakey: 通常一个流行的包在传达内容方面比一篇页面文档做得更好……

Jaana Dogan: 是的，确实如此。[笑]

Dave Blakey: 一个有很多星标、很多人使用的包，你会看到“哦，大家都在用这个……”它可能只有 50 行代码，但如果它为你设置了一个标准，那就是一个非常好的方式来传达这一点。

Jaana Dogan: 这是个非常好的观点。我发布过一些包，非常小的包或工具---因为很难给用户一个切入点……所以你就把它做成一个小项目，然后人们开始喜欢它，分享它，它变成了一种事实上的标准。这真的很有趣，把它呈现为一个项目或某种实用工具是一种很好的传播方式。

Johnny Boursiquot: 说到包，Go---好奇的是---有一个 expvar 包，它内置在标准库中。如果有人感到好奇，或者有人在思考“嗯，这看起来像是某种机制，我可以用它来收集指标并给我的 Go 代码加上仪表，随后暴露给某个将会抓取它的东西”，这种情况下……人们是否应该考虑将它作为在 Go 中对代码进行仪表的起点？你们怎么看？

Jaana Dogan: 我能解释一下这个问题吗？

Johnny Boursiquot: 当然，请讲。

Jaana Dogan: 基本上，这个包是以 varz 为模型的。Varz 是 Google 的一个约定，你可以有一些键和值，并且可以在二进制文件中注册任何键，然后设置一个值。expvar 包和 Google 的 varz 库非常相似；我想他们需要它是因为一些 SRE（站点可靠性工程师）要求，当他们第一次在 Go 中投入生产时……但随着时间的推移，varz 被认为“不太具有可扩展性”，因为人们会丢弃大量随机的东西，名称空间也变得非常复杂，等等……所以他们有点像是弃用了 varz，并切换到另一种模型。

我认为在 2.0 版本中有个话题，他们正在考虑弃用 expvar，并可能用更好的东西替代它，特别是如果有一个既定的标准；或者他们会重新考虑在 Go 2.0 中是否继续使用它。这就是背景故事……不过我们仍然可以讨论它对终端用户是否有用。

Dave Blakey: 是的，我们绝不是收集遥测信息的权威。我们专注于应用遥测的一个非常特定的领域，然后我们自己处理并报告所有数据。但在我的个人开发经验中---不是说在大规模项目中---我发现比起暴露一个遥测收集点，最好是采用“发送并忘记”（fire-and-forget）的方式。我不知道这是否真的会成为一种标准……也许以后人们会指着这个播客，说我错了，关于 Go 的遥测未来……但你知道，暴露很多我称之为调试信息的东西，作为遥测解决方案，有点滑坡效应……与其说“这是我们关心的指标，原因 X，我们将其发送到位置 Y，未来我们会用它做各种各样的事情”，不如说你真正开始学习到你需要什么遥测数据，以及如何使用遥测数据，是当它实际上要么帮助你解决问题，要么没有帮助你解决问题时。

如果你遇到了问题，并且能够通过你的遥测数据看到问题所在，那么你就学到了一些东西……尤其是当你无法通过遥测数据看到问题时，你也会学到一些东西。我们曾经遇到过这种情况---我们有性能问题，最终找到了问题所在，而我们的遥测数据没有找到这个问题，所以我们在代码的那部分增加了更多的跟踪。

我认为这几乎就像是通过一些 HTTP GET 方法将数据倾倒出来，然后人们需要收集数据并假装在现场处理……但这可能并不能真正解决开发人员的问题，确保这些数据被使用……不过这可能只是我的个人观点。

Jaana Dogan: 这实际上是一个非常好的话题，而且它仍然是一个非常相关的话题---什么是获取指标数据的最佳方式，是拉取（pull）数据，还是让进程推送（push）数据。我们目前认为调度推送更好，因为至少进程知道“我可以调度推送”。即使它不像 UDP 那样只是一个“发送并忘记”类型的推送，进程至少有更好的机会在后台运行并在合适的时候进行推送。

在拉取模型中，想象一下，一个服务器正在接收大量流量，而服务器上已经有了巨大的工作负载，然后你的监控系统进来并尝试拉取数据，进行一堆工作，以便生成所有指标的值，并将其呈现为一个 HTTP 端点，就像 Prometheus 的端点那样---这只是对进程的额外负担。所以与其采用那种模型，不如推送模型好得多……但你知道，这仍然是一个有争议的话题，因为这也取决于你如何部署你的监控栈。

我认为 Prometheus 的拉取模型来自 Borgmon，因为在 Google，最初每个人都部署了自己的 Borgmon 实例……所以他们对整体有更多的控制。他们转向了更像是一个集中的、全球可扩展的监控栈。要求是---几乎不需要关心你的监控栈的可用性，你也不需要严格地将你的监控栈或收集器与你的进程进行定位……所以他们在推送方面有更多的灵活性。但他们最初并没有把这看作瓶颈，因为还有其他问题，比如维护 Borgmon 实例，等等。

但如果你有一个全球可用的收集器，推送就要容易得多，因为至少进程可以判断“哦，现在流量不多。也许这是更好的时机……”因为你知道，导出指标很重要，但它并不像处理用户流量那么重要，对吧？所以给进程这种灵活性是非常重要的。

Dave Blakey: 是的，我完全同意。这就是推送的好处---你可以从“发送并忘记”开始，就像我说的，这真的很好，因为不用为此操心……但是如果你进一步上升，你可以让进程决定什么是重要的，什么是不重要的。如果它快要失败了，它可能会阻塞发送该消息，告诉你“听着，我们这里有个严重的问题。”但另一方面，如果它想决定现在不需要存储遥测信息，因为系统过载了，它也可以这样做……而如果是收集模型，它就像一个静态的---几乎就像你有一个 cron 作业，不管发生了什么，它都会获取一大堆页面，然后你只是将这些东西倾倒到那些页面上。

是的，如果这能回答你的问题---我认为我们的方法一直是尽可能地将数据推送出去，并让应用程序决定什么是重要的，如何传递这些消息。

Jaana Dogan: 既然你提到了 UDP，你们有一个代理来收集数据吗……收集模型是什么样的？

Dave Blakey: 对我们来说---我们实际上有两种遥测方式……我们有我们的产品，它收集特定的遥测数据，比如关于 ADCs 和负载均衡器以及类似的东西……但我更多地是指我们自己的内部使用，比如对我们的代码、我们的托管系统等……在这些方面，我们只是有我们自己的---再次强调，那种 DevOps，自己拼凑的东西……但我们有自己的中间收集器，它对那些数据做了很多不同的处理。这样做的原因是我们将其用于一些实际应用程序，尤其是用于其中的异常检测……

但我们的一些数据---我们直接从 UDP 发送并忘记，直接发送到 Datadog。例如，我们甚至探索了平台外的一些共享的、基于 SaaS 的托管东西，然后其他东西我们保存在产品中。所以我们完全就是那种糟糕的例子，我们自己构建了一切。

Johnny Boursiquot: 有趣的是，一个产品是收集和暴露某些数据的公司，实际上在使用另一个公司来展示这些数据……所以这是一个症状吗---我想知道这是否是一种症状，表明“基本上没有一个工具或平台可以做所有事情，或者回答你可能有的所有问题”，所以你最终不得不拉入很多不同的东西，以获得整体的可观测性答案？

Dave Blakey: 完全正确。因为我们并不能回答所有问题。我们的产品位于网络的入口点。它是一个 ADC(智能缺陷分析系统)，所以你有负载均衡、安全、防火墙等，负责进来的流量。因此我们非常具体地报告这些信息。这意味着我们还需要将这些信息提供给我们的客户，以便与其他内容集成……因为如果他们在这方面有问题---是的，他们会直接来到我们的平台，查看他们的数据报告，等等……但如果他们的整个应用程序有问题，我们需要将我们的小部分信息贡献给他们的整体遥测。因此，将信息从我们的平台传输到他们的平台，或以某种方式公开信息，是非常常见的。

通常，当我们与大型企业打交道时，我们尝试尽可能保持开放性。几乎所有企业都有自己的用例，尽可能开放你的平台，我认为最终是最好的。不过，正如之前所说，没有很多标准，所以我们最后不得不添加七种不同的方式来从我们的平台获取数据，因为这是需要的……[笑]

Jaana Dogan: 当我们发起 OpenCensus 时，我们意识到的一个有趣的事情是，我们的许多大客户依赖于多个产品……有时候这是因为他们真的想从某个供应商那里获得一些额外的功能，有时候是因为团队的偏好。在一个非常大的组织中，一个团队可能喜欢 Datadog，他们想使用 Datadog，而另一个团队想要使用其他产品……所以我们认为，拥有一个与供应商无关的解决方案是关键。你不能把这种数据锁定在一个提供商中；这对任何人都没有用……因此能够将数据导出到多个供应商也是非常重要的。

Dave Blakey: 我完全同意。当你看更传统的模式时，你还会看到有多个利益相关者，他们只想在自己的平台上查看某些数据。你有 IT 运维和安全团队，他们可以完全独立运行……所以我认为这是至关重要的。我们不得不自己构建。

Jon Calhoun: 你提到在 ADC 方面，你们收集了某些遥测数据……你能分享一些你们觉得更重要的遥测数据吗？哪些是客户觉得特别有用的？

Dave Blakey: 当然可以。我们最新的产品叫 Nova，它是我们专注于云原生的可扩展 ADC。一个重要的组成部分是我们在中心运行多个 ADC，所以这是一个控制平面/数据平面模型；我们从数据平面收集大量数据，显示在控制平面上……但是我们在传统产品示例中学到了很多，这是一个独立的 ADC。

有趣的是，我们尝试以一种非常不同的方式来处理它。我们收集的主要是相同的数据---你获得了多少种 HTTP 响应码？你收到了多少请求？你有多少 TCP 连接？有多少 TCP 连接失败？有多少超时？响应时间是多少？当你看响应时间时，有很多信息。比如，连接到服务器的 TCP 连接时间是多少---是否有网络问题？服务器的 HTTP 响应时间是多少---是否有后端问题？客户端的响应时间是多少？我们何时关闭与客户端的会话---是否有前端网络问题？

这些都是指标，但我们尝试做的事情是---时间会证明我们的方法是否足够有趣或正确……我们试图不为任何这些数据设置硬编码的值，而是仅仅通过异常检测和预测性分析来确定我们期望的数据样子。因为我们的系统会自动扩展，所以它需要基于这些数字进行大量预测。因此我们最终建立了这样一个系统，我们收集了大量遥测数据，但没有为任何数据设置硬性阈值，而是根据其变化来发出警报……到目前为止，这一切进展顺利，但对某些人来说可能有点奇怪，因为他们想说“我希望我的网站响应时间为 200 毫秒，如果它超过 250 毫秒，请告诉我。”而我们说的是“好吧，如果它一直是 200 毫秒，我们会在它变成 250 毫秒时告诉你。但如果它不是这样，我们就不会。”

所以所有这些东西都是你期望的传统指标，比如收集的吞吐量、请求率、响应码……因为你可以通过说“哦，我通常会生成 0.1% 的错误，现在我生成了 0.5% 的错误”来提前发现问题。你可能不会注意到这一点，但这意味着某些事情发生了变化，而且可能意味着问题会变得更糟；这也可能意味着有安全问题，可能意味着所有这些事情。

但同样，我们还会检查两个数据之间的差异。例如，如果平均用户发送的 GET 请求远多于 POST 请求，但某个用户发送的 POST 请求远多于 GET 请求---这是不是一个安全问题？他们是在尝试暴力破解密码吗，还是有什么奇怪的事情？某个特定用户收到的 404 错误远多于其他用户？为什么会这样？这可能是某个脚本的问题。因此，遥测通常是两个值的组合，比如“这个值与那个值相比是什么情况”，而不仅仅是一个单一的值。这是我们关注的很多东西。

客户端连接到我们，我们连接到 Web 服务器，然后我们返回他们的数据。这是我们的模式……所以通信链中的所有内容都是我们非常关心的遥测数据，因为它可能意味着客户服务器有问题，可能意味着存在影响用户的延迟或问题，或者可能是安全问题……所以这些是我们需要显然跟踪的东西，用于扩展和缩减，也用于提醒用户他们的服务存在问题。

Jaana Dogan: 是啊，听起来这是一个非常困难的领域，特别是考虑到流量的趋势可能会变化，使用情况也会变化……你必须将这些都考虑进去，才能对检测充满信心，对吗？

Dave Blakey: 没错。你知道，大家总喜欢在这儿提到“ML”，也就是机器学习。这是他们常用的词汇。但实际上，这只是一个统计问题的核心。你实际做的就是将数字与其他数字进行比较。我们确实在处理一些类似机器学习的东西，因为正如你所说---流量模式可以快速变化。有时候一分钟的流量可能是下一分钟的十倍，但如果你看所有的数据而不是单一的数据点，它们的变化是有规律的。比如，你的吞吐量会随着每秒请求数的减少而以可预测的方式下降，HTTP 200 响应码、POST 请求、服务器上的 CPU 使用率、网络延迟都会随之下降……如果其中某个指标没有按照预期的速度下降，那么对于一个整体观察数据的系统来说，异常就会变得非常明显。

我们遇到的一个很大困难是要过滤掉所有噪声数据……但我猜这可能是我们的增值部分。不过，真正的挑战在于平衡---你知道，关于遥测、分析和可见性/可观测性平台，最糟糕的事情就是生成太多的警报，导致人们开始忽略它们；那样的话整个系统就失去了意义。我宁愿少发些警报，确保真正重要的信息能传递出去……所以这确实很难，尤其是在我们扩展的过程中。我们试图基于这些信息提前做好扩展，所以这是一项非常困难的平衡工作。

对我个人来说，在遥测方面学到的最大一课是：当你在一组测量数据中寻找异常，而不是单个测量数据时，一切都会变得更加清晰。我认为这是我们平台的一个核心设计因素。

Jon Calhoun: 这完全合理，因为任何曾经负责监听报警系统的人都知道，当你收到太多异常报警时，你基本上会开始怀疑“我会等它再次出现，看看是不是真正有问题”。当这种情况出现时，你就会觉得“好吧，这完全违背了我们设置这个系统的初衷”，因为人们开始忽略警报……但你也提到过，如果你在处理异常时，可能会遇到一些流量激增的情况……

我记得有一次让我印象深刻的是我在帮助处理 Google Code Jam 时，大家都会在比赛开始时同时登录。当时他们的监控系统也是在检测异常。所以设置系统的人知道需要提前热身服务器。因此他运行了一个脚本，让服务器提前适应即将到来的请求负载……这只是为了忽略那个显然会出现的异常，因为大家知道它会发生。这种情况通常出现在定时事件中，当流量突然激增时，检测异常变得非常具有挑战性……我想视频游戏和类似的产品在发布时也会遇到这种问题，那时很难区分是否是异常，因为一切都会突然飙升。

Dave Blakey: 是的，没错。不过很多时候，异常其实可以提供有价值的信息。我认为这也取决于接收到这些信息的团队，确保他们做出正确的反应。如果我们的官网在这期播客之后的访问量变成十倍，我很乐意被告知。虽然我们不会因此宕机……不过，有时信息性的遥测数据并不一定意味着出现了问题，但确实可能会变成垃圾信息，导致人们开始忽略它们，这就成了一个大问题。不过，这仍然是一个平衡问题。在警报和异常检测方面，一切都关乎平衡；你要确保能够捕捉到重要的东西。

在我们这种规模下，问题变得非常复杂。比方说我们有一个银行客户，他们可能在 20 个不同的国家/地区运行系统。你觉得他们每秒会有多少次登录失败呢？可能是 500 次，也可能是 1,000 次……那么如果他们每秒多了 10 次、20 次、50 次登录失败，系统可能不会检测到异常。但如果他们在全球的所有地点都多了 50 次登录失败，且这些登录失败都来自同一个国家呢？这可能就是个问题了。这就是遥测有趣的地方：人们往往只关注局部细节。

我们之前讨论过的跟踪 IDE 和“单个请求”是什么的问题，很多时候这些非常重要，但有时从全局视角看问题---比如从 10,000 英尺高的视角看整个系统是什么样子---也是非常重要的。做到这一点现在并不容易，也没有很多标准或者最佳实践。比如，如果你使用 Prometheus 或 Datadog，如何设置你的仪表板呢？这是目前 DevOps 团队和传统团队中的一个大问题。你总是需要回头看看你的遥测数据，问自己“为什么这些数据没能提前告诉我们这个问题？” 你几乎应该对问题进行根本原因分析……这不一定需要很复杂的流程，但至少要问问“既然我们现在明白了问题是什么，为什么我们之前没有注意到？”

Jaana Dogan: 是啊，这真的是一个很好的观点……特别是对于那些大型团队、大公司来说，如果他们一开始没有考虑遥测，后来想要引入它时，可能不知道从哪里开始。异常检测可以帮助他们进行探索。虽然刚开始可能不太明显，但你可以运行它来查看并探索所有这些边缘情况和一些关键的关联性……它可能会帮助你了解哪些地方需要更多关注，即便最终你采用的是 SLO（服务级别目标）类型的方法。

Dave Blakey: 是的，你提到的“关联性”是最重要的词……很多时候这些关联性对人眼来说并不明显，但在你试图扩展系统时，它们真的很有帮助。如今的扩展方式已经发生了巨大变化。现在你可以轻松地在云端或者容器中进行扩展，但我们编程语言中的难点是在更高的抽象层次上。很多时候，诊断瓶颈或性能问题变得非常困难……而将两个数据点结合起来，理解为什么某些东西变慢了，或者即使你放了 3,000 台服务器在后端，它也无法扩展，这些问题可以通过异常检测得到很大帮助。

Johnny Boursiquot: 听起来这更像是一门艺术而非科学……

Dave Blakey: 确实如此。我前几天读到一个有趣的东西，说开发者之间有些人是艺术家，有些人是工程师，无论如何……但这确实像一门艺术，因为你真的需要问自己“有什么可能性？我能存储哪些数据，并看看能得到什么？” 我认为这是一个实验性的过程。

Johnny Boursiquot: 好的。在我们进入下一个环节之前，我还有一个最后的问题……根据你目前的观察，以及你从客户使用产品的数据中得到的见解，触发你们关注的异常大多来自内部原因吗？也就是说，开发人员推送了新的代码，导致了一些问题？还是来自外部原因？比如，有人试图暴力破解，或者公司刚刚在某个热门网站上被列出，因此流量激增。通常来说，最大的故障来源是什么？

Dave Blakey: 通常来说---我想给出的答案是“这两者都有”。但既然你要我给出实际答案……

Johnny Boursiquot: [笑]

Dave Blakey: 如果一定要我选择，我会说大多数情况下是服务器和应用程序在团队测试中没有覆盖到的情况下发生故障。如今测试事情变得非常困难。以我们的平台为例---我们需要测试一千万个活跃连接，来自一千万台活跃设备。我们有 6 台 Kubernetes 服务器运行在 2,000 台机器上，依然是一场噩梦。所以你会遇到这些系统，人们将其扩展并放入自动扩展组中，最终还是会有某些瓶颈，他们根本无法测试到。就像黑色星期五一样；如果大规模的电商网站都会宕机，我保证你的网站也会在不可预测的负载下出现问题。

所以现实是，大多数情况下，是这些东西在出故障……但有趣的是，通常很容易预测它们会出问题，并希望能有足够的时间去纠正问题。你可以预测页面加载时间比平时更慢，流量比平常在这个时间点上更高……我们甚至会深入到 DNS 查询。如果我们收到的 DNS 查询比平时多得多，而每秒请求数却没有相应增加---所有这些事情……

大多数情况下，问题出在上游 API 或网站的实际服务器宕机；问题的原因通常是流量激增、某个意外情况，或某个新功能的推出，或者数据库系统的更改。比如有人从一个版本的 SQL 升级到另一个版本，而查询缓存从默认的 1GB 变成了 0GB，整个系统就崩溃了……但你可以开始看到这些问题，比如凌晨 2 点页面加载时间变慢了。如果有人能看到并说“等等，早上 6 点页面加载时间变慢了。昨晚发生了什么？它不会在 9 点流量高峰时崩溃。”

我认为遥测的美妙之处就在于能理解这些未知的变化。你升级了 SQL 服务器，打开网站，一切正常，你会想“太好了……没问题。”但你不知道页面加载时间已经增加了 25%，因为你无法感知到……但当你收到每秒 100,000 个请求时，你就会立刻感受到这个问题了。

Johnny Boursiquot: Jon，你想介绍一下我们接下来的环节吗？

Jon Calhoun: 当然。Mat 开创了这个叫“不受欢迎的观点”的环节……我们通常在这里放一些音乐过渡……

Jon Calhoun: 基本上，这个环节的目的就是希望你分享一个你持有的不受欢迎的观点，最好是关于科技的，但也不一定非得如此……目的是让听众知道，并不是每个人都同意那些非常流行的观点，每个人都有不同的想法和看法，值得分享。

Dave Blakey: 没错。我如果不说这个可能有点过意不去，但我是素食主义者，这个观点很不受欢迎……[笑] 不过如果我们谈论科技，我觉得我最常见的、也许是不受欢迎的观点就是，我认为初创公司和很多人几乎总是在用错误的编程语言写代码。

Johnny Boursiquot: 所以你是说他们应该使用 Go，对吧？他们应该使用 Go。

Dave Blakey: 这要看他们团队里有多少 Go 开发者。所以这正是我的观点---我认为很多年轻公司选择编程语言时，更多是基于它的流行程度和性能表现。但没有人真的愿意维护一个用 Erlang 写的 Wiki 系统。很多时候，人们并没有考虑到如何轻松地招聘到会这种语言的开发者，如何扩展这个系统？这种语言在开发者圈子和市场中的认知度如何？

我认为你的应用程序速度慢，更多是因为你的代码不好，而不是因为你选择的语言不好。当你跨过这个阶段时，你就超越了这个挣扎期……但总是追逐最新语言的趋势，我认为会给企业带来扩展问题，而且很难找到相应的人才，也很难围绕某种语言建立一个工程团队……所以是的，我认为人们在选择编程语言时经常犯错。

我不认为 Go 是这种情况，因为它很容易上手学习，资源也很丰富，而且有很多人在使用它……它做得很好，建立了一个社区。但很多人只是根据他们最新收听的播客或观看的网络研讨会中的语言来写代码……我认为这是个错误。

Johnny Boursiquot: 太棒了。

Jon Calhoun: 我对此深有同感。我也见过相反的情况，有些通用的建议是“如果你们团队只有三个人，你们可能会在接下来的六个月到一年内只靠这三个人来处理这个项目，直到你们有能力雇佣更多人。”也许不总是这样，但很多时候确实如此……所以在这六个月到一年里，哪种语言能让你们三个人最有效率？你会根据这个来选择语言。我说三个人---实际可能是一两个人，或者其他人数。

我见过一些公司因为这个原因选择使用非常老的编程语言……我记得有个公司用的是 Perl；他们在这方面生产力很高，完成了很多工作，但他们遇到的问题是，正如你所说，当他们后来需要招聘时，他们遇到了困难。因为当你是一个时尚的初创公司时，大家看到你使用的语言时就会觉得“嗯，这不是我会优先选择的语言……”没有人愿意花时间学习一门可能对未来职业发展没有帮助的语言。

如果你学习 Go，至少你会觉得“好吧，这对未来还是有帮助的，其他公司也在使用它。”但如果你学的是一种并非已经过时，但也没有在增长的语言，情况就有点不同了。所以我明白你的意思，但我也会在另一面提醒大家，不要选择一种过于陈旧的语言，因为它可能会带来问题，即使你对它非常熟悉，它仍然可能会引发各种问题。

Dave Blakey: 是的，你说得完全正确。我的观点的核心就是确保你选择的语言能够让你容易找到对应的人才……这和你说的完全一致---在选择一种正在稳步发展的语言时，要找到一个平衡点。这种语言应该被广泛接受，大家都在讨论它，并且它被公司实际使用过，开发者有生产环境的经验……因为仅仅有人懂某种语言并不意味着他们知道如何用它构建一个大型应用程序、保持系统在线并实际交付和维护它。

框架就是一个好例子。“不要使用框架，因为我们必须尽量精简代码。”那么你为什么不直接用汇编写呢？如果某个框架能够让你们三个人在前六个月的工作效率提高五倍，从而快速完成 MVP（最小可行产品），那就使用它。我会说找到那条中间路线，但我认为很多人走得太远了，应该提醒他们往回走一点。

Jon Calhoun: 是的，不幸的是，我认为这是所有---嗯，我在想如何表达……基本上，如何部署东西也会带来问题，现在每个人都想用 Docker 和 Kubernetes。不过我记得当 Google 的 App Engine 刚出来时，我认识一些用 Python 编写很多项目的人，然后他们决定使用 App Engine，因为它可以自动扩展。但他们的第一个项目真的很困难，因为你必须学习很多关于 App Engine 的特定知识。一旦他们弄明白这些，他们的第二个项目就可以在 App Engine 上顺利运行，但第一个项目简直是一场噩梦，遇到了很多不该有的障碍。

Dave Blakey: 是的，你提到了我另一个不太受欢迎的观点。我不知道这是不是不受欢迎，但……我不认为容器、Kubernetes 和云原生是终点。当我们还在用物理服务器时，大家都说“好吧，所有人都会转向虚拟机。”然后我们都转向了虚拟机，接着大家又说我们都会上云。到这里就开始变得不太确定了，因为并不是所有东西都迁移到了云上……现在大家认为下一个演进步骤是容器和云原生，我认为这是错误的。

我认为有些工作负载非常适合容器化，有些工作负载适合无服务器架构，但总会有一些工作负载更适合在离你家一英里内的物理服务器上运行。我认为这是一种光谱化的选择，不要强行让圆形钉子塞进方孔。并不是所有东西都必须部署到容器上，这正是你提到的重点。通常来说，最简单的、使用最广泛的东西，往往是最好的选择。

Jaana Dogan: 我觉得云计算正在变得像编程语言产业一样；你必须推出一个新产品或新的抽象层，才能吸引人们的注意力。也许这就是为什么我们有这么多不同解决方案的部分原因，因为大家都想制造点噪音。

Dave Blakey: 是啊，你说得再对不过了……有趣的是，现在那些简单的云平台增长得更快。我们在业务中也看到了这一点，因为我们与云中的商品化负载均衡竞争，比如 ELB、LB、Azure 的网关等等；每个云平台都有负载均衡器，所以我们跟它们竞争。但有趣的是，现在人们更希望保持云中立。也就是说，他们可能现在在 GCP 上，但他们希望能轻松切换到 Azure 等等，他们实际上希望尽量少使用云平台的专有工具，保持中立。因此，云平台不断推出新功能，以保持人们对它们的关注，但我认为人们越来越倾向于避免使用某个特定基础设施提供商的解决方案。

Johnny Boursiquot: 新功能带来新销售啊……你得考虑到这一点。 [笑]

Dave Blakey: 是啊，我们也不断推出新功能。我懂你。[笑] 做我说的，不要做我做的。

Johnny Boursiquot: [笑] 太棒了，太棒了。所以总体而言，我们可以说编排和扩展通常已经变得更容易了。遥测仍然是一个尚未完全解决的难题，很多公司，包括你们的公司，仍在努力寻找答案……正如我们今天与你探讨的那样，这没有统一的解决方案。但至少，建议每个人都从某个地方开始；拥有某种形式的遥测，可以为你的工作负载提供某种洞察力，至少是被认为准备好生产环境的最低要求。

Dave Blakey: 是的。我是说，当你开始工作时，如果你在代码里留

Dave Blakey: 是的，我的意思是，当你开始工作时，如果你在代码里留下一条注释，写上“待办事项：为此添加遥测功能，因为这是一个瓶颈”，那么这样也可以。只要开始去考虑这件事，剩下的事情就会慢慢跟上。

Johnny Boursiquot: 很好。希望你不仅仅只是考虑一下，还能多做一点……[笑] 是的，确实如此。感谢你加入我们的节目，Dave，也感谢我的两位联合主持人，Jon 和 Jaana。我是 Johnny Boursiquot，我们在下一期的 Go Time 再见。