[开场音乐]

Ryan Donovan：大家好，欢迎来到Stack Overflow播客，这是一个讨论所有软件和技术话题的地方。我是主持人Ryan Donovan，今天我们要讨论复杂性危机。我们将深入探讨什么是复杂性危机、可能的解决方案以及与今天嘉宾Nic Benders的讨论困惑点。Nic是New Relic的首席技术策略师。欢迎来到节目，Nic。

Nic Benders：谢谢Ryan。很高兴来到这里。

Ryan Donovan：在我们深入复杂性危机之前，你是如何进入软件和技术领域的？

Nic Benders：我经常和别人交谈，他们有着精彩曲折的职业生涯，接触过各种事物，而我的职业生涯就像一条直线。小时候，我有一台疯狂的TI个人电脑。它有24KB的大内存，我花了所有时间在那上面，直到我能获得越来越大的电脑。在这个过程中，我发现管理系统本身就是一种乐趣。除了编写软件，我还去大学学习了计算机科学。实际上，我职业生涯的大部分时间都是作为运维和系统架构师，管理大型服务器群，这有无尽的乐趣。然后，你知道，这很自然。你会遇到所有这些问题，然后说，“嗯，实际上没有什么东西能按预期工作。”于是，你会在这里拼凑一点，那里用一些胶带，一堆Perl脚本，然后我得到了来New Relic工作的机会，你知道，我当时想，“我使用New Relic。我需要那种可见性。我要去那里直接参与其中。”所以，就像我说的，我的职业生涯在很多方面就像一条直接通向这个点的漏斗。你在从事可观测性工作。

Ryan Donovan：有更高阶的CIS管理员。

Nic Benders：是的。是的。

Ryan Donovan：你花了很多时间思考计算机系统、网络系统以及它们如何工作。我们现在面临的复杂性危机是什么？

Nic Benders：嗯，当我回顾我的职业生涯时，其中越来越大的部分——当我从90年代开始时，我们有很多人和很少的系统。你知道，大学的系统工作人员有六个人，我们可能只有三四台计算机真正需要关注。所以，每个人都在围绕它工作，你知道每一个部分，并且非常特别地对待它们。随着生活继续，我们得到了越来越多，然后你说，“嗯，我不能再给我的服务器命名了。我将不得不采用一些自动命名方案。”我的意思是，服务器命名很有趣。你有一些有力的主题，但你知道，复杂性增长了，我们说，“嗯，我们需要软件来跟踪我们的硬件，因为我们现在有这么多硬件。我们需要软件来管理我们的软件部署，因为实际上——我们正在部署很多东西。”我们转向了微服务。我记得第一个告诉我关于微服务的人，我们说，“好吧，我们需要几十个不同的服务来构建这个架构。”他说，“哦，我认为会有几百个，”结果三年内就超过了1000个。这就是发生的爆炸式增长，它带来了好东西。你知道，我们突然能够真正减少在编写单个软件时所考虑的范围。但它也带来了很多坏处。它使调试变成了一个精心设计的谋杀谜案，你不确定谁做了什么，比如各个部分是什么。你不能只是用调试器逐步跟踪它。一次又一次，我们做了这件事。我们转向了微服务，我们转向了云，所以我不能只是去数据中心用脚踢服务器，或者听它看它是否在交换。我们转向了容器，所以甚至没有操作系统可以连接。我们转向了编排，我甚至不一定知道我的容器在哪里运行。它们在某处运行，下一分钟，它们可能在别处运行。这些步骤中的每一步都很棒。这是我们构建的一个非常强大的层，没有这些层，我们就无法构建今天拥有的软件，但在每一步，我们也放弃了一点；而复杂性就是我们放弃的东西。所以，你知道，我认为过去30年一直在持续向上移动堆栈，但那个金字塔因为内部的所有部分而变得非常非常宽。

Ryan Donovan：我们正在提升这些抽象层次，对吧？但你说复杂性来自于：我们本不应该担心下面的所有其他东西，对吧？

Nic Benders：嗯，这总是一个谎言。

Ryan Donovan：是的。你还在用汇编语言编码吗？是你吗？

