摘要

Bruno Borges讨论了性能管理的范式转变：从手动调优转向自动化的SRE智能体。他解释了如何结合使用USE和jPDM方法论与大型语言模型（LLM），将平均修复时间从数小时减少到几秒钟。通过利用MCP工具进行实时诊断和内存转储分析，他分享了工程领导者如何在满足严格目标的同时扩展系统。

正文

Bruno Borges: 我是Bruno Borges，在微软工作。今天我们将讨论SLO违规。在座有谁处理过这个问题？谁不想处理这个问题？我们将讨论定义性能、设定SLO、设定目标。什么是性能诊断？我们如何进行？然后我们将讨论SRE智能体。如果能够自动化，就应该自动化。这是我们的座右铭。本次演讲是关于故障排除性能需求和SLO违规的。它不涉及性能调优。

高级性能调优，我认为这实际上取决于您拥有的工作负载类型、使用的技术栈类型、语言运行时类型。在座有谁处理JVM？谁处理.NET CLR？Go？Node？我不会给你们讲弹性架构。关于这方面有更多人撰写了数十年的许多书籍。那是你们应该去学习的地方。还有SRE实践。我们之前也有来自微软的David的演讲，他做了一个关于SRE的精彩演示。那些是你们应该学习的人，而不是向我学习。希望本次演讲能给你们一个宏观的视角，以便你们随后可以深入研究本演示的每个内容、每个部分，并从其他人那里进行更高级别的学习。

定义性能 性能到底是什么？在座有谁喜欢音乐？大家都喜欢音乐吗？你们喜欢去听现场音乐会吗？那是一场演出。你们去听音乐会时有一个期望，希望它会很棒。它不会太短，也不会没完没了，恰到好处。你们支付了票价，并期望这个价格符合你们对所寻找乐队或戏剧等的期望。性能实际上就是关于这些。这里有一个例子。您的应用程序可以很快，但如果它运行过热，成本高昂或在负载下崩溃，这就像一辆跑车被困在城市交通中。它只是没有发挥应有的性能。它可以跑得很快，但由于环境、城市交通的原因，它没有发挥出应有的性能。

性能不一定与速度有关，而是关乎满足期望。这就像您拥有一辆舒适的车，可以通勤，并且不会在旅程中抛锚。它是关于一致性、效率以及在成本、时间预算之内。有一种更好的方式来可视化这一点。你们看到底部的这个条形图。系统的性能可能太慢，不符合期望，但也可能太昂贵。它可以超级快，但没有满足其他期望。这就是性能的含义。当我们思考性能时，通常会想：它必须快。它必须有高吞吐量。它必须有低延迟。

只要保持平衡，您不想仅仅为了快而花费数百万美元。您不想仅仅为了拥有低延迟、高吞吐量而花费数百万美元。您想要恰当的平衡。有时性能调优是关于如何降低成本，或者如何在不多花费的情况下提高系统的处理速度。这就是您要尝试做的。您试图找到中间点，试图满足成本、时间和客户期望的期望。SRE们倾向于关心效率和可靠性，不一定关心速度。如果它快但经常崩溃，或者便宜但无法满足SLO，那么它就没有发挥性能，不一定是不快，只是没有发挥性能。

还有另一种可以想象的可视化方式。想象一个三角形，在一个角是速度，另一个角是成本，最后一个角是客户期望。您可以任选两个，但SRE的工作实际上是平衡所有这三个。扩展的方式实际上是做得更少。如何在不增加更多成本的情况下扩展系统？您尝试做更少的事情，因此不需要更多资源。当系统难以扩展时，例如，您缓解问题的第一个解决方案可能是添加更多副本、添加更多虚拟机，仅仅拥有更多系统实例或数据库集群中的更多节点。任何横向扩展或纵向扩展应用程序的方法都可能缓解问题，但可能实际上没有给您那种平衡。您只是增加了更多成本。一个很好的例子，想象一家杂货店。增加更多收银员有帮助，但如果您能训练收银员在顾客购买酒精时更快地验证ID。比如，这是我爷爷，他不需要出示ID。收银员就直接放行。这加快了流程。您消除了流程中的一个步骤以加快速度。挑战在于您需要找到系统中哪个步骤正在拖慢整个流程。

