DeepSeek：运维怎么用？脚本与排障

运维借助 DeepSeek 这类模型，能省时间的只有两块：写一次性脚本，和把排障思路列全。前者省敲键盘的时间，后者省漏查的代价。两块都有同一个前提——你给的输入足够具体，它给的输出你逐行看过。

脚本先要只打印的版本

让模型写批量操作脚本，头一版一律要求「只打印将要执行的动作，不实际执行」。看输出里的路径、文件名、目标主机对不对，再改成真正执行。这一步花两分钟，能挡掉大部分误删。

三个必问：操作范围是否精确到具体对象、失败时是中断还是继续、有没有可回滚的动作。范围写成通配符的，要求它先把匹配结果列出来确认，再执行。

一个细节：让它把「预计影响多少条记录」也打印出来。数字和你预期差一个量级，说明匹配条件写错了，这时候停手比调试划算。

能用的脚本长什么样

可用的运维脚本有几个特征：开头声明失败即退出、关键变量集中在顶部、每条危险命令前有回显、结束时输出结果摘要。按这个结构提要求，比只说「写个脚本删掉七天前的日志」安全得多。

工具自带的预演能力优先用。rsync 的 -n、kubectl 的 --dry-run、包管理器的模拟安装，都是现成的保险，比在提示词里反复叮嘱有效。

脚本里不要出现明文口令。需要凭据时从环境变量或密钥管理服务读取，把这一条写进提示词，它会照做；不写，它经常直接给你一个带密码的示例。

排障要清单，不要结论

把现象写清楚：报错原文、涉及服务、开始时间、最近变更、影响范围。让它按可能性排序列检查项，每项写清查什么、看到什么算正常、看到什么算异常。它的价值是不漏项——人在压力下容易只盯一个方向。

别问「这是什么原因」，问「按可能性从高到低列出八个检查点」。前者给你一个猜测，后者给你一张能逐条划掉的单子。

时间点要对齐时区。日志时间和你说的时间差八小时，整条排查线都会跑偏，提问时顺手写明「时间为北京时间」。

这类需要多步推理的任务，可以开深度思考模式，让它把推理过程摊开；只是写一段脚本或改一行配置，普通模式更快。

上线前的两道闸

头一道是环境闸：脚本先在测试或预发跑一轮，观察完再上生产。第二道是人眼闸：涉及删除、批量改配置、重启核心服务的命令，逐行读参数，特别是路径末尾的斜杠、通配符、--force 这类开关。

变更留痕不要省。执行时间、执行人、脚本内容、影响范围、回滚方式，写进变更记录。出事时这份记录决定你多久能定位。

回滚方案要在执行前写，不是出事时想。删了文件再找恢复手段，通常已经晚了。

五类故障的处理对照

它做不到什么

它看不到你的监控面板、日志平台和网络拓扑。你说「接口变慢」，它只能给通用方向，给不出「这台机器连接数打满」这种结论。真正的定位靠指标和日志，模型负责把检查顺序排好。

它给的命令参数可能记错版本差异。同一个工具在不同发行版里参数名不一样，systemd、iptables、kubectl 都有这种情况。执行前用 --help 核一遍，别直接粘贴。

它也不替你做容量规划和架构决策。要它算「加两台机器够不够」，先得把 QPS、单机承载、余量要求告诉它，否则得到的是一个看起来合理的数字。

还有一条底线：生产凭据不外传。密钥、令牌、连接串、内网地址，都不要贴进对话；需要它理解结构时，用占位符替换。

三条不能碰的线

运维使用红线

• 生产凭据、连接串、内网地址不上传
• 删除、批量修改、重启核心服务，命令人工审一遍
• 脚本与手工操作都留痕：时间、内容、执行人
• 没有回滚方案的变更，不上生产

三个容易被追问的细节

• 脚本里带 rm -rf 或 --force，怎么处理？：先删掉这类命令再评估必要性。确有需要时把目标路径写死、去掉通配符、加一次确认，并在预发环境跑一遍。让它逐行解释会删什么，比自己猜快。
• 排障清单太长，先做哪几步？：挑改动小、信息量大的先做：看时间点前后的变更、看错误率曲线、看依赖健康状态。三步没有方向，再往深处查。
• 怎么把排查经验留下来？：每次故障后把现象、检查项、结论写成固定三栏，攒进团队共享知识库。下次遇到同类现象，先查库再问模型，能省一轮试探。

同一条排障线索往往跨好几个会话，把关键结论写进标题里，配合历史记录的搜索与导出，回头找得到当时的判断依据。