Linux命令与Shell脚本实战

从电商订单系统看Linux命令：基础操作与高频场景速查

前年双十一大促，我负责的电商订单系统峰值QPS冲到了12万，当时线上Ubuntu 24.04 LTS服务器（内核6.8版本）突然出现订单状态同步延迟。排查时发现，订单服务日志目录被大量临时文件占满，磁盘使用率飙到98%，导致新日志无法写入。我第一反应不是重启服务，而是直接用ls -lhS /var/log/order/按文件大小排序，发现有个order_temp_*.log的通配符文件堆积了3.7万份，单个最大达2.1GB。

原因在于，订单系统在大促时会生成临时校验文件，但清理脚本因权限问题未执行。解决方案是用find /var/log/order/ -name "order_temp_*.log" -mtime +1 -exec rm -f {} \;批量删除超过1天的临时文件——这里必须用-exec而非管道xargs，因为部分文件名包含空格，管道处理会截断。清理后磁盘使用率降到32%，同步延迟从800ms回落到120ms。

日常运维中，我常用的基础命令都围绕订单系统的实际场景设计。比如权限控制，订单服务的配置文件order.conf必须限制为仅运维用户可读写，我会用chmod 600 order.conf && chown order:ops order.conf，而不是图省事用chmod 777——去年团队有个新人这么做过，导致配置文件被测试环境误修改，订单支付回调失败持续17分钟。这里的权限数字计算逻辑是：6=4(r)+2(w)（所有者读写），0表示组用户和其他用户无权限，比chmod +x更精确，后者仅添加执行权限，无法控制读写范围。

进程管理方面，订单服务的Java进程偶尔会出现假死，用ps aux | grep order-service | grep -v grep只能看到进程存在，但用top -p $(pgrep -f order-service)观察时发现CPU占用率持续为0，内存却稳定在2.3GB。这时候直接用kill -9 $(pgrep -f order-service)重启太粗暴，我会先jstack $(pgrep -f order-service) > /tmp/order_stack.log导出线程栈，确认是数据库连接池耗尽后再重启，避免丢失未处理的订单消息。

网络工具在订单系统里用得最多的是ss替代netstat——在Fedora 40服务器上，ss -tuln | grep 8080查看订单服务端口监听状态的速度比netstat快3倍，因为ss直接从内核获取socket信息，而netstat需要遍历/proc目录。有一次支付回调接口超时，我用curl -w "Time: %{time_total}s" -X POST https://pay.callback/order -d "order_id=123"测试，发现总耗时达2.1s，排查下来是Nginx反向代理配置错误，而非订单服务本身问题。

这些命令在Bash 5.2.21版本下都经过验证，通配符处理比旧版本更稳定——比如rm order_*.log在旧版Bash中可能因文件名过长报错，5.2.21版本支持更长的参数列表。现在我们的运维手册里，基础命令都标注了适用版本和场景限制，避免新人踩权限或兼容性的坑。

# 订单系统临时文件清理脚本（日常手动执行版）
#!/bin/bash
# 清理/var/log/order/目录下超过1天的临时日志，排除正在写入的当前日志
LOG_DIR="/var/log/order"
CURRENT_LOG="order.log"

# 先检查磁盘使用率，超过80%才执行清理
DISK_USAGE=$(df -h $LOG_DIR | awk 'NR==2 {print $5}' | sed 's/%//')
if [ $DISK_USAGE -gt 80 ]; then
    echo "磁盘使用率 ${DISK_USAGE}%，开始清理临时文件..."
    find $LOG_DIR -name "order_temp_*.log" -mtime +1 ! -name "$CURRENT_LOG" -exec rm -v {} \;
    echo "清理完成，当前磁盘使用率：$(df -h $LOG_DIR | awk 'NR==2 {print $5}')"
else
    echo "磁盘使用率 ${DISK_USAGE}%，无需清理"
fi

千万级日志分析实战：grep、awk、sed性能对比与组合技

今年3月，我们的订单系统单日日志量突破1200万条，Nginx访问日志（combined格式）单文件达8.7GB。运营部门需要统计近7天访问量前10的IP，以及这些IP的订单转化率。我分别用grep、awk、sed单独处理和组合处理，得到了差异明显的性能数据。

先测试单独工具的处理能力：用grep "2024-03-15" access.log | wc -l统计单日日志行数，耗时12.3秒；换成awk '$4 ~ /2024-03-15/ {count++} END {print count}' access.log，耗时仅4.7秒——原因在于grep需要逐行匹配正则表达式，而awk可以直接对字段进行条件判断，字段分割后匹配效率更高。再用sed -n '/2024-03-15/p' access.log | wc -l，耗时18.9秒，因为sed主要是流编辑器，大量模式匹配时不如awk的字段处理优化得好。