当您识别出这一点时，就识别出了瓶颈。瓶颈是一个限速活动。这里另一个例子，比如您有一条生产线，一个工人还在阅读手册以了解如何处理零件。这拖慢了整条生产线。当您找到流程中的这个步骤时，就优化它，然后其他一切就顺畅了。这可能是CPU、内存、I/O、线程池、或者只是糟糕的代码、代码热点路径。您需要识别并优化它。

有时您可能优化了一堆东西，但这实际上对系统整体没有帮助。您仍然在某个地方存在着那个瓶颈。回到音乐。这里有一个有趣的练习。想象您在参加一场音乐会，进入场地只有一个门。有一个保安人员在检查包。然后我们增加另一个门。瓶颈在哪里？是检查包的保安。只有一个。现在您有两个门，通过的人多了一倍，但仍然只有一个保安检查。这非常明显。我只想在这里快速做个小测验。如果我们仍然只有一个门，并且有一个等待队伍在等待一个保安检查，但您增加另一个保安检查会怎样？会发生什么？

参与者1: 门是瓶颈。 Bruno Borges: 门是瓶颈？不一定。瓶颈不一定在那里，问题是等待队伍会发生什么。当您增加两个保安检查时，门口的单人等待队伍会发生什么？

参与者2: 会快很多。 Bruno Borges: 会快很多。是的，保安检查速度快了一倍。等待队伍会发生什么？等待队伍缩短的速度是多少？以什么速率？

参与者3: 快一倍。 Bruno Borges: 快一倍？有趣的是，实际上是指数级的。排队论中有一个公式可以计算这个。您需要知道服务时间、到达率。这回到了排队论，您可以找到速度是多少。实际上比快一倍还要快，仅仅因为现在您有两个检查包的保安，其中一个可能需要一分钟，但另一个，那个人没有包，所以他直接通过，所以快很多。等待队伍将随之移动，因为您现在在做这个。当您去超市、杂货店时也是如此，您希望看到一个单一队伍通向所有收银台。那是杂货店的最佳优化。

由于许多原因，有时人们在心理上喜欢选择，因为他们认为自己很聪明，他们想选择他们认为最短的队伍。有时这实际上会误导您。从排队论继续。同样，您找到了瓶颈并想要优化它，需要哪些步骤？您需要进行性能调优。您需要调整流程中那个特定步骤的性能。您必须心中有方法论，我们将在此更详细地介绍，但您必须有目标。我们也将介绍这一点。您必须了解应用程序架构。

最重要的是，您必须设定时间预算。流程、系统、那个REST调用或那个函数中的所有步骤，您必须为所有步骤设定时间预算，以便您能知道，对这个REST API的调用在这里花费100毫秒做这个，200毫秒做那个，500毫秒访问数据库，等等。您开始为系统中的那个函数设定时间预算。还有一点您应该注意，比如数学概念和原理、对技术的理解。同样，我见过一些团队查看JVM，但他们不了解JVM的细节，不知道如何优化它。对于CLR、Deno和V8、Go也是如此。团队应该了解这些技术的可调节参数。Kubernetes调度、CPU限制，所有这些主题都极其重要。然后是所有您可以用来观察、调整、尝试、验证、测试生产环境变化的工具和策略。

我们刚刚描述了什么是性能调优。我只想给你们一个幻灯片总结。您必须有目标。什么是目标？我的请求中95%低于100毫秒。在这种情况下，我希望我的p95。吞吐量观察，如果吞吐量下降到5,000 RPS以下，我会有一个警报触发。然后我必须诊断那个问题。我必须找到症状。而寻找症状是SRE、开发人员、工程师、运维人员花费大部分时间的地方，因为您刚刚收到这个警报。“CPU太高，内存太高，I/O花费时间太长，发生了什么？”然后您必须开始深入系统以找到问题所在。之后，您才进入调优模式。我可以投入更多资源，或者我可以找到瓶颈并修复它。