Nic Benders：不，但我认为你仍然需要知道它是什么。你需要知道汇编语言存在。也许不像我们过去优化循环时那样深入机器语言，或者像，你知道，我过去常常一直怀疑编译器。你会说，“那个编译器在搞我。”但特别是在运维领域，每个人都知道有时候你使用的工具是一个美丽的抽象，但它不够准确。比如，屏幕后面发生了什么？如果你不知道，哦，这实际上只是向Kubernetes发出这些命令，Kubernetes在做什么？Kubernetes实际上只是在操作这些操作系统概念。那些操作系统概念实际上是在操作这个管理程序，或者它们向下到硬件，在网络上。你必须要能够想象整个事情，因为有时候那些抽象确实会泄漏。它会变得有点奇怪，大多数时候它很棒，我几乎觉得它越经常很棒，当它不棒时就越糟糕。

Ryan Donovan：是的。嗯，似乎你谈到了过去用汇编语言优化循环；计算机和计算已经变得几乎太强大了，你感觉不到那个糟糕循环的压力，或者你那里的任何东西。你没有因此受到困扰。

Nic Benders：是的，不，我认为这绝对正确。所以，我们生活在如此丰富的资源中——

Ryan Donovan：对。

Nic Benders：你会说，“哦，我就启动一个更大的实例。会没事的。”而且，你知道，我不确定，我确信当我开始时胡子已经花白的人会对我有同样的说法。就像，你知道，我没有打自己的卡片。我不必来回拉磁带，而且像，“哦，你有所有这些内存。你有兆字节的内存，”就像，“你变软了。”

Ryan Donovan：我们过去不得不在雪地里上下坡编码。

Nic Benders：没错。

Ryan Donovan：那么，场景下的复杂性，我们如何使其可见和可理解，并让人们进入其中？

Nic Benders：你在第一个问题中立即触及了两个关键概念，即可见性和可理解性，因为它们密切相关，但并不相同。我认为很多人混淆了这一点。我在可观测性行业工作；这就是我们对自己的称呼。这是一个有点傻的名字。可观测性是我们制造的工具，它是一个重要的工具，但它不是你需要的全部。所以，我们做的第一件事是试图说，“嘿，当某物做了你意想不到的事情时，你知道你的应用程序正在被资源压垮，但你说，嗯，为什么会发生这种情况？”首先，你必须使你的系统可观测。所以，你必须构建每个部分，以便在需要时可以看到内部发生的情况，并且你需要将这些数据发送到某个地方，以便你可以比较历史数据，这样你可以回去说，“是的，这是一个问题。这是一个新问题，还是我只是没有注意到的某个东西？”所以，逐步完成所有这些可观测性使我们能够回溯时间并查看系统内部，就像取下服务器的侧面，软件的侧面，然后说，“嗯，这个应用程序很慢，为什么？”但下一步是，你能理解它吗？可理解性是我认为我们应该被称为的东西，因为这是复杂系统中缺失的部分，你可以观察复杂系统的每一个部分。我认为我们很多人当我们坐在控制台前时都会这样做，你可能有一个带有500个小部件的仪表板。现在你知道，你可能有一百万个不同时间序列的指标。所以你观察了系统，但这与理解它不同。我们谈论可理解性，特别是在这个AI时刻，因为AI正在助长这个问题并使其变得更糟，同时也给我们机会使其变得更好。可能摆脱这个循环的方法，因为我们第一次有机会真正将一些额外的人类式思维带到一些我们永远没有足够人手的问题上。所以，我们来到了一个非常有趣的时刻，我们不知道我们是否都会被AI带来的额外复杂性完全淹没，或者它是否最终会给我们一些东西，让我们浮在系统之上。

Ryan Donovan：是的，我的意思是，我认为它有几件事，你知道，在不同的方向上起作用，它擅长处理大量数据并使其变得可理解，但然后它本身也不非常可观测。对吧？

