企业私有化 AI 高可用怎么做？单点、冗余、容量、故障切换、RTO/RPO、降级、恢复演练与验收清单

企业知识助手上线后，最让运维头疼的未必是整套平台彻底宕机。更常见的情况是聊天页面能打开，回答却一直转圈；模型服务正常，向量库返回了旧权限；一台加速卡故障后，流量全部压到剩余节点，重试又把它们一起拖垮。监控面板可能还有大片绿色，用户已经无法完成工作。私有化 AI 的高可用，需要沿着真实任务逐层检查。

先定义什么叫可用

登录成功、接口返回 200、模型吐出文字，只能证明局部组件在运行。对知识问答，完整可用应包括身份验证、权限过滤、文档检索、模型生成、引用跳转和必要日志；对动作型 Agent，还要加上工具调用与人工确认。任一关键步骤失败，业务任务都可能无法完成。

按业务影响划分服务等级

生产客服、内部资料查询、批量文档处理和实验环境的中断后果不同。业务负责人要说明允许停多久、能否转人工、积压如何补做、哪些时间段最关键。所有场景都追求同一可用率，会让低价值环境消耗过多资源，也会让关键场景的保障不够具体。

从业务影响分析开始

NIST 的信息系统应急规划指南把业务影响分析、恢复策略、计划、测试和维护连成一套流程。企业可以沿用这个思路，先确认中断会影响哪些人员、客户、收入、合规义务和下游系统，再确定技术投入。

RTO 和 RPO 分别解决什么

RTO 是业务从中断到恢复的目标时长，RPO 是可接受的数据回退范围。知识助手的配置和文档索引可以有不同 RPO，在线会话与离线评测也未必一样。目标要写到具体服务和数据对象，不能只为“AI 平台”填一个统一数字。

绘制完整依赖图

从用户入口向后列出 DNS、证书、负载均衡、身份系统、API 网关、应用、模型服务、加速卡调度、对象存储、关系库、向量库、消息队列、日志和外部接口。每条连线标明协议、超时、重试和数据方向。没有依赖图，团队很容易只给最显眼的模型节点做冗余。

逐项标出故障域

层级	常见故障	需要验证的保护
入口与身份	DNS、证书、单点登录不可用	冗余解析、到期告警、应急登录边界
应用与网关	进程崩溃、版本错误、连接耗尽	多实例、健康检查、限流与回滚
模型与算力	加速卡故障、显存耗尽、模型冷启动	跨节点副本、保留容量、替代模型
数据与检索	索引损坏、权限延迟、存储不可达	备份、校验、重建与只读降级
外部依赖	身份、API 或网络中断	超时、熔断、缓存边界与人工流程

先消除明显单点

检查只有一台的负载均衡、数据库、向量库、模型节点、控制平面、许可证服务和密钥服务。双实例也可能共用同一电源、交换机、存储或虚拟化宿主机。高可用图上画了两个方框，不代表它们处在不同故障域。

无状态服务优先横向复制

聊天前端、API 网关和编排服务尽量把会话状态放到共享且可恢复的数据层，实例可以随时替换。每个副本配置相同版本、资源和秘密引用。滚动发布期间至少保留满足最低流量的健康副本，并验证旧版与新版短时并存不会破坏会话。

模型副本要跨物理节点

两个推理进程若都在同一台加速卡服务器上，主机故障会同时失去。副本应分散到不同节点，关键环境还要考虑机架、可用区或机房。Kubernetes 的拓扑分布约束可以按节点、区域等故障域控制副本放置。

N+1 容量要用故障负载验证

正常状态下两组节点各承担一半流量，并不说明失去一组后还能承载全部高峰。测试剩余容量能否满足关键请求，观察首字延迟、完整响应、排队、显存和错误率。若无法全量接管，就提前确定限流、优先级和降级对象。

加速卡故障不只表现为离线

设备可能出现纠错告警、温度异常、驱动重置、通信错误或部分性能下降。监控要把硬件健康、容器状态和模型响应联系起来。节点反复恢复又退出时，自动调度可能制造流量震荡，运维应能隔离设备并人工确认后再放回资源池。

控制平面也需要保护