但单独工具无法完成复杂需求。比如统计访问量前10的IP并关联订单数据，我需要先从Nginx日志提取IP（$1字段），再从订单日志匹配该IP的支付成功记录。解决方案是用管道组合三者：grep "2024-03-15" access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -10这个经典组合，处理8.7GB日志耗时21秒，得到IP访问量列表。接着用awk关联订单日志：awk 'NR==FNR {ip_count[$2]=$1; next} $3 in ip_count {print $3, ip_count[$3], $5}' order_pay.log access.log，这里NR==FNR是awk处理多文件的技巧，先加载订单日志的IP和支付金额，再匹配访问日志的IP，最终得到IP、访问量、支付金额的三列数据，总耗时37秒。

有一次线上接口突然变慢，排查时发现Nginx日志里有个IP 192.168.1.100每秒请求达300次，明显是爬虫。我需要用sed批量替换该IP的访问记录中的User-Agent，模拟正常用户行为测试限流规则。单独用sed 's/192.168.1.100/192.168.1.101/g' access.log > new_access.log耗时22秒，但结合grep预过滤后：grep "192.168.1.100" access.log | sed 's/192.168.1.100/192.168.1.101/g' > new_access.log，耗时降到7.3秒——原因在于减少sed处理的行数，预过滤掉无关日志。

性能对比的结论是：千万级日志场景下，awk的字段处理能力最优，适合统计类操作；grep适合快速过滤特定模式；sed适合批量文本替换。三者组合时，遵循"先过滤再处理"的原则，能大幅降低耗时。我们的日志分析脚本现在都基于Bash 5.2.21编写，利用其支持的awk数组优化特性，比旧版本脚本快15%左右。

# 千万级Nginx日志分析：统计访问量前10 IP及对应订单转化率
#!/bin/bash
# 日志路径
NGINX_LOG="/var/log/nginx/access.log"
ORDER_LOG="/var/log/order/order_pay.log"
# 目标日期（近7天）
TARGET_DATE="2024-03-15"

echo "开始分析 ${TARGET_DATE} 的日志数据..."

# 步骤1：提取目标日期的IP并统计访问量（grep+awk+sort组合）
echo "提取访问IP并统计..."
IP_COUNT=$(grep "$TARGET_DATE" $NGINX_LOG | awk '{print $1}' | sort | uniq -c | sort -nr | head -10)
echo "访问量前10 IP："
echo "$IP_COUNT"

# 步骤2：关联订单日志，计算转化率（awk多文件处理）
echo "关联订单数据，计算转化率..."
# 将IP访问量存入数组，再匹配订单日志中的支付成功记录（支付状态为1）
echo "$IP_COUNT" | awk -v order_log="$ORDER_LOG" '
BEGIN {
    # 先读取订单日志，存储IP对应的支付成功次数
    while (getline < order_log) {
        if ($5 == "1") {  # 假设第5字段是支付状态，1表示成功
            order_ip[$3]++  # 假设第3字段是用户IP
        }
    }
    close(order_log)
}
{
    ip = $2  # 第一列是访问量，第二列是IP
    count = $1
    pay_count = order_ip[ip] ? order_ip[ip] : 0
    conversion = (count > 0) ? (pay_count / count * 100) : 0
    printf "IP: %s, 访问量: %d, 支付次数: %d, 转化率: %.2f%%\n", ip, count, pay_count, conversion
}'

Shell脚本自动化部署：变量、循环与错误处理的工程化实践

去年我们重构订单系统的部署流程，从手动操作改为Shell脚本自动化，目标是将3台服务器的部署时间从45分钟压缩到5分钟以内。当时用的是Bash 5.2.21，脚本需要兼容Ubuntu 24.04 LTS和Fedora 40两种发行版，这要求变量定义和错误处理必须足够严谨。

我首先遇到的问题是没有做变量校验。第一版脚本里直接用DEPLOY_DIR=/opt/order，但有一次运维人员在执行时误输入DEPLOY_DIR=，导致后续cp命令把文件复制到了根目录，覆盖了系统文件。解决方案是所有变量都加非空校验：[[ -z "$DEPLOY_DIR" ]] && { echo "DEPLOY_DIR未定义"; exit 1; }。对于路径变量，还会用realpath命令标准化：DEPLOY_DIR=$(realpath -m "$DEPLOY_DIR")，避免因相对路径导致的错误。

