Seal梁胜：近水楼台先得月，IT人员应充分利用AI解决问题

2023年9月2日，由平台工程技术社区与数澈软件Seal联合举办的⌈AIGC时代下的平台工程⌋——2023平台工程技术大会在北京圆满收官。吸引了近300名平台工程爱好者现场参会，超过3000名观众在线上直播平台观看了本届大会。

数澈软件 Seal 联合创始人梁胜博士和江鹏受邀出席此次大会并发表题为《AI时代的IT技术创新》的演讲，本文为演讲实录。

AI 正以不可逆转之势发展

这周二我去旧金山参加了谷歌一年一度的云计算大会（Google Cloud Next 23），这大约是我第8次参加这个活动，但今年与往届完全不同。在今年的大会上很少谈及云计算的底层基础技术，也没有介绍 Kubernetes 的进展，在近2个小时的主题演讲中几乎 100% 的时间都在谈论 AI 技术。从这里，我们可以看出 AI 技术给整个 IT 行业以及云计算带来了巨大的影响。

为什么会有这么大的影响呢？从我个人过去十几年从事云计算领域的体验来看，云计算根本上解决的是资源的问题。在没有云计算之前，如果需要资源，那么要购买机器、搭建机房，但云计算出现之后，就不需要干这样的事情了。取而代之的是，出现了 DevOps、Infrastructure as Code（IaC），这些新技术的出现大大增加了企业对人力资源的需求。在这样的情况下，未来的 IT 行业可能会面临的挑战不再是优化机器资源，而是优化人力资源，包括 IT 的人力资源或 IT 以外的人力资源。因此，AI 成为了一个恰如其分的主题。

现在技术领域的人力资源主要集中在两个方向：研发和运维。人员需求的方向定义了现代软件开发到部署、到运维、到升级的整个生命周期流程。我在上图的右侧列出了两个云厂商，但即便不部署在云上，部署在本地机器或者边缘设备上，整套软件开发流程并没有太大变化。

在过去十年中，甚至全球经济不景气的当下，对 IT 人员的需求量依旧非常大。这样的增长会不会继续呢？现在 AI 技术的出现对这个增长会有什么影响呢？

我们先从研发的角度来看这个问题。各位现在最为感同身受的可能是国内外的企业都在进行裁员，为什么会如此？

大家仔细想想过去的业界发展态势，比如移动互联网，大家每天都在手机端上使用各种 App，那么仔细回忆一下上次用到的新应用是什么时候？对我来讲，是有相当长的一段时间以前了。但是如果把时间拨回5年前、10年前，那可能每过几天、几个星期可能就会下载一个新的应用，当时新的东西源源不断地出现。但现在大家可能主要使用的只是各自领域里的主流App，比如抖音、微信、B站以及各种网银之类的。

尽管现在开发应用比以前容易得多，但长尾效应在慢慢减弱。

那么真正的研发现在去哪里了呢？从广义来说，现阶段的研发是那些在各种大平台不断生产内容的网红，他们可以吸引很多用户。那将来的研发又会往哪个方向走呢？从现在生成式 AI 的角度来看，研发的方向会越来越多。无论是 AI 会帮助研发，还是会直接被 AI 替代，AI 的发展是不可避免的。

接下来，我来讲讲软件 2.0，这个概念是由一个从事人工智能开发的程序员提出来的，是指世界上越来越多的事情是由软件来实现的。

现阶段，大家可以用 AI 助手来帮助生成一段代码，然后检查一下代码是否存在错误，如果没有问题就可以用了。我们大胆猜想：那么之后是不是可以用一个神经网或者一个 AI 模块来实现？可能你直接告诉 AI 你要做什么，神经网就直接把功能实现了，甚至不需要看到代码。

AI 在未来5年、10年的发展，会让很多想象的东西都成为现实，这对研发来说会造成很大的冲击。那么，将来研发人员的数量是否还会继续增长？我觉得毫无疑问，肯定会持续增长，但是方向可能和现在有很大的差别。

DevOps 遇瓶颈，AI 来破局

我个人对 DevOps 行业非常有体会，因为之前我做过 CloudStack、做过 Rancher，这些产品都是为 DevOps 服务的，过去十年伴随着云计算的快速发展，可以说是 DevOps 的飞速成长期，我们正好赶上了 DevOps 的热潮。

正如我前面提到的，在没有云计算之前使用资源需要购买机器、购买网络设备，这些设备需要有专门的人进行编程和配置，那些人就是思科认证的或者华为认证的工程师。

在 DevOps 时代，已经不依赖手动配置了，可能是 DevOps 工程师来写脚本，或者更多时候就直接写程序，所以可以说 DevOps 工程师其实是新一代的思科认证工程师。

