6.3 部署模式与运维监控

6.3 部署模式与运维监控

选型定了，本节把系统立起来跑。承接 6.1 与 6.2 的选型结果，先过四种部署形态的适用边界与升级触发条件，再给容量规划立个公式，最后交出一张可以直接抄进监控系统的指标清单。旧版教程的"部署模式""运维与监控"两节在此合并，因为部署形态决定了监控点怎么挂——两者本来就是一张图的两面。

四种部署形态与升级触发器

进程内嵌入式：向量库作为库文件跑在应用进程里，没有网络跳数，延迟最低、部署最简，适合单机装得下的工具型应用与离线任务；它的隐含约束是数据与应用同生共死，没有独立扩缩与高可用可言。单机容器：一个容器或一小组容器托管服务进程加本地盘，适合千万级以下、可用性要求一般的业务，把第四章的全部系统语义收进一台机器。容器编排集群：在 Kubernetes 上按第四章的组件图拉起索引节点组、协调器与元数据服务，分片副本齐备，滚动升级与故障自愈交给编排层，这是平台级服务的主力形态，代价是要真正具备容器平台的运维能力。云托管与无服务器：6.2 讲过，运维面最小，性能上限与合规边界要提前谈。

形态之间靠触发器衔接，把升级条件写进文档而不是靠感觉：数据逼近单机内存的七成、或峰值延迟开始被单点带宽限制，触发"单机走向集群"；核心业务可用性要求超过单机容错，触发"加副本与故障演练"；管理成本超过业务价值，触发"评估转托管"。反向降级同样值得写：业务收缩时把亿级集群缩回单机，省下的不只是钱。

图 6-2 从单机到集群的部署拓扑

容量规划：一个公式加两笔余量

向量库容量规划的主项是内存：内存约等于条数乘维度乘每维字节，再乘索引系数，再乘副本数。索引系数按第三章的结构算：图索引连边开销常在向量本身的四到六成，量化档位则小于一。两笔余量别省：增长余量按业务增速预留半年到一年的水位；运营余量为后台任务留地——合并、重建、迁移都要临时内存，水位打满的集群连重建都做不动。磁盘侧按"段文件加日志加快照"三笔算，日志保留窗口直接决定恢复能力，别为了省盘把窗口压到危险线。

监控清单：三类信号一次配齐

监控的价值在分层：性能指标告诉你快不快，健康度指标告诉你会不会坏，资源指标告诉你还剩多少余地。直接可抄的清单如下：

表里最容易被漏掉的是"召回代理指标"：延迟和错误率都正常，召回也可能在悄悄劣化（墓碑、分布漂移、模型错位都能干这事）。做法是内建一组带标准答案的探针查询，定时对线上实例发起，把命中率画进面板——这是 5.5 的方法在运维侧的直接复用，也是把"召回暗降"从用户投诉变成系统告警的关键一手。

告警要分级行动

指标配上阈值只是第一步，告警还得回答"响了之后做什么"。按响应方式分三级：紧急级（错误率抬升、副本全失、磁盘将满）直接呼叫值班，配套的应该是已验证的应急手册动作；警告级（P99 超预算、墓碑超限、合并滞后）进工单，二十四小时内有人分析趋势决定动作；观察级（水位缓涨、探针命中率缓降）只进报表，由周期评审消化。分级的好处是告警不再狼来了——紧急告警少而准，值班才敢睡觉；大量该进报表的指标挤进告警渠道，最终结局必然是全员屏蔽告警。给每条告警写清触发条件、检查动作与升级路径，这份文档与指标本身同等重要。

问题：单机容器形态要不要配监控？

要，且是全部形态里性价比最高的监控实践。单机形态的故障模式简单，一块面板（延迟、内存、磁盘、错误率四条曲线）就能覆盖八成问题；而这四条曲线的告警习惯一旦养成，升级到集群形态时只是指标变多、方法不变。反过来也成立：连单机都不配监控的团队，几乎不可能在集群形态下把监控做好。部署简化可以，可观测性不打折——这是从单机走向集群最重要的习惯迁移。

问题：托管服务的监控还用自己搭吗？

要，但要换位置。厂商控制台覆盖实例健康（CPU、存储、副本状态），你的面板应该聚焦业务视角：端到端延迟分位、按租户的查询量与错误、探针召回命中率、成本速率（查询单价随用量的变化）。两边的数据要能对时间轴——业务延迟抖动的时刻去厂商面板找实例事件，是托管排障的标准动作。另外把导出权限谈进合同：业务侧指标原始数据落在自己的监控体系里，迁移或争议时才有凭据。

容量规划的一个完整算例

把公式落到数字上最容易记牢。假设业务要求一年内支撑五千万条 768 维向量、单精度存储、图索引（连接度三十二，索引开销约为向量的五成）、副本两份：原始向量约一百四十 GB，索引开销加五成后约二百一十 GB，两副本翻倍到四百二十 GB，再加三成运营余量约五百五十 GB——这个数字要在三节点集群上跑，意味着每节点常驻内存约一百八十 GB。磁盘侧按段文件加十四天日志加每周快照算，通常是内存数字的一点五到两倍。这个算例里每一步的假设（维度、精度、索引系数、副本数、余量比例）都应替换成你自己的真实值——算例的价值不是给答案，而是展示从业务参数到采购清单的完整推导链，让容量评审会有账可查。

问题：多套业务共用一个集群时，监控要怎么隔离？

按租户与集合两个维度拆分指标，否则共享集群会变成责任黑洞。每个业务方看得到自己的延迟、查询量、错误率与配额水位，平台方看得到全局资源与邻居效应（某租户的突刺对其他租户的影响）。配额与限流联动监控：谁逼近配额、谁被限流，双方都要可见。这套分账体系最好在接入之初就谈好——事后向业务方解释"你的慢是他导致的"，没有按租户的曲线就没有说服力。

本节要点回顾

• 四种形态：嵌入式、单机容器、编排集群、云托管，靠触发器衔接而非感觉。
• 容量公式：条数乘维度乘字节乘索引系数乘副本数，增长与运营两笔余量别省。
• 监控分三层：性能、健康度、资源，健康度是性能变坏的前哨。
• 召回代理指标用定时探针实现，把召回暗降变成告警而非投诉。
• 磁盘侧按段、日志、快照三笔算，日志窗口决定恢复能力。

系统立起来了，最后一节补上底线：安全合规，以及一个完整的生产落地案例。