编排集群、镜像仓库、模型仓库、配置中心和许可证服务出问题时，已有实例可能继续运行，新实例却无法启动。列出控制平面中断对扩容、发布和恢复的影响，保存离线可用的镜像、模型、配置和许可材料，避免故障时才发现重建链条断了。

健康检查分成三类

启动检查确认模型和必要资源是否加载完成；存活检查判断进程是否需要重启；就绪检查决定实例能否接流量。把三者都做成一个“端口能连通”的探针，可能把尚未加载模型的实例推给用户，也可能在系统过载时反复重启健康进程。

端到端探针补上组件盲区

从受控测试账号发起一条轻量请求，走过身份、检索、模型和引用链路，检查结果与时延。探针数据不得进入真实统计或业务动作，也要控制频率。端到端探针用于发现链路问题，不能替代各组件的资源与错误监控。

超时必须逐层协调

浏览器、网关、编排服务、模型和外部工具各有超时。上游等待时间应覆盖必要的下游处理，同时给取消和清理留出空间。若下游已超时，上游仍继续等待或重试，线程、连接和显存会被没有价值的请求占满。

重试可能放大一次小故障

Google SRE 的级联故障章节说明了过载、重试与资源耗尽如何互相放大。企业要限制重试次数，使用带随机抖动的指数退避，并明确只有幂等、短暂失败且仍有时间预算的请求才能自动重试。

熔断器为故障划边界

外部模型、数据库或工具持续失败时，编排层应快速停止无效调用，经过冷却和探测后再恢复。熔断状态要被监控并能由值班人员查看。只返回统一的“系统繁忙”，会掩盖究竟是模型、检索还是业务接口出了问题。

限流要保护剩余容量

按租户、用户、场景和任务类型设置并发与速率，关键在线请求优先于批处理和实验。容量下降后收紧低优先级额度，避免所有请求一起变慢。队列、优先级和峰谷安排可结合私有化 AI 工作负载调度清单配置。

降级方案按任务设计

知识问答可以从大模型切换到较小模型，关闭耗时的重排序，缩短上下文，或只返回检索结果；批处理可以暂停接单并保留进度；动作型 Agent 可以退回“只建议、不执行”。每种降级都要说明用户提示、允许时长、数据一致性和恢复条件。

备用模型先测兼容性

替代模型的上下文长度、工具调用、结构化输出和安全行为可能不同。用生产回归集验证质量与格式，限制它能处理的场景。故障发生后才临时换模型，往往会把可用性问题变成错误输出或权限问题。

缓存既能救急也会制造旧数据

缓存公开知识、模型元数据和非敏感结果可以降低依赖压力，但权限、客户资料和频繁变更内容需要谨慎。记录缓存键、租户隔离、有效期和失效机制。数据源恢复后还要防止旧缓存继续覆盖新内容。

模型冷启动要进入时间预算

大模型从存储加载到加速卡可能需要较长时间，首次请求还会触发编译或缓存预热。测量从节点故障到替代实例真正就绪的完整时间，不以容器启动成功为准。关键服务可以保留温备副本，并控制扩容时的流量爬升。

模型文件准备独立副本

模型仓库、权重、分词器、量化配置和运行镜像都要做版本与校验。远端仓库不可达时，企业应知道本地是否有可启动副本。备份文件必须经过加载测试，文件存在和哈希正确仍不足以证明运行环境兼容。

知识库恢复不只靠向量备份

要保留原始文档、解析结果、切片规则、嵌入模型、索引配置、权限映射和任务状态。只有向量库快照时，很难解释某条索引从哪里来，也难以在模型变更后重建。恢复演练应从原始资料开始跑通一小批完整链路。

索引更新需要可重入

文档处理任务在中途失败后，应能从检查点继续，重复执行不会产生多份记录或错误删除。为每批任务记录来源版本、处理版本、范围和结果。恢复时先确认已完成边界，再补跑缺口，避免整库重建把系统拖入更长停机。

权限变化优先于搜索新鲜度

员工离职或文档收回权限后，旧索引不能继续返回内容。设计权限事件失败时的保护策略，宁可暂时拒绝访问，也不要沿用无法确认的新旧权限。监控身份源、同步队列和索引生效时间，并准备人工吊销通道。

