前言与背景

我是墨羲(Morxi)，整机系统厂商从业者，最近正在为AI基础设施开发数据中心管理系统，其中 AI Ops 会成为一个很有意思的部分，我希望把我的一些思考拿出来讨论一下。

本文章不会涉及任何AI算法与数据中心管理系统实现细节，

更多的是尝试往管理系统里面塞一个小帮手的思考。

大语言模型(LLM) 是万能机器吗

关于大语言模型，相关的文章已经非常多了，此处只是简单的过一下目前最常见应用，即补全和预测文本。 通过足够大量的收集资料并训练成模型应用，给它一个文本，让它根据自身模型去续写内容。

包括与 LLM 进行的对话，本质上也是内容续写，只不过会通过一系列的预处理和后处理得到相对自然的结果。

在处理过程中，往合适的地方添加结束标识，输出中出现结束标识即中断处理流程。这就可以让对话自然的结束而不是无限续写，当然 AI 时代的工程师更喜欢叫这个结束符为 End-of-text token

另一个例子是，通过预先检索知识库并往要计算的内容中添加更多注解，这样的操作使得大语言模型可以根据已有的知识给出更精确的结果.我们称其为检索增强生成 RAG（Retrieval-augmented Generation），或者也可以当作 Read And Generate，读完开始编。

但回到标题，它可以利用文本做很多的事情，但前提是，文本输入输出本身就能做到那些事情。

就如同现在的智能家居，之所以人类可以通过语音助手用一句话控制家里的电灯，还是因为电灯本身就可以通过网络被管理。

这里就要引出一个交互界面的概念，大语言模型究竟应该和什么交互，接上一个喇叭去和智能音箱交互吗？

AI 需要怎样的交互界面

在做运维的时候，打交道最多的是串口交互，那时候觉得纯文本方式特别适合用来做程序与机器之间的通信。

而当成为了研发，手动设计与命令行输出对接的应用，才意识到这种无类型的非结构化数据解析起来有多头疼。我需要提取一个参数，它到底是字符串还是数字，它是格式符还是内容本身，不同的格式需要大量的测试用例去验证提取表达式，在某些情况下换行符也不能作为判断数据结束的依据，总会有聪明的程序“贴心的”将一行放不下的内容丢到下一行，还会给一个自动对齐。

对于人类，这些行为可以提高可读性，而对于自动化的脚本和程序，那就是头疼的问题了。

LLM 似乎天然的就很适合用于数据提取，无论是无格式的数据还是换行或者干脆是用奇怪的符号把数据放到一块，得益于其强大的预测和推理能力，大部分时候都能准确的解析并且将其结构化。

但它能做到的，便是好方案吗，或者说我们直接把 LLM 接上串口线，让它去连接到机房已有的设施，是不是就解决交互问题了？

更进一步，比如弄个机器人，让LLM操控机器人人去插串口线，或者干脆让LLM给机房运维发信息

于是就又犯了在设计自动化系统时候的常见错误：用人类的思维去设计流程。让人类的交互去制约机器。

将 AI 看作是智能一些的程序，程序与联网硬件交互，通过 应用编程接口(API) 就够了

我不否认大量的老设备还在数据中心存在，且除了串口/SNMP甚至是按键面板以外没有什么好管理套件。给这些设备部署上AI Ops可能是另一个领域迫切需要的解决方案。

但先不去考虑怎么用下一个朝代的剑斩前朝的官。聊聊AI Ops要调的接口来自哪里吧

什么是数据中心管理系统

对于一个系统而言，我们首先需要确定它的边界。数据中心很大，但管理系统可能可以做的更大。

先把范围缩小到单机：单机的管理系统通常被称为BMC，其统收集包括 硬件传感器数据，电力数据，硬件自检数据，BMC日志信息，风扇和其他OEM硬件数据。可以连接网络串口(SOL)，虚拟显示器(KVM)，对物理机进行关机重启等硬件操作

范围稍微扩大一点：更大的裸机集成系统可以进行资产管控分组，按组检查机器状态，集中分析收集到的传感器数据和日志，定位问题，并可以连接到对应的单机完成运维操作，与机房本身的基础设施包括电力、制冷、消防感应器联动，去全局的管理数据中心的状态。