免责声明，有时解决方案是更多资源。这完全可以，只要您理解它。仍然像调节正确的旋钮，例如，更多资源可能只是在Kubernetes上增加容器的CPU和内存限制。这可能就是那个旋钮，不是JVM旋钮，不是应用程序旋钮，不是数据库，可能就是基础设施。您找到哪个旋钮？您打算查看并调节哪个旋钮？这并非不切实际的想法，就像，F1车手在比赛中不会触碰大部分这些按钮，他们是在排位赛中做的。在比赛中，他们会调整一两个东西。他们每圈都会在范围内按下DRS按钮。差不多就是这样。有些车手可能会按错按钮打开无线电。如果您关注F1，这很有趣。

关于F1车手的一点是，他们有目标。他们想跑得快。他们想在必须进站之前，将燃料燃烧到合适的量，因为F1现在不能再加油了。他们想在必须进站之前将轮胎用到合适的程度。他们在整个比赛中也有目标，不仅仅是获胜，还要保持一致性，在比赛中保持节奏。这就是为什么对于我们作为系统工程师、开发人员来说，设定目标非常重要。

设定SLO 在我与工程团队的对话中，有很多讨论，我们应该使用哪个术语，SLA、SLO、SLI？SLI很有趣，但我在这里只关注SLA和SLO。在几乎所有情况下，SLA只是法律文件。这只是供应商和客户之间的法律协议。对于我们工程师来说，我们真正关心的是目标。我真的很喜欢强调这个词，因为没有目标，您就不知道自己在寻找什么。您不知道去哪里找。一旦您有了这些目标，例如，CPU使用率、调用时间、响应时间、延迟、吞吐量等，那么您就可以回到您的绘图板，好吧，让我们对这些东西进行时间预算，以便我们知道如何保持在那些目标之内。这里，例如，我们有一个客户端应用程序、客户端应用程序服务器、后端，然后是数据库。

在这个图表的每个连接跃点中，您必须了解进行该跃点需要多长时间。OpenTelemetry是这方面的一个很好的工具。许多框架内置了这个功能，您可以启用它。它会给您这个很棒的可视化效果，您甚至可以在OpenTelemetry中自定义事件，使它们更具业务相关性而非技术性。例如，贷款批准时间，这可以是您在OpenTelemetry中可以创建的一个事件。它给了您这种灵活性，以便您可以拥有有时不一定技术性的目标，它们更偏向业务。这也很重要，因为它们关联起来并且更容易从客户角度理解。

接下来，出现了一个性能问题，我们想解决这个问题。我们可以将其分解，比如解决时间，MTTR，可以分为三个部分。一个是观察。我们可以使用APM解决方案。我们可以使用日志分析。我们可以使用仪表板、警报、PagerDuty。实际上，PagerDuty只是给您警报，有不好的事情发生了。您从这些解决方案中获得所有这些信息，并且希望您已经自动化了许多事情，根据某些事件，您已经有一些可以在短期内完成的缓解措施。缓解措施完成后，您可以回到第二个部分，即现在让我诊断这个问题，并尝试解决问题。问题在于，当不好的事情发生时，您只是不知道您不知道什么。正因为如此，很难找到问题所在。

据推测，在许多情况下，您时间预算中的绝大部分时间都花费在这里。最后，一旦您确实找到了问题，有时解决方案实际上非常快，因为您知道问题在哪里，解决方案可能很快。有时部署时间可能稍长一些。问题已修复，但是的，我们需要两周时间来部署，因为那是部署窗口。这取决于情况。

