楠风测开复习日记 Day11

Linux 命令 + AI 辅助排查（测试工程师实战）

🐧 30 个命令 + 真实排查 + ChatGPT/DeepSeek 实战 👉 Day 11 / 90 天 ⏱️ 阅读 10 分钟 | 建议收藏 ⭐

👋 朋友们好，我是楠风

Day 8-10 我讲了 AI 工作流、Obsidian 第二大脑。

今天进入 Linux——测试工程师必备技能。

我做测试 5 年，前 3 年以前都要用 Linux（服务部署在 Linux 上），但遇到问题就懵：

❌ 服务挂了不知道怎么查 ❌ 日志满屏不知道看哪里 ❌ 性能慢不知道瓶颈在哪

后来系统学了 Linux + AI 辅助，效率提升 10 倍。

今天讲 3 件事：

1. 📚 30 个常用命令（分组实战）
2. 🛠️ 真实问题排查（服务响应慢）
3. 🤖 AI 辅助定位（ChatGPT + DeepSeek）

📚 基础篇：30 个常用 Linux 命令

测试工程师不需要像运维那么精通，但 30 个命令必须会。

📁 文件操作（6 个）

pwd# 当前目录
ls -la                                       # 详细列表（隐藏文件+权限）
ls -lh                                       # 人类可读大小
cd /var/log                                  # 绝对路径
mkdir -p /opt/test/2024                     # 递归创建目录
rm -rf /tmp/test                             # 强制递归删除

📄 文件查看（6 个）

cat# 一次性显示
less                      # 分页显示（可搜索）
head -n 20               # 前 20 行
tail -n 100              # 后 100 行
tail -F                   # 实时跟踪（看日志变化）
wc -l                     # 统计行数

🔍 关键字搜索（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 个）

ps aux                                   # 所有进程
ps aux --sort=-%cpu | head# 按 CPU 排序
ps aux --sort=-%rss | head# 按内存排序
pgrep -f "java"# 查找进程
kill -9 PID                              # 杀进程

📊 系统监控（5 个）

top / htop                  # 实时监控（CPU/内存）
free -h                     # 内存使用
df -h                       # 磁盘使用
du -sh /opt/test            # 目录占用大小
iostat -x 1                 # IO 监控

🌐 网络工具（4 个）

netstat -tunlp              # 端口监听
ss -tunlp                   # 端口监听（新版）
curl http://localhost:8080 # HTTP 请求
ping -c 4 www.baidu.com    # 网络连通性

🛠️ 实战篇 1：真实问题排查案例

🎯 场景：服务响应慢，怎么排查？

某天下午，测试同事反馈："接口响应很慢，几秒才返回。"

下面是 完整的排查过程（真实可复用）：

Step 1：看系统整体状态

# 先看 CPU 和内存
top
# 看内存使用
free -h
# 看磁盘（避免磁盘满导致慢）
df -h

输出解读：

• top 第一行：load average: 5.20, 4.80, 4.50（CPU 满载）

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 prio=5
# → 某个线程卡住了

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.log

Step 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

🤖 实战篇 2：AI 辅助定位（ChatGPT + DeepSeek）

工具：仅用 ChatGPT 和 DeepSeek 两个 AI 工具。

4.1 用 ChatGPT 辅助排查

场景：Java 应用 OOM（OutOfMemory）异常

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 2：ChatGPT 回复

可能原因：
- 堆内存不够（512M 偏小）
- 内存泄漏（推荐用 MAT 分析 heap dump）
- 大对象未释放

排查命令：
# 1. 看 JVM 堆使用
jmap -heap 1234

# 2. 生成 heap dump
jmap -dump:format=b,file=heap.bin 1234

# 3. 看 GC 情况
jstat -gc 1234 1000

解决思路：
1. 提高堆内存：-Xmx2048m -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 / 175M（95%），Full GC 频繁

请帮我：
1. 这种情况说明什么？
2. 推荐的最优配置是什么？
3. 除了改内存，还有什么优化？

ChatGPT 回复：

这种情况说明：
- Old Gen 内存紧张，频繁 Full GC
- 应用存在大对象或内存泄漏
- 堆内存设置偏小

推荐配置：
-Xmx2048m -Xms1024m -XX:NewRatio=2
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/tmp/dump

其他优化：
1. 用 MAT 分析 heap dump
2. 优化 SQL（避免大结果集）
3. 用缓存代替重复查询
4. 及时关闭资源

4.2 用 DeepSeek 辅助排查

场景：性能突然下降 50%，找根因。

Step 1：DeepSeek 用中文对话（更符合国内习惯）

我的应用性能监控显示：
- 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 适合：
  - 中文业务场景
  - 复杂逻辑分析
  - 长篇代码 review

📊 真实数据：AI 辅助排查效果

我做 AI 辅助排查半年：

传统方式：30 分钟查一个问题
AI 辅助：1 小时（5 分钟 AI 提问 + 25 分钟执行）

提效：2 倍（但成功率提升 50%）

关键认知：

💡 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 / -i / -B -A / -c
🔐 权限用户：chmod / chown / sudo
⏰ 进程监控：top -p / tail -F / nohup &
📦 杂项：history / alias / man

💬 写在最后：测试工程师的 Linux 能力

做了 5 年测试，我最大的感受是——

测试工程师不懂 Linux 是短板。

今天：学 5 个 Linux 命令（top/free/df/ps/tail）
本周：用 AI 辅助排查 1 个问题
90 天：积累 30 个命令 + 10 个真实案例

1 年后回头看，你的 Linux 能力会从 0 到 60+。

💬 评论区聊聊

你们做团队/公司最常遇到什么 Linux 问题？

我是怎么处理 OOM 的？

我会尽量回复。

📚 关于楠风测开

我是楠风测开，5 年测试工程师，做测试平台方向。

• 🔧 自研 4 端测试平台：Web / 接口 / Android / PC
• 📝 写测试工程师成长日记

AI 重塑测试，一个人就是一个团队

🔗 找到楠风

📱 公众号：楠风测开（同名）
🌐 知乎 / 掘金 / CSDN：搜索"楠风测开"
💬 想进测试工程师交流群：加我微信备注「测试」

📅 下期预告

Day 12：Linux 日志分析 + AI 智能诊断
- 日志位置 + 类型
- 5 款 AI 工具实战演示
- 真实日志排查案例

如果这篇文章对你有帮助：

🌟 点赞 + 在看 + 转发
🌟 关注公众号「楠风测开」（同名）
🌟 加我微信（备注"测试"，进测试圈交流群）

🌱 楠风测开 · 测试工程师复习日记 Day 11 / 90 天 全文 3800 字 | 阅读 10 分钟

【免责声明】本文为楠风测开原创，转载请联系作者授权。