亚马逊云科技：生成式AI在DevOps中的应用

作者：沧海一生笑2024发布时间：2024-08-22

关键字: [出海日城市巡展, DevOps Guru, 生成式Ai, Devops应用, 运维操作, 自动化工具, 智能运维]

本文字数: 2200, 阅读完需: 11 分钟

导读

在这场演讲中,郑辉解决方案架构师介绍了生成式AI在DevOps中的应用。他阐述了DevOps的概念和运维工作的流程,以及传统运维、DevOps和智能化运维的区别。他重点介绍了Amazon DevOps Guru服务如何通过大模型和知识库实现自动化运维操作,包括事件监控、异常检测、根因分析和修复建议等,从而大幅降低运维工作量。他还分享了DevOps Guru在Serverless和RDS等场景的应用案例,展示了其提高运维效率、简化运维流程的优势。

演讲精华

以下是小编为您整理的本次演讲的精华，共1900字，阅读时间大约是10分钟。

各位下午好,我叫郑辉,是亚马逊的解决方案架构师,负责服务杭州地区的客户。今天我将分享的主题是”生成式AI在DevOps中的应用”。之前,海忠老师已经分享了如何在业务中嵌入深层次AI,而我将重点讲解如何在运维领域应用深层次AI,以简化运维操作。

在开始之前,我们先来定义什么是运维和DevOps。根据百度百科,运维本质上是对网络服务器整个生命周期的运营和维护。我个人对运维有一些独特见解,源于一个小故事。故事讲述魏文王问扁鹊,为什么他三兄弟都学医,但扁鹊的名声最大。扁鹊回答说,他的大哥能在病人没有发病时就做身体调理,所以名声最小但医术最好;二哥能在病人有小毛病时下药调理;而他自己是在病人有大病时下重药,虽然名声最大,但医术没有两位哥哥那么好。

在运维领域,情况也很相似。一个好的运维应该是默默无闻的,因为他能提前做好基础设施的维护和运营,确保服务的稳定运行,业务无需担心底层架构问题。那么什么是DevOps呢?DevOps本质上是一套实践的工具、文化和理念,其核心概念是自动化和集成,可以自动完成团队沟通和运维操作。

接下来,我们看一下运维工程师的日常工作流程。第一步是明确需要做什么;第二步是确定如何做;第三步是确定由谁来完成任务;最后是定义任务完成的标准。在传统运维模式下,所有这些步骤都由运维工程师亲自完成,工作量非常庞大。虽然早期系统较为简单,但随着业务发展,单纯依赖人力就无法支撑了,因此引入了DevOps概念。

DevOps的改进在于,将”谁去做”这一步由自动化工具完成,而”做什么”、“如何做”和”定义成功标准”仍由运维工程师定义。在最新的智能运维模式下,所有步骤都由大模型AI来定义,实现真正的自动化运维。

常见的运维场景包括:机器出现问题、需要增加服务器、开服时配置环境变量等。传统运维方式下,像增加3台服务器这样的需求,运维工程师需要登录控制台手动创建,然后检查配置,可能需要一个下午的工作时间。到了DevOps阶段,我们可以使用模板化工具如Amazon CloudFormation快速创建环境,只需1-2小时。而在智能运维模式下,运维人员只需与AI机器人交互,说明需求,AI就会理解意图,自动从知识库获取必要参数(如VPC ID、子网ID等),调用Lambda函数或API,执行模板化自动化工作流,在很短时间内完成任务。

那么大模型AI是如何帮助实现这一流程的呢?这里涉及到一个关键概念”Agent”。大语言模型擅长语义理解,可以理解前端需求,但无法直接执行操作,需要将语义转化为API参数。Agent就是将大模型的语义理解与实际操作相结合的桥梁,它将大模型的输出转化为可执行的API调用。为了让大模型准确理解意图,我们需要为它提供知识库、API文档、服务介绍等前置知识。以增加服务器为例,我们需要告知大模型,美服对应Amazon Web Services us-west-2区域,VPC ID是什么,子网ID是什么,通常使用的实例类型、镜像等参数是什么,大模型才能正确地调用API创建资源。

在DevOps中应用生成式AI,分为主动式和被动式两种场景。主动式场景是,运维人员主动与AI交互,提出需求,比如”在us-west-2区域增加3台服务器”。大模型会检索知识库,识别出需要调用哪个API,从知识库获取必要参数,然后调用Lambda函数或API Gateway执行自动化工作流,快速创建所需资源。整个过程都会记录在S3或数据库中,以备审计。

被动式场景则是通过监控日志、安全事件等触发AI。例如,监控到DDoS攻击事件,会触发Lambda函数,Lambda通过API调用大模型,输入攻击日志等信息,大模型分析后会输出修改WAF规则的API参数,Agent执行相应API调用,自动修改WAF防护规则,完成防御。所有操作日志都会记录在CloudWatch中。