回到本次演讲的主题，SRE智能体，您认为这里的哪个部分SRE智能体会擅长？观察？在某种程度上，是的。诊断？谁认为是修复和部署时间？谁认为是诊断？谁认为是观察？是诊断，因为这部分确实复杂，因为系统中有太多层需要遍历，太多流程、工具和日志，才能找到问题所在、瓶颈所在。这就是如果我们可以自动化，我们就应该自动化的部分。许多团队已经在没有AI、没有LLM的情况下自动化了这部分。如果我们能走得更远，我认为那里有很多价值。

性能诊断 - 方法论和工具 要自动化，您必须心中有方法论。您必须心中有一个关于如何诊断的过程。我要做什么，什么时候做，使用什么工具。所有这些对于拥有一个一致的过程都极其重要。有一种叫做USE方法。它是关于确定问题、识别有用的解决方案，然后评估这些解决方案的影响。这种方法可以应用于许多事情，不仅仅是软件工程、航空公司的运营、物流、供应链、建筑、人力资源部门。这是一个非常有用的方法，可以在任何领域应用。

Kirk Pepperdine设计了这个叫做jPDM的模型。它是一个最初为Java设计的性能诊断模型。它可以用于任何语言运行时。它是一种自上而下然后自下而上的方法。它首先查看时间预算。您必须在系统中有那些指标。就像我说的，它可以应用于任何语言运行时。将这些方法论视为您的行动手册，指导您如何进行诊断性能问题的旅程。一旦您知道系统在做什么以及谁在让它做这些，比如参与者，那么您就开始很好地理解从哪里开始调查。

系统是消费流。有一个参与者，数据进入，然后通过那个管道，发生了一些事情。什么是消费流？消费流，您可以想象这些层。如果您有参与者，可以是用户、作业、批处理计划、数据库事件、事件系统、另一个API。现在是一个AI调用MCP工具，最终调用您的REST API。有很多东西可以是参与者。

一旦请求到来，您就开始在整个系统中施加这种压力。它通过您的应用程序、业务逻辑，通过JVM或您的语言运行时、CLR、Go，一直到硬件。实际上还有额外的层不在这个图表中，但您可以考虑cgroups、容器、虚拟机、管理程序，许多东西介于您的托管内存和硬件之间。一旦您理解了这些层，您实际上就可以开始思考一个如何进行诊断的过程。Kirk在jPDM中设计了这个很好的流程。

首先，您思考，我如何对系统中间题发生的瓶颈进行分类？我遇到了SLO违规。是系统主导的吗？是应用程序主导的吗？还是根本没有主导？我应该看其他地方吗？这个图表可以在线找到。您可以搜索jPDM，可以学到很多东西。只是为了让您理解，心中要有方法论。有很多可用的方法论，但有些已经非常有效，已经在许多客户的生产环境中尝试过。

如果您能利用这一点，那就去做。如果您有自己的方法论，请思考如何自动化它，尤其是随着AI的发展。生产环境中发生了问题。您如何对其进行分类？您可以看到我们在这里读取了一些数字，CPU使用率、系统CPU使用率或用户CPU使用率。Linux中的哪个工具会做这个？我们可以从vmstat开始。这将帮助我们识别瓶颈主导发生在哪里。是应用程序、系统，还是无主导？这个工具会给您很多数据，特别是如果您持续查看它。它很棒，但通常在问题发生时的一个快照就足够了。

系统主导。您可以使用USE方法论调查症状。您寻找上下文切换率，最终您将深入到您使用的语言栈。然后，您看到该级别有多少工具可用，仅仅因为有太多可用的工具，您必须了解这些工具。SRE工程师很擅长这个。运维团队很擅长这个。如果我们能自动化这个呢？这是Brendan Gregg关于在Linux上应用USE方法进行故障排除的图表。他的网站有很好的资源，所以您绝对应该查看一下。这个图表只是让您了解找到实际瓶颈可能有多么复杂和困难。您可能会找到看起来像瓶颈的东西，但您如何真正找到瓶颈？这是一张关于应用程序主导的幻灯片。您做什么？您检查是否是垃圾收集器，检查可观察性代理，您的New Relic等。您获取GC日志以便了解GC的工作模式。

