运维
运维 FAQ 优先回答“环境已经搭起来了，但为什么还跑不稳”和“出问题时先查哪一层”这两类高频问题。
Q: 平台容器已经启动了，但应用发布或运行失败，先查什么？
优先按下面顺序检查：
- Docker Engine API 是否可达。
- 开发平台是否拿到了正确的
HOST_WORKSPACE_PATH。 workspace目录是否真实存在、可持久化、可被平台和运行容器共同访问。ouroboros-mothership基座镜像是否已经准备好，且版本与当前平台匹配。- 平台日志里是否已经出现容器创建、镜像拉取或工作区挂载相关错误。
如果你当前还在安装阶段，先回看 安装与初始化 和 环境要求。
Q: 平台能打开，但关键开发入口一进去就报错，先查数据库还是 RabbitMQ？
两个都要查，但建议顺序是：
- 先看平台服务日志有没有持续报错。
- 再确认数据库连接是否正常。
- 再确认 RabbitMQ 是否可用。
- 最后再看最近是否改过初始化配置、环境变量或镜像版本。
原因很简单：开发入口报错不一定是页面问题，很多时候是平台启动后某个关键依赖没有真正准备好。
如果你想看更系统的排障顺序，继续看 备份、监控与排障。
Q: 升级前最少应该备份什么，才算有回滚基础？
至少不要只备份数据库。
建议最少保留下面几类内容：
- 数据库备份
- 平台配置、环境变量和外部连接参数
- 上传文件、附件或文档类持久化目录
- 镜像标签、部署脚本和发布清单
- 升级前的执行记录与验证记录
如果这些内容没有一起保留，即便数据库能恢复，很多环境也很难真正回到“可运行”状态。
平台自身的变更见 平台升级与回滚；业务应用变更见 业务应用发布与回退。
Q: 页面访问正常，但定时任务、消息消费或实时推送异常，先查哪里？
不要只盯着页面本身，建议先判断是哪条运行链路出了问题：
- 定时任务没跑：优先查调度链路
- 异步处理不推进：优先查消息链路
- 页面在线但状态不刷新：优先查实时连接链路
如果是消息链路，RabbitMQ 正常不代表整条链路正常，还要继续看绑定加载、消费者装配和运行时接入。
如果是实时链路，除了 WebSocket 服务本身，还要继续看反向代理、鉴权和订阅路径。当前默认 WebSocket 入口是 /websocket/stomp。
专项排查路径请看 任务、消息与实时链路维护。
Q: 排障时应该先看平台服务日志，还是业务日志？
这两个日志解决的问题不同：
- 平台服务日志：更适合查启动失败、依赖连接异常、容器和运行时错误
- 业务日志：更适合查“谁在什么时候对哪个业务对象做了什么”
如果你面对的是“系统为什么起不来”“依赖为什么连不上”，先看平台服务日志。
如果你面对的是“这次操作是谁做的、结果如何、影响了什么对象”，先看业务日志。
更完整的说明，请看 业务日志与审计回溯。
Q: 我什么时候该回 FAQ，什么时候该直接进运维主线文档？
- 你已经有明确症状，但还不知道先查哪里：先看 FAQ
- 你正在设计环境、安装、升级、备份和长期维护流程：直接进 运维管理
如果你需要先盘点平台有哪些会影响部署方案的能力，也可以先看 平台能力地图。