以上是生成式AI在DevOps中的两种主要应用场景。看起来实现这一流程需要涉及Lambda、API Gateway、Terraform模板等多种亚马逊云科技服务,构建整套系统的工作量很大。幸运的是,亚马逊云科技已经推出了DevOps Guru服务,可以让我们快速体验智能化运维。

DevOps Guru之所以能发挥作用,是因为在大规模业务中,我们会产生大量日志、性能指标和应用迭代记录,单凭人力难以高效分析。此外,还会出现过多无效警告、可快速解决但反复出现的问题等困扰。DevOps Guru可以自动分析这些数据,给出见解和建议,减轻运维工作负担。

我举两个例子:第一,在Serverless架构中,如果Lambda函数的延时变高,传统运维需要人工审查代码、查找性能瓶颈,是一个很耗时的过程。使用DevOps Guru,它可以快速分析,发现是DynamoDB吞吐量达到上限导致的,并给出增加吞吐量的建议。第二,如果RDS CPU利用率100%,运维人员需要查看锁情况、内存磁盘IO是否满载、分析慢查询语句等,工作量很大。而DevOps Guru会自动检测异常、分析上下文,如果是内存不足,就会建议升级RDS实例类型或释放内存。

总的来说,DevOps Guru可以自动创建监控、性能指标和基线,自动调整告警阈值,并在出现问题时自动联系上下文、给出见解和解决方案建议,极大降低了运维的日常工作量。有了DevOps Guru这样的服务,我们不再需要手动构建监控仪表板、分析指标,也不用担心指标丢失或容错过程,可以将精力集中在游戏业务的开发上,提高运维效率。

传统运维模式下,运维工程师需要做许多手动操作,就像扁鹊在病人有大病时下重药一样,工作量很大。引入DevOps后,我们使用自动化工具,工作量有所减轻,相当于扁鹊的二哥,可以快速调理小毛病。而在智能运维时代,生成式AI就像扁鹊的大哥,能够在问题出现前就做好预防,确保系统稳定运行,使运维工程师可以充分专注于业务创新。

总之,生成式AI在DevOps中的应用,可以极大简化运维流程,实现自动化智能运维,降低运维工作量,提高运维效率,让运维人员充分释放潜能,专注于业务创新,为企业创造更大价值。这正是我们期望的运维工作方式,也是亚马逊云科技一直努力的方向。

根据视频字幕,我将进一步丰富细节:传统运维模式下,如果需要增加3台服务器,运维工程师需要登录控制台手动创建,然后一个个检查配置,可能需要花费一个下午的工作时间。到了DevOps阶段,我们可以使用Amazon CloudFormation等模板化工具,在1-2小时内就能快速创建所需环境。

而在智能运维模式下,运维人员只需与AI对话,说”在us-west-2区域增加3台服务器”。大模型会自动检索知识库,找到us-west-2对应的VPC ID是vpc-0f08949abcdef123,子网ID是subnet-0a9102ef3456789a,通常使用的实例类型是m5.large,镜像是ami-0123456789abcdef。获取这些参数后,大模型会调用相应的API或执行CloudFormation模板,在很短时间内完成创建3台服务器的任务。

另一个场景是,如果监控到DDoS攻击事件,会触发Lambda,Lambda调用大模型分析攻击日志。假设日志显示攻击流量达到了100Gbps,大模型会输出修改WAF规则的API参数,比如调整WAF规则wafv2-rule-0f08949abcdef123的速率限制阈值为120Gbps,Agent接收到这些参数后,就会自动调用修改WAF规则的API,完成防御。

在Serverless架构中,如果发现Lambda延时从平均100ms升高到300ms,DevOps Guru能够快速分析,发现是因为DynamoDB的读写吞吐量从2000单位提高到6000单位达到了配额上限,因此建议将DynamoDB表ddb-0f08949abcdef123的读写吞吐量从2000单位提高到8000单位。

如果RDS CPU利用率100%,DevOps Guru会自动检测,发现是因为锁等待时间较高,有20%的查询语句等待时间超过1秒;内存使用率95%,磁盘IO使用率90%。分析常见的慢查询语句后,DevOps Guru会建议将RDS实例db-0f08949abcdef123的规格从db.m5.xlarge升级到db.m5.2xlarge,内存从16GB升级到32GB,以解决CPU过载问题。

通过以上具体案例,我们可以看到,生成式AI大大简化了运维流程,降低了运维工作量。有了DevOps Guru这样的智能化运维服务,我们不再需要手动构建监控和分析体系,也不用担心指标丢失或容错过程,可以将有限的人力资源集中在业务创新上,充分释放运维人员的潜能,为企业创造更大价值。