自建 GEO 平台（六）：部署与运维，让它稳定跑下去

直接回答：这类平台的运维压力比想象中小，一台小机器加一批定时任务就能长期跑。真正需要提前想清楚的是三件事：成本是否可预测、备份能不能真的恢复、出问题时看不看得见。前两条决定它能不能活着，第三条决定它能不能被修好。

单机跑得动，不必上集群

常见的过度设计是：一开始就上容器编排、消息队列、分布式调度。对个人或小团队的自用平台，这些都是负担而不是能力。

实际构成可以很简单：

选型理由在《自建 GEO 平台（一）：整体架构与技术选型》里已经说明过：**数据量决定架构，而不是反过来。**几万篇以内的内容规模，单机加索引就能支撑。

什么时候该考虑扩容？两个信号：查询明显变慢（而不是变复杂），或者采集任务在一个周期内跑不完。在这两个信号出现之前，扩容都是浪费。

成本要能预测，关键在控制三类调用

这类平台的成本结构比服务器费用更值得关注：

最容易被忽略的是模型调用。监测功能如果每次采样都把同一批问题重跑一遍，成本会随时间线性上升。可行的做法是记录每次采样的原始答案，分析时读历史记录，而不是重新调用。

一个实用的习惯：每周记录一次当周的实际支出。成本失控往往是渐变而不是突发的，有记录才能在趋势变陡时及时发现。

备份的关键是"能恢复"，而不是"有备份"

这条说起来像常识，但真正验证过恢复流程的人很少。

需要备份的内容分三类：

• 关系数据：文章、片段、采样记录、任务状态
• 向量数据：与片段对应的向量
• 配置：连接信息、问题集、采集规则

两个要点：

**第一，正文和向量要一起备份。**只备份正文的话，恢复时需要重新调用模型把所有向量算一遍——恢复时间与恢复成本都会成倍上升，这在真正出事的那天会非常难受。

**第二，定期做一次真正的恢复演练。**把备份恢复到一台临时实例上，确认数据完整。没有验证过的备份不算备份，它只是一个你希望有用的文件。

1
2
3
4
5
6

# 结构 + 数据一起导出，包含向量列
pg_dump -Fc -f geo-$(date +%F).dump geo_platform

# 恢复演练（在临时库上做，不要碰生产库）
createdb geo_restore_test
pg_restore -d geo_restore_test geo-2026-09-17.dump

可观测性：先让失败能被看见

这类平台最常见的故障模式是静默失败：任务挂了，但没有报错，只是数据不再更新。

三个最小手段：

**状态表统计。**时刻知道各状态的条数，异常一眼可见：

1
2

SELECT status, COUNT(*) FROM crawl_tasks GROUP BY status;
-- 期望：pending 有少量、failed 接近 0

failed 持续增长、或者 pending 堆积不下降，都是需要处理的信号。

**关键时间戳。**记录"最后一次成功采集时间""最后一次成功采样时间"。如果超过两个周期没更新，说明出了问题——这比任何日志告警都直观。

**日志轮转。**采集日志会稳定增长，不轮转迟早写满磁盘。用系统自带的 logrotate 就够。

换模型意味着重建索引，这件事要提前知道

这是这类平台的一个结构性约束：向量与生成它的模型绑定。

换用另一个向量模型后，旧向量在新模型的语义空间里没有意义，不能混用，只能全量重算。维度不同的话还要改表结构。

所以有两个建议：

• 把向量模型名称和版本记在数据库里，避免以后分不清索引是哪一版生成的
• 把重建当作计划内操作：选一个流量低的时段，保留旧索引直到新索引可用

重建的成本与平台规模直接相关，这也是为什么增量更新做得越细，长期越省事。

一份可以照着走的运维清单

清单不长，但关键在于固定周期执行——这类平台的故障几乎都是"很久没人看"造成的。

常见问题（FAQ）

一定要用云主机吗？

不一定，但建议用。这类任务需要长期在线、定时执行，家用环境在断网、断电、IP 变动上都会带来额外麻烦。成本上，一台低配云主机的费用通常远低于你自己维护稳定性的时间成本。

数据库和服务放在同一台机器上安全吗？

对自用平台来说足够。注意两点即可：数据库不要对公网暴露端口，只监听本地或内网；定期把备份文件同步到机器之外，避免主机故障导致数据全丢。

采集任务失败了要不要立即重试？

不要立即重试。多数失败是暂时性的（目标站点超时、限速），立即重试反而会加重对方压力并触发更严格的限制。建议退避重试：失败后等一段时间再试，连续失败超过阈值就标记为失败并记录下来，人工确认原因。

平台长时间不用，需要停机吗？

如果只是暂停内容更新，采集任务可以停，但备份不要停。数据是长期积累出来的资产，停掉备份意味着一次意外就可能失去全部历史记录。存储成本通常很低，不值得为省这点开销冒风险。

小结

• 单机加定时任务足以支撑自用平台，扩容要等信号出现。
• 成本控制的关键是向量化、模型调用和存储三处，尤其要避免重复调用。
• 正文与向量要一起备份，并且定期做真实的恢复演练。
• 静默失败是主要风险，用状态统计和最后成功时间戳发现它。
• 换向量模型必须重建索引，提前记录模型版本并把它当作计划内操作。

本系列的其余几篇：整体架构与技术选型、内容采集与结构化流水线、AI 收录监测与效果度量、把检测数据变成一份能读的报告、增量更新。如果你的运维方式更省事，欢迎到留言板交流。