Nic Benders：是的，AI，它现在在我们行业中有三个接触点。所以，一个是人们使用AI驱动的工具来编写软件的想法。所以，他们使用Copilot，或者他们使用Claude Code，任何这些系统——Cursor——然后说，“哦，我现在可以更快地编写软件，因为我有这个编码助手。我可以，你知道，也许进行氛围编码，像低代码或无代码的方法来构建一个软件，否则我永远无法构建，或者需要花费大量时间来构建。”所以，这太棒了。这些是强大的新事物。再次，我回想起，你知道，过去的软件工程师，也许会责备我们，因为，“嗯，编译器，你会失去对机器的感觉。”同时，如果我雇佣了一个新员工，他们写了一个软件，然后它在生产中没有按我预期的方式工作，我只需在Slack上联系他们，我问，“嘿，你能看一下这个吗？这是你预期的吗？你能向我解释一下你的想法吗？为什么它是这样写的而不是那样写的？比如，有什么我不理解的吗？”如果我使用编码助手，或者如果我使用氛围编码系统，它写了一个软件，或者它写了一个软件模块，然后它进入生产环境，它没有按我们预期的方式工作，你要问谁？比如，我不能去找Copilot然后说，“嘿，Copilot，你能解释一下你在这里的想法吗？”因为它不知道它在想什么。它只知道它构建了什么。它没有那个内部决策历史：“哦，我做了这个而不是那个，尽管我担心另一个东西。”它只会告诉你，“嗯，我可以像你一样阅读代码，”然后告诉你那是个问题。所以，很多调试是关于将那些对宇宙的期望与现实匹配起来。所以，这是AI正在做的一件事。它正在创造这个新问题，既因为它生成大量软件，也因为它不理解它写的软件。第二是AI是一项新技术，就像移动、云或其他任何东西一样，每个公司都在部署它。我认为，你知道，当我们和——你知道，我们每年都做这个可观测性预测来帮助理解我们的市场。人们正在将大量AI软件投入生产，所以然后你必须能够查看其中。在我们交谈的公司中，去年大约有40%多对其生产AI系统有可观测性。今年是50%多。这很好。这是朝着正确方向前进。这是我们第一次看到这个结果超过一半，但这仍然意味着几乎一半的AI系统还没有被任何东西观测到。这不只是New Relic客户，这只是行业中的一般人。好吧，这有点可怕。有很多软件在那里做事，没有人关注它。

Ryan Donovan：当你谈论这些系统的可观测性时，你是指对LLM本身某种可解释性的观点，还是围绕模型的输入输出？

Nic Benders：主要是输入输出。所以我们看到很多客户和这个领域的很多其他公司非常依赖这些云交付的AI解决方案，特别是对于LLMs。所以，还有其他，你知道，较小的统计技巧和类似的东西在本地运行，随着新的开放权重模型，也许我们会看到那再次增长。出于隐私原因，人们会推动那个，但OpenAI、Anthropic和你知道，Google，他们只是在他们的云托管模型上如此快速地推进最先进的技术——

Ryan Donovan：对。

Nic Benders：以至于大多数人只是转向那些。所以，模型内部发生了什么？嗯。这对我们来说真的很难看到。但我们可以看到的，我们可以观察那个交互并说，“你向这个系统发送了这条消息。它用另一条消息回答了你。它花费了你这么多令牌。它花了这么多时间。”这些是相当基本的测量，但它们真的很重要，因为它让你以后找到有奇怪客户交互的人，然后说，“嘿，模型对他们说了什么？”比如，“让我们回到过去看看说了什么。”你也可以使用AI来监控AI并做简单的事情，比如对所有响应进行情感分析。“嘿，我们的聊天机器人昨天对任何人发誓了吗？它真的很生气或抑郁吗？”让我们检查那些类型的事情。当然，成本，就像云的早期，我们给了每个人一盒颜料，它们相当昂贵，如果有人试图用油画颜料涂他们的房子外部，我们不应该感到惊讶，因为我们没有告诉他们该做什么。所以，你必须关注那些基础知识，你知道，它们在那里应用的东西就像在任何地方一样。

Ryan Donovan：我可以想象人们查看保存每个交互的提示和响应，就像，你知道，日志记录的问题放大了n倍，对吧？你只是有这么多存储用于这些三段式响应。然后你是在泄漏敏感信息吗？

Nic Benders：这绝对是，你知道，我们和市场上的每一个其他工具都必须非常注意敏感信息部分，特别是存储大小与发生的很多事情相比。在机器规模上，一个服务调用另一个服务，它生成像10段异常堆栈的日志行，与那些相比，你来回与LLMs的数据量相对较小，并且它是可管理的，因为它发生在人类规模上。某个人做了一件事，人类交互的数量比机器交互的数量小得多，所以它真的保持在控制之下。但你必须应用控制来屏蔽。你必须说，“让我们屏蔽掉任何已知的敏感数据。”你必须应用采样控制并说，“嘿，如果发生某些事情导致音量爆炸，我们实际上不需要捕获每一个。我们如何知道要查找哪些？让我们查找有错误的那些，”等等。很多我们在过去10年中采取的相同实践来分析分布式跟踪树，查看“我如何知道哪些数据库调用是我想要捕获的？”我们可以查看那些相同的技术，然后你知道，将它们应用到这个中。当一切归结到底，它只是另一个服务调用。就像，我们仍然通过网络联系，我们在与另一个系统交谈，协议有点奇怪，而且奇怪的是它用人类语言与我交谈，而不是像，你知道，用SQL，但它在根本上是一样的。

