基础运维操作手册：服务重启顺序、日志位置、常见报错代码对照表

合作伙伴培训里，运维手册的目标不是让每个人都会改代码，而是至少知道“问题在哪看、服务怎么重启、异常怎么分层”。

这篇内容虽然很大一部分属于交付经验，但也并不是完全没有公开依据。官方 Compose 与自部署文档已经明确给出了服务名称和基本运行方式，因此“看哪些日志、重启哪些服务”至少可以建立在公开服务结构之上；而社区文章则补充了升级后 Weaviate 报错、Internal Server Error、500 错误等一线排障案例。

一、从公开资料能确认的运维抓手

1. 先识别服务角色，再谈重启顺序

官方文档已经公开列出 api、worker、worker_beat、web、plugin_daemon、sandbox、db_postgres、redis 等服务，因此基础运维培训首先要让学员建立“故障现象对应哪类服务”的心智模型。

2. Compose 与 Kubernetes 的日志查看路径是公开可确认的

对于 Compose，可以直接走 docker compose logs <service>；对于 Kubernetes，则是 kubectl logs、deployment 与 pod 级排查。这些是培训里最基础也最实用的动作。

3. 社区公开文章已经能覆盖一部分典型错误

例如 Weaviate 版本不兼容、Azure VM 上的 Internal Server Error、知识管道导致的异常等，都说明 Dify 运维问题往往分布在依赖组件、版本升级和文件处理链路上。

二、重启顺序建议

如果只是前端异常，不要全量重启。建议按影响面最小原则处理：

• 单服务重启
• 依赖服务检查
• 最后才做整套重启

三、日志位置

• Docker Compose：docker compose logs <service>
• Kubernetes：kubectl logs deployment/<name> 或 pod 级日志
• 重点查看 api、worker、enterprise、sandbox

四、常见报错分层

• 认证 / 权限错误
• 数据库连接错误
• Redis / 队列错误
• 对象存储错误
• 向量库检索错误
• 外部模型 Provider 错误

五、建议补充

若你们内部已有常见错误码对照表，建议后续直接补在本文件；公开资料通常不会把交付现场的报错经验写得这么全。

公开资料线索

note.com

• 【保存版・初心者OK】月1万円→1,000円台に。Difyとn8nを1台のVPSで動かす完全ガイド｜SSL対応＆トラブル解決付き | https://note.com/ai_restart/n/nd882767068c6

zenn.dev / 官方文档 / 其他公开页面

• Docker ComposeでDifyをデプロイする | https://docs.dify.ai/ja/self-host/quick-start/docker-compose
• 【Dify】アプデで「Weaviate 1.19 is not supported」が出た時の … | https://zenn.dev/kotap/articles/ea3b5995b8ba44
• Azure VM上のDify「Internal Server Error」の原因と対処 | https://zenn.dev/ytksato/articles/6cb73e68a568e6

这篇当前能从公开资料确认的有效信息

• 基础运维首先要建立服务角色与故障现象之间的对应关系
• Compose 与 Kubernetes 的日志查看路径是公开明确的
• 社区已经沉淀了一部分升级报错、500 错误、依赖组件异常等一线案例