然后使用分析工具。您在这里寻找的，当您查看应用程序主导的问题时，是运行时如何管理内存、运行时如何管理线程、运行时如何管理分配率等。您可以根据应用程序需求调整运行时，始终回到您心中的目标。这是我们内部在微软用于Java的工具示例。在这个特定的截图中，我们可以看到延迟。图表中有几个点非常糟糕，与底部的平均值相比。为什么？这是垃圾收集器的暂停时间（秒）。那个暂停时间在生产环境中花了将近44秒。其他所有都低于1.5秒、1秒。非常好，但系统中发生了什么事情。为什么GC中的长暂停时间会导致糟糕的延迟？因为如果GC工作时间太长，您的应用程序就不工作。

这是一般原则。这意味着在那44秒的时间段内，几乎所有对您应用程序的请求将至少需要44秒。那么吞吐量呢？这是一个暂停时间百分比的示例。在应用程序的整个生命周期中，如果发生太多暂停，同样，您的应用程序处理能力不足。一个请求可能很快通过，但由于暂停如此频繁，您的应用程序降低了吞吐量水平。这些信号可以给您内存复杂性。

一种解决方案是调整GC。另一种解决方案是减少系统的分配压力。另一种解决方案是仅仅减少活动集。不同的技术栈有不同的工具。对于Java，您有VisualVM和JDK Mission Control，它们很棒。内存复杂性非常普遍，但也是最不可见的问题之一。在分析内存、GC日志等时，要确定问题所在可能很棘手。这不一定是关于我们有多少内存。我们有足够的内存吗？而是关于语言运行时如何使用内存。

让我们看几个图表来理解这是如何发生的。这里有一个显示堆大小使用情况的图表。这看起来像内存泄漏吗？当内存这样变化时？不一定是内存泄漏。有时应用程序在做它必须做的事情，GC正在尽力将内存消耗保持在设定的限制内。显然，它不再释放内存了。不一定是内存泄漏。就是这样。另一方面，这个图表显示了一个非常健康的应用程序。您看到内存消耗，GC工作并清理，工作并清理。

另一方面，这个图表看起来像内存泄漏，因为清理发生了，然后您开始有越来越多的对象始终在内存中。更多的GC工作被完成，图表从未下降。GC的频率持续增加。这是一个内存泄漏。回到我们关于MTTR的那个图表，您有诊断，花费很长时间。您必须查看所有这些数据、所有这些图表，尝试理解它。有时需要几个小时，希望如此。有时需要几天。根据系统的复杂性，有时可能需要几周。

然后修复时间，同样，可能需要几个小时、几天或几周。如果我们进一步自动化会发生什么？已经有很多自动化在进行，但如果我们能用LLM和AI进一步自动化呢？这就是这两个部分实际上可以缩短到几秒钟和几分钟的时候。因为现在您有了这个方法论，无论您选择什么，都可以在环境中访问所有这些工具。然后所有这些方法论都可以由智能体反复应用。该智能体遵循您的方法论，给您一个分析，甚至给您一个建议。

一旦您有了那个建议，您可以将其输入到开发人员智能体、编码智能体中，该智能体将应用代码中的更改。如果您足够勇敢，您可以全自动完成，然后直接进入生产。如果您不够勇敢，那也没关系，您实际上希望在进入生产之前审查它。如果您正在进行金丝雀部署、A/B测试等操作来隔离负载，您实际上可以让生产系统中一定百分比的应用更改生效。如果一切顺利，一切顺利。只需将该更改复制到其余部分。