循环处理多服务器部署时，我最初用for server in ${SERVERS[@]}遍历服务器列表，但某台服务器SSH连接超时会导致整个脚本卡住。改进后用while循环配合超时控制：while read -r server; do ssh -o ConnectTimeout=5 root@$server "echo '连接成功'"; done < servers.txt，并设置SERVERS数组为("192.168.1.101" "192.168.1.102" "192.168.1.103")。有一次102服务器磁盘满，部署失败，脚本需要跳过它继续部署其他服务器，同时记录错误日志——这时候||操作符比if判断更简洁：ssh root@$server "deploy.sh" || { echo "$server 部署失败" >> deploy_error.log; continue; }。

错误处理是自动化部署的核心。我们的脚本里每个关键步骤都有退出码检查：比如拉取代码git pull origin master，如果失败（退出码非0），必须终止部署并回滚。我设计了一个check_exit函数：check_exit() { if [ $? -ne 0 ]; then echo "步骤失败：$1"; rollback; exit 1; fi }，在git pull后调用check_exit "拉取代码失败"。回滚函数会恢复上一版本的二进制文件：cp /opt/order/backup/order-service.jar /opt/order/。去年有一次因为Maven依赖下载失败，git pull后编译出错，脚本自动回滚，避免了将不完整版本部署到线上，影响时长仅2分钟。

权限控制也不能忽视。部署脚本需要root权限执行，但二进制文件运行应该用普通用户order。我会在脚本里切换用户：sudo -u order nohup java -jar order-service.jar &，而不是全程用root启动服务——原因在于root进程如果被攻击，会直接获得系统最高权限。同时用chmod 750 deploy.sh限制脚本仅所有者可执行，避免其他用户误触发。

现在这个部署脚本已经运行了8个月，累计执行127次，成功率99.2%，仅有的失败是因为服务器硬件故障。脚本里还集成了容器检查：if command -v docker &>/dev/null; then docker ps | grep order-service; fi，适配云原生趋势，未来计划加入K8s资源管理命令。

#!/bin/bash
# 订单系统自动化部署脚本（工程化版本）
# 适用Bash 5.2.21+，兼容Ubuntu 24.04/Fedora 40

# 变量定义（严格非空校验）
APP_NAME="order-service"
DEPLOY_DIR="/opt/order"
BACKUP_DIR="$DEPLOY_DIR/backup"
SERVERS=("192.168.1.101" "192.168.1.102" "192.168.1.103")
CURRENT_USER=$(whoami)

# 错误处理函数
check_exit() {
    if [ $? -ne 0 ]; then
        echo "$(date '+%Y-%m-%d %H:%M:%S') 错误：$1" | tee -a deploy.log
        rollback
        exit 1
    fi
}

# 回滚函数
rollback() {
    echo "开始回滚..."
    if [ -f "$BACKUP_DIR/$APP_NAME.jar" ]; then
        cp "$BACKUP_DIR/$APP_NAME.jar" "$DEPLOY_DIR/"
        echo "回滚完成，已恢复上一版本"
    else
        echo "无备份文件，无法回滚"
    fi
}

# 部署前校验
[[ $CURRENT_USER != "root" ]] && { echo "请用root用户执行部署"; exit 1; }
[[ -z "$DEPLOY_DIR" ]] && { echo "DEPLOY_DIR未定义"; exit 1; }
mkdir -p "$BACKUP_DIR" || check_exit "创建备份目录失败"

# 循环部署多服务器
for server in "${SERVERS[@]}"; do
    echo "开始部署到服务器：$server"
    
    # 备份当前版本
    ssh -o ConnectTimeout=5 root@$server "cp $DEPLOY_DIR/$APP_NAME.jar $BACKUP_DIR/" || {
        echo "$server 备份失败，跳过部署" >> deploy_error.log
        continue
    }
    
    # 拉取最新代码并编译（简化示例，实际场景可能是scp传输jar包）
    echo "在 $server 上拉取最新代码..."
    ssh root@$server "cd /opt/order && git pull origin master" 
    check_exit "服务器 $server 拉取代码失败"
    
    # 重启服务（用普通用户运行）
    echo "重启 $server 上的服务..."
    ssh root@$server "sudo -u order systemctl restart $APP_NAME" 
    check_exit "服务器 $server 服务重启失败"
    
    # 检查服务状态
    ssh root@$server "systemctl is-active --quiet $APP_NAME" 
    check_exit "服务器 $server 服务未正常运行"
    
    echo "服务器 $server 部署成功"
done

echo "所有服务器部署完成，耗时：$SECONDS 秒"

4. 线上事故复盘：rm -rf与权限失控，我是如何救火的

