以下为本页可直接引用的结论要点，均来自正文对应章节的详细论证。
结论：100 人以内、资产量在十万级以下选单机或主从即可；需要高可用与横向扩容再上集群；已有私有云平台优先复用其存储与编排能力。选型的两个硬指标是「并发用户数」与「资产与向量数据总量」，其余因素（信创、等保、跨网段）只影响组件选型，不影响形态判断。
DravenAI 的内容资产、知识资产、应用资产与业务资产四大域共享同一套底座服务，因此形态选择本质是决定底座服务（网关、元数据、检索、对象存储、任务队列）是单副本还是多副本运行。下面给出四种形态的对比，数值为工程实践中的保守区间，实际以压测结果为准。
| 部署形态 | 适用规模 | 组件构成 | 可用性 | 扩容方式 | 运维复杂度 |
|---|---|---|---|---|---|
| 单机（All-in-One） | ≤50 并发、资产 ≤10 万条 | 全部服务部署于一台服务器，内置数据库与对象存储 | 无冗余，单机故障即中断 | 垂直扩容（加 CPU/内存/磁盘） | 低，1 人可维护 |
| 主从（应用与数据分离） | ≤200 并发、资产 ≤100 万条 | 应用节点 1 至 2 台 + 独立数据库主备 + 独立对象存储 | 数据库主备可切换，应用层需手工拉起 | 应用层可加节点，数据库垂直扩容 | 中，需懂数据库主从 |
| 集群（多副本 + 负载均衡） | 200 至 2000 并发、资产百万至千万级 | 应用节点 ≥3、数据库集群或云厂商托管实例、分布式检索与对象存储、负载均衡 | 单节点故障无感，支持滚动升级 | 横向加节点，支持在线扩容 | 较高，建议配套监控与专职运维 |
| 私有云（容器编排托管） | 规模弹性、需多租户或多套环境隔离 | 复用私有云的容器编排、分布式存储与服务网格，DravenAI 以容器镜像交付 | 依赖云平台自身的副本与自愈能力 | 调副本数与资源配额，分钟级 | 需云平台团队协作 |
并发低于 200 且没有严格的停机窗口约束时，集群带来的收益有限，却会引入分布式检索分片、会话共享、分布式锁三类新故障面。建议先用主从形态运行 1 至 2 个季度，积累真实负载数据后再决定是否升级。
不影响形态，但影响组件选型。信创场景下数据库替换为达梦、人大金仓或高斯等国产数据库，操作系统替换为国产服务器操作系统，中间件选用国产消息队列与缓存；部署形态仍按并发与数据量定档，只是把对应组件换成国产版本并做适配验证。
结论：按「并发每增加 100 人加 8 核 16 GB」的经验值做保守估算，磁盘按资产原始文件 2.5 倍预留（含向量、索引、缩略图与版本历史）。以下为推荐配置，低于下限会明显增加检索延迟与任务排队时间。
| 资源项 | 最低配置 | 推荐配置 | 说明与注意事项 |
|---|---|---|---|
| CPU | 8 核 | 16 核及以上 | 向量检索与文档解析为主要消耗点；开启知识图谱抽取时建议再增加 4 核 |
| 内存 | 32 GB | 64 GB 及以上 | 检索索引常驻内存，资产量百万级时预留不少于 32 GB 给检索服务 |
| 系统盘 | 200 GB SSD | 500 GB SSD | 仅放操作系统与应用，不要与数据盘混用 |
| 数据盘 | 1 TB | 按资产量 ×2.5 预留 | 建议使用独立挂载点，文件系统优先 XFS 或 ext4，避免使用网络盘作为数据库存储 |
| 网络 | 千兆 | 万兆（集群必选） | 集群节点间时延建议 ≤1 ms，跨机房部署会显著放大检索耗时 |
结论：优先选择长期支持版本，数据库优先使用客户已有机房运维能力的品种，避免为了「最优」引入无人会运维的组件。
支持主流 Linux 服务器发行版的长期支持版本（内核 4.19 及以上）与国产服务器操作系统；生产环境不建议使用桌面版与滚动更新发行版。需关闭 Swap 或对 Swap 使用倾向做限制，避免检索服务被换出。
支持开源关系型数据库与达梦、人大金仓、高斯等国产数据库；字符集统一使用 UTF-8，排序规则按中文习惯选择；连接池上限需与应用节点数联动计算，详见「关键配置项」一节。
缓存与消息队列用于削峰与异步任务（文档解析、向量化、图谱抽取）；对象存储可使用本地文件系统、网络文件系统或私有云对象存储。三者均需开启持久化，避免重启丢任务。
结论：管理后台与看板按现代浏览器 evergreen 版本支持，建议使用近两年内的 Chrome、Edge、Firefox 与国产主流浏览器的最新两个大版本，最低分辨率 1366×768。移动端支持查看与审批类操作，批量上传、图谱编辑与看板配置建议在桌面端完成。若客户内网仍在使用旧版浏览器，应在选型阶段明确，避免上线后大面积兼容性问题。
结论：清单共 12 项，全部通过才可进入安装环节；其中「时间同步」「文件句柄数」「磁盘 IOPS」三项最常被忽略，也是上线后故障的主要来源。建议由实施方与客户运维共同逐项签字确认。
结论：共六步——环境准备、依赖安装、初始化配置、服务启动、健康检查、验收交付。每步都有明确的产出物与准入条件，前一步未通过不进入下一步。以下命令为格式示例，占位值需替换为实际环境参数。
主机、网络、存储、账号就绪
运行时、数据库客户端、中间件
配置文件、数据库建表、管理员
服务拉起、开机自启、日志落盘
接口探活、链路连通、性能基线
功能验收、文档交接、回滚演练
创建运行用户与目录、挂载数据盘、配置时间同步与文件句柄数。产出一份由双方签字的《环境检查表》。
# 创建运行用户与目录（示例，路径按实际规划替换）
useradd -m -s /bin/bash draven
mkdir -p /data/draven/{app,storage,backup,logs}
chown -R draven:draven /data/draven
# 校验时间同步与文件句柄数
timedatectl status
ulimit -n安装运行时、数据库客户端、缓存与消息队列，并确认版本在支持列表内；信创环境需同步安装对应国产数据库的驱动与客户端工具。产出一份《依赖版本清单》，记录每个组件的名称、版本与安装路径。
# 安装依赖并校验版本（示例）
./scripts/install-deps.sh --offline --mirror /opt/pkgs
./scripts/check-deps.sh
# 输出示例：
# [OK] runtime : 21.x
# [OK] database : 已连通（国产数据库：达梦 / 人大金仓 / 高斯）
# [OK] cache : 已连通
# [OK] mq : 已连通这是全流程中最关键的一步，端口、存储路径、数据库连接串、管理员账号都在此确定。建议使用配置模板生成，避免手工编辑 YAML 缩进错误。数据库建表由迁移脚本完成，执行前必须确认已有全量备份。
# 由模板生成配置，随后按环境修改关键项
cp conf/application.example.yaml conf/application.yaml
vim conf/application.yaml
# 初始化数据库结构（执行前确认已备份）
./scripts/migrate.sh --target latest --dry-run # 先演练
./scripts/migrate.sh --target latest # 再执行
# 创建管理员账号（示例占位，口令按客户安全策略设置）
./scripts/create-admin.sh --user admin --email ops@example.com按「数据库与中间件 → 应用服务 → 网关」的顺序拉起，配置开机自启与进程守护。启动顺序错误是最常见的首次启动失败原因：应用会在数据库未就绪时反复重启并写满日志。
# 拉起服务并设置开机自启（示例）
systemctl enable --now draven-core
systemctl enable --now draven-gateway
systemctl status draven-core draven-gateway
# 实时观察启动日志，确认无 ERROR
journalctl -u draven-core -f结论：健康检查必须覆盖「进程存活、接口可用、依赖连通、性能基线」四层，只看进程存活是不够的。健康检查接口返回 200 且各依赖项为 up 才算通过。
# 探活与健康检查（域名与端口为示例占位）
curl -s -o /dev/null -w "%{http_code}\n" https://ai.example.com/health
curl -s https://ai.example.com/health/detail | head -40
# 预期输出中各依赖状态应为 up：
# {"status":"up","db":"up","cache":"up","mq":"up","storage":"up","search":"up"}按「部署后验证清单」逐项打勾，完成一次真实业务的端到端演练（上传资产 → 检索 → 问答 → 看板出数），并做一次回滚演练确认预案可用。交付物包括验收报告、配置文件副本、运维手册与紧急联系人清单。相关的角色与流程说明可参考 私有化部署服务 页面中的实施阶段划分。
结论：90% 的线上问题集中在五类配置——端口与域名、存储路径、数据库连接池、备份策略、日志级别。配置修改后需重启对应服务生效，禁止在运行中直接改数据库参数表绕过配置中心。
| 配置类别 | 典型配置项 | 建议取值 | 注意事项 |
|---|---|---|---|
| 端口与域名 | 网关端口、应用端口、内部通信端口 | 对外统一走 443，内部端口不暴露 | 内外网端口分离；修改后需同步更新防火墙与负载均衡配置 |
| 存储路径 | 资产存储目录、索引目录、临时目录 | 分别挂载独立子目录，临时目录单独限速 | 禁止把存储目录放在系统盘；迁移路径需走配置变更而非直接挪文件 |
| 数据库连接池 | 最大连接数、最小空闲、超时回收 | 单节点 20 至 50；总连接数 ≤ 数据库上限的 80% | 集群场景需按节点数折算，避免多节点叠加打满数据库连接 |
| 备份策略 | 全量周期、增量周期、保留份数、异地副本 | 全量每周 1 次，增量每日 1 次，保留 ≥3 份 | 备份必须做恢复演练；备份盘与数据盘物理隔离 |
| 日志级别 | 全局级别、模块级别、审计日志开关 | 生产默认 INFO，排障期临时 DEBUG 并在 24 小时内恢复 | DEBUG 会显著放大磁盘写入；审计日志独立存储且不可关闭 |
数据库的最大连接数是全局上限，集群每增加一个应用节点就线性增加一份连接占用。若单节点配置 50 而数据库上限 200，四节点即可打满，表现为偶发的「获取连接超时」。正确算法是：单节点上限 ≈（数据库最大连接数 × 0.8）÷ 应用节点数。
可以，但必须走标准变更流程：先停写、再迁移数据、改配置、校验一致性、恢复写入，禁止在运行中直接移动目录。资产量在百万级时，迁移耗时以小时计，需提前申请停机窗口并在变更单中写明回滚步骤。
结论：升级前必须完成「全量备份 + 配置差异比对 + 回滚演练」三件事，且只能在有停机窗口的时间段执行。回滚的唯一可靠依据是升级前的完整快照，而不是靠卸载新版本。
回滚分两级：应用级回滚（换回旧版本程序包，适用于无数据库结构变更的小版本升级，耗时约 10 至 30 分钟）与全量回滚（恢复数据库与资产快照，适用于含结构变更的大版本升级，耗时等于备份恢复时长）。全量回滚会丢失升级后新产生的数据，因此必须在回滚前导出增量数据并告知业务方。
结论：以下 15 项全部通过方可签署验收，任何一项失败都要回到对应步骤重做，不允许「先上线后补」。建议由客户方操作人员执行验证，实施方只做指导，以验证运维交接是否到位。
以下是实施现场最常遇到的 8 个问题，答案给出了可直接执行的判断与处理方式。
环境就绪的前提下，单机形态通常 0.5 至 1 个工作日，主从形态 1 至 2 个工作日，集群形态 3 至 5 个工作日（含联调与压测）。实际耗时主要取决于环境准备与账号审批，而不是安装本身，因此建议提前一周启动环境准备工作。可参考 私有化部署服务说明 规划实施排期。
可以，这是私有化部署的主要场景之一。离线部署需提前获取离线安装包与镜像仓库包，导入内网后按离线模式安装；许可激活采用离线授权文件方式。需要注意的是模型与词库等资源的离线更新需要走定期人工导入，应在运维手册中明确更新周期。
需要在初始化配置阶段指定数据库方言并加载对应驱动，迁移脚本会自动按方言生成表结构。上线前必须做三项验证：建表语句在目标库执行通过、分页与批量写入性能达标、备份工具支持该数据库。建议在与生产同版本的库上先做一次完整迁移演练。
按「网络 → 账号 → 驱动 → 字符集」四步排查：先用客户端工具从应用服务器直连数据库验证网络与账号，再检查驱动版本与数据库版本是否匹配，最后确认字符集与排序规则正确。多数情况下问题出在防火墙未放通或账号只有库级权限而无建表权限。
公共配置（数据库连接、存储路径、密钥、外部地址）必须一致，节点特有配置（节点 ID、监听地址、副本角色）必须不同。建议用同一份配置模板渲染，只替换节点变量，避免手工维护多份配置导致漂移。会话与文件需使用共享存储或集中式会话，否则会出现登录状态在节点间丢失。
按资产原始文件大小的 2.5 倍预留，其中包含向量数据、全文索引、缩略图、版本历史与日志。建议配置三层水位告警：70% 提示、85% 预警、95% 严重，并提前规划扩容或归档策略。历史版本与回收站是两大隐性占用源，需在运维手册中设定清理周期。
只要升级前完成了全量备份且备份校验通过，数据不会丢失，回滚后可恢复到升级前状态。风险在于含数据库结构变更的大版本升级：若迁移脚本执行到一半失败，需要按迁移工具记录的断点继续或回滚，因此必须保留迁移日志并禁止手工修改结构。
私有化部署的日常运维由客户方承担，实施方交付运维手册与培训；如需托管运维或驻场支持，可在服务合同中约定。建议客户方至少指定两名运维人员完成交接培训，并明确备份检查、证书到期、磁盘水位三项周期性任务的责任人。