Ryan Donovan：对。归根结底，它只是一个API调用。所以，我们谈了很多关于AI如何使事情复杂化，使事情变得困难。它如何帮助？

Nic Benders：它帮助的方式是第三部分。我几乎想退一步。我们现在谈论AI这么多。就像，你知道，什么是AI？它是人工通用智能吗？所有这些移动的球门柱。我在这里想特别谈论两件事，一是LLMs。LLMs是那些聊天机器人和一切大多数人现在使用AI这个词时谈论的东西，另一个是基于神经网络的预测系统，不是用于语言的。所以，就像，超越统计模型，你可能有一个静态基线系统，但它不与你交谈，它在智能地进行推理。这两个系统共同拥有的对我们行业超级有价值的东西是它们擅长处理非结构化和半结构化数据。结果证明我们在世界上有很多半结构化数据。我们谈到了那些日志行——我有日志行，虽然我知道它来自哪个主机，但我的主机名可能在一个有点古怪的模式中，有时解析，有时不。我知道时间戳，但然后日志行的消息，是100行堆栈跟踪吗？是一条消息吗？是同样的消息，但由不同团队的人措辞，他们只是没有完全用同样的方式表达，里面有拼写错误？所以，它有这种半结构，我们世界的很多东西对人类来说很容易看。我们会说，“哦，那是一个有趣的错误。哦，那是同一个东西。哦，你知道吗？这条消息让我想起了六个月前我们处理事件时看到的一条消息。嗯。那很有趣。我现在应该回去查看那个事件。”让我们进入LLM世界。LLM几乎可以实时完成所有这些。它可以说，“哦，这里有一条日志行。这是一个错误，或者是一个新的爆发。”我说，“我看到与标准速率的显著偏离。”我看着日志消息。它里面有一些有趣的词。那些有趣的词映射到我对我们以前见过的每一个事件以及那些事件中说的任何东西的完美人工记忆，“哦，那在这些RCA中，让我们调出那些RCA。这些RCA与你现在看到的任何当前问题有关吗？也许是。我会展示给你。或者，也许我甚至会只是向人类提议它们，”不是作为最终答案，而是作为，“嘿，让我为你省去一些跑腿工作，你应该看看这个旧的回顾。”我认为这种可能性，结合预测特征来判断某物是否异常，与日志数据、跨度数据、主机名、应用程序名、错误堆栈、回顾、你知道、聊天消息之间的结构化和半结构化合并——你可以开始将所有这些东西缝合在一起，并大规模地做一些否则根本不可行的事情。而且你不需要超级智能来做这个。你只需要擅长导航工程师说话和打字的奇怪方式，以及概念相关的方式。我认为这是一个巨大的承诺。所以，那就是我早先谈到的理解引擎，我们从仅仅是“看到”到“理解”。然后从那里，你能进入“行动”吗？你能看到发生了什么？理解发生了什么，并采取行动来处理它。你知道，这是我们作为一个行业谈论的事情，好像它是一个圣杯，但如果我回头看，自动修复是真实的。对我们来说每天都在发生。是“白帽子”或任何东西在20年前重启我们的守护进程。Kubernetes——

Ryan Donovan：把它关掉再打开，对吧？

Nic Benders：对。关掉再打开，大规模地。Kubernetes，当我失去一个节点时，它只是在其他地方重新调度。就像，你知道，我们今天系统的这么多部分——自动扩展，“哦，我们有额外的负载。只需启动更多实例。”这是自动修复，但所有这些都是以非常非常清晰的方式完成的。这个发生，然后这个发生。我必须构建每个剧本。我们可以为每一个可以想象的任务构建剧本，但我们永远跟不上。所以，我们能使用同样类型的半结构化、结构化接口来获取那些剧本并使它们工作，而不必花费我整个生命为每个应用程序写每一个案例吗？