SRE智能体 - 强大的MCP工具带来更强大的自动化 我们已经涵盖了性能、目标、方法论和工具。我们手头有了一切来自动化。现在我们需要做的就是加入一些AI，然后就成了。没那么简单，但也没那么难。MCP工具是解决这个问题的一个很好的解决方案，因为您可以在您的环境中运行这些MCP服务器，并访问这些Linux工具、语言运行时工具。然后，当发生SLO违规时，可以触发这个MCP服务器并自动开始诊断问题。这几乎就像您收到一个PagerDuty警报，发生了一些事情，然后您回头去倒杯水，因为您对此感到紧张。然后，您喝完水后，另一个警报，系统正常了，因为您的SRE智能体刚刚修复了问题。祈祷吧，这就是我们想要实现的。

如果这确实发生了，那实际上取决于许多事情。什么是SRE智能体，这些东西如何协同工作？用于此事的自主AI智能体将能够访问那些性能工具，最好使用MCP，因为这是一种很好的方式，可以让LLM只做您希望它做的事情，并访问所有这些工具，vmstat、jps、strace。希望大多数触发器是基于您拥有的那些目标自动化的，但它也可以由人工触发。您可以进入您的IDE并说，我好奇这个性能如何，为我运行那个诊断。然后您得到这个结果，说，我实际上可以在这里进行一些优化，甚至在警报触发之前。

最有趣的是，您将诊断从数小时和数天缩短到几秒钟和几分钟。您可以进行评估，评估AI的建议，然后您可以应用更改。这就是SRE智能体和SWE智能体（软件工程师）协同工作在生产环境或暂存环境中应用那些更改的不太遥远的未来有趣之处。这些更改，我们审查它们，我们分析它们，但您不必深入研究所有这些层来找到问题，那已经为我们完成了。这里的一些功能，7x24小时运行。也许您可以减少您晚上醒着、担心系统的时间，睡得更安稳。基础设施最佳实践，回到您的方法论。您自动化响应，您甚至可以自动化缓解，比如一个缓解智能体，并且实际上加速了您的根本原因分析。

演示 让我们看一个演示。我这里有两个演示，一个用Java，一个用.NET。希望我能取悦最酷的企业生态系统，它们正在与Go、Python、JavaScript激烈竞争。在我展示视频之前，我想向您展示一下它看起来是什么样子，至少从我们正在进行的Java SRE智能体解决方案来看。我们这里有这个例子。这是分析发生后的结果。您在这里可以看到，我返回了所有已执行诊断的列表，然后它将使用MCP来识别服务器中发生了哪些诊断？这是我的目标配置文件。我这里有延迟触发器。这进入我的应用程序以及我的APM解决方案。一旦这在生产环境中运行，现在我可以去问我的SRE智能体，我们称之为Illuminate for Java，发生了什么？

然后，是的，我看到您正在查看IlluminateProfiles.java，这实际上与此上下文无关。这更像是一个人希望在生产中诊断某些东西，而不考虑触发器。对于这个演示，我们每60秒运行一次诊断。我们有一个JMeter实例一直在触发API，然后每60秒，我们有一个警报，并触发诊断。我查看诊断。这是一个JSON示例，来自这个MCP工具。

基于这些信息，我可以看到有一个诊断可用，系统检测到您的petclinic/api/owners存在性能问题。根据我为触发器设定的目标，这个特定的REST API表现不佳。它将深入分析。我将获取这个诊断，这个特定的诊断，这是我的输出。我这里有什么？标识符，系统是0，空闲是99%，权重是0。出于演示目的，请忽略数字，但关键点是您得到了那个诊断文件。然后，从那里开始，MCP工具与LLM结合，它们可以调查问题。它还可以访问Kubernetes级别的其他工具，因为我们的SRE智能体部署在Kubernetes上。

有一个警报类型：请求延迟违规。这个API，花费的时间比应该的要长。90%的请求应在2毫秒以下。我们在那里随机抛出一个Thread.sleep。这是一个10秒的监控窗口，这意味着希望我们不会一直触发这个，因为我们希望限制窗口，以免淹没警报系统。这是最小样本，需要30个请求。在采样中发生30个请求后，它会触发警报。关键发现。这是LLM与SRE智能体的MCP工具协同工作，试图找出问题所在。诊断显示等待过多是主要问题。