但有些系统十分复杂，比如 Kubernetes，那么这给诸如 Rancher、HashiCorp、GitLab、DataDog 之类的公司创造很大的机会，这些创新公司都已经成长为大型企业。尽管是红利受益者，但我们也在反思：为什么企业对 DevOps 的需求量无法抑制地增长？

最早 DevOps 刚刚出现的时候，正常的人员配比应该是 10 个研发人员，配 1 个 DevOps 工程师。但发展到后来就发现这样的人员配比导致 DevOps 人员的压力好大，于是变成 5:1。再到后来，那些发展迅速的互联网企业内部的配比已经变成 3:1，甚至 2:1。这通常意味着这个系统已经过于复杂了。

当前，在 DevOps 领域已经出现了很多工具，但这些工具也并不能完全减轻这些人的压力。那么在现在的 AI 时代，可能还会需要更多的运维人员对大模型、应用进行运维，情况也许会变得更加糟糕。

基于此，我们思考是否可以把 DevOps 的复杂度控制下来，那么“平台工程”的概念就出现了。不同企业的内部环境差异极大，那么怎么能够真正把内部的 DevOps 流程变得更加有效，而不是机械地重复？AI 的出现将会带来一个全新的机会。

AI时代中非常明显的现象是，无论是公有云、私有云还是混合云，将来在云上运行的大模型将会占据越来越高的比例。所以云需要针对大模型的运行进行优化，真正把它们给运行好。稍后我们也会演示如何快速部署大模型。

另外，AI 不应该仅仅服务于终端用户，我们既然是 IT 从业者，应该“近水楼台先得月”，充分利用 AI 技术来解决我们自己的问题，比如 AI 可以减轻 DevOps 工程师的工作量。这样研发与 DevOps 的比例就可以不断下降，最终达到理想状态。

绝大部分 AI 应用的本质是云应用，并且现在 Kubernetes 实际上已经成为大模型平台的运行标准。上图截取自 OpenAI 的官网，当时 GPT3 已经推出，但 ChatGPT 尚未诞生。值得注意的是，Kubernetes 官方推荐使用的最大节点数是5000，但 OpenAI 因为需求量大，已经把 Kubernetes 用到极致——扩展到7500个节点。

据我了解，他们现在仍然在使用 Kubernetes，但目前的具体使用状况外部也不是很清楚。我相信，在他们迎来爆发式增长的这段时间，应该是把 Kubernetes 扩展得更大了。OpenAI、微软 Azure 这些公司都在大量购入 Nvidia 的图像处理器，然后放在服务器里，由 Kubernetes 等技术进行管理，最后再在上层运行大语言模型。

总而言之，AI 时代下的整个应用架构基本上已经建立了，这也是目前业界都比较认可的标准：最底层是公有云、私有云，再往上是 Kubernetes，然后是管理 AI 本身的一些工具，比如 Pytorch、Tensorflow，再往上层是大模型，顶层是应用。

AI释放开源力量，开源赋能AI发展

数澈软件Seal 本身是一家开源的公司，我们这个团队投身开源领域已经有十几年了，我们一直认为开源是非常好的方向。但直到 AI 出现之后，我们才真正体会到开源的力量。

上图中，红色的线表示 Kubernetes star 数量的增长趋势，到今年刚刚超过 10 万颗 star。众所周知，Kubernetes 早已成为业界认可的容器编排的事实标准。但是 AI 相关的开源项目 star 数量能在几个月之内就超越 Kubernetes，这令人惊叹。所以可以看出开源界对 AI 的重视程度，另外一方面，开源也能够为 AI 带来一些真正的机会。

在现阶段，闭源软件的创业已经很难成功了，所以在软件领域开源是必须的。因为开源社区是跨国界的，不受地缘政治的限制。比如，在中国结束了疫情管控之后，目前最流行的开源组织之一，云计算基金会 CNCF，就立马到上海来举办 KubeCon，完全没有受到政治方面的影响。

换言之，中国企业可以通过开源把真正世界级的技术推向全球，成为全球技术的引领者，并从中获得很多发展的机会。

上文提到 AI 必须能够帮助 DevOps 工程师提升效率，在传统 DevOps 领域也曾有类似的需求，那时候叫自动化（Automation），通过脚本把手工工作变为自动。

但是自动化发展到一定程度之后，仍然对人有巨大的需求。因为很多需要判断力的事情，无法通过简单的脚本规则来规定清楚，主要还得依靠人进行判断。所以自动化的下一步应该是 AI。