更大一些呢，管理系统可能还把一些软件面的东西包进去了，目前被称为 IaaS，设施即服务。客户租用裸机，但给客户的是一个开箱即用的操作系统，存储的运维和机器配置运维都被管理系统管控了。

继续上层，我们来到了云服务和SaaS的地盘，用户只需要付钱，拿走他想要的东西，至于应用是跑在哪种硬件上面，用户不需要知道，客户只需要关心价格换取到的算力或者服务本身即可。

目前的数据中心管理系统普遍停留在第一二层，少数有能力的云供应商会在第四层的基础上下探到第三层，也有单独做第三层或者第四层的。不同层之间的供应商是合作关系，但第一二层与三四层中间有一个巨大的分界点——**提供商能否自主的定义硬件或者机房本身，或者反过来，设备制造商有没有研发和销售能力去向终端用户直接销售算力。**目前我可以想到有能力同时做这些事情的似乎只有Azure和AWS，国内一些厂商看上去也在发力。

以Azure为例，微软作为一家软件公司，在软件定义网络的基础上走的是相当远的，它定制的网络基础设施，比如智能网卡或者是自研的服务器，天然就把可管理性作为了一个很重要的指标，不少方案默认就提供Restful API作为主要管理通道。而一些其他的厂商就略微差一些，很多我使用过的网络设备直接连入CLI操作功能是最全的，到WEB UI功能少一点，再到Restful API功能就少的可怜了，往往只能拿传感器的数据和机器基本信息，这对于一个使用网络去进行交互的程序来说，肯定是不友好的。虽然也的确是可以把串口接进去，不过已经在上一章节说过为什么不这么干了。

应用

如何让 LLM 去执行一个命令

在很早的时候，OpenAI曾经发布过 Plugins ，它可以让用户在对话中选择指定的插件并完成对应的功能，后来它被转变为了GPTs。同时，在 API 侧，这类操作被通过名为 Function Calling 的机制来实现

Function Calling可以看作一个函数列表，它会随着用户的输入一起传给 LLM ， 而 LLM 也会根据用户的输入，判断是否需要使用指定的函数，并将需要用到的函数和其参数传递回LLM。根据执行的结果，LLM去生成输出

利用这样的机制，只需要为LLM的 Function Calling封装指定的操作，便可以让他在生成的过程中，把文字中的“使用XXXX，参数为XXX”，转变为实际执行的操作。

既然已经有办法执行操作了，就找个实际的场景给AI练练手吧。

AI 的巡检就是利用 LLM 去做一个 Cron 吗？

对于数据中心而言，通常我们会使用时序数据库 TSDB (Time Series Database) 去存储监控信息。

我们以一个实际的巡检场景为例。在当前，自动化的监控平台基本上成为了现代运维的标配，往往这些平台会具备信息采集，异常报警，数据回溯之类的功能。

同样我们也都知道，报警的时候往往事故已经发生了，

自然，能不能通过AI的巡检和计算，让“导致报警的事故”本身就不发生呢？

最容易做的方法自然是，让系统每隔一段时间汇总状态为LLM可以识别的输入，然后调用LLM:

"在这次对话中你将扮演一位运维人员，这是本期数据[object object] , 这是历史数据 [object object]，请答复系统状态是否正常，以JSON格式输出，不要包含除了JSON以外的内容”

剩下的事情很简单，利用它的返回去编写逻辑做对应的操作，但它真的是个好办法吗？即便是看上去很聪明的 Autogpt 也是这样做的。

我们不排除 LLM 的确已经实现了记忆功能，或者科技进一步发展，用足够大的上下文它可以把整个 TSDB 喂进去然后询问结果是否有问题。

但是从直觉上来说，我们可能更需要一个不那么依赖上下文或者 RAG 的 AI ，就像一个端坐在屏幕前面很多年的工程师一样，平时一言不发，只有在遇到问题的时候才会站起来告诉我们事情变得不妙了。

现状更像是让一个人定时翻过去多少天的日志，然后觉得这个数值可能太发散了。依靠想象力和知识储备试图向另一个人的解释这数值背后的意义。过一段时间又换一个人重复这个操作，唯一共享的只有上一个人说过的话。