CPU使用率非常低，所以只是在等待，所以那里有一些阻塞。没有资源使用。可能的根本原因，数据库连接问题。可能，同样，您的应用程序只是在等待数据库响应，或者是网络I/O瓶颈。可能您的云环境网络出现了一些中断，线程池饥饿，或同步阻塞操作。它帮助您缩小问题空间，以便您可以只调查那些可能更直接影响问题的方面。

例如，此分析中没有磁盘使用率。磁盘使用率很糟糕。这没关系，因为问题不在这里。它给出了一些建议。这是建议的操作。让我检查您的Spring PetClinic应用程序配置文件。之所以显示这个，让我检查PetClinic配置文件，是因为我正在进行分析，在Visual Studio Code中诊断项目处于打开状态。GitHub Copilot，LLM将尝试基于您拥有的上下文查看所有内容。

下一个演示，.NET演示在一个在线仪表板如Azure DevOps中更展示这个解决方案，您从生产角度查看SRE。它无法访问源代码，并且发生在服务器端。在这里，分析是在部署在Kubernetes上的SRE智能体与运行在您本地计算机上并可以访问源代码的LLM之间协同进行的。这就是为什么这里的诊断与Azure DevOps SRE智能体略有不同。这是总结。这是配置文件ID，发生的触发器，值，阈值，最小采样，诊断结果：等待过多。关键见解是什么？然后建议的下一步。就是这样。您有一个SRE智能体，它将问题缩小到最可能导致瓶颈的原因。您无需花费一小时查看所有层级的日志，而是直接找到发生问题的地方。

这里的演示，这是App Insights，每秒300个请求发生，响应时间为20毫秒。我们可以在这里看到警报发生。我们将SRE智能体与查看日志的系统自动化。我们可以查看日志，然后，有一个警报。触发警报。这是配置的存储方式。所有内容都部署在Kubernetes中。您有SRE智能体。您有诊断智能体。您有通过APM在应用程序级别完成的监控。然后，这将经历我刚才展示的过程。

在这里的情况下，我认为其中一个建议将是增加堆大小。“您希望我获取更详细的信息吗？”同样，这是LLM与您的本地上下文协同工作，查看部署配置文件。我得到了我的诊断。这是一个GC暂停问题。这是一个建议的修复。您应该更改堆大小。这可能需要某人在生产环境中诊断数小时。在您必须查看的所有日志、配置文件和所有内容中，GC日志并不容易查看，尤其是对于新手来说。一旦您掌握了它，并不难，但有很多工具可以帮助。这就是Illuminate所做的。它使用GC日志，并使用将解析GC日志并找到优化点的工具。它更改了容器的内存限制量，并更改了JVM的堆大小。工程师只是说，应用修复。很好的建议。我批准它。进入生产。

让我们看另一个演示。这是一个.NET演示。

工程师: 现在让我们演示如何利用SRE智能体以响应式方式实时响应事件。我有另一个部署到容器应用程序的应用程序。这里的这个应用程序让我们可以模拟应用程序的各种行为并测试弹性。您可以看到，我可以创建死锁，我可以触发高CPU，并且我可以消耗资源的内存，在这个案例中是容器应用程序。我想在这个场景中强调的是，我只想突出在特定条件下出现的问题，所以不一定是由于配置错误。我想模拟一个内存泄漏，这将导致这个应用程序崩溃。有一些源代码没有清理干净，它消耗了太多内存，最终我们耗尽了应用程序的内存，它崩溃了。这个容器应用程序已与一个名为PagerDuty的事件管理工具集成。我已经配置了PagerDuty，当应用程序变得不可访问或达到某个错误阈值时发送警报。这些警报将通知值班工程师，目前是我。让我们来做这个。让我们不断消耗直到应用程序内存耗尽。就这样，我们现在看到了500错误。我们的应用程序无法访问，它崩溃了。

