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....
 

参考链接：https://mp.weixin.qq.com/s/4FHYX1Vlm__nCBX300moJg
作者：Seal 软件