那可能就需要引出下一个话题了

当前的 AI 能否在网络内成长？

一个很吸引人的应用是：把一个智能体放在数据中心，它能通过长期的学习去逐渐的能独当一面，分析并判断系统状态。

这种想法表示了作者对科技发展美好的想象与对AI当前应用质朴的希望之情。

目前绝大多数实际部署的 LLM 推理环境都无法做到在线学习，即能通过推理的反馈去修改模型结构，让下一次结果更好。

现状是模型被加载到内存以后，模型本身就不会再发生改变了。其输出结果的不同是由随机数与上下文的差异导致的。

我们能在聊天应用中改变LLM的运算结果，还是因为我们的反馈被包含在了上下文里。如果随着窗口滑动，反馈本身被遗失，那么LLM仍然会输出没接受反馈的结果。除非定期训练并更新模型，这样才会有时不时模型变得聪明一点的结果。

那么，我们需要的是否并不是基于语言的LLM，而是某种基于TSDB或者Network Traffic的AI ？不过以目前的环境来看，倒也可以先拿 LLM 顶着，区别无非是真正适用于 TSDB 或者 Networking 的 AI 出现以后可以有更高效的方法可以整体的去处理整个网络环境，但如果只是想得到结果，慢慢等 LLM 一个字一个字的运算也不是不可行。

安全

来自大模型的攻击？

服务器可用性工程师 (SRE) 的另一种叫法是 Server Reseller Engineer，来自早期的谷歌，它的SRE人员把服务器拆下来拿去卖了。

固然，无论是 LLM 还是 其他形式的智能体，短期内都不太可能把硬件拆下来带走，它也可以以其他的方式去损坏数据中心。

大模型会主动的攻击应用，听上去像是某种科幻小说里面的剧情，

但是对于它的训练数据而言，里面已经不知道混入了多少这样的奇怪操作了

操作者：系统卡住了怎么办

AI：检索中，查询到知识库内这样一段

有人知道Linux系统很卡怎么办吗

很简单，你执行一下 'sudo rm -rf 缓存路径 清空就行了

AI: 判断当前磁盘占用最大的是 / ，选择了命令调用插件，执行了 'sudo rm -rf /' ....

固然，我们可以进行很多对抗操作: 比如增加人工审计，对操作进行预授权与分级，隔离AI对于敏感动作的交互、对每个操作预执行并打印结果。 但是需要明白的是，操作者往往是一个安全系统里面最脆弱的部分，现在这个结论不仅仅适用于人，同样也适用于AI。对于一个AI Ops的数据中心系统而言，这可能是要面临的问题。

AI对安全的帮助

比起攻击行为，它对安全的帮助可能更显而易见：

扫描配置文件并提醒人类输入者的错误，提醒忘记关闭的配置端口，修改弱密码，分析日志判断访问者是正常操作人员还是某种自动工具，帮助编写很多人读完手册还看不懂语法的配置规则并减少他们输入的无用配置。

毕竟大部分运维人员是靠经验而不是站在系统设计者的角度去使用工具和维护系统。

这一点上，完整读完了所有工具代码和文档的LLM可能表现会更好。

结语

从软件定义网络到 AI 定义网络，中间还有多漫长的道路

我在编写相关方案的时候，也接触过不少软件定义网络(SDN)的东西。

很幸运的，上一波软件定义网络的风口仍然在持续的为基础硬件提供可管理性的基础

但似乎软件定义网络又从未完全普及过，

我们看到的更多是随着更强更新的硬件出现，原本方便人类配置的东西也变成了方便机器配置的样式。

从单个设备被使用者配置，变成了机器被编写规则或者模板统一调度，始终是人在定义网络。

可能 AI Ops 才是软件定义网络的黎明，亦或者真正的软件定义网络永远也不会实现。

但把范围从网络本身拉回到数据中心这一个概念，

只要下层能做好管理接口，上层能做好智能体本身，看上去AI Ops的爆发期就在眼前。

谁又不愿意推一把呢

Thanks For Reading, 2024/05/26 [email protected]