第15章：Dify 日常运维与故障排查

1. 项目背景凌晨 2 点，运维小陈被报警电话吵醒："AI 客服回复不了消息了！所有用户都在骂！"小陈打开 Dify 的控制台——「应用正常运行」——没有报错。但用户就是收不到回复。慌了手脚的小陈开始挨个容器重启：docker restart api, worker, web, nginx… 折腾了 20 分钟，故障自己消失了。第二天复盘，他发现日志里其实有明确的报错——“Redis connection timeout”——只是因为时间窗口太短，他没来得及看到。Dify 的日常运维看似简单（docker ps看状态，docker logs看日志），但真正出了问题，排查效率取决于你对服务拓扑和日志体系的理解。Dify 是典型的微服务架构——api、worker、db、redis、nginx、sandbox、weaviate——任何一个服务出问题都可能导致"AI 回复不了"。但具体是谁的问题？api 挂了？worker 队列堵了？Redis 连接满了？还是 Knowledge Base 向量数据库挂了？这需要一套系统化的排查思路。本章模拟了 5 种生产中最常见的故障场景：模型调用失败、知识库检索为空、Workflow 执行超时、配置语法错误导致启动失败、磁盘空间不足。针对每个故障，给出"现象 → 定位 → 根因 → 解决"的 SOP（标准操作流程），让你在凌晨 2 点被叫醒时，能 3 分钟内定位问题。2. 项目设计小胖：（顶着黑眼圈）“大师，昨天晚上 Dify 挂了 20 分钟，我到处重启容器，最后不知道怎么就自己好了