📱

Get Our Mobile App

Take your business learning on the go!

Download on the App StoreGet it on Google Play

Resolve AI: Autonomous Production Engineering with AWS Bedrock | AWS OnAir S6

AWS Events16:58

Transcription

哇,杰夫,我们在这里得到了急需的休息。正是我们需要的补水和能量,来结束我们最后的环节,并讲述一个真正有影响力的客户故事。当你想到这些代理式想法的扩散,以及让编码变得更容易时,不仅仅是在沙盒中,而是在真正的企业基础设施和应用程序中,正如 Resolve AI 所说的,机器随时待命为人类服务,没有人比米尔在这里更适合评论他们使用 Agentic AI、Amazon Bedrock 及其他技术的方式了。欢迎来到节目,米尔,很高兴有你。>> 嘿,罗比,很高兴来到节目。>> 你能给我们讲讲 AI 和它的起源故事吗?我是怎么知道你是创始人呢?嗯,嗯,你公司里的很多人都来自 Open Telemetry?所以你们亲身经历过,亲身感受过可观测性世界,以及开发者和 SRE 在半夜被叫醒去解决问题时可能面临的痛苦。没有上下文。他们必须深入研究。你们是怎么偶然发现这个说法的?Resolve AI 是如何开始的?>> 是的,我的意思是,这是一个很棒的问题,对吧?如果你想到起源故事,就像这些都在网站上都有记录一样。在过去的几年甚至几十年里,一直都是关于向工程师提供越来越多的数据,关于如何思考对生产环境进行故障排除。所以你有更多的仪表板,更多的跟踪,更多的日志,更多的指标,以及越来越多的这些,但辛劳总是留给人类。所以当我们看看创始团队,你知道,Resolve AI 的共同创造者,他们实际上已经一起工作了 15 年以上,经历了多个不同的事业,这些事业让他们去了 Splunk,去了 VMware,共同创立了另外两家被这些供应商收购的公司,共同创造了 Open Telemetry。直到在 Splunk,他们才觉得他们已经完成了这个,你知道的,创业冒险,他们觉得这里有什么不同,是 AI 所承诺的,而这确实是他们自己想象力的局限性,他们觉得嘿,我们没有那个上限,想象力就在那里。现在工具终于到位了,我们如何重新思考管理生产系统意味着什么?值班意味着什么?管理那些战争室意味着什么?是的。所以,斯皮罗斯和梅的创始故事。所以他们是 Resolve 的两位联合创始人。嗯,这绝对是亲身经历了几十年的辛劳和艰辛,最终找到了一个解决方案,解决了,你知道的,各地工程师的痛苦。>> 是的,伙计,听起来你有一个演示要给我们看。我想看看 Resolve AI 在做什么,嗯,让我们在你展示的时候谈谈。>> 是的,我很乐意。所以,嗯,如果演示环境今天启动了。所以你在这里看到的是,你知道,Resolve 提供两种体验。我将从用户体验开始,因为我真的想弄清楚,你知道,Resolve 是什么以及我们如何工作,这对于为后续内容铺平道路很重要。但最终,你知道,当我想到一个多代理系统时。所以这不是一个 LLM 包装器。这不是一个 rag 系统,你知道,我们不仅仅是进行一次 MCP 调用。这是一个真正多代理、多模态的系统,它建立在能够做几件事情的基础上。一是理解你的生产环境,从遥测跟踪或可观测性数据一直到基础设施和代码。它也是一个旨在推理的系统,对吧?就像人类通过复杂性和辛劳进行推理一样。采取行动,能够找出修复计划是什么。调用其他工具来启动流程,然后持续学习,这可能是最难做的事情,也是最重要的方面,对吧?就是我们如何进行这种学习。所以我们处理这个问题的方式实际上就是带你了解人们在这里设置时的情况。所以,让我来调出知识图谱。这就像是所有其他事情的骨干或大脑。>> 现在,这并不是为了供人类消费。我不认为世界上有任何一个人能从头开始了解你的端到端生产环境。但你可以想象,这是一个生产系统,以及它所包含的依赖关系和一切。如果你深入到节点级别的性能,所有这些都记录在这里。在这个特定的,我们稍后会回到这里,但在这个特定的环境中,从集成角度来看,它是基于 Datadog 设置的,我们进行了 DNS 捕获,我们还集成了 GitHub 和 Kubernetes。嗯,在这个特定的环境中,我们还集成了 Slack。现在还有其他集成和服务可用,比如如何进入 AWS 等等。但对于这个特定的设置,这就是我们配置的。所以如果我回到那个知识图谱。>> 那个知识图谱是关于一个工作负载的,所以那些都是微服务吗?>> 是的,所以这些是你的微服务,就像在这个例子中,这是消费者结账,就像结账购物车。嗯,我们这里有什么。所以如果我点击前端代理,作为一个例子。它允许我映射出环境中所有的相互依赖关系。所以,这非常强大,因为大多数人,除非你在处理你自己的微服务或你拥有的服务集,否则你不会有这种程度的上下文。如果你是那个晚上值班的人,而别的东西坏了,或者如果以前有过这样的映射,也许是在六个月前映射的,在事情发生变化之前,而且它已经过时了,你正在查看旧文档。所以我经历过。>> 是的,我的意思是六个月,我认为甚至一周,对吧?就像现在,就像 Dako 所说的,你的 Vibe 编码,代码变化如此频繁,它甚至不是关于六个月,而是关于每周甚至每天发生的改变。嗯,在我带你们去看有趣的东西之前,我想提一下的是学习能力,对吧?所以随着时间的推移,每一次互动,每一次事件,或者我只是进来,你知道,帮助改进知识库,代理会变得越来越聪明,并且根据这些互动,越来越适应你的特定环境。所以它们总是在学习,并以记忆的形式保留下来。所以这变得非常强大。这样,你就不必每次它回去值班时都重新训练它。就像它只是去值班,它就像是自我改进。所以,有了这些,让我来展示一下这对人们来说是什么样的用户体验。嗯,有几种方式。在这种情况下,我们有一个,你知道,我们的警报系统设置好了。嗯,我现在在 Slack 里。所以这是完全在生产环境中运行的。所以如果它确实,嗯,你知道,稍微停顿一下,或者它需要思考几个周期,这不是一个阶段性环境。这是为了一个现场演示场景而完全在生产环境中运行的。所以我只是来这里。这个触发器是在今天下午 12 点 12 分左右触发的。嗯,是的,下午 12 点 12 分。所以就在节目进行的时候,Resolve 立即介入,确认了这个,你知道的,这个触发器,这个问题被触发了,然后开始进行初步的调查,你知道的,我认为发生了什么,以及最重要的发现是什么。在这种情况下,它是前端 P50 延迟,对于 post API 结账超过了阈值,大约在,你知道的,1901 UTC 开始。所以大概是 701 左右,对吧?如果我没记错军事时间的话。嗯,是的,我认为差不多。>> 快速说一下,P50 可能是 50 个百分位数。这可能是你配置这个警报以在延迟超过 50 个百分位数时触发的方式。只是为了让>> 是的,所以,是的。是的,这是 100% 正确的。所以它理解了设置的参数的上下文,然后就像,好吧,嘿,这个确实被触发了,警报被触发了,所以我们不在警报业务中,但警报被触发了,我们介入并开始进行分类和调查,但你开始理解,因为它拥有你的生产系统的知识,以及开始时加载的任何部落知识,并且它会随着时间的推移而学习,它开始运行,就像,你知道的,这些是我认为我想测试的多个假设,基于已知的经验,我所拥有的关于这些类型的事件的上下文,或者仅仅是警报的起点,以及我可能拥有的任何依赖关系。所以最终它会这样做。然后很快,它就提出了这个最有可能的工作理论,而且再次强调,这一切都在 Slack 中展示,我甚至还没有离开 Slack 的体验。所以,你知道,大多数人在事件或战争期间的初步调试,每个人都在他们的 Slack 体验或 Teams 或其他什么地方忙碌。所以最后,如果我想达到一个点,就像,好吧,我想深入了解,我想看看到底发生了什么,或者找出修复计划是什么,那么我会来到 UI。而在这里,我可以开始,你知道的,我也可以在 Slack 中与 Resolve 进行互动。所以,就像 Resolve 一样,继续在那里对话。但如果我想今天开始看到,至少是更多的细节,所有正在浮现的证据,因为它理解了一个拉取。所以它不仅仅是一个黑盒体验。它会浮现出证据。那就是你会来到 Resolve 的体验。所以,在这种情况下,你看,仪表板正在加载。它正在读取那些仪表板。它对相关的仪表板有很好的理解。它也带回了你在这里看到的工作理论。对吧?所以多个下游服务正在退化,然后这是证据,如果我想深入了解。在这种情况下,有 391 个红色连接错误日志发生。你知道,我继续提供你期望的粒度,而你通常需要自己去寻找。如果我继续深入,而这只是在警报触发后的几分钟内提供的调查。>> 它实际上还按时间顺序排列了时间线。继续。而有趣的是,你刚才展示的这种输出,通常是在两个星期后,在一次完整的绩效审查之后才会看到,就像,这是两个星期前发生的事情。我们花了很多时间才弄清楚这一切,而你说,这个可以非常快速地提取这些东西。>> 是的,它非常,我的意思是,你说得对。这是非常快速的,我的意思是,在几分钟内。所以通常在大多数情况下,我们看到从分类到完成调查并提供证据大约需要五分钟,对吧?你说得对。通常情况下,这取决于警报或事件的严重程度,如果它是一个,你知道的,你知道的,它是一个停机事件,显然是全力以赴,但其他像 SE1 步骤2 这样的,你可能不会那么优先考虑,这可能需要更长的时间,但这绝对是,我们如何才能做到这一点?我们如何让工程师更快地开始修复,而不是仅仅试图弄清楚出了什么问题?所以,企业护栏或人工干预集成看起来是什么样的?我必须接受一些改变吗?我可以设置护栏,哪些改变需要我接受,哪些可以自动修复吗?>> 是的,这是一个很好的问题。所以,今天我们还没有进入修复业务,对吧?所以,这一切都是关于我们如何实际减少或消除弄清楚出了什么问题的辛劳。现在你能想象在几个月后,我们会在那些护栏或预定义的活动类型范围内,Resolve 可以采取行动,这是可行的吗?很有可能,对吧?所以一个例子可能是,显然回滚非常安全,对吧?尤其是在你进行了新的发布时,就像,嘿,这个问题是由发布引起的,你有很高的信心水平,你有所有证据支持,那么就自动回滚到之前的版本,这可能是一个预定义的护栏内的。而且我们听到客户实际上正在变得,我认为,如果你回顾一下,即使是六个月到一年,可能还有一点犹豫让 AI 代替人类采取行动。而我们现在正处于一个点,我们的客户正在问我们,抱歉,不是那个 Slack 通知在响。嗯,客户实际上正在问我们,就像,嘿,你能为我们采取行动,在这些预定义的护栏内吗?所以,然后你的第二个问题是关于人工干预,在任何时候,无论是在最初的 Slack 体验中还是在这里,我作为工程师或任何正在调查此事的人都可以随时接管并开始深入研究。所以在这里,我将开始询问,只是为了了解是否有其他依赖关系,作为一个例子。嗯,你知道的,显示了升高的错误率或资源饱和度的依赖关系。抱歉拼写错误,正在快速完成。嗯,结账延迟飙升。对吧?所以,它会开始转动。嗯,希望这会很快。就像我说的,它正在进行,你知道的,一切都在后台运行。但是,嗯,所以,好吧,它实际上做得很快。嗯,所以你回到这里,你看到,嘿,在前端结账延迟期间,确实有下游依赖项受到了影响,这就是所有这些额外魔法开始发挥作用的地方,我实际上可以问,就像,嘿,修复计划是什么?嗯,是什么,是什么修复?嗯,写一个 PR,创建一个事后总结,对吧?所有这些通常是工程师的负担,他们需要去做的事情,就像,我们如何从他们的盘子里移除这些辛劳?所以他们更多地专注于构建,而不是被这种救火模式分心。>> 所以我有两个问题给你。你知道,这是我们直播的,有成千上万的开发者在收听,我想从观众那里问一些问题,如果可以的话。曼尼尔,人们非常兴奋。>> 和>> 是的,尽管来吧。>> 我想,我想先问一个问题。嗯,是关于根本原因分析的。所以,有一个 GVO Cipher 说,所以,根本原因分析在哪里,如何发挥作用,以及 Resolve AI 使用它的顺序是什么?>> 是的,所以,就像,显然根本原因,如果你想到它,即使是今天的人类,也是一件极其困难的事情,因为你,你知道的,最可能的默认是去找出,就像,嘿,这些是我已知的症状,所以这是我的部落知识,我知道它很可能在这里,但这可能不是事情的真正原因,因为可能有一些下游依赖项导致了理论。所以,我认为这个领域的所有人,包括 Resolve AI,我们都在逐步努力改进根本原因分析,并达到最高的置信度水平,但所有这些的目标实际上是达到根本原因,对吧?所以有很高的信心,所有这些东西。在这种情况下,我们将其定性为工作理论,但如果你进一步深入,嗯,在这里,就像它实际上是最可能的原因。我们实际上,你知道的,在不说是根本原因的情况下说,嘿,这是你的根本原因,非常可能是其中一个事件,这个事件,或者你导致这个问题的多个下游服务性能退化。所以,但你可以想象,它非常接近于达到根本原因。>> 我们还有最后一个问题,来自同一个人,关于这显然引起了共鸣,我们已经收到了关于这需要多少钱的问题。>> 嗯,是的,联系我们是最好的方式。嗯,现在,你知道的,我认为,你知道的,它不是公开定价的,但我就说,最好的方式就是联系我们,你知道的,我们可以看看这对你的特定环境意味着什么,以及其他一切。所以,我想总结一下。我知道你们的时间快到了,但你看,它已经完成了,带着一个修复方案回来了。我甚至可以问接下来是否有代码问题或与代码相关的修复。它会为我生成代码,如果我愿意的话,可以去一个编码代理,然后像在那里做所有魔法一样。嗯,我知道有人提到了 Vibe,Dako 提到了 Vibe 编码。这方面的另一个方面是,这都是关于实时生产事件,就像火灾正在燃烧,但你如何主动出击?我们称之为 Vibe 调试,就像工程师进来,就像,嘿,你知道吗,客户说可能有性能问题,你能告诉我发生了什么吗?仅仅是这样的简单提示,使用自然语言来理解你的生产系统中正在发生什么,这也是 Resolve AI 的另一个方面。>> 是的,我本来想说 Vibe Ops。怎么样?>> 是的,Vibe Ops。我不知道。我们会看看我们能实现哪个。但如果这不是一个术语,那我们就接受了。>> 或者混乱的 Vibe。怎么样?>> 是的,我不知道。我们让观众来决定吧。我只能这么说。>> 好的,伙计,V,这真的很棒。我真希望我们有更多的时间,但非常感谢你的演示。它真的很有趣。很高兴看到 GenAI 和所有代理,我们只是看到了新的,就像,你受到想象力的限制。所以就像,哦,做一些研究,然后一切。但现在我们看到,就像任何看到你演示的人都能以某种方式与之相关。无论是,你知道的,就像试图弄清楚发生了什么,根本原因分析,但我就能看到,虽然这可能不是真正的根本原因分析,但它是一个很好的起点,当你三更半夜不知道该做什么的时候,你没有任何起点。这些看起来确实是很有希望的起点。>> 100%。对。就像你不再身处一个空荡荡的迷宫里,对吧?或者你知道,大海捞针。就像你有了方向,然后根本原因,你就会看到,嗯,改进会越来越好,准确率也会越来越高,而且我们绝对是这方面的领导者。所以,是的,但谢谢你们的时间。