组织维护
如果你的 OPL 数据空间 部署启用了组织，那么维护工作不只是保证可用性，还包括在迁移、扩缩容和恢复系统时持续守住租户边界。
上线前需要复核什么
在启用或扩大组织化使用范围之前，请确认：
- 注册路由 已经配置了有效的落地组织
- 运维管理员 理解“选中的组织”和 Global 作用域之间的差异
- 文件存储 与 向量检索 的部署模式适合多组织数据
- 恢复流程 已经覆盖失败迁移、待同步状态和失效资源
关键维护关注点
落地组织
新用户创建流程应始终能解析到一个有效的归属组织。
- 从单工作区升级而来的实例，通常会先引导到一个默认组织
- 每次配置或迁移变更后，都应重新检查注册与 SSO 流程
- 如果落地组织缺失或被停用，系统应该明确失败，而不是创建损坏用户
可执行的检查项：
- 确认落地组织仍处于启用状态。
- 在调整组织默认值后，至少测 试一次新注册或 SSO 下发。
- 在扩大上线范围前，先确认新账号是否落到了预期归属组织。
向量与检索维护
如果部署依赖 RAG，这一块需要格外谨慎：
- 组织感知检索依赖正确的租户元数据
- 维护上线时应避免继续提供陈旧或只迁移了一半的向量载荷
- Qdrant 和其他外部向量后端，应该与整体扩缩容方案一起评估
另请参考：
如果本次变更对 RAG 很敏感，建议按下面顺序推进：
- 暂停租户迁移或大规模文档搬迁。
- 确认所有副本都能访问且向量后端处于健康状态。
- 完成向量存储所需的任何租户元数据迁移。
- 恢复流量前，再验证一次同组织查询和一次跨组织拒绝路径。
文件归属与修复
上传文件、生成产物以及派生出的知识资产，都应被视为带租户属性的运维数据。
如果你正在迁移存储布局，或者把用户移动到其他组织，请事先写清楚：
- 迁移后如何验证文件仍可访问
- 在你的环境里，“待修复”到底意味着什么
- 谁负责处理失败的组织同步
需要修复时，建议这样处理：
- 先解决文件存储同步中的 pending 状态。
- 再解决向量归属同步中的 pending 状态。
- 之后重新测试受影响组织里的上传、知识检索和共享聊天附件。
不要把“用户能成功登录”误判为“租户迁移一定已经干净完成”。
运维检查清单
- 在重大升级前确认组织结构
- 在调整 provider 或功能策略前，重新确认全局与组织级设置的边界
- 在多副本环境里谨慎执行维护上线
- 为失败同步、损坏文件和 RAG 漂移保留清晰的恢复路径
- 每次上线后都显式测试选中组织作用域下的管理页面
- 对每个受影响租户至少验证一条用户路径和一条管理员路径