Ryan Donovan：DevOps全是关于自动化很多事件基础设施生产的东西，对吧？就像，只是让它运行得更顺畅。但我认为也有很多人像，“我不理解这个AI的思维过程，”对吧？只是让Kubernetes启动一个新节点。你理解那个思维过程。那里没有很多思维需要进入，但当它像，“好吧，我如何修复这个事件？”你想要一些你可以理解其思维的东西，对吧？

Nic Benders：是的，我认为那是真的，我认为我们将来到的是清晰和可理解之间的那条线，就像，“哦，机器只是做它。”Kubernetes不会页面人类说，“嘿，我失去了一个节点。我应该移动东西吗？”你像，“是的，显然移动东西。”它被认为是如此简单。下一个层是什么？有哪些事情我们可能五年前说需要人类，今天也许不需要？也许，“哦，嗯，如果我看到这条消息，那实际上是一个很坏的迹象，触发回滚。回滚大部分工作了，但这个节点卡住了。我需要你杀死那个节点然后移动它通过。”我不是要求它 necessarily 为我写一首诗，尽管我猜我们看到LLMs真的很擅长那个。但只是稍微思考一下静态运行手册的边界之外，我认为我们实际上可能从这中获得很多，只是看看我们如何推动那个边界，然后，你知道，三年后，五年后，如果我们再次看这个问题，也许我们对什么是机器的工作与人类的工作有不同的想法。我认为总有一个人类的工作。就像，构建软件来实现目标和类似的事情，但你知道，就像你早先问我，我还在写任何汇编语言吗？我像，“不，我没有。”你知道，也许五年后我会对今天我们做的一些事情有同样的感觉。

Ryan Donovan：对。你不再翻阅堆栈跟踪了，或类似的东西。我们如何获得一个理解所有这些上下文、系统所有可能性的LLM，并有足够的防护栏，这样当它行动或建议行动时，它不会破坏任何重要的东西？

Ryan Donovan：我认为

Nic Benders：我们必须建立信任，你必须建立上下文。所以，信任来自于——作为人类，我们将不得不看到系统内部。所以，我们需要看到应用程序中发生了什么。什么是正常的，什么不是，之后发生了什么，行动是什么？我们想处于那个人马模式，其中AI为我们提供动力并让我们做这个，但我们仍然看到所有步骤并在这一点上做出决定。然后，我认为我们将发现的是，其中有一些部分我们可以真正理解其边缘并说，“好吧，我们可以在这周围放一个强盒子。AI被允许重启节点并升级并做这个和这个，但它不允许就像，你知道，删除我所有的AWS资源。”那是我不需要它做的事情。我们必须寻求慢慢向上移动那个。为了达到这一点，我们将需要解决一些今天在行业中相当分散的事情。我认为我们需要在AI工具本身上达成一致，而且也在可见性上，比如我们需要为可观测性做什么？现在，很多AI监控只是由编写AI系统的人完成，我认为这对那些单独的技术平台没问题，但对消费者不好，对需要跨多个平台查看的客户不好。所以，我们真的希望看到OpenTelemetry在AI系统中的采用。我们在几年前对OTel下了一个大赌注，因为我们已经可以看到，即使这是在AI成为新闻项目之前，你永远无法在任何地方安装你自己的软件。你将永远以合作伙伴模式工作。我有这个云提供商，我有这个SaaS提供商，我有这个团队喜欢的这个工具，它回答这个问题，但我想访问其中一些数据，我想把它们全部拉在一起做我的工作。你知道，我不能说服每个云提供商出去到处安装我公司的软件。所以相反，我们与OpenTelemetry小组合作，让他们解决，“这里是我们如何用那个做这些问题，”我们看到了这个回报。我们看到亚马逊几年前接受了它。Google现在正在接受它。如果我们能让OpenTelemetry也在AI世界中被接受，那将，我认为，增加那个关键成分，即对AI系统正在做什么的可互操作的可见性。

Ryan Donovan：那很有趣。所以，让OpenTelemetry进入AI的决策过程——或某种在API后面？

