夜雨聆风先说我为什么干这事
做运维的谁没攒过一堆文档：故障处理记录、部署手册、监控配置说明、网络拓扑图。微信收藏夹、有道云笔记、Confluence、本地Markdown，散落得到处都是。
每次出问题，第一反应是百度/谷歌，查了一圈发现这个问题以前处理过。于是再去翻文档，翻半天找不到在哪。
我之前统计过，同样的Nginx配置问题，我至少查了5次文档才记住。不是记性差，是文档散落在不同的地方，每次都要重新找。
后来我想了个办法：把这些文档全部喂给AI，让它替我记、替我查。
选什么工具
方案对比了一圈，我选了Dify。
Dify是一个开源的LLMOps平台，通俗讲就是帮你把大模型接上自己的数据和工具。2026年这项目在GitHub上已经50k+ Stars，社区很活跃，中文支持也好。
为什么不用LangChain？那玩意对普通运维来说太底层了，啥都要自己写代码。Dify有可视化界面，拖拽就能搭一个AI应用，门槛低很多。
也有其他选择：FastGPT（国产，知识库做得好）、MaxKB（专注于知识库）、AnythingLLM。但Dify功能最全，既能做RAG（检索增强生成，就是把文档切成片段存向量库，查的时候匹配最相关的片段给AI），又能做Agent和Workflow，以后扩展空间大。
装一个Dify
Dify官方推荐用Docker Compose部署，一行命令搞定：
git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d等几分钟，访问 http://your-server:3000 就能看到登录页了。
配置要求： 2核4G起步，4核8G比较舒服。我跑在一台4C8G的云服务器上，同时跑Dify + Ollama也没问题。
登录后第一步要做两件事：接模型、接知识库。
第一步：把大模型接上
Dify本身不跑模型，它通过API调用外部的LLM。有两种方案：
方案A：用云API（推荐新手）
注册DeepSeek或者硅基流动的API，在Dify的设置里填上API Key。DeepSeek的API价格很便宜，百万token（约75万字）只要几毛钱，查文档这种场景一个月花不了两块钱。
配置路径：设置 > 模型供应商 > DeepSeek，填API Key，选择deepseek-chat模型。
方案B：用本地模型（省钱但需要GPU）
在服务器上装Ollama，拉一个Qwen2.5或者DeepSeek的量化模型：
curl -fsSL https://ollama.com/install.sh | sh
ollama pull qwen2.5:7b然后在Dify里配置Ollama作为模型供应商，填上 http://your-server:11434 就行了。
我自己先用云API跑通了流程，后来才切换到本地模型。建议你也先云API上手，省去折腾GPU的时间。
第二步：建知识库
这是最核心的一步。
点"知识库" > "创建知识库"，上传文档。Dify支持的格式很全：PDF、TXT、Markdown、HTML、甚至网页链接。
我把这些文档扔了进去：
- ·/etc/nginx/ 下的所有配置文件和注释
- ·自己写的运维手册（大概30篇Markdown）
- ·过去一年处理过的故障记录（按时间+症状+原因+解决方案格式写的）
- ·MySQL、Redis、ES的配置最佳实践
- ·团队内部Wiki导出
Dify会自动把文档切成小片段（chunk），默认每段500个token，然后做向量化（把文字转成数学向量，方便搜索匹配），存入内置的向量数据库。
这里有个要点：文档质量决定知识库质量。如果你的文档写得像天书，AI也看不懂。我在上传之前花了半天把关键文档重新梳理了一遍，加了清晰的标题和分段，效果比直接扔进去好很多。
问它几个问题试试
知识库建好之后，创建一个AI应用。在Dify里选择"文本生成"或者"对话型应用"，关联刚才建的知识库。
然后我试了几个问题：
我：Nginx返回502怎么排查？
AI的回答（基于我上传的故障记录和Nginx配置）：
Nginx 502 Bad Gateway的一般排查步骤：
1. 先查后端服务是否存活：systemctl status php-fpm（或你的后端服务）
2. 查看Nginx错误日志：tail -100 /var/log/nginx/error.log
3. 如果是PHP应用，检查php-fpm进程数和超时配置
4. 检查后端端口是否被占用或防火墙拦截
5. 根据历史记录，你上次遇到类似问题是因为php-fpm的pm.max_children设置太小
要我把具体的排查脚本发给你吗？问完之后确实感觉不一样。以前我是去翻那个存了半年没打开的Wiki页面，现在直接问AI，它把我分散在各个文档里的内容整合成了规范的回答。
我：MySQL磁盘快满了，怎么安全清理？
AI的回答直接定位到我的故障记录：
根据2025年11月的故障记录，你上次处理过类似问题：
1. 先查binlog：SHOW BINARY LOGS; 确认空间占用
2. 安全清理7天前的binlog：PURGE BINARY LOGS BEFORE DATE(NOW() - INTERVAL 7 DAY);
3. 查慢查询日志和general_log是否开启占用空间
4. 查performance_schema和mysql库的大小
5. 不要直接用rm删binlog文件，要用SQL命令清理这些内容分别来自我不同时期的故障记录和MySQL配置笔记，AI把它们拼起来了。而且最后的提醒"不要直接用rm删"是我踩过的坑，能记住这个说明AI确实理解了上下文。
进阶：让AI不仅能查，还能动手
纯知识库只能回答问题，但运维很多时候需要AI动手干活。Dify的Agent功能可以做到。
我在Dify里给AI配了几个工具：
1. SQL执行器：连到只读从库，可以查数据库
2. Shell执行器：通过SSH在服务器上跑命令（限制了白名单）
3. 文件读取：读服务器上的日志和配置文件
配置好之后，AI就不是光说不练了：
我：帮我查一下生产库最近有没有慢查询
AI先调用SQL执行器查 SHOW FULL PROCESSLIST 和慢查询日志，发现有两条SQL执行超过3秒。基于知识库里的优化建议，给出了加索引和改写SQL的方案。
整个过程我没碰过数据库一次。
不过这里我要强调：让AI操作生产环境之前，一定要经过人工确认。Dify有"对话前审核"功能，AI的每一步操作都会生成预览，你确认之后才实际执行。生产环境务必打开这个开关。
踩过的几个坑
文档切分策略很重要。 默认500 token一段对于技术文档偏小了，一个完整的步骤可能会被切成两段导致AI理解不全。我改成了1000 token，重叠度设了200 token（重叠是为了保证上下文不丢失），效果好很多。
向量模型选择。 Dify内置了好几种向量化模型，中文场景建议用text-embedding-v3或者bge-large-zh，英文文档多的可以用OpenAI的embedding。选错了向量模型，搜索精度能差20%以上。
文档要持续维护。 知识库不是搭好就不管了。每次处理完故障，我把记录追加到文档里，重新上传更新。时间越久，知识库越值钱。
Dify本身的维护。 Dify依赖PostgreSQL和Redis，偶尔需要备份数据库。建议把Dify的Docker Compose纳入你的日常备份策略。
投入产出比
搭这个知识库花了一天时间（装Dify+整理文档+配置调试），之后每周大概花半小时更新文档。
效果呢？原来查一个问题的平均耗时从15分钟降到2分钟。小组里4个人都在用，不再有人问"那个文档在哪"了。
安全提醒： 不要往知识库上传包含密码、密钥的文档。不要在知识库里放敏感业务数据。Dify建议配置访问权限，知识库只对运维团队开放。
最后，Dify的官网和GitHub地址搜一下就有。别光看，动手搭一个试试，一两个小时就能跑起来。
E N D
运维少年 · 科技观察
