资讯详情

资讯详情

Linux 命令 + AI 辅助排查:测试工程师实战指南

Linux 命令 AI 辅助排查测试工程师实战指南作者楠风测开 | 5 年测试工程师 | 上海 本文 3800 字 | 阅读 10 分钟 | 建议收藏 ⭐前言Day 7-10 我讲了 AI 工作流、Obsidian 第二大脑。进入 Linux 领域——测试工程师必备技能。我做测试 5 年前 3 年以前都要用 Linux服务部署在 Linux 上但遇到问题就懵服务挂了不知道怎么查日志满屏不知道看哪里性能慢不知道瓶颈在哪后来系统学了 Linux AI 辅助效率提升 10 倍。今天讲 3 件事30 个常用命令分组实战必备真实问题排查案例用命令查分析AI 辅助定位ChatGPT DeepSeek 两个工具实战一、基础篇30 个常用 Linux 命令测试工程师不需要像运维那么精通但30 个命令必须会。1. 文件操作6 个pwd # 当前目录 ls -la # 详细列表隐藏文件权限 ls -lh # 人类可读大小 cd /var/log # 绝对路径 cd ../logs # 相对路径 mkdir -p /opt/test/2024 # 递归创建目录 rm -rf /tmp/test # 强制递归删除3. 文件查看6 个cat # 一次性显示 less # 分页显示可搜索 head -n 20 # 前 20 行 tail -n 100 # 后 100 行 tail -F # 实时跟踪看日志变化 wc -l # 统计行数4. 关键字搜索4 个grep ERROR app.log # 关键字搜索 grep -i error app.log # 忽略大小写 grep -B 5 -A 5 error app.log # 显示前后 5 行 grep -c error app.log # 统计出现次数5. 进程查看5 个ps aux # 所有进程 ps aux --sort-%cpu | head # 按 CPU 排序 ps aux --sort-%rss | head # 按内存排序 pgrep -f java # 查找进程 kill -9 PID # 杀进程6. 系统监控5 个top / htop # 实时监控CPU/内存 free -h # 内存使用 df -h # 磁盘使用 du -sh /opt/test # 目录占用大小 iostat -x 1 # IO 监控7. 网络工具4 个netstat -tunlp # 端口监听 ss -tunlp # 端口监听新版 curl http://localhost:8080 # HTTP 请求 ping -c 4 www.baidu.com # 网络连通性二、理论篇脚本设计 3 原则写脚本前记住 3 个原则原则一通读跑一遍再上线 先在自己机器测试再上生产 原则二加 set -e 和错误处理 set -e # 任何命令失败就停止 trap echo Error at line $LINENO ERR 原则三加日志 exec /var/log/script.log 21 echo $(date %Y-%m-%d %H:%M:%S) - 开始三、实战篇 1真实问题排查案例场景服务响应慢怎么排查某天下午测试同事反馈接口响应很慢几秒才返回。下面是完整的排查过程真实可复用Step 1看系统整体状态# 先看 CPU 和内存 top # 看内存使用 free -h # 看磁盘避免磁盘满导致慢 df -h输出解读top 第一行load average: 5.20, 4.80, 4.50CPU 满载Step 2找最耗资源的进程# 按 CPU 排序找最耗 CPU 的进程 ps aux --sort-%cpu | head -10 # 输出可能看到 # USER PID %CPU %MEM COMMAND # root 1234 95.0 30.0 java -jar app.jar # → 进程 1234 占 CPU 95%Step 3看进程详情# 看进程详情 ls -la /proc/1234/ # 或用 jstack 看线程栈Java 应用 jstack 1234 | head -100 # 输出可能看到 # Thread-12 #12 daemon prio5 # → 某个线程卡住了Step 4查日志找原因# 查 ERROR 日志 tail -200 $LOG_DIR/app.log | grep ERROR # 查慢请求 grep slow /var/log/app.log | tail -20 # 查数据库慢查询 grep slow_query /var/log/mysql/mysql.logStep 5定位根因经过上面 5 步常见原因现象可能原因解决方案CPU 满载死循环/计算密集优化代码/扩容内存满内存泄漏dump 分析网络慢SQL 慢查询加索引磁盘 IO 高日志写太多异步写Step 6实时跟踪# 实时跟踪某个进程 top -p 1234 # 实时跟踪日志变化 tail -F /var/log/app/app.log | grep ERROR # 查看网络连接 netstat -an | grep ESTABLISHED | wc -l四、实战篇 2AI 辅助定位ChatGPT DeepSeek工具仅用 ChatGPT 和 DeepSeek 两个 AI 工具。4.1 用 ChatGPT 辅助排查场景Java 应用 OOMOutOfMemory异常Step 1把错误日志贴给 ChatGPT我的 Java 应用报错 java.lang.OutOfMemoryError: Java heap space at com.test.service.OrderService.createOrder(OrderService.java:42) at com.test.web.ApiController.handle(ApiController.java:28) 应用启动参数-Xmx512m -Xms256m 并发用户约 200 请帮我分析 1. 最可能的原因是什么 2. 给我一些排查命令 3. 推荐解决思路Step 2ChatGPT 回复可能原因 - 堆内存不够512M 偏小 - 内存泄漏推荐用 MAT 分析 heap dump - 大对象未释放 排查命令 # 1. 看 JVM 堆使用 jmap -heap 1234 # 2. 生成 heap dump jmap -dump:formatb,fileheap.bin 1234 # 3. 看 GC 情况 jstat -gc 1234 1000 解决思路 1. 提高堆内存-Xmx1024m -Xms512m 2. 用 MAT 工具分析 heap dump 3. 排查代码中的大对象Step 3执行 ChatGPT 提供的命令# 看堆内存配置 jmap -heap 1234 | grep MaxHeap # 看 GC 情况 jstat -gc 1234 1000 | head # 输出发现 Old Gen 占用 95%确认内存不足Step 4让 ChatGPT 解读结果我的 jstat 输出 S0C S1C S0U S1U EC EU OC OU PC PU 10752K 10752K 0K 0K 65536K 16384K 174784K 166785K ... Old Gen 已用 166M / 175M95%Full GC 频繁 请帮我 1. 这种情况说明什么 2. 推荐的最优配置是什么 3. 除了改内存还有什么优化ChatGPT 回复这种情况说明 - Old Gen 内存紧张频繁 Full GC - 应用存在大对象或内存泄漏 - 堆内存设置偏小 推荐配置 -Xmx2048m -Xms1024m -XX:NewRatio2 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/tmp/dump 其他优化 1. 用 MAT 分析 heap dump 2. 优化 SQL避免大结果集 3. 用缓存代替重复查询 4. 及时关闭资源4.2 用 DeepSeek 辅助排查场景性能突然下降 50%找根因。Step 1DeepSeek 用中文对话更符合国内习惯我的应用性能监控显示 - CPU 使用率昨天 30%今天 80% - 接口响应时间昨天 100ms今天 500ms - 数据库连接池昨天 50%今天 95% 应用最近 1 天有 2 次发布 1. 中午 12 点缓存策略调整 2. 下午 4 点数据库索引优化 请帮我分析 1. 哪个发布最可能导致性能下降 2. 给我具体排查命令 3. 如何快速验证猜测DeepSeek 回复最可能下午 4 点的数据库索引优化 原因 - 索引优化可能导致索引失效或选错索引 - 数据库连接池占用 95% 暗示 SQL 执行慢 快速排查命令 # 1. 看慢查询日志 grep slow_query /var/log/mysql/slow.log | wc -l # 2. 看当前执行的 SQL SHOW PROCESSLIST; # 3. 看索引使用情况 EXPLAIN SELECT * FROM orders WHERE ...; # 4. 对比昨天和今天的慢查询数 diff (grep slow /var/log/mysql/slow.log.1) \ (grep slow /var/log/mysql/slow.log)Step 2执行命令验证# 看今天的慢查询数量 grep slow_query /var/log/mysql/slow.log | wc -l # 输出532昨天只有 89 # 看现在执行的 SQL mysql -e SHOW PROCESSLIST; # 发现有 5 个慢查询卡在 orders 表Step 3让 DeepSeek 解读我查到了 - 今天慢查询 532 条昨天 89 条 - 当前有 5 个慢查询卡在 orders 表 请帮我 1. 索引优化的常见错误是什么 2. 如何快速修复回滚 vs 优化 SQL 3. 怎么避免类似问题DeepSeek 回复索引优化常见错误 1. 删了被查询依赖的索引 2. 改了索引但没看执行计划 3. 索引顺序错误联合索引顺序 4. 函数导致索引失效 快速修复方案 1. 立即回滚索引如果有备份 2. 或用 EXPLAIN 找问题索引 3. 重写有问题的 SQL 避免方法 1. 索引变更前备份 2. 上线前用 EXPLAIN 验证 3. 灰度发布 4. 加监控告警五、AI 工具对比什么时候用哪个工具优势场景ChatGPT英文技术强、回答详细国际框架、Java/Python 调试DeepSeek中文友好、推理强国内场景、业务逻辑分析实战技巧ChatGPT 适合 - Java/Python 报错信息 - 国际技术框架问题 - 深度技术解释 DeepSeek 适合 - 中文业务场景 - 复杂逻辑分析 - 长篇代码 review六、真实数据AI 辅助排查效果我做 AI 辅助排查半年传统方式30 分钟查一个问题 AI 辅助1 小时5 分钟 AI 提问 25 分钟执行 提效2 倍但成功率提升 50% 关键AI 提供思路 命令我执行 验证关键认知AI 提供思路 命令我执行 验证不是 AI 替代排查而是AI 加速排查。七、30 个命令速查表保存用 文件操作pwd / ls / cd / mkdir / rm / find 文件查看cat / less / head / tail / grep / wc ⚙️ 进程管理ps / kill / pgrep / pkill / nohup 系统监控top / htop / free / df / du / iostat 网络工具netstat / ss / curl / ping 关键字搜索grep / grep -i / grep -B -A / grep -c 权限用户chmod / chown / sudo ⏰ 进程监控top -p / tail -F / nohup 杂项history / alias / man八、写在最后测试工程师的 Linux 能力做了 5 年测试我最大的感受是——测试工程师不懂 Linux 是短板。今天学 5 个 Linux 命令top/free/df/ps/tail 本周每周用 1 次 AI 辅助排查先 ChatGPT 90 天积累 30 个命令 10 个真实案例1 年后回头看你的 Linux 能力会从 0 到 60。下期预告Day 12Linux 日志分析 AI 智能诊断 - 日志位置 类型 - 5 款 AI 工具实战演示 - 真实日志排查案例如果这篇文章对你有帮助点赞 收藏建议收藏评论区告诉我你最常遇到的 Linux 问题转发给同样怕 Linux 的测试同事全文 3800 字 | 阅读 10 分钟 | 建议收藏【原创声明】本文为楠风测开原创转载请联系作者授权。
觉得有用,分享给同行:

为您的企业打造数字门面

稳重轻奢商务风格,端正雅致视觉,长效耐看不易过时。

立即咨询 →