那是一个周五的晚上，我正准备下班去接孩子，突然收到监控告警，说我们的订单服务接口响应时间从平均 120ms 飙升到了 3000ms 以上，QPS 也从 2000 掉到了不足 100。我当时心里一咯噔，赶紧连上跳板机去查。

我们当时的环境是 Ubuntu 22.04，后来升级到了 24.04 LTS（2024年4月发布），内核版本是 6.8。那天晚上，一个新来的运维同学在执行一个清理临时文件的脚本，脚本里有一行是 rm -rf ${TMP_DIR}/*。问题出在变量 TMP_DIR 没有正确赋值，结果在 root 权限下直接变成了 rm -rf /*。

他执行完还没意识到，直到我登录上去，发现 /usr/bin 下面好多东西都没了，连 ls 命令都跑不起来了。那一刻我后背全是冷汗，因为那是生产环境，跑着三个核心的订单节点，数据库里还有 800 多万条未完成的订单记录。

我第一反应是赶紧停掉所有写操作，防止数据进一步损坏。然后我尝试用 scp 从备份机拉文件，但发现 scp 也因为依赖缺失挂了。最后我只能靠救援模式启动系统，挂载磁盘，从我们之前做好的镜像里把缺失的二进制文件一个个拷回来。

整个过程我花了将近两个小时才把基础命令恢复，接着是检查文件权限。这里我得提一下，我们当时用的 Bash 版本是 5.1，后来我查了下，现在最新的稳定版是 5.2.21（2023年12月发布），在变量处理上确实比老版本严谨一些，但核心问题还是出在脚本写法上。

为了防止这种事再发生，我后来强制要求团队在写这类脚本时必须做两件事。第一，变量赋值后必须检查是否为空，第二，执行删除前先用 echo 打印出实际要执行的路径，确认无误再加 -f 参数。

下面是我后来重构的那个清理脚本的核心部分，现在一直在用：

#!/bin/bash
# 清理订单临时文件脚本
# 运行环境：Bash 5.2.21，Ubuntu 24.04 LTS

TMP_DIR="/data/order_tmp"

# 检查变量是否为空
if [ -z "$TMP_DIR" ]; then
    echo "错误：TMP_DIR 变量未定义，脚本终止"
    exit 1
fi

# 检查目录是否存在
if [ ! -d "$TMP_DIR" ]; then
    echo "目录 $TMP_DIR 不存在，无需清理"
    exit 0
fi

# 先打印要删除的内容，人工确认（自动化场景可去掉）
echo "即将删除 $TMP_DIR 下的所有文件："
ls -lh "$TMP_DIR"

# 安全删除，只删文件，不删目录结构
find "$TMP_DIR" -type f -mtime +7 -print0 | xargs -0 rm -v

# 检查上一条命令是否成功
if [ $? -eq 0 ]; then
    echo "清理完成，释放空间：$(du -sh $TMP_DIR | awk '{print $1}')"
else
    echo "清理过程中出现错误，请检查日志"
    exit 1
fi

这个脚本里我用了 find 加 -type f 来限定只删文件，而且通过 -mtime +7 只删七天前的，避免误伤正在使用的临时数据。另外，我特意把 rm -rf 换成了 rm -v，这样能在日志里看到到底删了什么。

那次事故之后，我们还调整了 chmod 的默认掩码，把一些关键目录的权限从 755 收紧到了 750，并且禁止了 root 直接远程登录。后来我在面试里也常问别人 chmod 755 和 chmod +x 的区别，很多人只能背出数字含义，却说不清在真实场景里，给一个脚本文件 chmod +x 其实只是增加了执行位，而 755 还会重新定义属主、组和其他人的读、写、执行权限，这在多用户协作的服务器上差别巨大。

5. 云原生时代新趋势：容器中的Shell优化与AI辅助脚本生成

去年我们团队把那个订单系统往 Kubernetes 上迁，用的是 Fedora 40（2024年4月发布）作为基础镜像的构建环境。在容器里写 Shell 脚本，感觉和以前在物理机或虚拟机上完全不一样。容器本身追求轻量，有时候你进去连 ps 命令都找不到，更别提 netstat 了。

我印象很深的一次是，我们想在 Dockerfile 里写一个启动脚本，负责检查依赖服务（比如 Redis 和 MySQL）是否就绪。最开始我用了个简单的 for 循环去 ping，结果发现基础镜像里连 ping 都没装。后来我改成用 nc 或者 curl 去做端口探测，但这样又得保证镜像里一定有这些工具。

为了不让镜像体积膨胀，我后来养成了一个习惯：在容器里能用 Bash 内置功能就绝不用外部命令。比如判断一个变量是不是数字，我以前习惯用 grep，现在我会直接用 Bash 的正则。

下面这个是我们现在用的一个健康检查脚本，跑在容器里，专门用来检测 MySQL 是否可用：

#!/bin/bash
# 容器健康检查脚本
# 适配 Docker 及 Kubernetes，Bash 5.2.21

DB_HOST="127.0.0.1"
DB_PORT="3306"
TIMEOUT=5

# 使用 Bash 内置的 /dev/tcp 进行端口探测，无需安装额外工具
if (echo > /dev/tcp/$DB_HOST/$DB_PORT) 2>/dev/null; then
    echo "MySQL 端口 $DB_PORT 已开启，服务正常"
    exit 0
else
    echo "无法连接到 MySQL，请检查网络或配置"
    exit 1
fi

这种写法在容器里特别省心，因为它不依赖 netcat 或者 telnet，只要 Bash 在就能跑。我们现在用的 Bash 5.2.21 在处理这种重定向时非常稳定，而且内存占用极低，大概只有几 MB，对比装一个 netcat 工具包要轻量得多。

另外一个让我觉得变化很大的趋势是 AI 辅助写脚本。我前阵子试用 GitHub Copilot，发现它现在真的能听懂人话。比如我直接输入注释：“写一个脚本，找出 /var/log/nginx 下昨天修改过的日志文件，并打包到 /backup 目录，文件名带上日期”，它生成的代码基本能直接用，只需要微调一下路径和权限。

不过 AI 生成的脚本有时候会有点“想当然”。有一次它给我生成了一个用 chmod 777 来解决问题的脚本，我一看就觉得不对劲。在云原生环境下，安全性要求极高，给 777 权限等于是自找麻烦。我后来手动改成了 chmod 644，并且在脚本里加了用户归属检查。

未来几年，我觉得 Shell 脚本不会消失，而是会更贴近云原生。比如现在的 ss 命令已经慢慢替代了 netstat，在 Fedora 40 里，ss 是默认安装的，而且输出更规范，方便用 awk 解析。我预测到 2026 年左右，我们写脚本时会更多地直接调用 Kubernetes 的 API，或者通过 kubectl 的 Shell 补全来快速生成复杂的运维命令。

对于开发者来说，现在学习 Shell 脚本，不能只盯着 ls 和 cd 了。你得去理解管道背后的数据流，去习惯在只有 50MB 大小的容器镜像里生存。如果你还在用 ifconfig，那真的该更新一下自己的知识库了，试试 ip addr 和 ss -tulnp，你会发现处理网络问题比以前顺手得多。

站长实战手记

一次差点让我背锅的日志分析

去年双十一，我还在一家做电商的公司。大促刚开始，订单量猛增，客服那边反馈说有几千笔订单状态卡在“支付中”，没有回滚也没有成功。我当时负责排查，面对的是几十个节点上分散的、每秒几百兆增长的日志文件。

一开始我脑子一热，想写个Python脚本去逐行解析，结果跑了十分钟还没出结果，差点被运维同事打。后来我冷静下来，直接上了 awk 和 grep 的组合拳。

我是这么干的：

* 先用 grep 把含有特定订单ID的日志行捞出来，这一步很快。

* 接着用 awk 对日志里的响应时间字段做累加和统计，计算平均耗时。

* 最后发现是某个下游接口超时，导致事务没释放。

整个排查过程不到五分钟，脚本就两行。那一刻我深刻体会到，在处理这种临时性的、大文本的分析任务时，Shell命令就是比写高级语言快。

我的真实看法

关于Shell脚本，我有很深的体会。

适合用的场景：我觉得它最适合做胶水。比如把几个命令串起来做自动化部署、定时清理磁盘、或者像我刚才那样临时救火。它胜在随手可得，不需要复杂的运行环境。

没必要上的场景：千万别拿它写复杂的业务逻辑。我曾经接手过一个前辈留下的几百行的Shell脚本，里面各种 if 嵌套，连数组和字典都快用上了。那个脚本维护起来简直是噩梦，稍微改个逻辑就崩，后来我直接用 Go 重写了，哪怕编译麻烦点，但可读性和健壮性强太多了。

给新手的一点建议

别死记硬背参数。我到现在也记不全 sed 和 awk 的高级用法，遇到不会的就查手册或者搜一下。只要你能熟练用 管道符 把命令串起来，解决80%的线上问题就够用了。真的，别为了炫技写那种没人看得懂的一行流代码，方便自己和同事排错才是最重要的。