上方左侧的图片是波音747刚刚推出时的驾驶舱配置，当时（上世纪60年代）大约需要3、4个驾驶员，2个驾驶飞机，剩下的观测仪表盘。通过自动化的改进，现在基本上2个人就可以开飞机了，复杂的仪表也消失了。那要再往下前进一步，能不能既减少开飞机的人数，同时还能提升安全性？这时候光靠自动化已经不够了。

那么我们希望通过 AI 能够真正把运维工作自动化，一会儿江鹏会对我们目前已经完成的工作进行演示。目前我们只是刚刚开始，我们希望通过开源让大家能够尝试、使用并且能够给我们提意见。

平台工程为 AI 提供护栏（Guardrail）

大家在用 ChatGPT 的时候可能会发现，它尽管能回答你的问题，但并不一定是对的，因为大模型不是 100% 可靠。这个缺陷对于简单的任务来说无足轻重，但如果是在生产环境上运行的应用，在接收到错误的命令之后直接运行，可能会造成难以估量的后果。

因此我们在思考能够降低大模型出错的概率的方案，这在业界有一个标准的做法——Guardrail，即通过给 AI 系统设置规则来对其进行限制，比如预计限制让 AI 只控制阿里云、腾讯云、AWS。

因此我们在中间添加一层机制进行审核，如果出现明显的错误，那么审核不通过。在审核通过之后，再让 AI 的指令上手完成任务。而这些是可以平台工程实现的。这类似于我们常常提到的自动驾驶汽车，因为路况太复杂，所以自动驾驶汽车的实现是很困难的。但是如果说我们要做自动驾驶火车，那就简单很多。因为火车被限制在轨道上运行，路况相对来说简单很多。

所以平台工程不仅应该为工程师提供工具，还应该为 AI 提供护栏（Guardrail）。

数澈软件Seal 正在借助 Guardrail 机制开发 AI 时代的 DevOps 平台，希望能够给 DevOps 工程师减轻工作量并成为他们的 AI 助手。接下来，我将介绍我们目前已经完成的工作，然后邀请江鹏进行产品演示。

关于平台工程，业界已经形成了基本的认知：平台工程的出现主要是为了解决 DevOps 复杂度的问题。

首先，平台工程可以解决 DevOps 团队和研发团队之间的沟通协作问题。因为研发团队平时通常通过 IDE 来完成工作，他们也许能清晰地了解业务需求、程序设计语言和框架、包括当前的 AI 技术，但是他们可能完全不了解 DevOps 工具，比如 Terraform 可以做什么，怎么样部署 Kubernetes ，于是这些成为了 DevOps 团队的工作。那么这两个团队之间的协作成为一个问题，无论是通过邮件还是发工单进行沟通，都非常繁琐，且易出错，因此需要平台工程。

在过去两三年间，我们和至少几百家企业交流过，发现大家都有类似的需求。最终就形成了企业内部的平台，它为研发人员提供UI、CLI以及服务目录（Catalog），研发人员可以直接调用现成的工具来完成应用开发工作。

但是我们发现，由于没有现成的解决方案，每个团队在搭建平台过程中都对中间的一层花费了大量的精力，我们把它称之为“应用管理”。

为什么叫应用管理呢？因为它关心的是应用配置、部署可靠性以及多环境管理，甚至包括应用成本。通过应用管理层，企业可以清楚地了解各类环境信息，应用开发资源的成本管理，包括生产环境中的实例成本、研发团队成本、测试团队成本等，方便企业进行优化。

之前提到，我们与上百家公司交流过，每家公司内部都在构建自己的一套应用管理，并且再和开发者门户进行集成。实际上开发应用管理工作量是很大的，并且十分繁琐，于是我们构建了这样一个开源应用管理平台 Walrus。

Walrus 是一款 100% 开源的基于平台工程理念构建的应用管理平台，开源地址是：github.com/seal-io/walrus。除了基础的应用部署、服务模板等功能，我们把 AI 技术列为了开发重点。所以在 Walrus 平台内部整合了丰富的 AI 技术，我们还提供一个 AI 助手 Appilot（预计本月中下旬开源，敬请期待），帮助用户运维。那接下来有请江鹏来进行演示。

点击下方视频，空降至 35:45 即可查看 Seal联合创始人及COO 江鹏的产品演示，包括在 Walrus 上借助其服务模板的特性快速部署 Meta 开源大模型 Llama 2 和 Stable Diffusion，并引入 Seal AI 助手 Appilot，通过输入自然语言，借助 AI 大模型的推理能力完成资源调度、服务查询、应用部署等任务。

https://www.bilibili.com/video/BV158411B7Mn/?spm_id_from=333.999.0.0&vd_source=0afbb2a94baeee24b5d65e44bc1e58d9

参考链接：https://mp.weixin.qq.com/s/4FHYX1Vlm__nCBX300moJg

作者：Seal 软件