数据库主备要验证写入语义

主库切到备用库后，连接串、事务、序列、会话和只读状态都可能变化。测试切换期间的在途请求怎样处理，客户端是否会重复提交。对于有外部副作用的操作，使用幂等键或明确人工确认，不能依赖盲目重试。

备份先按恢复目标设计

模型、配置、业务库、向量索引、日志和原始文档的变化频率不同，备份周期也应不同。保留异地或隔离副本，限制删除权限，并记录加密密钥恢复方式。通用原则可参考企业官网灾备与业务连续性清单。

配置与秘密一起纳入恢复

应用恢复后若缺少模型路由、限流规则、提示词版本、证书和密钥，服务仍无法使用。配置进入版本控制，敏感值存入专用秘密系统，备份与恢复分别测试。恢复后的秘密应按计划轮换，避免备用环境长期持有过期或无人管理的凭据。

单机房高可用有明确边界

跨节点副本能处理主机故障，却无法覆盖机房断电、核心网络或共享存储中断。企业要把已覆盖和未覆盖的故障写入服务承诺。若业务能接受数小时恢复，异地备份加人工重建可能比双机房在线运行更合适。

双机房先选运行模式

双活能缩短切换，但数据一致性、流量治理和日常运维更复杂；主备架构易于理解，却要承担备用容量、数据延迟和切换时间。根据 RTO、RPO、网络条件和团队能力选择。架构名称不能代替实际故障演练。

跨区域延迟会改变体验

身份、向量检索、模型和文件若分散在不同区域，每次问答可能产生多次跨区往返。测量真实链路，不只测模型推理。还要核对数据跨区域复制是否符合合同、隐私和客户要求，不能为了冗余默认把所有数据复制出去。

备用环境保持最小活动

完全冷备成本低，但配置漂移、证书过期和镜像缺失往往在启动时才暴露。定期让备用环境完成健康检查、少量同步和受控查询，保持人员熟悉。是否长期保留加速卡，要根据采购周期、启动时间和 RTO 计算。

监控平台和模型两种健康

NIST 把安全与韧性列为 AI 可信特征，并指出可用性涉及系统及其数据、软件和硬件，可参考AI 安全与韧性研究说明。监控既要看延迟、错误和资源，也要看拒答、引用、越权、输出格式与模型行为漂移。

平均值会掩盖尾部故障

记录首字和完整响应的 P50、P95、P99，按模型、租户、场景和节点拆分。平均延迟正常时，一小部分超长请求仍可能占满并发。错误率也要区分限流、超时、依赖、模型和用户输入，便于值班人员找到真正故障层。

日志留够调查字段

记录请求标识、时间、租户、路由、模型版本、知识库版本、主要依赖、耗时、重试、降级和结果状态。提示词正文按隐私和必要性控制，不默认长期留存。字段与销毁边界可对照企业安全日志管理清单。

告警面向用户影响

单台节点离线但用户无感，可以低级告警；关键任务成功率下降，即使所有节点在线也应升级。告警要包含影响场景、开始时间、当前容量、值班人和处置手册。对同一根因产生的几十条组件告警应聚合，避免值班人员被噪声淹没。

SLO 用关键任务表达

可以定义“授权用户在规定时间内获得带有效引用的答案”或“批处理在截止时间前完成”的比例。把成功率、响应、质量和权限合在业务路径上，再分解到组件指标。制定方式可借鉴企业官网 SLA、SLO 与错误预算清单。

错误预算约束发布节奏

在可接受失败范围内，团队可以发布模型、检索和应用改进；错误预算消耗过快时，减少高风险变更，把资源转向稳定性。质量错误与平台错误可分开统计，但不能让低质量回答因为接口成功而被排除在外。

计划维护也要保护容量

Kubernetes 的中断管理文档区分自愿与非自愿中断，并说明副本、跨故障域放置和 PodDisruptionBudget 的作用。企业升级节点或缩容时，要确保同时不可用的副本不会跌破关键服务下限。

滚动升级准备回退条件