一旦发生这种情况，PagerDuty正在创建一个警报，它正在通知我这个事件。我想展示的是，我如何设置我的SRE智能体来处理来自PagerDuty的此类警报。这是已部署的SRE智能体，我的订阅中有另一个。同样，我们可以确认它正在管理与此应用程序关联的正确资源。这是我的容器应用程序，已经标记为不健康。如果我们进入设置下的事件管理，我们可以看到我如何配置我的智能体以与PagerDuty集成。我这里有我的PagerDuty API访问密钥。

如果我们回到我们的智能体，应该已经创建了一个线程，就在这里，来自那个警报。从PagerDuty创建的ICM被拉入我们SRE智能体的一个新线程。它将其用作诊断此问题可能是什么的提示。它正在启动该调查。它正在运行工作流以提供根本原因分析。您可以想象如果您是值班工程师，我们都经历过这种情况，我们要睡觉了，我们非常害怕会接到凌晨2点、3点的电话吵醒我们，说有事件发生。您可以放心，SRE智能体已经在处理它，并且已经启动了工作流来诊断问题，并希望解决该问题。

它正在执行其流程。我想做的是跳转到一个已经完成的线程，因为它确实经过了一个相当严格的工作流，检查我们应用程序的所有不同设置、健康状况，做诸如内存转储之类的事情，这可能需要一点时间，但再次强调，这是一个非常彻底的调查。我们将切换到一个已经完成的线程，我们可以看到这个事件已经得到补救。我们的智能体能够检测到，是的，内存极高，达到97%，500错误确实开始出现在我们的日志中。它代表我们执行了内存转储。同样，这些任务并不简单。它能够在几分钟内完成。它提供了这个内存转储。

然后它做的是，它知道它可以通过扩展我们的应用程序来暂时缓解这个问题，将内存和副本扩展到三个，以解决这个问题。由于它认识到这个事件不一定是由配置更改引起的，更有可能是代码引入的问题，它提出了一个GitHub问题，并附上了该内存转储的详细信息。我们实际上可以跳转到我们的GitHub仓库，我可以查看已打开的线程。说是我打开的，但实际上智能体代表我完成了这个。

这里有来自该内存转储的所有信息，以便负责这部分应用程序的软件工程师可以查看并解决这个问题，提供更永久的修复。我最后想展示的是，您始终可以从这些问题跳回到线程。您可以看到智能体进行的完整调查分析。就这样，这是两个不同的场景，您可以使用SRE智能体主动和响应地缓解应用程序在Azure中运行时出现的任何问题。

关键要点 Bruno Borges: 我希望你们记住这一点。性能不是关于速度。不仅仅是关于快速。而是关于满足期望。设定那些目标，以便您知道期望是否得到满足。这极其重要。否则，您不知道自己在寻找什么。像USE或jPDM这样的方法论确实有帮助。它们帮助您识别瓶颈。您可以手动完成，或者可以自动化，或者可以使用AI为您自动化，以便它们可以遍历整个方法论完成所有事情。同样，自动化下一步是什么？也许这是针对这个问题空间的问题。如果您有很多脚本、警报和监控，那很好。您已经完成了一半。因为进行性能诊断并不有趣。它可能有趣，但当生产系统受到影响时，就没那么有趣了。

如果您能进一步自动化，就去做。LLM在这方面很棒。MCP工具是下一步。赋予对这些工具的访问权限，同样，要有非常强大的护栏，这极其重要。我们的SRE智能体解决方案确实有不同的模式。您有读取模式、写入模式，您只有观察者模式等，这些可以真正限制SRE智能体在生产中能做什么。您可以选择您让AI诊断生产问题的勇敢程度。这完全在您的控制之下。您可以自己做。您不必使用Azure SRE智能体。我相信许多其他供应商也在研究类似的解决方案。您可以自己做。您可以获取这些LLM并集成到您的系统中。本地LLM也是这个问题的很好解决方案，因为它们可以轻松地运行在您的工作负载旁边。