使用Open Interpreter实现亚马逊云科技云的自然语言运维

<!--StartFragment--> 云的本质是网络API，但是面对成千上万的API和参数，人类其实并不是特别在行。为了实现良好的人与云的人机界面，我们已经探索了多种的可能。\ 最常见的是Web Console，极客们自然也喜欢awscli这种方式，大规模场景下往往会引入CloudFormation, Terraform等传统IaC方案，对于程序员们，CDK同样吸引了他们的注意，还有五花八门的各类云管系统，运维产品的集成，总之现在同样的云运维操作，我们总是会先纠结使用哪种方式最为合理。但无论是哪种方式，似乎都并不完美，都需要人适应机器的思维方式，存在一定的技术要求和难度。近两年AGI领域的迅猛发展，越来越多的人使用AI作为提高云开发和运维的手段，笔者在日常工作中也尝试使用AGI工具来执行一些云运维任务，这其中一个比较亮眼的工具就是[Open Interpreter](https://www.openinterpreter.com/ "https://www.openinterpreter.com/") Open Interpreter是一个开源的帮助大语言模型执行代码的工具，支持各种本地和托管的大语言模型。只要是可以利用程序脚本执行的操作，都可以借助Open Interpreter来进行，这当然也包括与云的交互。具体的[安装配置](https://docs.openinterpreter.com/getting-started/setup "https://docs.openinterpreter.com/getting-started/setup")非常简单，这里就不再展开，直接看一些实例，由于对话通常非常长，这里只展示一些关键的部分： 在开始之前，为了简化，我们已经配置好了基本的aws configuration和AWS环境变量，以便Open Interpreter在默认情况下能够获取到执行操作的权限，当然，在执行过程中让Open Interpreter进行登录操作也是可以的。 首先，选择让Open Interpreter使用ollama加载的Mistral本地模型，也可以选择其他本地开源模型或线上商业模型。启动之后即进入交互模式。\ 先尝试获取一下当前的用户信息，并创建一个IAM Role，这样可以作为最佳实践让Open Interpreter使用一个权限受控的Role来执行操作，避免一些高危权限的风险：\  第一个操作就遇到了困难，执行失败了，但是没关系，Open Interpreter会自动发现错误并修正代码的执行。可以注意到在未设置-y参数是，每步执行Open Interpreter都需要用户的确认，这样可以避免意外执行一些不希望的操作的情况：\  很好，仅经过了一次自动修正，Open Interpreter即完成了任务，正确创建了需要IAM Role：\  接下来，再尝试一些基础的云运维操作，比如VPC的配置，这次我们明确让Open Interpreter来使用CloudFormation而不是awscli来执行：\  Open Interpreter成功完成了CloudFormation的创建，对于执行过程，Open Interpreter进行了详细的分步处理，俨然一个有经验的云运维工程师：\  准备充分，一次部署成功：\  确认部署完成后，Open Interpreter还贴心的整理好了部署资源的id清单：\  紧接着是一个比较复杂的任务，为刚才新建的VPC配置VPC FlowLog并配置相应的Athena Table，这个执行过程中遇到了CloudFormation执行权限问题，Open Interpreter轻松自己解决了：\  这次CloudFormation的执行遇到了问题：\  Open Interpreter开始自动查看CloudFormation部署事件并尝试解决问题：\  经过一轮排障，Open Interpreter顺利修改好了CloudFormation模板并更新成功：\  VPC FlowLog的Athena Table创建遇到了一些语法问题，Open Interpreter顺利修正了：\   最后请Open Interpreter基于刚才创建的资源，进行一些简单的查询：\  将查询结果保存到本地：\  除了一些常规的运维任务，Open Interpreter+LLM擅长的，可能是下面这种数据收集处理任务。Open Interpreter同样是先设计出一个执行计划，再动手，俨然一副老司机的样子：\   执行过程中依然会遇到问题，但是还没等我看清楚报错，Open Interpreter已经自己解决了：\  最终结果，可以用于相关资源的成本优化，清理和配置等工作：\   ## 总结 ### 应用场景： AGI技术的应用，为云的自动化运维提供了新的途径选择。用户可以使用更轻松高效的方式完成一些日常和复杂的任务。总体上，Open Interpreter配合大语言模型执行云运维的效果达到了预期，其能力接近中等水平的云运维工程师。在很多场景下，可以达到生产应用的要求。在前面这些实测中，笔者完全没有修改一行代码，Open Interpreter+大语言模型完全依靠自己的能力完成了任务。 更为重要的是，除了交互模式，Open Interpreter还提供了API，可以和用户的其他系统进行集成，将自动执行融入到现有的流程中。这样，Open Interpreter+大语言模型将完全有可能替代初级的IT运维人员对接用户，按照一定的流程规范直接完成简单的云运维任务。 ### 缺点与优化 虽然Interpreter顺利完成了任务，但在实践中也发现当前大语言模型执行自动化任务时存在两个明显的弱点： 1. 对于SDK, API等版本变化，经常不能很好的处理，比如使用了过时的接口参数，或者代码中使用了不兼容的组件版本，这种情况往往需要人类协助排障。 2. 少数情况下，大模型仍会出现“幻觉”制造出并不存在的变量、配置项或接口，也许其与人类一样，可能把不同的库弄混了，或者记错了吧。 当然，如果配合知识库，模型微调，DevOps等工程化实践，可以进一步提升自然语言自动化运维的效果和能力边界。 ## 思考 有人可能会问，现在已经很多人利用大语言模型来编写自动化代码，比如[Amazon Q](https://aws.amazon.com/cn/q/?trk=cndc-detail)，Interpreter模式仅仅是把这个过程加入了自动执行罢了。但是笔者认为，Interpreter模式与先让大模型辅助写好自动化代码，再由人工去执行还是有很大区别的。在云运维场景下，Interpreter模式更重要的是打通了大语言模型与云平台的交互控制和数据交换渠道，人不再需要在机器和机器间做信息的搬运工，而是更专注于创造性的思考任务的规划和目标，这让三方都能专注于自己擅长的领域。另外，Interpreter模式执行和排障效率都明显更高，工作流更灵活和流畅，对于一些探索性的任务，则更为合适。 大语言模型+Interpreter的应用，改变了传统云运维自动化的模式，自动化开发和数据驱动运维不再由于高昂的成本和技术复杂度成为需要决策权衡的事情。 传统IaC的声明式编程，不可变基础设施的思想，由于大语言模型的引入将发生一些微妙的变化，流水线式的云运维模式将有可能逐渐转变为高度可定制的架构，ITSM等围绕传统运维模式的工具产品也可能被新的模式取代。 在探索”云的自然语言运维“模式过程中，也有一些最佳实践可以进行探讨： - 由于是操作实际的环境，对大语言模型的安全性提出了更高的要求，云运维领域应使用私有部署可信的模型，并管控好运维数据的安全 - 建议从只读和简单的任务开始实践 - 通过设计完善的IAM和日志体系，限制和跟踪Open Interpreter等途径的运维操作权限范围，避免意外的高危操作。 - 在应用大语言模型用于云运维前，在测试环境进行足够的测试评估，对其能力范围有比较清晰的认知，类似雇佣人类运维工程师前的面试 - 向大语言模型+Interpreter发送提示的人员，应该比传统运维工程师有更高的技术要求，因为只有对云的技术足够熟悉，才能更准确的构建提示词并准确评估大语言模型给出的执行计划和代码是否符合预期，以及是否存在问题。 - 交给大语言模型+Interpreter执行的任务应具备一定规范，并不是所有类型的任务都适合，哪些可以做哪些不能做需要清晰定义，并遵循一定的执行流程， - 大语言模型+Interpreter的运维任务执行过程应记录详细的日志，确保可以对问题进行追溯 - 运维团队应建立提示词知识库，将测试和实战中积累的有效提示词积累下来，不断完善共享形成标准化指令，给到大模型的提示词越详细准确全面标准，效果自然越好。 - 和所有运维任务一样，使用大语言模型+Interpreter执行云运维任务比传统方式存在更多的不确定性，需要准备一定的修复和回退计划 <!--EndFragment-->