Linux 日常运维不是背命令，而是建立一套可重复、可审计、可回滚的操作方法。本文面向日常值班和生产维护，覆盖命令检索、文本处理、用户权限、软件包、磁盘、进程、网络、日志以及标准变更流程。
安全原则：先确认主机、环境和影响范围，再执行修改；先保存现场，再做止损；涉及删除、权限、磁盘和服务重启时必须准备回滚方案。
一、适用环境与学习目标
示例适用于常见的 Ubuntu、Debian、Rocky Linux、AlmaLinux、CentOS Stream 和 RHEL。不同发行版的软件包管理器、日志路径和默认安全策略可能不同，执行前请先确认系统版本。
cat /etc/os-release
uname -r
hostnamectl
whoami
id
date -Is完成本文后，应能够快速找到命令和配置说明，安全处理文本与文件，管理用户和权限，排查软件包、磁盘、进程、网络及日志问题，并完成一次可回滚的生产变更。
二、开始操作前的五项确认
确认当前主机、账号、环境和时间是否正确。
确认操作对象是测试环境还是生产环境。
记录变更单、影响范围、观察指标和回滚条件。
备份待修改文件，并保留权限、属主和时间戳。
打开第二个终端保持登录，避免防火墙或 SSH 配置错误导致失联。
hostname -f
ip -br addr
pwd
git diff -- /etc/app/app.conf 2>/dev/null || true
cp -a /etc/app/app.conf /etc/app/app.conf.bak.$(date +%F-%H%M%S)三、命令检索：先查清楚再执行
不知道命令位置或参数时，不要依赖记忆拼接危险命令。优先使用下面的检索顺序：
type -a systemctl
command -v nginx
whereis nginx
man systemctl
systemctl --help
apropos 'disk usage'
info coreutilstype 可以区分别名、Shell 内建命令和可执行文件；command -v 适合脚本判断依赖；man 和 --help 用于核对参数。脚本中不要依赖交互式别名。
四、文本与日志处理
1. 查看文件
less /var/log/app/app.log
head -n 50 file.txt
tail -n 100 file.txt
tail -F /var/log/app/app.log
sed -n '20,60p' file.txttail -F 能在日志轮转后继续跟踪新文件，比 tail -f 更适合服务日志。
2. 搜索与统计
grep -Rni --exclude-dir=.git 'timeout' /etc/app/
grep -E 'ERROR|WARN' app.log | tail -n 100
awk '{print $1}' access.log | sort | uniq -c | sort -nr | head
cut -d: -f1,3 /etc/passwd
wc -l app.log处理大日志时先缩小时间和文件范围，避免对整个磁盘递归搜索。正则表达式和字段位置应先用少量样本验证。
3. 安全修改
sed 's/old/new/g' config.ini > config.ini.new
diff -u config.ini config.ini.new
install -o root -g root -m 0644 config.ini.new config.ini先生成新文件并比较，确认无误后再替换。不要未经验证直接使用 sed -i 批量修改生产配置。
五、用户、组与权限
id appuser
getent passwd appuser
getent group appgroup
sudo -l -U appuser
namei -l /srv/app/config.yaml
stat /srv/app/config.yaml
getfacl /srv/app/config.yaml排查“Permission denied”时，要检查路径上每一级目录的执行权限、文件属主、传统权限位、ACL、SELinux/AppArmor 以及挂载参数，而不是直接执行 chmod -R 777。
useradd --system --home-dir /srv/app --shell /usr/sbin/nologin appuser
install -d -o appuser -g appgroup -m 0750 /srv/app
chown appuser:appgroup /srv/app/config.yaml
chmod 0640 /srv/app/config.yaml
restorecon -Rv /srv/app # SELinux 环境最小权限原则：服务账号不允许交互登录；配置文件只向必要用户开放；sudo 规则应限定命令并经过审计。
六、软件包管理与版本核对
Debian / Ubuntu
apt-cache policy nginx
apt list --upgradable
apt-get update
apt-get install --simulate nginx
apt-get install nginxRHEL 系
dnf info nginx
dnf check-update
dnf repoquery --requires nginx
dnf install --assumeno nginx
dnf install nginx生产升级前应确认软件源、目标版本、依赖变化、配置兼容性和回滚包。内核、数据库、容器运行时等关键组件必须先在预发布环境验证，并安排维护窗口。
七、磁盘与文件系统排查
df -hT
df -i
findmnt
lsblk -f
du -xhd1 /var | sort -h
lsof +L1
journalctl -k -p warning --since '-2 hours'
smartctl -a /dev/sdaNo space left on device 不一定是容量用完，还可能是 inode 耗尽、已删除文件仍被进程占用、配额限制、文件系统只读或容器存储层异常。
止损顺序通常是：停止持续写入的异常任务；确认可安全清理的缓存和旧日志；处理删除未释放文件；扩容文件系统；最后验证应用写入和监控恢复。不要直接删除数据库文件、当前日志或不认识的目录。
八、进程、服务与资源
uptime
ps -eo pid,ppid,user,stat,%cpu,%mem,etime,cmd --sort=-%cpu | head
free -h
vmstat 1 5
pidstat -dur 1 5
systemctl status app.service
systemctl show app.service -p ActiveState -p SubState -p NRestarts
journalctl -u app.service --since '-30 minutes' --no-pager负载高不等于 CPU 高。运行队列、不可中断 I/O、内存回收、锁等待和外部依赖都可能推高 Load Average。重启服务前应保存进程、日志、连接和资源现场。
九、网络基础检查
ip -br addr
ip route
ss -lntup
ss -s
getent hosts example.com
curl -vk --connect-timeout 5 https://example.com/health
ping -c 4 gateway.example
tracepath target.example排查连接问题应按 DNS、路由、端口监听、本机防火墙、云安全组、TLS、应用认证的顺序进行。Connection timed out 与 Connection refused 指向的故障阶段不同。
十、日志和现场证据
journalctl --since '-1 hour' -p warning
journalctl -u app.service --since '2026-09-24 19:00:00'
dmesg -T | tail -n 100
last -x | head
lastb | head
auditctl -s 2>/dev/null || true记录故障开始时间、业务影响、告警变化、执行命令和结果。不要在取证前清空日志，也不要把包含密码、Token、客户数据的日志直接粘贴到工单或公开平台。
十一、标准变更与验证流程
变更前：确认负责人、窗口、依赖、备份和回滚命令。
保存基线：记录端口、进程、服务、版本、磁盘和关键指标。
小范围执行：优先单节点、灰度或旁路验证。
技术验证：检查服务状态、日志、端口、健康接口和监控。
业务验证：验证核心业务链路，而不只是进程存活。
观察期：持续观察错误率、延迟、资源和告警。
失败回滚：达到预设条件立即回滚，不在生产现场无限调试。
systemctl daemon-reload
systemctl restart app.service
systemctl is-active app.service
ss -lntp | grep ':8080'
curl -fsS http://127.0.0.1:8080/health
journalctl -u app.service --since '-5 minutes' --no-pager十二、常见危险操作
未经确认执行递归删除或对变量路径执行删除。
使用
chmod -R 777掩盖权限问题。在未保存现场时直接重启服务器或服务。
把密码、私钥和 Token 写进命令行、脚本或 Shell 历史。
在线修改防火墙、SSH 或网络配置但没有备用会话。
只确认进程存在，没有验证端口、依赖和业务链路。
十三、交付检查清单
系统、命令和配置版本已记录。
原配置和关键数据已经备份。
修改内容经过比较和同事复核。
权限、属主和 SELinux/AppArmor 上下文正确。
服务、端口、日志、监控和业务验证全部通过。
回滚步骤已验证，观察期结束后再关闭变更。
总结
高质量运维的核心不是命令数量，而是证据、边界和可恢复性。每一次操作都应回答：为什么要改、会影响谁、如何验证、失败如何回滚、怎样避免再次发生。按照这套流程执行，日常命令才能真正成为可靠的生产能力。