Nic Benders：我在想API后面，像，围绕所有事情。当我考虑OTel的优势时，有一个线协议和类似的东西，但这些实际上几乎有点无聊。优势是它是一组共同的决定，像概念、名词和动词，我们可以谈论的东西，这样我们知道，“哦，这是一个跨度。这是一个指标的样子。这是一个分布如何工作。”那是我们需要的。我们认为它将是OpenTelemetry，也许是别的东西，我们将不得不适应那个，但你必须有一个共同的概念框架来监控这些事物在做什么。然后那不仅提供从AI系统输出到你对它们的监督，而且它也可以提供输入，因为我们将使用AI来帮助解决由AI引起的这个复杂性问题。所以，能够堆叠那个对于理解所有这些代理、或工具、或无论我们这周叫它们什么，如果它们在做我想要它们做的事情，然后能够回到过去并理解当它们不这样做时它们哪里出错了，是超级有价值的。

Ryan Donovan：我的意思是，我可以在AI公司中看到一点阻力。有一点魔法和烟雾和镜子。我记得有一些最先进的LLM实际上是八个不同的模型或类似的东西，而让OpenTelemetry进入那里，会像，“这里是它如何工作的全部。这里是幕后的Oz。”

Nic Benders：要求它一直在后面可能太过分了，但我认为稍微向前只是能够看到那些交互。一个很好的例子是你可以用于进行向量搜索、推理和编写代理的所有不同框架，所以一个关于我们如何构建AI代理的通用检测，我认为，将大大有助于能够信任我们的代理在做我们想要它们做的事情，而且几乎没关系——是的，幕后是什么？伟大而强大的Oz可以安静地待着，但我想知道Munchkin Land发生了什么。

Ryan Donovan：很多公司已经转向开源，只是因为它是一个更可见的生态系统。拥有开源，或至少开放权重的AI，有助于获得那种可见性吗？

Nic Benders：我认为开放权重很有趣。我玩了很多开放权重模型。我认为开放权重模型对于理解可能的世界真的很好，像，“嘿，我有一些实验想运行。也许我有一些专有数据，我不舒服发送到一些不透明的API给一个可能的竞争对手。所以，我想玩玩这个。”而且我认为它也只是人们理解没有伟大而强大的法则的机会，你知道，就像，“哦，你知道吗，这实际上主要是Python和一些GPU，”而且它去神秘化，即使它没有明确告诉我，“哦，嗯，这就是在我的生产环境中确切发生的事情。”是的，开放权重是理解，“哦，它做这个，它通过一个路由器，然后它被转换。它出来并吐出，”并建立那种直觉，对系统的感觉，使它们不那么可怕的完美工具。

Ryan Donovan：也许我们需要一个伟大的整体去神秘化。我认为我们早先谈过的是人们正在失去可见性和下面发生的事情的基本细节。在这些抽象层之上。也许我们需要再次从AI和软件工程中去除魔法。

Nic Benders：是的，我认为这绝对正确，因为脾气暴躁的软件工程师在这里是为了去除魔法。但你知道，这有点正确，很多错误是由认为JVM是魔法的人犯的。然后结果发现JVM只是运行在计算机上，然后，“哦，它是云。云可以做任何事。”云只是别人的数据中心。“哦，AI将产生所有这些奇迹。”你知道？它真的只是一个统计模型。一些Python。它有令牌进，它有令牌出。它很复杂。它似乎有点神奇。它仍然奇怪和奇妙，但最终，它只是软件，当你自己运行它时，是的，也许是去除一些那种魔法的健康剂量。

Ryan Donovan：嗯，是节目时间了，各位，我们向那些来到Stack Overflow，放下一点知识，分享一些好奇心，并为自己赢得徽章的人喊出。今天，我们向 populous 徽章的获胜者喊出——有人在“C++中的读者/写者锁”上放了一个答案，它如此好，以至于超过了被接受的答案。恭喜Yochai Timmer回答了“Reader/Writer Locks in C++”。如果你对那个好奇，我们会在节目笔记中为你提供答案。我是Ryan Donovan。我编辑博客，在Stack Overflow主持播客。如果你有话题、评论等，你可以发邮件到podcast@stackoverflow.com。如果你想直接联系我，你可以在LinkedIn上找到我。

Nic Benders：我是Nic Benders，来自New Relic，当我不观察系统并试图理解它们时，你可以在LinkedIn上找到我，或发邮件到nic@newrelic.com。我总是很高兴收到你的消息。

Ryan Donovan：好的，各位。谢谢收听，我们下次再谈。