新模型、新驱动、新镜像和新提示词先进入小流量，观察质量、性能、显存和错误。提前写明自动停止与回退阈值，保存兼容的旧版本和数据结构。发现问题后继续全量发布，再指望稍后修复，会扩大故障范围。

上线前压到降级点

容量测试不应只证明目标流量能通过，还要找出从排队、限流、降级到崩溃的完整曲线。测冷启动、大上下文、批量上传和混合负载，观察故障节点退出后剩余容量。生产规划以测得数据为准，不能照搬硬件标称吞吐。

故障注入从可控场景开始

依次模拟模型进程退出、一台加速卡不可用、向量库延迟、身份系统超时、对象存储只读、网络分区和证书到期。每次只改变少量变量，设定停止条件和回滚人。成熟后再组合故障，检查系统是否出现意外级联。

恢复演练要测真实时间

从告警触发开始计时，记录确认、决策、切换、数据校验、业务开放和积压处理各阶段。最终恢复时间要包括模型预热与知识库核验，不能在服务器开机时就停止计时。演练结果与 RTO/RPO 比较，未达标项要有负责人和期限。

值班手册按症状组织

值班人员最先看到的是“回答变慢”“引用打不开”或“某租户全部失败”，未必知道组件名称。手册从用户症状出发，给出确认指标、常见根因、隔离动作、降级、升级联系人和恢复验证。命令涉及删改或切换时，要标出风险与审批。

事件期间明确谁做决定

技术负责人处理故障，事件负责人维护时间线和优先级，业务负责人决定降级是否可接受，沟通负责人向用户更新。角色可以由少数人兼任，但不能无人承担。切换、回退、停止 Agent 动作和恢复服务都要有清楚授权。

供应商支持纳入演练

如果模型许可、硬件、平台或实施由外部供应商负责，合同中的响应时限要在演练中验证。确认夜间联系渠道、日志交付、远程访问、备件与升级责任。供应商能在工作日回答工单，不等于能支撑生产系统的恢复目标。

运维阶段持续看行为变化

NCSC 的安全 AI 运行维护指南建议监测系统行为和输入，并管理更新。企业要把性能退化、数据漂移、异常输入、攻击、版本变化和资源故障放进同一运行视图，避免各团队只看自己的一段链路。

验收必须包含失败状态

验收项目	合格证据	常见假通过
单点故障	停止指定节点后关键任务仍达标	只检查副本数量
容量接管	失去一个故障域后通过高峰负载	在空载时完成切换
数据恢复	按备份恢复并校验权限、索引和版本	备份文件存在
降级	触发条件、用户提示与恢复均可复现	文档写有备用方案
RTO/RPO	演练时间线和数据差异均在目标内	由项目人员口头估计
事件协作	值班、供应商和业务完成联合演练	通讯录里留了电话

高可用成本要对准风险

双机房、温备加速卡和多份数据会增加硬件、网络、许可与运维成本。用业务损失、采购周期和恢复目标判断投入，不追求没有依据的“五个九”。低风险内部助手可以接受人工切换，关键客户流程则需要更短恢复和更完整的自动保护。

一个九十天落地节奏

首月完成业务影响分析、依赖图、故障域、RTO/RPO 和当前单点清单。第二个月补齐副本、健康检查、限流、降级、备份与监控，建立版本化回归集。第三个月依次执行节点、依赖、数据和机房级演练，根据实测时间修正架构与值班手册。

上线前的最终核对

逐项确认：可用性按用户任务定义；关键场景有服务等级；依赖和故障域完整；模型副本跨节点；故障后容量经过压力测试；超时与重试不会放大流量；知识库和权限可恢复；备用模型完成兼容测试；监控覆盖质量与平台；RTO/RPO 来自演练；供应商能按时响应；退出降级后用户知道怎样继续工作。

稳定来自一次次可复现的恢复

私有化 AI 高可用不能靠采购两套设备直接获得。团队要知道哪一层会坏、坏后流量去哪里、数据回到哪个时间点，以及用户还能完成哪些任务。若企业需要结合官网知识、内部资料、模型和权限设计可恢复架构，可从凯乐丰 Colorfun 私有 AI 服务了解交付范围，再按本清单把故障与验收条件写进项目。