AI云产品，缺运维技术指南
1. 本文有三个科普目的
本文和我过去写的云计算文章大不相同，主要是为了说明三个执行过程中的具体问题：
第一. 云产品的设计者需要掌握一个关键技能：目标客户能看懂哪些技术信息，能怎么使用你的产品。PaaS云产品的生产者和使用人都是研发工程师，这个工作就比较好做；但IaaS云产品的使用人是运维工程师，IaaS云研发很难天然理解“软件的可运维性”，本文就要介绍这个名词。
第二. 云主机、VPC等云产品，刚诞生时就有客户自建环境做对标竞品，虽然客户对这类产品的质量要求很高，但云厂商不需要培养“客户使用产品的技能”，导致大家经常忘记这个必备环节。而AI或其他的全新云产品的推广环境变了，客户对产品本身的质量要求不高，但云厂商需要培养（或等待友商培养）客户完善使用产品的IT技能。
第三. 它山之石可以攻玉，这篇文章可以被甲方运维朋友拿去，既可以当做自己整理技术资料的参考框架，也可以用作给研发部门要维护信息的标准。我跟运维工程师交朋友，一直是很用心很用力的。
2. 要卖AI云，要关注甲方运维承接能力
云厂商想卖AI云产品给甲方客户，而甲方在付费之前，需要在AI云产品上部署和维护大模型软件。现在有个关键节点卡住了：甲方运维工程师很难胜任自家大模型软件的部署和维护工作，这就导致甲方很难大量采购AI云产品。云厂商可以坐等行业自然解冻，也可以主动完成相关的技术科普。
云产品须和资源有强关联，才能卖出高价，AI云产品也不例外。这些和资源强关联的IaaS云产品，其操作承接方只能是甲方的运维工程师。但是在AI云产品的推广过程中，我们看到了一个新问题，甲方运维工程师不懂如何搭建和维护AI业务。
前几年大家主要做AI模型训练，这是离线项目制任务，落到甲方运维的工作压力并不大。但是近年来，AI推理业务越来越重要，AI推理可是在线平台服务，和其他的互联网服务一样，需要高并发、大负载、不间断运行，甲方运维是既要学技术又要扛责任。
各种开源大模型的技术PK刚刚开场，这些软件的目标都是“在本地电脑上能运行程序”，即搞不懂也不关注什么叫“服务端软件的可运维性”。但是因为老板们对新兴业务的SLA和TCO的要求不高，甲方运维确实还有很多学习的时间。
云厂商当然可以什么都不做，等上三五年的时间，甲方运维自然会补上这些技能。但是，如果云厂商在本阶段承担起技术指导的工作，这不仅是个公益科普，也是在培养用户的产品预期和使用习惯。
3. 运维单体软件的技术指南
运维工程师和后台研发的思维方式差异很大，他们不关注软件的功能和实现方法，而是关注软件的“可运维性”。
本文先从单体软件的角度介绍，一个具备可运维性的软件，需要以严谨文档的形式，向用户提供下列信息：
软件名称和概述，200字以内说明本服务承担的工作内容和重要特性。
为了保证本软件的正常部署启动，需要准备的硬件、系统、内网资源。
本软件启动自检时，逻辑依赖的其他软件服务，以及这些逻辑依赖的报错信息。
对本软件的配置文件、工作目录、系统日志进行详细介绍，对业务日志进行简要介绍和对接。
为了完成生死监控，本软件启动以后的进程和负载状态，本软件可以确认正常工作的仿真访问方法。
大模型软件相关的性能指标，比如GPU利用率、访问延迟和token吞吐率等等。
在单一软件层面上，数据和程序的备份和恢复方法。
虽然AI技术很酷很新，但是在老运维眼里，AI训练群集和离线大数据群集没什么区别，AI模型推理就是个普通但黑盒的Web应用容器。研发工程师总喜欢念叨“AI程序Debug、常见故障3000问”这类话，但在运维眼里，线上故障哪有时间磨叽，运维只能快速完成“监控-重启-重装-重置”这几层急救动作。
4. 整个业务群集的设计技术指南
高级运维要规划整个群集的业务承载能力，并且要做好群集高可用，还需要做好降本增效工作。
这些高级工程师在其他业务中，会基于现有的Web、数据库、缓存队列等软件的权威技术资料，自行推导整个群集的规划设计指南。如果云厂商想加快AI云产品的推广速度，应该送佛到西，主动提供下列信息。
介绍AI业务新引进的IT技术新特性、新名词，保证“研发-运维-业务”三者在一个沟通平面上。比如，训练群集是个重度依赖网络的严格并行系统；再比如，模型训练和模型推理各自关注FP32和FP16，但偶尔也会用到混合精度；还比如，介绍类似模型预热、推理延迟、模型漂移的概念和运维侧应对思路。
本业务群集的技术逻辑图，需要包含各个软件的逻辑分层和调用依赖关系，需要详解常见的访问请求或任务计划，各自串起了哪些软件功能模块，请求如何处理下发，数据如何变换。
对高负载组件（比如AI推理的主计算单元），需要说明程序初始化和常规请求会用到多少硬件和网络资源，运维需要这些材料才能完成群集规模和成本开销的规划。很多研发会说，“每个访问请求用的资源都不同”，没问题，那就从轻到重举出10种访问请求的例子吧——这种建议并不是抬杠，而是运维就认可这种沟通方式。
对高负载组件提供可靠的弹性伸缩方案，可以是负载均衡注册和调度、访问端hash、后端分库分表，甚至只保证BASH数据软一致性。如果上述工作太难太久，也可以先用K8S承接AI推理应用，至少满足弹性伸缩需求，其他的工作慢慢优化。
详细介绍重要业务组件的状态信息，详细介绍非故障业务日志，让运维监控从故障防灾变为业务量调控，最终运维会接管业务调度工作。
除了常规的安全设计之外，AI业务还需要重度考虑数据合规运营的问题，特别是跨境数据传输时，运维更关注这些信息，而研发几乎不考虑这类问题。
常规的服务中，还需要描述客户业务数据的生命周期、备份方法和回滚预案，但AI大模型应该不太需要专门关注业务数据，运维的精力还是集中在数据库和日志系统上就够了。我知道模型训练过程中会有检查点、模型推理也会有缓存，但这些都只是中间临时信息，并是严肃的业务数据。
某些运维工程师的能力退化，沉迷于“盯监控、做备份、发版本、写脚本”的舒适区里，把自己做不了的工作称为“基础架构部or系统架构师”。但我很清楚，我认识的高级运维、包括我本人做运维时，都能完成上述所有工作。
5. 测试和实施的技术步骤参考
甲方运维团队要做其他云产品（比如LB、RDS）的技术选型时，因为都是同质化老产品，客户很了解产品的技术指标和验证方法。但是，AI云产品是新产品，当云厂商说做了AI网络优化、AI推理加速等工作时，需要给客户提供明确的测试和实施的方法。
前序两节的技术指南都属于“云厂商帮甲方运维做技术指导”，但是，本节介绍的产品测试验收和迁移实施的技术指南，是云厂商在展示自家产品优势，云产品团队必须做好客户布道和推广这个本职工作。
无论是哪种云产品的测试报告和实施文档，都需要给出甲方运维能看懂的测试环境和测试步骤，让测试方案百分百可控、百分百复现。
虽然这是个很基础的要求，但是大部分云产品写测试实施文档时，都不满足要求。因为实际撰稿过程中，产品经理不了解预设读者（甲方运维）的技能和信息，他们遇到这种技术类工作，就会习惯性的推给云研发，读者、写手、验收方三者的工作方式毫无关联，能写对了才怪。
除了保障读者的可读性之外，云产品的测试报告在规划撰写时，还要充分考虑到下列三类工作目的：
在测试前科普，引导客户该关注哪些技术指标，这些技术指标对甲方的帮助提高稳定性、加快响应速度还是节省成本？
测试结束后，测试成果是能展现出本公司产品有明显优势，还是能规劝客户舍弃一些错误概念？
测试环境和客户现场有很大的差异，但是，只要合理提炼测试过程，本次测试仍然能给客户起到参考借鉴的作用。
迁移和实施文档都只是“参考指南”，只是给甲方技术团队当“建议”和“证据”用的，比要求百分百可复现的测试报告好写。此时云厂商需要向传统商业软件学习，充分发挥这些文档的“证据”功能，帮助甲方技术团队拒绝不合理的需求。
比如说，很多昂贵商业软件就官方声明，不支持无缝升级和切换，必须留下充足的操作窗口，甲方技术团队拿着官方文档就能堵住业务团队要无缝升级的需求。
比如说，编写AI推理服务的程序员们懒得关注“可运维性”，那运维宣称某某技术需求属于“K8S最佳实践”，这些程序员就很配合修改了。
6. 云厂商的获利空间
这些工作是云厂商“可以但非必须”的工作，云厂商确实可以嘴上喊着AI万岁、实际等着甲方运维自学运维AI的技术。但是，如果云厂商主动去做AI运维技术的布道推广，可以获得如下四大类优势和价值。
首先，领航者们有义务加快市场孵化，这不是唱高调说梦话。那些开发者友好的API云产品没一个能打的，能创造大额营收的AI云产品就是GPU云主机、GPU容器云和GPU裸金属，而这些产品就要依赖甲方运维才能承接和使用，有梦想的云厂商就要亲自破冰布局，等友商破冰是做不成行业第一的。
第二，结合自家产品，给客户植入扬长避短的思维钢印。技术选型本来就是顾此失彼的，即是免费中立的技术布道，一样可以对客户进行倾向性诱导，客户也不太反感这种洗脑。因为AI软件还不成熟，我还看不透AI云产品具体该有哪些扬长避短的叙事逻辑，但只要沉下心给客户写技术指南，就肯定能找到对自家产品最有利的对比角度。
第三，“云产品、云资源、云服务”三者可以彼此协助。云计算最大的魅力就是，它即是云产品（技术），也是云资源（GPU池），还是云服务。如果你的产品和资源有瑕疵，做好客户服务一样能争取到客户；如果你的产品和资源都很优秀，那更不应该让客户能力拉后腿了。
第四，验证自家尖刀团队的真实工作实力。很多云厂商都自称AI云是最重要的创新方向，最重要的团队就要吸纳最优秀的人才啊。一个合格的AI产品经理做产品规划，一个称职的技术支持工程师回答客户疑问，都要求从业者们最好能规划、其次能写出、最差能熟练掌握这些运维技术指南文档。
7. 例行推销书籍，本文内容和我书稿的关联
我写了一本《云计算行业进阶指南》，本文提到的很多内容，都和我这本书有硬性关联。在此，我继续向各位推荐本书。
本文很重视甲方运维工程师，不仅仅是因为我做过运维，更是因为运维工程师的IaaS云的操作者。业内的IaaS和PaaS分类都是鸡贼的噱头，只有我的书稿整个第8章都是在介绍，如何有意义的区分IaaS和PaaS云。
大部分AI云噱头是在谈SaaS应用和大谈什么开发者友好。但我亲身体验过，SaaS云是一个个早就存在的夹缝小市场，详情见我的书稿8.5章节。开发者给云厂商带不到什么价值，我为此专门写过《让开发者云单飞吧》。
很多读者因为不了解云计算，对AI云产品也在卖资源会很失望。但是，实际情况是，包含资源的云产品才是技术难度最大、收入和获利都很丰厚的选择。我写过一篇《云卖资源，天经地义》，书稿的第4章也是在详细的分析介绍，资源型云产品最有价值。
如果云厂商只是简单透传GPU资源给云主机、容器云或者裸金属，这属于非常成熟非常古老的云产品。我在书稿的5.3章节甚至将其归类到“低成本简易云产品”，这类GPU产品的正式名称应该是“第11.2章-模板化云主机”，都不值得做专门的产品分析介绍。
有些云厂商对AI云产品投入了大量的精力，这些GPU云产品就值得专门分析了。比如AI模型训练依赖复杂的网络，我就写了一篇《给AI网络诊脉》，虽然是个广告，但科普效果很好。再比如，AI推理加速也能写很多东西，我就是发现AI推理加速的运维资料非常匮乏，甚至和AI推理研发的沟通很困难，我才想写本文的。
本文多次提及，给甲方撰写技术指南时，就是要考验产品经理和技术支持工程师的能力。我的书稿第15章节，明确介绍产品经理只有掌握客户侧工程师的IT技能，才能够胜任工作；我书稿第17章呼吁云厂商提高技术支持工程师的能力，也提到了要从甲方技术团队优中选优的挖角。