• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。本附录按生产场景组织常用命令。以主流 Linux 发行版和 systemd 环境为主线，不同发行版的路径、服务名和工具参数可能有差异，生产操作前应以当前系统文档为准。1. 登录后第一分钟date -Ishostnamewhoamiuptimefree -hdf -hTss -ssystemctl --failed --no-pagerdmesg -T | tail -50进程 Top：ps -eo pid,ppid,user,stat,%cpu,%mem,rss,etime,cmd \ --sort=-%cpu | head -20ps -eo pid,ppid,user,stat,%cpu,%mem,rss,etime,cmd \ --sort=-rss | head -20确认三件事： 检查 目的 主机、用户、目录 防止误操作 资源水位 快速判断压力 失败服务和内核错误 找明显故障点 2. 文件与目录pwdls -lahls -ld /opt/appstat app.conffile app.binmkdir -p /opt/app/{conf,logs,run}cp -a /opt/app /opt/app.bakmv app.log archive/du -sh /var/logdu -h --max-depth=2 /var | sort -hfind /data -xdev -type f -size +1G -printf '%s %p\n' | sort -nr | headinode：df -ihls -i file已删除但仍被占用：lsof +L1ls -l /proc/<pid>/fd归档：tar -czf app-$(date +%F).tar.gz /opt/apptar -tf app-2026-08-25.tar.gz | headtar -xzf app-2026-08-25.tar.gz -C /tmp3. 权限与用户身份：idwhoamigroupsgetent passwd appgetent group app修改：chmod 640 app.confchmod 750 deploy.shchown app:app app.confchown -R app:app /opt/appfind /opt/app -type d -exec chmod 750 {} +find /opt/app -type f -exec chmod 640 {} +ACL：getfacl filesetfacl -m u:dev01:r filesetfacl -m g:audit:r filesetfacl -b filesudo：sudo -lsudo -u app /opt/app/bin/healthcheck.shsudo visudo -csudo journalctl -t sudo --since today推荐权限： 对象 权限 私钥 600 配置 640 脚本 750 应用目录 750 .ssh 目录 700 4. 文本处理查找：grep -n ERROR app.loggrep -i error app.loggrep -v DEBUG app.loggrep -r --include='*.log' ERROR /var/loggrep -E 'ERROR|WARN' app.logzgrep ERROR app.log.gz字段与替换：awk '{print $1}' access.logawk -F, '$3 > 100 {print $1, $3}' orders.csvsed -n '10,20p' app.logsed 's/debug=true/debug=false/' app.confcp app.conf app.conf.baksed -i 's/debug=true/debug=false/' app.confdiff -u app.conf.bak app.conf统计：wc -l app.logawk '{print $1}' access.log | sort | uniq -c | sort -nr | head -10awk '{print $9}' access.log | sort | uniq -c | sort -k2nJSON：jq . event.jsonjq '.status' event.jsonjq '[.[] | select(.status == "PAID")]' orders.jsonjq -r '.[] | [.id, .amount] | @tsv' orders.json安全传递文件名：find /opt/app -type f -name '*.log' -print0 | xargs -0 grep ERROR5. 进程与信号查看：ps auxfps -eo pid,ppid,user,stat,%cpu,%mem,etime,cmd --sort=-%cpupstree -apstop -H -p <pid>ps -T -p <pid>详情：cat /proc/<pid>/statuscat /proc/<pid>/iocat /proc/<pid>/limitstr '\0' '\n' < /proc/<pid>/environreadlink -f /proc/<pid>/cwdreadlink -f /proc/<pid>/exels -l /proc/<pid>/fd信号：kill -15 <pid>kill -9 <pid>pkill -TERM -f 'java -jar order.jar'退出码： 退出码 常见含义 0 成功 126 无执行权限 127 命令不存在 130 SIGINT 137 SIGKILL，常见 OOM 或强制停止 139 SIGSEGV 143 SIGTERM 6. systemd服务：systemctl status app --no-pagersudo systemctl start appsudo systemctl stop appsudo systemctl restart appsudo systemctl reload appsudo systemctl enable appsudo systemctl disable appsudo systemctl daemon-reload检查：systemctl cat appsystemctl show app -p MainPID -p ActiveState -p SubStatesystemctl list-units --type=servicesystemctl list-units --failedsystemctl list-timers --all日志：journalctl -u app -n 200 --no-pagerjournalctl -u app -fjournalctl -u app --since '1 hour ago'journalctl -p err --since todayjournalctl --disk-usagesudo journalctl --vacuum-size=2G常用 unit 片段：[Service]Type=simpleUser=appGroup=appWorkingDirectory=/opt/app/currentEnvironment=APP_ENV=productionEnvironmentFile=-/etc/app/envExecStart=/usr/bin/java -jar app.jarRestart=on-failureRestartSec=5sTimeoutStopSec=30sKillMode=mixedLimitNOFILE=65535MemoryHigh=5GMemoryMax=6GCPUQuota=300%7. 软件包APT：sudo apt updateapt list --upgradablesudo apt install nginxsudo apt remove nginxsudo apt purge nginxapt show nginxdpkg -l | grep nginxdpkg -L nginxdpkg -S /usr/sbin/nginxDNF：sudo dnf check-updatesudo dnf install nginxsudo dnf remove nginxdnf info nginxdnf historyrpm -qa | grep nginxrpm -ql nginxrpm -qf /usr/sbin/nginx锁定：sudo apt-mark hold nginxsudo apt-mark unhold nginxsudo dnf versionlock add nginx8. 磁盘与 IO设备：lsblk -fblkidsudo parted -ldf -hTdf -ih挂载：sudo mount /dev/vdb1 /datasudo umount /datafindmntsudo findmnt --verifyLVM：sudo pvssudo vgssudo lvssudo lvextend -L +50G /dev/datavg/datalvsudo xfs_growfs /datasudo resize2fs /dev/datavg/datalvIO：iostat -xz 1pidstat -d 1iotop -P -d 2cat /proc/<pid>/iocat /proc/meminfo | grep -E 'Dirty|Writeback'fio：sudo fio --name=rand-read \ --filename=/data/fio.test \ --direct=1 --rw=randread --bs=4k \ --ioengine=libaio --iodepth=32 --numjobs=4 \ --runtime=60 --time_based --group_reporting9. CPU 与内存CPU：uptimelscpuvmstat 1mpstat -P ALL 1pidstat -u 1pidstat -t -p <pid> 1pidstat -w 1内存：free -hcat /proc/meminfovmstat 1ps -eo pid,user,rss,cmd --sort=-rss | head -20cat /proc/<pid>/smaps_rollupdmesg -T | grep -Ei 'oom|out of memory|killed process'容器：docker statskubectl top podcat /sys/fs/cgroup/cpu.statcat /sys/fs/cgroup/memory.currentcat /sys/fs/cgroup/memory.maxcat /sys/fs/cgroup/memory.events判断： 现象 方向 available 低 内存压力 si/so 持续 swap 压力 throttled 增长 CPU 限流 OOM 日志 已牺牲进程 RSS 持续增长 泄漏或缓存增长 10. 网络地址与连接：ip -br addrip routeip -s linkss -sss -lntupss -antpss -ti探测：ping -c 4 <peer>nc -vz <host> <port>mtr -rwzc 100 <host>dig api.example.comcurl -v --max-time 5 https://api.example.com/healthz统计：ethtool -S eth0 | grep -Ei 'drop|err|miss|fifo'nstat -az | grep -Ei 'drop|err|retrans'netstat -s | grep -Ei 'listen|overflow|retrans'sudo conntrack -S抓包：sudo tcpdump -ni any host <peer> and port <port>sudo tcpdump -ni eth0 port 443 -w /tmp/net.pcap11. 性能分析采样：perf stat -p <pid> -- sleep 10sudo perf record -F 99 -g -p <pid> -- sleep 30sudo perf report --stdio追踪：strace -c -p <pid>strace -T -e trace=file,network -p <pid>lsof -nP -p <pid>lsof +L1eBPF：sudo biolatency 10 1sudo runqlatsudo tcpretranssudo execsnoopsudo opensnoopUSE 方法：每个资源检查：Utilization 使用率Saturation 饱和度Errors 错误12. Shell 可靠性头部：#!/usr/bin/env bashset -euo pipefailIFS=$'\n\t'参数与环境：env_name="${ENV_NAME:?ENV_NAME is required}"timeout="${TIMEOUT:-5}"[[ -r "$conf" ]] || { echo "cannot read $conf" >&2; exit 1; }清理：tmpdir=$(mktemp -d)cleanup() { rm -rf "$tmpdir"}trap cleanup EXIT INT TERM检查：bash -n script.shshellcheck script.shshfmt -w script.sh高危删除前预览：find /tmp -type f -name '*.tmp' -printfind /tmp -type f -name '*.tmp' -delete13. 安全基线账号：awk -F: '$7 !~ /(nologin|false)/ {print $1}' /etc/passwdlast -alastb | head -50sudo journalctl -u ssh --since today文件：find /etc -type f -perm /o+w -lsfind / -xdev -type f -perm /4000 -ls 2>/dev/nullstat /etc/shadow入侵排查：ps auxfss -antpcrontab -lsudo ls -la /etc/cron.*find /tmp /var/tmp /dev/shm -type f -executable -lssystemctl list-timers --allrpm -Vadpkg --verify加固原则：[ ] 禁 root SSH[ ] 禁密码 SSH[ ] 只允许可信来源[ ] 服务独立低权限账号[ ] sudo 最小授权[ ] 只开放必要端口[ ] 补丁流程[ ] 日志集中[ ] 密钥轮换[ ] 审计 sudo 和登录14. 防火墙nftables：sudo nft list rulesetsudo nft list tablesiptables：sudo iptables -Ssudo iptables -L -n -vsudo iptables -t nat -L -n -vsudo iptables-save > firewall.rulessudo iptables-restore < firewall.rulesfirewalld：sudo firewall-cmd --list-allsudo firewall-cmd --permanent --add-service=httpssudo firewall-cmd --reloadufw：sudo ufw status verbosesudo ufw allow 443/tcpsudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp远程修改防火墙前必须先保住 SSH 和 established 连接。15. 备份恢复文件：sudo tar -czf /backup/data-$(date +%F).tar.gz /datasha256sum /backup/data-*.tar.gz > /backup/checksums.txtsha256sum -c /backup/checksums.txtsudo rsync -a --delete --dry-run /data/ backup:/backup/data/sudo rsync -a --delete /data/ backup:/backup/data/快照：sudo lvcreate -s -n datalv-snap -L 10G /dev/datavg/datalvsudo mount /dev/datavg/datalv-snap /mnt/snapsudo umount /mnt/snapsudo lvremove /dev/datavg/datalv-snap必备元数据：[ ] 备份时间[ ] 主机和数据集[ ] 版本[ ] 校验值[ ] 加密方式[ ] 保留期限[ ] 恢复步骤[ ] 最近演练结果16. 监控清单主机：CPU 使用率、runq、context switch、throttle内存 available、swap in/out、OOM磁盘空间、inode、await、IOPS、吞吐网络错误包、丢包、重传、连接数systemd failed、进程重启、日志错误应用：QPS、成功率、错误率P50 / P95 / P99连接池、线程池、队列GC、FD、RSS依赖耗时发布：版本、时间、批次、配置版本回滚事件、变更人、工单17. 常见故障路径无法登录ping <host>nc -vz <host> 22ssh -vvv user@<host>检查安全组、防火墙、sshd、PAM、磁盘满、CPU/IO 打满、账号锁定。磁盘满df -hTdf -ihdu -sh /var/* /opt/* /tmp /rootlsof +L1sudo journalctl --disk-usageCPU 高uptimevmstat 1pidstat -u 1top -H -p <pid>perf record -F 99 -g -p <pid> -- sleep 30内存不足free -hvmstat 1ps -eo pid,rss,cmd --sort=-rss | headdmesg -T | grep -Ei 'oom|killed process'服务启动失败systemctl status app --no-pagerjournalctl -u app -n 200 --no-pagersystemctl cat appsudo -u app /opt/app/bin/start --checkss -lntp网络不通dig <host>nc -vz <host> <port>curl -v <url>ip route get <host>sudo tcpdump -ni any host <host> and port <port>18. 上线检查清单系统：[ ] 用户和目录权限[ ] systemd unit[ ] ulimit 和资源限制[ ] 日志轮转[ ] 时间同步[ ] 磁盘水位[ ] 只开放必要端口应用：[ ] 健康检查[ ] 指标暴露[ ] trace_id[ ] 超时和重试[ ] 优雅停机[ ] 版本记录发布：[ ] 制品校验[ ] 配置校验[ ] 灰度批次[ ] 停止条件[ ] 回滚演练[ ] 监控看板[ ] 值班通知安全与恢复：[ ] 非 root 运行[ ] sudo 最小授权[ ] SSH 来源限制[ ] 密钥轮换[ ] 备份可用[ ] 恢复演练通过19. 高危命令确认表 命令 风险 执行前 rm -rf 删除不可恢复 展开通配符和路径 dd 覆盖设备 确认 of 目标 mkfs 清空文件系统 lsblk 确认设备 iptables / nft 锁死管理通道 放行 SSH 和 established sysctl -w 改内核行为 记录默认值和回滚 kill -9 丢清理机会 先 SIGTERM lvreduce 缩容风险 备份并确认文件系统 xfs_repair -L 可能丢数据 专家评审和备份 执行前三问：1. 我在哪台机器？2. 目标真实路径是什么？3. 回滚命令是什么？20. 学习地图第一阶段：命令行、文件、权限、进程第二阶段：systemd、日志、磁盘、网络、软件包第三阶段：CPU、内存、IO、网络栈、namespace、cgroup第四阶段：安全、SSH、防火墙、备份、监控第五阶段：Shell、Ansible、高负载部署、发布回滚第六阶段：内核文档、源码、eBPF、专项性能优化
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。掌握 Linux 的标志不是记住所有命令，而是能在复杂系统中定位问题、设计边界、自动化治理，并通过证据和指标持续改进。本章给出成长阶段、能力矩阵、学习计划和实践项目。31.1 五个阶段Level 1 使用者 会命令行、文件、权限、进程 | vLevel 2 管理者 会 systemd、磁盘、网络、日志、安全 | vLevel 3 排障者 能定位 CPU、内存、IO、网络和应用问题 | vLevel 4 架构治理者 能设计部署、容量、监控、安全和自动化 | vLevel 5 专家 能读内核文档和源码，优化系统与大规模平台31.2 能力矩阵 能力 初级 中级 高级 命令行 常用命令 管道和脚本 工具链和自动化 文件系统 查看文件 权限与挂载 IO 与一致性治理 进程 ps/top 信号与 systemd 生命周期和资源隔离 性能 看 CPU 定位瓶颈 建立容量模型 网络 ping/curl 分层排障 内核栈与架构优化 安全 基础权限 SSH 与防火墙 零信任和审计体系 治理 手工操作 Ansible 平台化和自服务 31.3 每日实践建议每天做一个实验：周一：进程与 systemd周二：内存和 IO周三：网络排障周四：Shell 与 Ansible周五：安全和审计周六：压测和性能分析周日：复盘和文档记录格式：问题：环境：命令：输出：结论：风险：改进：31.4 必做实验清单实验一：优雅停机写一个捕获 SIGTERM 的服务 -> systemd 停止 -> 观察 journal -> 调整 TimeoutStopSec实验二：磁盘水位生成大文件 -> 观察 df / du / iostat -> 删除并被进程持有 -> lsof +L1 分析实验三：网络丢包用 tc 制造丢包 -> 观察 retrans 和 ss -> 抓包确认 -> 恢复环境实验四：cgroup 限流创建 systemd 服务 -> 设置 CPUQuota -> 压测 -> 观察 cpu.stat throttled实验五：自动化初始化编写 Ansible role -> 用户、目录、服务、日志、监控 -> dry-run -> 测试环境验证31.5 项目训练项目一：主机巡检平台功能： 批量采集主机指标； 检查 systemd failed； 磁盘和 inode 水位； 安全基线； 生成报告； 告警。产出：Web 看板和定时报告。项目二：发布系统功能： 制品校验； 批次发布； 健康检查； 自动回滚； 审计日志； 配置版本。验收：模拟失败发布时自动恢复。项目三：故障演练平台功能： CPU 压力； 内存压力； 磁盘满； 网络丢包； 进程退出； 服务限流。产出：可重复的演练手册和监控验证报告。31.6 阅读路径推荐顺序：man bashman procfsman signalman systemd.unitman sysctlLinux Kernel DocumentationBrendan Gregg 性能分析资料Linux insides内核源码读法： 带实验读； 记录版本差异； 从工具输出反推机制； 从机制回到生产场景； 不把单个内核参数当万能结论。31.7 90 天计划第 1 到 15 天：命令行、文件、权限、进程、基础网络第 16 到 30 天：systemd、日志、磁盘、软件包、Shell 脚本第 31 到 50 天：CPU、内存、IO、网络栈、性能工具第 51 到 70 天：安全、SSH、防火墙、备份、监控第 71 到 90 天：Ansible、高负载部署、故障演练、复盘报告每周产出一份实验报告，每月完成一次故障演练。31.8 长期习惯 所有变更先想回滚； 所有结论要给证据； 所有高危命令先确认目标； 所有重复操作自动化； 所有阈值结合业务； 所有故障沉淀监控； 所有密钥可轮换； 所有备份做恢复演练； 所有配置进入仓库； 所有系统持续更新。31.9 职业方向后端工程师：进程模型、IO、网络、容器限制、服务部署、性能 profileSRE：监控、容量、自动化、故障演练、应急响应、可靠性治理平台工程师：镜像、部署、配置管理、内部工具、自服务体系安全工程师：账号权限、审计、入侵检测、漏洞治理、零信任内核或性能工程师：调度、内存、IO、eBPF、内核源码、专项优化本章小结从 0 到大师的 Linux 路径，是从操作者到排障者，再到系统治理者和性能专家。持续进步来自实验、压测、故障复盘、自动化和文档阅读。最终目标是在任何生产事故中，都能分层定位、快速恢复、讲清证据并沉淀改进。思考题 评估你当前所处的阶段和三个短板。 设计个人 90 天 Linux 实验计划。 为团队制定主机安全基线。 设计一次磁盘满导致服务故障的演练。 写一份你所在系统的高可用部署方案。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Linux 面试不是背命令，而是考你能否从现象出发分层定位，能否解释指标含义，能否处理生产风险。本章按主题整理高频问题和回答思路。30.1 基础命令问题：load average 高怎么办？回答思路：1. 和 CPU 核数比较2. 看 us/sy/wa/st3. 看 r 和 b 队列4. 定位进程和线程5. 区分 CPU、IO、D 状态、虚拟化抢占命令：uptimenprocvmstat 1pidstat -u 1加分点：load 包含不可中断任务，高 load 不一定是 CPU 不足。问题：磁盘空间不足如何排查？df -hTdf -ihdu -sh /var/* /opt/*lsof +L1find / -xdev -type f -size +1G -ls加分点：同时检查容量和 inode，注意已删除但仍被占用的文件。30.2 权限与用户问题：Permission denied 怎么排查？idls -ld /opt/app /opt/app/confls -l /opt/app/conf/app.ymlgetfacl /opt/app/conf/app.ymlsudo -u app cat /opt/app/conf/app.yml回答要点： 检查用户和组； 检查路径每一级目录执行权限； 检查文件权限和 ACL； 检查 SELinux 或 AppArmor； 用目标用户验证。问题：sudo 和 su 的区别？ 项 sudo su 授权 当前用户密码或免密规则 目标用户密码 粒度 可限制命令 通常切换完整身份 审计 sudo 日志 需要额外审计 原则 最小授权 便于共享 root，风险高 30.3 进程与信号问题：kill -9 和 kill -15 区别？SIGTERM 可被捕获，应用可以摘流、处理存量请求、释放资源。SIGKILL 不可捕获，进程立即终止，可能丢数据或留下锁。生产顺序：SIGTERM -> 等待 -> 超时 SIGKILL问题：进程退出码 137 是什么？通常表示 128 + 9，即收到 SIGKILL。常见于编排系统超时停止或 OOM Killer。需要查：dmesg -T | grep -Ei 'oom|killed process'journalctl -u appkubectl describe pod <pod>30.4 文件系统问题：软链接和硬链接区别？ 项 硬链接 软链接 指向 inode 路径 跨文件系统 通常不可 可以 目录 一般不允许 可以 目标删除 数据仍可访问 可能悬空 问题：删除大日志为什么磁盘没释放？文件名是目录项，进程持有 fd 时 inode 和数据块不会释放。lsof +L1ls -l /proc/<pid>/fd处理：重载日志组件或安排重启，并修复轮转策略。30.5 内存问题：free 里 buffer/cache 高是否异常？不一定是异常。Linux 用空闲内存做页缓存，提高读写性能。判断要看 available、swap、major fault 和 OOM。free -hvmstat 1cat /proc/meminfo问题：容器 OOMKilled 如何排查？kubectl describe pod <pod>cat /sys/fs/cgroup/<path>/memory.eventscat /sys/fs/cgroup/<path>/memory.stat方向： memory limit 太小； 堆设置过大； 堆外内存泄漏； 请求量上升； 页缓存和内核内存计入 cgroup。30.6 IO问题：如何判断磁盘慢？iostat -xz 1pidstat -d 1cat /proc/meminfo | grep -E 'Dirty|Writeback'关注： await； util； 队列深度； IOPS 和吞吐； 进程写入量； 云盘规格。加分点：多队列设备 util 100% 不一定代表饱和，await 和延迟分布更重要。30.7 网络问题：服务访问不通怎么排查？DNS -> TCP -> TLS -> HTTP -> upstreamdig api.example.comnc -vz api.internal 8080openssl s_client -connect api.example.com:443 -servername api.example.comcurl -v --resolve api.example.com:443:192.0.2.10 https://api.example.com/healthzss -lntpsudo tcpdump -ni any host <peer> and port <port>加分点：区分云安全组、主机防火墙、conntrack、服务监听和应用拒绝。问题：TIME_WAIT 和 CLOSE_WAIT 大量出现说明什么？TIME_WAIT 通常在主动关闭方，常见于高频短连接，影响临时端口。CLOSE_WAIT 在被动关闭方，对端已关闭而本端应用没有关闭 socket，通常是代码资源泄漏。处理重点： 状态 重点 TIME_WAIT 连接池、长连接、复用、容量 CLOSE_WAIT 应用关闭逻辑 30.8 systemd问题：为什么 systemd 服务读不到环境变量？systemd 服务不是登录 Shell，不读取 ~/.bashrc 或 ~/.bash_profile。正确方式：[Service]Environment="JAVA_HOME=/opt/java"EnvironmentFile=-/etc/order/env修改后：sudo systemctl daemon-reloadsudo systemctl restart order问题：daemon-reload 和 restart 区别？daemon-reload 重新读取 unit 配置；restart 重启服务进程。修改 unit 后通常先 reload systemd，再 restart 服务。30.9 安全问题：服务器被入侵后第一件事做什么？回答思路：1. 确认影响面和是否仍在活动2. 隔离主机，保留证据3. 保护日志和内存现场4. 禁用异常账号和 key5. 轮换凭据6. 排查横向移动7. 按应急流程通知不建议：在被控主机上反复手工安装工具或直接重装导致证据丢失。问题：如何做 SSH 加固？要点： 禁 root 登录； 禁密码登录； 只允许可信来源； 使用密钥或短期证书； MFA； 跳板机； sudo 最小授权； 集中审计； 保留会话修改配置。30.10 场景设计问题：设计一台 Java 应用服务器回答框架：用户：独立 app 用户目录：releases + shared + logs + current服务：systemd Type=simple资源：LimitNOFILE、MemoryMax、CPUQuota内存：堆占上限约 65%，预留堆外和系统日志：结构化 + 轮转 + 采集网络：只开放必要端口发布：版本目录 + 灰度 + 回滚监控：主机 + JVM + 应用 + 业务问题：优化一次 P99 延迟上升回答框架：1. 确认影响范围和开始时间2. 查发布、配置、流量、依赖变更3. 看黄金指标4. 检查 CPU throttling、GC、IO、网络5. 抓应用 trace 定位慢请求6. 复现或压测验证7. 灰度修复8. 前后指标对比本章小结Linux 面试要展示分层思维、证据意识、风险控制和生产经验。回答问题时先说判断路径，再给命令和原理，最后补充止损和复盘。思考题 你如何回答“服务器慢”？ CLOSE_WAIT 大量出现时应该检查什么？ 如何证明磁盘是瓶颈？ systemd 环境变量为什么和登录 Shell 不同？ 为团队整理五个最常见的 Linux 应急场景。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。高负载服务的 Linux 部署不只是把进程启动，还要规划用户、目录、版本、服务、日志、端口、资源限制、安全边界、健康检查、发布回滚和容量。本章把这些要求组合成一套可执行方案。29.1 部署目标1. 可重复安装2. 配置可版本化3. 服务可观测4. 发布可回滚5. 资源有边界6. 安全最小化7. 故障可恢复8. 容量可扩展非目标： 手工修改单台机器； 依赖登录 Shell 环境变量； 日志无上限； root 运行； 单机部署且无备份。29.2 用户与目录创建服务用户：sudo useradd -r -s /sbin/nologin -d /opt/order app目录：/opt/order |-- releases/ | |-- 202608251200/ | +-- 202608260900/ |-- shared/ | |-- conf/ | +-- data/ |-- logs/ |-- run/ +-- current -> releases/202608260900权限：sudo mkdir -p /opt/order/{releases,shared/{conf,data},logs,run}sudo chown -R app:app /opt/ordersudo chmod -R 750 /opt/ordersudo chmod 640 /opt/order/shared/conf/*发布产物与可变数据分离，回滚时只切换符号链接。29.3 systemd 服务/etc/systemd/system/order.service：[Unit]Description=Order ServiceWants=network-online.targetAfter=network-online.target[Service]Type=simpleUser=appGroup=appWorkingDirectory=/opt/order/currentEnvironment=APP_ENV=productionEnvironment=JAVA_OPTS=-XX:MaxRAMPercentage=65.0EnvironmentFile=-/etc/order/envExecStart=/usr/bin/java $JAVA_OPTS -jar app.jarExecStop=/bin/kill -TERM $MAINPIDRestart=on-failureRestartSec=5sTimeoutStopSec=30sKillMode=mixedLimitNOFILE=65535LimitNPROC=4096UMask=0027NoNewPrivileges=truePrivateTmp=trueProtectSystem=strictReadWritePaths=/opt/order/logs /opt/order/shared/data[Install]WantedBy=multi-user.target启用：sudo systemctl daemon-reloadsudo systemctl enable --now order.servicesystemctl status order --no-pager29.4 日志与轮转/etc/logrotate.d/order：/opt/order/logs/*.log { daily rotate 14 missingok notifempty compress delaycompress dateext create 0640 app app copytruncate}应用日志也可以输出 journald 或 stdout，由采集器处理。无论哪种方式，必须有： 留存周期； 大小上限； 结构化格式； trace_id； 敏感信息脱敏； 采集监控。29.5 健康检查健康端点：curl -sf http://127.0.0.1:8080/healthzcurl -sf http://127.0.0.1:8080/readyz分层： 检查 用途 liveness 进程是否需要重启 readiness 是否可以接流量 dependency 依赖是否异常 version 版本确认 metrics 指标采集 不要把所有慢依赖都放入 liveness，否则依赖抖动可能引发服务重启风暴。29.6 资源边界systemd：CPUQuota=300%MemoryHigh=5GMemoryMax=6GTasksMax=2048IOWeight=100容量检查：systemctl show order -p CPUQuota -p MemoryMax -p TasksMaxcat /proc/$(systemctl show -p MainPID --value order)/limitsJava 内存：容器或服务内存上限 6G -> 堆约 65% -> 元空间、线程栈、直接内存预留 -> 系统和页缓存预留29.7 发布流程1. 构建产物并生成校验值2. 上传到制品库3. 预检查：磁盘、端口、依赖、配置4. 分发到批次实例5. 解压到 release 目录6. 校验版本和配置7. 更新 current 链接8. 重启或热加载9. readiness 通过10. 接回流量11. 观察错误率、延迟、资源12. 继续下一批单机脚本：#!/usr/bin/env bashset -euo pipefailrelease_id="${1:?release id required}"release_dir="/opt/order/releases/${release_id}"[[ -d "$release_dir" ]] || { echo "release not found" >&2; exit 1; }ln -sfn "$release_dir" /opt/order/current.nextmv -T /opt/order/current.next /opt/order/currentsudo systemctl restart ordercurl -sf --retry 10 --retry-delay 1 \ http://127.0.0.1:8080/readyz29.8 回滚1. 判定停止条件2. 摘除异常实例3. current 指向上一版本4. 重启服务5. readiness 验证6. 接回流量7. 保留现场日志和配置可回滚前提： 数据库变更向后兼容； 配置版本可切换； 上一制品仍在； 健康检查可信； 回滚步骤演练过。29.9 容器化部署Kubernetes 示例：apiVersion: apps/v1kind: Deploymentmetadata: name: orderspec: replicas: 6 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 0 maxSurge: 1 selector: matchLabels: app: order template: metadata: labels: app: order spec: terminationGracePeriodSeconds: 30 containers: - name: order image: registry.example.internal/order:1.0.0 ports: - containerPort: 8080 envFrom: - configMapRef: name: order-config resources: requests: cpu: "1" memory: 2Gi limits: cpu: "2" memory: 3Gi readinessProbe: httpGet: path: /readyz port: 8080 initialDelaySeconds: 10 periodSeconds: 5 livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 20 periodSeconds: 10镜像要求： 固定基础镜像版本； 非 root 用户； 只包含必要文件； 健康检查； 正确处理 SIGTERM； 不写可写层。29.10 监控接入主机：CPU、内存、磁盘、IO、网络进程：进程存活、重启次数、FD、线程数、RSS应用：QPS、成功率、P95 / P99、队列、依赖耗时发布：版本、发布批次、配置版本、变更时间日志：ERROR、WARN、GC、连接失败、认证失败29.11 上线检查清单[ ] 服务用户和目录权限正确[ ] systemd unit 通过语法和启动验证[ ] 健康检查和指标端点可用[ ] 日志轮转和采集验证[ ] ulimit、内存、CPU、任务数设置[ ] 防火墙只开放必要端口[ ] sudo 和 SSH 权限审计[ ] 备份和恢复流程确认[ ] 发布与回滚演练[ ] 监控告警配置[ ] 值班和升级路径[ ] 文档和 Runbook本章小结高负载服务部署要以可重复和可回滚为核心：独立用户、版本目录、systemd 边界、日志轮转、资源限制、健康检查、监控和灰度发布。容器化后同样要保留这些要求，只是由镜像和编排系统承载。思考题 releases 目录加 current 链接有什么好处？ readiness 和 liveness 应该如何设计？ Java 服务内存上限如何分配？ 哪些数据库变更会导致无法回滚？ 设计一套 20 台机器的灰度发布方案。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。手工操作难以重复、难审计、容易漂移。Ansible 用 YAML 描述期望状态，用 SSH 执行，适合批量巡检、系统配置、发布预检和应急操作。本章覆盖 inventory、playbook、变量、role、vault、常用模块和 CI 集成。28.1 安装python3 -m pip install --user ansibleansible --version依赖 SSH：ssh-keygen -t ed25519ssh-copy-id app@192.0.2.1028.2 Inventoryinventory/prod.ini：[web]web01 ansible_host=192.0.2.10web02 ansible_host=192.0.2.11[app]app01 ansible_host=192.0.2.20app02 ansible_host=192.0.2.21[prod:children]webapp[prod:vars]ansible_user=deployansible_python_interpreter=/usr/bin/python3测试：ansible all -i inventory/prod.ini -m pingansible web -i inventory/prod.ini -a 'uptime'28.3 Playbooksite.yml：- name: Configure web servers hosts: web become: true gather_facts: true tasks: - name: Install nginx ansible.builtin.package: name: nginx state: present - name: Deploy nginx config ansible.builtin.template: src: templates/nginx.conf.j2 dest: /etc/nginx/nginx.conf owner: root group: root mode: "0644" notify: - Reload nginx handlers: - name: Reload nginx ansible.builtin.service: name: nginx state: reloaded执行：ansible-playbook -i inventory/prod.ini site.yml语法检查：ansible-playbook --syntax-check -i inventory/prod.ini site.ymlDry run：ansible-playbook --check --diff -i inventory/prod.ini site.yml28.4 常用模块| 模块 | 用途 ||—|—|| package | 跨发行版装包 || service | 服务管理 || systemd | systemd unit || copy / template | 分发文件 || file | 文件与目录 || user / group | 账号 || ` authorized_key | SSH 公钥 || lineinfile | 单行配置 || replace | 正则替换 || sysctl | 内核参数 || firewalld | 防火墙 || stat | 检查文件 || uri | HTTP 检查 || command / shell` | 执行命令 |优先使用幂等模块，shell 应作为最后选择。28.5 变量group_vars/web.yml：nginx_worker_processes: autonginx_keepalive_timeout: 65app_env: production使用：- name: Show env ansible.builtin.debug: msg: "env={{ app_env }}, workers={{ nginx_worker_processes }}"优先级示例：extra vars -> inventory vars -> group_vars -> role defaults敏感变量不要写普通 group_vars。28.6 条件、循环与变更条件：- name: Install chrony on Debian ansible.builtin.package: name: chrony state: present when: ansible_facts.os_family == 'Debian'循环：- name: Create app users ansible.builtin.user: name: "{{ item.name }}" groups: "{{ item.groups }}" state: present loop: - { name: dev01, groups: release } - { name: ops01, groups: ops }变更处理：- name: Deploy app ansible.builtin.copy: src: files/app.jar dest: /opt/app/app.jar notify: - Restart apphandler 只有任务变化时才执行。28.7 Role结构：roles/nginx |-- defaults/main.yml |-- files/ |-- handlers/main.yml |-- meta/main.yml |-- tasks/main.yml |-- templates/ +-- vars/main.yml使用：- name: Configure web hosts: web become: true roles: - role: nginx vars: nginx_worker_processes: autoGalaxy 安装：ansible-galaxy install geerlingguy.nginx第三方 role 要评审来源、版本和权限，不能只因为流行就使用。28.8 Vault创建加密文件：ansible-vault create group_vars/all/vault.yml编辑：ansible-vault edit group_vars/all/vault.yml执行：ansible-playbook --ask-vault-pass -i inventory/prod.ini site.yml更安全的方式是把密钥交由 Secret Manager，Ansible 只保存引用和权限。28.9 批量巡检check.yml：- name: Linux health check hosts: all become: false tasks: - name: Collect uptime ansible.builtin.command: uptime changed_when: false register: uptime_output - name: Collect disk ansible.builtin.command: df -hT changed_when: false register: disk_output - name: Show result ansible.builtin.debug: msg: - "{{ inventory_hostname }}: {{ uptime_output.stdout }}" - "{{ disk_output.stdout_lines }}"执行：ansible-playbook -i inventory/prod.ini check.yml28.10 CI/CD 集成流程：Git MR -> syntax check -> lint -> test env dry-run -> approval -> prod canary -> full rollout要求： inventory 和代码在仓库； playbook 有 lint； 高危 playbook 需要人工审批； 执行记录保留； 生产与测试环境变量隔离； 支持回滚； Ansible 版本固定。lint：ansible-lint site.yml本章小结Ansible 把主机、变量、任务、角色和密钥组织成可版本化的自动化。生产使用要坚持幂等、dry-run、审批、审计和回滚。它适合系统配置和批量操作，复杂发布编排可交给专业 CI/CD 系统。思考题 幂等性为什么重要？ handler 和普通 task 有什么区别？ 什么情况下不应使用 shell 模块？ 如何安全使用 Ansible Vault？ 设计一套生产主机初始化 playbook。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。性能调优不是复制参数，而是定义目标、建立基线、定位瓶颈、验证收益和控制风险。一次合格的优化必须有前后指标、适用条件和回滚方案。27.1 调优流程1. 定义指标和目标2. 采集基线3. 定位瓶颈4. 提出假设5. 测试环境验证6. 小流量上线7. 对比指标8. 固化配置9. 持续监控目标示例：P99 从 800ms 降到 300ms单机支持 QPS 从 2000 到 3000磁盘 await 从 40ms 降到 10ms错误率不超过 0.1%27.2 容量评估峰值 QPS -> 单实例容量 -> 实例数 -> 冗余系数需要考虑： 项目 说明 CPU 峰值、限流、批任务 内存 工作集、缓存、堆外 磁盘 IOPS、吞吐、延迟 网络 带宽、PPS、连接数 依赖 DB、缓存、队列 发布 摘流后剩余容量 推荐保留 20% 到 30% 的余量，具体按业务风险决定。27.3 CPU 优化定位：pidstat -u 1top -H -p <pid>perf record -F 99 -g -p <pid> -- sleep 30方向： 优化算法和热点代码； 减少锁竞争； 调整线程数； 使用异步和非阻塞 IO； 增加缓存； 削峰限流； 扩容。容器：cat /sys/fs/cgroup/<path>/cpu.stat如果 throttled 增长，应提高 limit 或降低实例流量，而不是只改应用参数。27.4 内存优化定位：free -hvmstat 1pidstat -r 1ps -eo pid,rss,cmd --sort=-rss | head方向： 调整应用堆和缓存上限； 修复泄漏； 减少大对象； 控制并发； 使用流式处理； 扩容内存； 增加水位告警。Java 容器示例：java -XX:MaxRAMPercentage=65.0 -jar app.jar剩余内存要留给元空间、线程栈、直接内存、页缓存和系统。27.5 IO 优化定位：iostat -xz 1pidstat -d 1cat /proc/<pid>/io方向： 问题 优化 小随机 IO 多 批量写、顺序化 fsync 频繁 组提交、批量刷盘 日志过大 降低级别、异步日志 读放大 索引、缓存 云盘规格不足 升级规格 快照影响 错峰 参数必须在真实 workload 下验证：cat /sys/block/vdb/queue/schedulercat /sys/block/vdb/queue/read_ahead_kb27.6 网络优化定位：ss -tinstat -az | grep -Ei 'retrans|drop|overflow'ethtool -S eth0方向： 减少短连接； 使用连接池； 开启 keepalive； 增大 backlog； 修复丢包； 调整缓冲区； 优化协议和序列化； 扩容带宽。监听队列：sysctl net.core.somaxconnsysctl net.ipv4.tcp_max_syn_backlog应用自身 backlog 也必须同步设置。27.7 内核参数管理查看：sysctl -a配置：/etc/sysctl.d/99-app.conf应用：sudo sysctl --system示例方向：net.core.somaxconn = 65535net.ipv4.tcp_max_syn_backlog = 65535net.core.netdev_max_backlog = 16384每个参数要写注释说明来源、适用条件、验证指标和回滚方式。27.8 限流与隔离在线服务：核心接口 -> 独立资源离线任务 -> 低优先级 -> 独立时段 -> IO / CPU 限制systemd：[Service]CPUWeight=50IOWeight=50Nice=10CPUQuota=50%Kubernetes 使用 requests / limits、PriorityClass 和 dedicated node 隔离。27.9 NUMA 与中断亲和查看：lscpu | grep NUMAnumactl --hardwarecat /proc/interrupts适合优化： 高 PPS 网络服务； 数据库； 低延迟系统； 特定硬件加速场景。必须评估： CPU 利用率分布； 跨 NUMA 内存； 中断分布； 弹性伸缩； 故障时的接管能力。27.10 基准测试工具： 场景 工具 HTTP wrk、wrk2、vegeta CPU stress-ng IO fio 内存 stream、stress-ng 网络 iperf3、sockperf 压测要点： 明确目标； 固定版本； 预热； 记录环境； 从低到高压； 找拐点； 观察错误率； 保留原始数据； 不压生产依赖。27.11 变更与回滚优化上线前：[ ] 基线记录[ ] 测试通过[ ] 参数说明[ ] 生效方式明确[ ] 回滚命令[ ] 监控看板[ ] 灰度范围[ ] 停止条件配置管理示例：- name: Tune somaxconn ansible.posix.sysctl: name: net.core.somaxconn value: "65535" sysctl_set: true reload: true本章小结性能调优必须以指标和瓶颈为依据。CPU、内存、IO 和网络的常见优化方向不同，但流程相同：目标、基线、假设、验证、灰度、回滚和沉淀。没有压测和监控的参数不建议进入生产。思考题 为什么调优前必须建立基线？ CPU throttling 应如何优化？ IO 调优有哪些方向？ 短连接高并发场景要关注什么？ 设计一次服务容量压测方案。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。故障排查的目标是用最短时间恢复业务，同时保留足够证据找根因。本章提供一套可复用的 Linux 故障流程：先定影响面，再定资源，再定进程，最后进入应用和依赖。26.1 处理原则1. 恢复优先于完美定位2. 先确认影响面和变更3. 每个结论要有证据4. 止血动作可回滚5. 保留现场日志6. 单点操作要有第二人确认7. 高危命令先确认目标时间线必须实时记录：10:00 告警触发10:02 确认 5xx 上升10:04 发现 10 分钟前有发布10:06 开始回滚10:10 指标恢复26.2 五分钟采集date -Ishostnameuptimedf -hTfree -hvmstat 1 5iostat -xz 1 5ss -sdmesg -T | tail -100systemctl --failed --no-pager进程：ps -eo pid,user,stat,%cpu,%mem,rss,etime,cmd --sort=-%cpu | head -20ps -eo pid,user,stat,%cpu,%mem,rss,etime,cmd --sort=-rss | head -20保存：mkdir -p /tmp/incident-$(date +%F-%H%M)ps auxf > /tmp/incident-*/ps.txtjournalctl -b > /tmp/incident-*/journal.txt26.3 无法登录常见原因： SSH 进程异常； CPU 或 IO 打满； 磁盘满； PAM 或权限配置错误； 账号锁定； 安全组阻断； 主机宕机。检查：ping <host>nc -vz <host> 22ssh -vvv user@<host>云环境使用带外控制台或救援模式。不要盲目重启，先保存可能的内核日志。26.4 CPU 高uptimevmstat 1mpstat -P ALL 1pidstat -u 1ps -eo pid,ppid,user,stat,%cpu,cmd --sort=-%cpu | head -20分类： 现象 方向 us 高 业务计算、GC、算法 sy 高 系统调用、锁、线程切换 wa 高 IO 等待 st 高 虚拟化抢占 R 多 CPU 饱和 进入线程：top -H -p <pid>pidstat -t -p <pid> 1perf record -F 99 -g -p <pid> -- sleep 3026.5 内存异常free -hvmstat 1cat /proc/meminfops -eo pid,user,rss,cmd --sort=-rss | head -20dmesg -T | grep -Ei 'oom|out of memory|killed process'判断： 现象 方向 available 低 容量压力 si/so 持续 swap 压力 RSS 持续增长 泄漏或缓存增长 OOM 日志 已被杀 cgroup event 容器限制 容器：kubectl describe pod <pod>cat /sys/fs/cgroup/<path>/memory.events26.6 磁盘满df -hTdf -ihdu -sh /var/* /opt/* /tmp /root 2>/dev/nulllsof +L1sudo journalctl --disk-usage常见处理：sudo journalctl --vacuum-size=1Gfind /var/log -type f -name '*.gz' -mtime +14 -print根分区满可能导致 SSH、sudo、日志和数据库异常。清理前确认文件归属，不要删除服务正在写的活动文件。26.7 IO 高iostat -xz 1pidstat -d 1cat /proc/meminfo | grep -E 'Dirty|Writeback'常见来源： 数据库 checkpoint； 大查询； 日志刷盘； 备份； 快照； 索引重建； 磁盘故障； 云盘限速。处理： 停止非关键任务； 限制备份速率； 扩容存储； 优化 SQL； 调整应用刷盘策略。26.8 网络异常ip -br addrip routess -sss -antpss -tiethtool -S eth0nstat -az | grep -Ei 'retrans|drop|err'分层：DNS -> TCP -> TLS -> HTTP -> upstream命令：dig api.example.comnc -vz api.internal 8080openssl s_client -connect api.example.com:443 -servername api.example.comcurl -v --max-time 5 https://api.example.com/healthz26.9 服务启动失败systemctl status app --no-pagerjournalctl -u app -n 200 --no-pagersystemctl cat app检查： ExecStart 路径； User 和 Group； WorkingDirectory； 环境变量； 端口占用； 文件权限； 依赖服务； limit； 应用配置。以应用用户验证：sudo -u app /opt/app/bin/start --checksudo -u app cat /opt/app/conf/app.yml26.10 进程消失journalctl -u app --since '1 hour ago'dmesg -T | grep -Ei 'oom|segfault|killed process'systemctl show app -p MainPID -p NRestarts -p Result常见退出： 退出码 常见含义 1 应用错误 126 无执行权限 127 命令不存在 130 SIGINT 137 SIGKILL，常见 OOM 或强制停止 139 SIGSEGV 143 SIGTERM 26.11 高危操作执行前必须确认： 命令 风险 rm -rf 误删不可恢复 dd 覆盖磁盘 mkfs 清空文件系统 iptables / nft 断开管理通道 sysctl -w 影响内核行为 kill -9 丢失清理机会 lvreduce 缩容风险 xfs_repair -L 可能丢数据 确认方式：pwdhostnamereadlink -f <path>ls -la <path>26.12 应急止血常见动作： 现象 止血 发布后异常 回滚 单实例异常 摘流 流量超容量 限流 CPU / 内存耗尽 扩容 批任务抢占 停任务 磁盘满 清理归档 安全事件 隔离主机 止血后仍要保留证据并完成复盘。26.13 故障报告模板# Linux 故障报告## 摘要- 故障时间：- 恢复时间：- 影响范围：- 故障等级：- 当前状态：## 时间线- 监测：- 响应：- 定位：- 止血：- 恢复：## 根因- 直接原因：- 促成条件：- 变更来源：## 证据- 系统指标：- 日志：- 进程：- 网络路径：- 配置变更：## 后续| 行动 | 负责人 | 截止时间 | 优先级 | 验证 ||---|---|---|---|---|本章小结Linux 故障排查按“影响面、变更、资源、进程、应用、依赖”的路径推进。第一分钟保存现场，止血和根因可以并行。所有高危操作都要确认主机、路径和回滚，最终用指标恢复和复盘闭环。思考题 为什么恢复优先于完整根因？ 磁盘满时为什么不能直接删除活动日志？ 进程退出码 137 通常说明什么？ 如何避免防火墙变更锁死自己？ 写一份服务器 CPU 高的排查手册。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。监控的目标是发现异常、定位问题、评估容量和验证变更。告警的目标是让人行动，而不是制造噪音。Linux 监控通常结合指标、日志、事件、trace 和配置审计。25.1 监控分层 层 指标 主机 CPU、内存、磁盘、网络、进程 系统 systemd、日志、内核事件、时间 应用 QPS、延迟、错误率、连接池 中间件 队列、复制、缓存命中率 业务 订单量、支付成功率 体验 客户端成功率、首屏时间 黄金信号： 信号 说明 Latency 延迟 Traffic 流量 Errors 错误 Saturation 饱和度 25.2 主机指标CPU：uptimevmstat 1mpstat -P ALL 1内存：free -hcat /proc/meminfovmstat 1磁盘：df -hTdf -ihiostat -xz 1网络：ip -s linkss -snstat -azethtool -S eth0进程和服务：systemctl --failedpidstat 1journalctl -p err --since '1 hour ago'25.3 常用采集器 采集器 特点 node_exporter Prometheus 主机指标 cAdvisor 容器指标 Telegraf 插件丰富 Datadog Agent 商业 SaaS CloudWatch Agent AWS 生态 Vector / Fluent Bit 日志采集 Prometheus 示例：node_cpu_seconds_totalnode_memory_MemAvailable_bytesnode_filesystem_avail_bytesnode_disk_io_time_seconds_totalnode_network_receive_bytes_total典型 PromQL：100 * (1 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])))25.4 容器监控docker statskubectl top nodeskubectl top pods核心指标： 指标 说明 CPU usage 实际使用 CPU throttled 限流 Memory working set 常用口径 Memory limit 上限 Restart count 重启 Pod phase 状态 Network IO 收发流量 容器内存指标有多个口径，working set 更接近 OOM 风险，但要结合 cgroup memory.stat 分析。25.5 日志监控采集：journald / file / container stdout -> Fluent Bit / Vector -> Loki / Elasticsearch / OpenSearch告警： 类型 示例 关键字 OOM、panic、certificate expired 错误率 5 分钟 ERROR 比例 缺失 心跳日志 数量突变 5xx 突增 审计 sudo fail、SSH 登录 日志告警要结构化，否则很容易被多行、日志级别滥用和采样干扰。25.6 告警设计告警必须包含：名称严重级别影响可能原因排查入口处理手册值班组升级路径分级： 级别 含义 P0 核心业务不可用，立即响应 P1 重要功能受损 P2 存在风险但可等待 P3 观察项 避免： 一个指标配十几个无差异告警； 告警无处理手册； 长期未知告警； 基于临时现象配置过严； 只告警主机 CPU，不告警业务错误率。25.7 常用主机告警CPU 使用率 > 90% 持续 10 分钟内存 available < 10%swap out 持续增长磁盘使用率 > 85%inode 使用率 > 80%磁盘 await > 50ms 持续 5 分钟网络错误包持续增长TCP重传率异常systemd failed units > 0NTP 偏差 > 100ms备份超过 25 小时未成功阈值要结合业务节奏。批处理机器和在线服务不能用同一套阈值。25.8 仪表盘主机总览：可用性CPU / 内存 / 磁盘 / 网络Top 进程最近变更最近告警服务总览：QPS成功率P50 / P95 / P99实例分布上下游依赖资源水位发布事件排障视图：时间线指标关联日志trace变更网络路径25.9 事件与变更监控必须关联事件： 事件 来源 发布 CI/CD 配置变更 配置中心 扩缩容 编排系统 数据库变更 工单 网络变更 云平台审计 值班操作 工单 排障第一问通常是“什么变了”。没有变更事件，定位会慢很多。25.10 故障验证止血后验证：1. 错误率回落2. 延迟恢复基线3. 队列积压下降4. 实例健康5. 日志无新异常6. 客户端指标恢复7. 24 小时内复盘复盘产物： 时间线； 根因； 为什么监控没更早发现； 为什么告警没有触发； 新监控； 自动化检查； 容量计划； 责任人和截止时间。本章小结监控要覆盖主机、容器、应用、依赖和业务指标，并把告警与变更、日志和 trace 关联。好的告警能行动、能定位、能升级。监控体系的价值通过故障发现时间和排障效率验证。思考题 黄金信号包括什么？ CPU 使用率高是否一定需要告警？ 容器内存监控应关注哪些口径？ 如何减少无效告警？ 为一个 Web 服务设计主机和应用监控清单。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。备份的价值不在于文件存在，而在于能按目标恢复。恢复目标通常用 RPO 和 RTO 衡量：最多丢多少数据，最多停多久。没有演练过的备份不能视为可用备份。24.1 备份目标 指标 含义 RPO 恢复点目标，最多丢失多少数据 RTO 恢复时间目标，最多允许多久不可用 RCO 恢复一致性目标 保留期 历史版本保存多久 加密 静态和传输加密 示例：订单数据库 RPO 5 分钟 RTO 30 分钟 全量每日 + 增量每 5 分钟 异地保存 季度演练24.2 备份对象系统： /etc； systemd unit； crontab； 包列表； 磁盘分区表； 内核参数； 用户和 sudoers。应用： 代码版本； 配置； Secret 引用； 证书； 部署清单。数据： 数据库； 对象存储； 消息队列状态； 索引数据； 用户上传文件。不要备份秘密明文，也不要把备份权限开放给所有人。24.3 文件备份tar：sudo tar -czf /backup/etc-$(date +%F).tar.gz \ --one-file-system /etcrsync：sudo rsync -a --delete \ /data/ backup-server::data/增量：sudo rsync -a --delete --link-dest=/backup/current /data/ /backup/$(date +%F)/恢复：sudo tar -xzf etc-2026-08-25.tar.gz -C /tmp/restoresudo rsync -a /backup/2026-08-25/ /data/rsync 目标路径末尾 / 语义不同，执行前必须预览 --dry-run。24.4 数据库备份MySQL 逻辑备份：mysqldump --single-transaction --triggers --routines --events \ -h db.internal -u backup_user -p shop > shop.sqlPostgreSQL：pg_dump -Fc -h db.internal -U backup_user shop > shop.dumppg_restore -h db.internal -U postgres -d shop_copy shop.dumpMongoDB：mongodump --host mongo.internal --db order --out /backup/mongomongorestore --host mongo.internal --db order /backup/mongo/order大数据库应使用物理备份、快照、WAL 或 oplog 方案，并按数据库官方恢复流程设计。24.5 快照文件系统快照：sudo lvssudo lvcreate -s -n datalv-snap -L 10G /dev/datavg/datalvsudo mount /dev/datavg/datalv-snap /mnt/snapsudo umount /mnt/snapsudo lvremove /dev/datavg/datalv-snap云盘快照通常由平台提供。数据库快照要保证一致性： 使用数据库一致性快照能力； 或先冻结写入； 或使用备份锁； 恢复后执行一致性校验； 记录 LSN / WAL 位点。24.6 加密与校验加密：gpg --symmetric --output backup.tar.gz.gpg backup.tar.gzgpg --decrypt --output backup.tar.gz backup.tar.gz.gpg校验：sha256sum backup.tar.gz > backup.tar.gz.sha256sha256sum -c backup.tar.gz.sha256备份元数据：备份时间主机数据集版本大小校验值加密方式保留期限恢复步骤24.7 保留策略常见策略：每日 7 份每周 4 份每月 12 份每年按合规保存不要只保留“最新一份”。逻辑误删除、勒索加密、配置错误和数据损坏都依赖历史版本。异地：生产机房 -> 同城备份 -> 异地备份备份存储要独立权限，避免生产主机被攻破后可直接删除备份。24.8 恢复演练演练步骤：1. 选择备份点2. 准备隔离环境3. 恢复系统或数据4. 启动应用5. 校验数据6. 执行核心业务用例7. 测量 RTO 和 RPO8. 记录问题9. 优化流程数据校验：SELECT COUNT(*) FROM orders;SELECT MAX(created_at) FROM orders;SELECT * FROM orders ORDER BY id DESC LIMIT 10;应用校验：登录创建订单支付状态查询历史关键报表上下游链路24.9 监控与告警必须监控： 指标 说明 备份成功率 是否按计划完成 备份时长 是否接近窗口 备份大小 突变需解释 校验结果 文件是否可读 恢复演练结果 是否可用 存储水位 备份空间 备份年龄 最近成功时间 告警示例：最近一次成功备份超过 25 小时备份失败连续 2 次校验失败备份耗时环比增长 50%备份存储剩余低于 20%24.10 恢复手册模板# 数据恢复手册## 1. 触发条件- 故障类型：- 影响范围：- 决策人：## 2. 恢复目标- 目标 RTO：- 目标 RPO：- 备份点：- 恢复环境：## 3. 前置检查- 备份完整性：- 权限：- 网络：- 依赖服务：- 通知对象：## 4. 恢复步骤- 命令：- 检查点：- 超时：- 负责人：## 5. 验证- 数据一致性：- 应用健康：- 业务用例：- 监控指标：## 6. 收尾- 切流：- 清理临时资源：- 复盘：- 记录改进：本章小结备份设计从 RPO 和 RTO 出发，覆盖系统、配置、应用和数据。备份必须加密、校验、异地保存并有独立权限。恢复演练是唯一能证明备份可用的方式。思考题 RPO 和 RTO 分别决定什么设计？ 为什么快照不能完全替代备份？ 备份保留策略为什么要多版本？ 如何验证数据库恢复点？ 为订单系统设计备份和演练方案。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。防火墙控制主机或网络边界上的流量。Linux 上常见 nftables、iptables、firewalld、ufw，同时云平台还有安全组。排障时必须同时看这两层，否则容易得出错误结论。23.1 netfilterPacket -> Prerouting -> Input / Forward -> Output -> Postroutingiptables 表： 表 用途 filter 过滤 nat 地址转换 mangle 修改包 raw 连接跟踪前处理 security SELinux 相关 链： 链 时机 PREROUTING 路由前 INPUT 发往本机 FORWARD 转发 OUTPUT 本机发出 POSTROUTING 路由后 23.2 iptables查看：sudo iptables -L -n -vsudo iptables -t nat -L -n -vsudo iptables -S放行：sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPTsudo iptables -A INPUT -p tcp -s 203.0.113.0/24 --dport 22 -j ACCEPT拒绝：sudo iptables -A INPUT -p tcp --dport 3306 -j DROP保存与恢复：sudo iptables-save > firewall.rulessudo iptables-restore < firewall.rules新系统更推荐 nftables 或 firewalld。iptables 命令在很多发行版上是兼容工具。23.3 nftables查看：sudo nft list rulesetsudo nft list tables示例：sudo nft add table inet filtersudo nft add chain inet filter input '{ type filter hook input priority 0; policy drop; }'sudo nft add rule inet filter input iifname "lo" acceptsudo nft add rule inet filter input ct state established,related acceptsudo nft add rule inet filter input tcp dport 443 accept保存：sudo nft list ruleset > /etc/nftables.conf修改远程主机防火墙时，必须先放行 SSH 和已建立连接，再切换默认策略。23.4 firewalldsudo firewall-cmd --statesudo firewall-cmd --get-active-zonessudo firewall-cmd --list-all开放：sudo firewall-cmd --permanent --add-service=httpssudo firewall-cmd --permanent --add-port=8080/tcpsudo firewall-cmd --reload限制来源：sudo firewall-cmd --permanent --new-zone=sshadminsudo firewall-cmd --permanent --zone=sshadmin --add-source=203.0.113.0/24sudo firewall-cmd --permanent --zone=sshadmin --add-service=sshsudo firewall-cmd --reloadruntime 与 permanent 要区分： 模式 生效范围 默认 runtime 立即生效，重载可能丢失 --permanent 写配置，需 reload 23.5 ufwsudo ufw status verbosesudo ufw allow 443/tcpsudo ufw allow from 203.0.113.0/24 to any port 22 proto tcpsudo ufw deny 3306/tcpsudo ufw enable查看编号：sudo ufw status numberedsudo ufw delete 3ufw 适合简单主机，不适合表达复杂网络策略。23.6 云安全组云安全组通常在虚拟化或 SDN 层生效，主机内 iptables 不一定能看到。排查连接：ip route get <peer>nc -vz <peer> <port>curl -v http://<peer>:<port>变更原则： 最小开放； 命名带业务和方向； 避免大段 0.0.0.0/0； 入方向默认拒绝； 记录变更原因； 定期清理过期规则； 与主机防火墙责任分层。23.7 NAT查看：sudo iptables -t nat -L -n -vsudo nft list table ip natSNAT：sudo iptables -t nat -A POSTROUTING \ -s 10.0.0.0/24 -o eth0 -j MASQUERADEDNAT：sudo iptables -t nat -A PREROUTING \ -p tcp --dport 8080 -j DNAT --to-destination 10.0.0.10:80转发开关：sudo sysctl -w net.ipv4.ip_forward=123.8 连接跟踪sudo conntrack -Lsudo conntrack -Csudo conntrack -Ssysctl net.netfilter.nf_conntrack_max常见问题： 表满丢新建连接； 长连接被超时清理； NAT 端口耗尽； 规则不对称导致回包丢； 双栈规则只配了 IPv4。IPv6：sudo ip6tables -L -n -vsudo nft list ruleset23.9 防火墙设计主机入方向基线：1. 允许 lo2. 允许 established,related3. 允许 ICMP / ICMPv6 必要类型4. 允许 SSH 限制来源5. 允许业务端口6. 其他默认拒绝应用部署模型：Internet -> LB: 443 -> App: 8080 only from LB -> DB: 3306 only from App -> Admin: 22 only from bastion23.10 排障流程1. 确认源、目标、端口、协议2. ip route get 确认路径3. nc / curl 分层探测4. 查云安全组5. 查主机防火墙6. 查 conntrack7. tcpdump 确认包是否到达8. 修复后双向验证抓包：sudo tcpdump -ni any host <peer> and port <port>能收到 SYN 但没有 SYN-ACK，通常是服务未监听、应用拒绝或防火墙丢弃。收到 RST 则更可能是应用或端口未开放。本章小结防火墙策略要按路径、方向、协议、端口和来源精确描述。Linux 主机可能同时存在 nftables、firewalld、ufw 和云安全组，多层策略都要检查。远程变更必须先保住管理通道和已建立连接。思考题 INPUT 和 FORWARD 链分别处理什么流量？ firewalld runtime 和 permanent 有什么区别？ 云安全组为什么在主机 iptables 中看不到？ DROP 和 REJECT 的排障表现有什么不同？ 设计一个 Web、App、DB 三层主机防火墙策略。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。SSH 是 Linux 生产环境的主要入口。治理 SSH 的目标是：只有可信来源能连、只有授权用户能登录、登录后操作可追踪、异常登录可发现、密钥可轮换。22.1 SSH 基础连接：ssh -i ~/.ssh/id_ed25519 app@192.0.2.10ssh -J bastion@203.0.113.10 app@192.0.2.20配置：~/.ssh/config示例：Host web-prod HostName 192.0.2.10 User app IdentityFile ~/.ssh/id_ed25519 ProxyJump bastion.example.internal ServerAliveInterval 30 ServerAliveCountMax 3文件： 文件 用途 ~/.ssh/id_ed25519 私钥 ~/.ssh/id_ed25519.pub 公钥 ~/.ssh/authorized_keys 服务器授权公钥 ~/.ssh/known_hosts 已知主机 ~/.ssh/config 客户端配置 22.2 密钥管理生成：ssh-keygen -t ed25519 -a 100 -C "dev01@laptop"上传公钥：ssh-copy-id -i ~/.ssh/id_ed25519.pub app@192.0.2.10权限：chmod 700 ~/.sshchmod 600 ~/.ssh/id_ed25519chmod 644 ~/.ssh/id_ed25519.pubchmod 600 ~/.ssh/authorized_keys轮换： 生成新密钥； 添加新公钥； 验证登录； 删除旧公钥； 记录变更； 发现泄露立即撤销。22.3 sshd 配置查看：sudo sshd -Tsudo systemctl status sshd常见配置：Port 22AddressFamily anyListenAddress 0.0.0.0PermitRootLogin noPasswordAuthentication noPubkeyAuthentication yesAuthenticationMethods publickeyMaxAuthTries 3MaxSessions 10LoginGraceTime 30AllowGroups ssh-usersX11Forwarding noAllowTcpForwarding yesClientAliveInterval 300ClientAliveCountMax 2不同发行版服务名可能是 ssh 或 sshd。修改流程：sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F-%H%M)sudo vim /etc/ssh/sshd_configsudo sshd -tsudo systemctl reload sshd严禁关闭现有会话后直接改配置。应保留一个已登录会话，并用新终端验证。22.4 限制来源防火墙：sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcpsudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.0/24" port port="22" protocol="tcp" accept'云安全组应只允许堡垒机或办公出口访问 SSH，不建议 0.0.0.0/0 开放 22。hosts.allow / deny 在不同发行版支持情况不同，现代系统更常用防火墙、云安全组或 fail2ban。22.5 多因素认证常见方式： 方式 特点 SSH 密钥 + TOTP 本机策略 跳板机 + SSO / MFA 集中身份 硬件密钥 FIDO2 安全性强 云平台临时证书 可控生命周期 高权限账号、生产变更入口和特权操作必须具备第二因素。22.6 跳板机模型User -> Bastion / MFA -> SSH key / short-lived cert -> Production host -> sudo command allowlist -> audit log建议： 生产主机不直接暴露公网； 按环境划分跳板机； 登录身份与业务身份区分； 会话录像； 文件传输受控； 定期审计账号。22.7 sudo 审计授权：ops01 ALL=(app) /opt/app/bin/deploy.shdba01 ALL=(mysql) /usr/bin/mysqladmin日志：sudo journalctl -t sudo --since todaysudo grep sudo /var/log/auth.logsudo grep sudo /var/log/secure要求： 命令路径绝对； 限制参数； 不使用 NOPASSWD: ALL； 定期回收； 与工单关联。22.8 会话审计命令记录：historyfc -l -100审计增强： 方案 说明 auditd execve 记录命令执行 syslog / journald 集中系统日志 堡垒机会话录像 可回放 sshd ForceCommand 强制包装命令 rootsh / sudo log 特权操作记录 方案要防止普通用户关闭。审计日志集中发送到独立系统。22.9 异常登录排查last -alastb | head -50whojournalctl -u ssh --since '24 hours ago'grep 'Accepted publickey' /var/log/auth.loggrep 'Failed password' /var/log/secure关注： 现象 风险 深夜陌生 IP 登录 可能入侵 新 authorized_keys 持久化 大量失败后成功 爆破成功 未知用户创建 权限提升 sshd 配置被改 后门 日志中断 痕迹清理 应急： 隔离主机； 禁用异常 key； 锁定账号； 保留内存和磁盘证据； 排查横向移动； 轮换相关凭据； 按安全事件流程通知。22.10 SSH 故障排查ssh -vvv app@192.0.2.10sudo journalctl -u ssh -n 200sudo sshd -T | grep -Ei 'permitroot|password|pubkey|allowgroups'客户端：ls -l ~/.sshssh-keygen -y -f ~/.ssh/id_ed25519nc -vz 192.0.2.10 22常见问题： 私钥权限过宽； authorized_keys 权限错误； 用户 home 权限过宽； AllowGroups 未包含用户； 密码认证被禁； 账号锁定或 nologin； PAM 配置错误； 防火墙阻断。本章小结SSH 治理应从入口、身份、密钥、授权和审计五方面入手。生产环境使用密钥或短期证书，禁用 root 和密码登录，只允许可信来源访问，并把 sudo 与会话日志集中保存。修改 sshd 时必须保留现有会话并校验配置。思考题 修改 sshd 时为什么要保留现有会话？ 如何安全轮换 SSH key？ 如何设计跳板机与生产主机访问链路？ 哪些 SSH 异常日志需要告警？ 如何把 sudo 操作和工单关联？
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Linux 安全不是一堆积攒的加固开关，而是一套边界：最小攻击面、最小权限、可信来源、及时补丁、审计、加密和快速响应。本章按账号、SSH、文件、内核、服务、补丁和入侵排查组织。21.1 安全基线1. 只安装必要软件2. 只开放必要端口3. 每个应用独立低权限账号4. SSH 使用密钥并限制来源5. root 不直接运行业务6. sudo 按命令授权7. 补丁和 CVE 有跟踪流程8. 日志集中保存9. 密钥有轮换10. 变更可审计查看当前信息：cat /etc/os-releaseuname -aidss -lntupsystemctl list-unit-files --state=enabled21.2 账号加固查看账号：getent passwdawk -F: '($2 != "x" && $2 != "*" && $2 != "!") {print}' /etc/shadowawk -F: '$7 !~ /(nologin|false)/ {print $1}' /etc/passwd锁定异常账号：sudo passwd -l usernamesudo usermod -s /sbin/nologin username密码策略：/etc/login.defs/etc/security/pwquality.conf/etc/security/faillock.conf常见配置：PASS_MAX_DAYS 90PASS_MIN_DAYS 1PASS_MIN_LEN 12云环境更推荐集中身份、密钥登录和 MFA，而不是依赖本机密码复杂度。21.3 文件与权限检查：find /etc -type f -perm /o+w -lsfind / -xdev -type f -perm /4000 -ls 2>/dev/nullstat /etc/shadow敏感文件：sudo chmod 600 /etc/shadowchmod 600 ~/.ssh/id_ed25519chmod 644 ~/.ssh/authorized_keyschmod 700 ~/.sshSUID 文件清单应纳入基线管理。新增或变化的 SUID 文件需要解释来源。21.4 软件与补丁查看可升级：sudo apt update && apt list --upgradablesudo dnf check-update漏洞扫描：debsecandnf updateinfo list available补丁原则： 跟踪 CVE 影响面； 区分远程利用和本地利用； 测试环境验证； 控制重启窗口； 备份回滚； 记录版本； 不长期“先不更”。21.5 内核参数加固查看：sysctl net.ipv4.conf.all.rp_filtersysctl net.ipv4.icmp_echo_ignore_broadcastssysctl kernel.kptr_restrictsysctl kernel.dmesg_restrict常见方向：kernel.kptr_restrict = 2kernel.dmesg_restrict = 1net.ipv4.conf.all.rp_filter = 1net.ipv4.icmp_echo_ignore_broadcasts = 1配置文件：/etc/sysctl.d/*.conf应用：sudo sysctl --system不同 workload 和内核版本可能有差异，修改前要逐项验证。21.6 审计auditd：sudo systemctl status auditdsudo auditctl -lsudo ausearch -k identity查看登录：lastlastbwhowsudo journalctl -u ssh --since today建议审计： 对象 事件 sudoers 修改 passwd / group 修改 SSH key 写入 systemd unit 创建修改 cron 修改 安全工具 停止和卸载 数据目录 异常访问 日志必须集中保存，否则攻击者可以清理本机痕迹。21.7 服务加固systemctl list-unit-files --state=enabledss -lntup禁用：sudo systemctl disable --now service常见不必要服务： 类型 示例 打印 cups 邮件 本地 mail relay，按需 远程桌面 vnc 旧协议 telnet、rsh 调试服务 未知 debug port systemd 沙箱示例：[Service]NoNewPrivileges=truePrivateTmp=trueProtectSystem=strictProtectHome=trueReadWritePaths=/var/lib/app /var/log/appCapabilityBoundingSet=按应用能力逐步收紧，避免一次性过严导致服务不可用。21.8 证书与密钥检查：find /etc /opt /home -xdev -type f \ \( -name '*.pem' -o -name '*.key' -o -name '*credentials*' \) -ls原则： 私钥权限 600； 不提交 Git； 使用 Secret Manager； 定期轮换； 区分环境； 审计使用； 发现泄露立即撤销。21.9 入侵迹象排查账号：cat /etc/passwdsudo cat /etc/shadowgetent group wheel sudolast -a | head -30lastb | head -30进程与网络：ps auxfss -antpss -lntpcrontab -lsudo ls -la /etc/cron.*文件与单元：find /tmp /var/tmp /dev/shm -type f -executable -lssystemctl list-timers --allfind /etc/systemd/system -type f -mtime -7 -ls完整性：rpm -Vadpkg --verify可疑迹象： 未知 SUID 文件； 未知定时任务； 异常外连； SSH key 新增； 日志被清理； 安全软件停止； 系统库被修改。确认事件后应隔离主机、保全证据、按应急流程处理，不要在被控机器上反复试探。21.10 云与容器注意点云主机： 安全组默认拒绝； 管理端口只对堡垒机开放； 使用云审计和 flow log； 元数据服务加固； 云账号权限最小化； 密钥不放在 user-data。容器： 不使用 root 运行； 只挂载必要目录； 不随意 --privileged； 镜像来自可信仓库； 扫描漏洞； 限制 capability； NetworkPolicy 控制访问； 保护 Docker socket。本章小结安全加固的核心是减少攻击面和权限，持续打补丁，集中审计和快速响应。账号、SSH、sudo、文件权限、服务、密钥、内核参数和日志都要有基线。安全不是一次加固，而是持续验证。思考题 为什么业务进程不用 root 运行？ 如何发现异常 SUID 文件？ auditd 应重点监控哪些事件？ systemd 沙箱有哪些常用指令？ 怀疑主机入侵时的前十个检查动作是什么？
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。性能分析不是收集所有数据，而是根据假设选择证据。Linux 提供 uptime、vmstat、pidstat、iostat、perf、strace、bcc 和火焰图等工具。关键是建立从现象到瓶颈的分析路径。20.1 USE 方法对每类资源检查： 检查项 含义 Utilization 使用率 Saturation 饱和度或排队 Errors 错误 示例： 资源 Utilization Saturation Errors CPU us/sy/id runq、throttle machine check 内存 available swap、reclaim OOM IO util、带宽 await、aqu-sz IO error 网络 带宽、PPS drops、retrans CRC、RST 20.2 第一分钟巡检uptimedf -hTfree -hdmesg -T | tail -50systemctl --failed --no-pagerss -s进程：ps -eo pid,user,stat,%cpu,%mem,rss,etime,cmd \ --sort=-%cpu | head -20ps -eo pid,user,stat,%cpu,%mem,rss,etime,cmd \ --sort=-rss | head -20IO 与 CPU：vmstat 1 5iostat -xz 1 520.3 vmstatvmstat 1 10关键字段： 字段 含义 r 可运行进程 b 不可中断进程 swpd swap 使用 free 空闲内存 buff/cache 缓存 si / so swap 换入换出 bi / bo 块设备读写 us / sy / id / wa / st CPU 分布 判断：r 持续大于 CPU 数 -> CPU 饱和b 持续高 -> IO 等待si/so 持续 -> 内存压力wa 高 -> IO 压力st 高 -> 虚拟化抢占20.4 pidstat安装：sudo apt install sysstatsudo dnf install sysstatCPU：pidstat -u 1pidstat -u -p <pid> 1内存：pidstat -r 1IO：pidstat -d 1线程：pidstat -t -p <pid> 1上下文切换：pidstat -w 120.5 stracestrace -p <pid>strace -c -p <pid>strace -T -e trace=file,network -p <pid>常见场景： 场景 过滤 找不到配置 trace=file 网络异常 trace=network 进程卡住 查看当前阻塞系统调用 系统调用开销 -c 统计 strace 有明显性能开销，不要在高流量生产进程上长期附着。20.6 lsof 与 /proclsof -nP -p <pid>lsof +L1lsof -nP -iTCP -sTCP:LISTEN/proc：cat /proc/<pid>/statuscat /proc/<pid>/iocat /proc/<pid>/limitstr '\0' '\n' < /proc/<pid>/environreadlink -f /proc/<pid>/cwd适合在不安装工具的机器上快速取证。20.7 perf统计：perf stat -p <pid> -- sleep 10采样：sudo perf record -F 99 -g -p <pid> -- sleep 30sudo perf report --stdio内核符号：sudo perf report --kallsyms /proc/kallsyms常见输出： 指标 含义 task-clock 任务运行时间 context-switches 上下文切换 cpu-migrations CPU 迁移 page-faults 缺页 cycles CPU 周期 instructions 指令数 IPC 指令 / 周期 20.8 火焰图安装 FlameGraph：git clone https://github.com/brendangregg/FlameGraph.git生成：sudo perf record -F 99 -g -p <pid> -- sleep 30sudo perf script > perf.scriptFlameGraph/stackcollapse-perf.pl perf.script > perf.foldedFlameGraph/flamegraph.pl perf.folded > flame.svg解读： 宽度代表样本占比； 栈深代表调用层级； 关注最宽的业务或系统路径； 区分 on-CPU 和 off-CPU； 保留符号和二进制版本。20.9 eBPF / bccsudo execsnoopsudo opensnoopsudo biolatency 10 1sudo tcpretranssudo runqlat适用： 新进程追踪； IO 延迟分布； TCP 重传； 调度延迟； 内核与用户态联合观测。需要内核版本、权限和 BTF 支持。容器环境可能受安全策略限制。20.10 性能分析流程1. 明确现象和影响面2. 确认近期变更3. 看黄金指标：延迟、流量、错误、饱和度4. 判断资源：CPU、内存、IO、网络5. 定位进程和线程6. 进入运行时内部栈7. 提出假设并验证8. 小流量或回滚验证效果9. 记录指标和结论不要跳过基线。没有延迟分布和对比版本，很难证明“变慢”。20.11 报告模板## 问题- 现象：- 开始时间：- 影响范围：## 基线- 指标：- 时间窗口：- 对比对象：## 证据- 系统指标：- 进程指标：- 日志：- trace：- profile：## 根因- 直接原因：- 促成条件：## 验证- 变更：- 前后指标：- 回滚：## 后续- 监控：- 容量：- 优化：本章小结性能分析要先建立现象、影响面和基线，再用 USE 方法检查资源，用进程工具定位到具体执行流，最后进入运行时 profile。工具只是证据采集方式，结论必须有前后对比和回滚验证。思考题 USE 方法的三个检查项是什么？ vmstat 中 b 列高说明什么？ strace 为什么不能随意长期使用？ 火焰图的宽度代表什么？ 设计一次线上延迟升高的排查报告。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Namespace 解决“能看到什么”，cgroup 解决“能用多少”。容器、systemd slice 和云原生资源隔离都建立在这两个机制上。理解它们，才能定位容器看不到宿主机进程、CPU 限流、内存被杀和存储视图差异。19.1 Namespace常见 namespace： Namespace 隔离对象 PID 进程编号 NET 网卡、路由、iptables、socket MNT 挂载点 UTS 主机名 IPC System V IPC、POSIX 消息队列 USER UID / GID 映射 TIME 系统时钟，较新内核支持 查看：lsnslsns -t pidreadlink /proc/<pid>/ns/pidls -l /proc/<pid>/ns19.2 unshare 示例创建新的 UTS namespace：sudo unshare --uts bashhostname demohostnameexit创建新的 mount namespace：sudo unshare --mount bashmount --bind /tmp /mntexit这些实验说明隔离边界，但生产容器由容器运行时组合 namespace、cgroup、capabilities 和文件系统。19.3 PID namespace容器内常见 PID 1 视角：Host PID 12345 -> Container PID 1 -> Container app process查看：ps -efdocker top <container>sudo nsenter -t <host-pid> -p -m ps -efPID 1 责任： 初始化进程； 转发信号； 回收子进程； 处理退出。Shell 入口脚本如果不转发信号，容器可能无法优雅停止。19.4 Network namespace查看：sudo ip netns listsudo ip netns exec web ip addrsudo ip netns exec web ss -lntp创建并连接两个 namespace：sudo ip netns add websudo ip netns add dbsudo ip link add veth-web type veth peer name veth-dbsudo ip link set veth-web netns websudo ip link set veth-db netns dbsudo ip netns exec web ip addr add 10.200.1.1/24 dev veth-websudo ip netns exec db ip addr add 10.200.1.2/24 dev veth-dbsudo ip netns exec web ip link set veth-web upsudo ip netns exec db ip link set veth-db up清理：sudo ip netns del websudo ip netns del db19.5 cgroup 版本cgroup v1：/sys/fs/cgroup/cpu/sys/fs/cgroup/memorycgroup v2：/sys/fs/cgroup cpu.max memory.max io.max查看版本：stat -fc %T /sys/fs/cgroupmount | grep cgroupv2 输出常见为 cgroup2fs，v1 常见为 tmpfs。19.6 CPU cgroupv1 常用：cpu.cfs_period_uscpu.cfs_quota_uscpu.sharesv2：cat /sys/fs/cgroup/cpu.maxcat /sys/fs/cgroup/cpu.stat示例：200000 100000表示每 100000 微秒可使用 200000 微秒 CPU，即 2 核。限流指标： 指标 含义 nr_throttled 被限流次数 throttled_usec 被限流时长 nr_periods 周期数 19.7 Memory cgroupv2：cat /sys/fs/cgroup/memory.currentcat /sys/fs/cgroup/memory.maxcat /sys/fs/cgroup/memory.stat限制： 文件 作用 memory.max hard limit memory.high soft limit，触发回收 memory.swap.max swap 限制 memory.events OOM 等事件 hard limit 达到时可能触发 OOM Killer。页缓存也会计入 cgroup memory current，需要结合 memory.stat 分析。19.8 IO cgroupv2：cat /sys/fs/cgroup/io.statcat /sys/fs/cgroup/io.maxio.max 示例：259:0 rbps=104857600 wbps=max riops=max wiops=1000设备号可用：lsblkcat /proc/partitionsIO 限制效果与存储类型和队列深度有关，需压测验证。19.9 容器视角查看进程 cgroup：cat /proc/<pid>/cgroup查看容器资源：docker statsdocker inspect <container> --format '{{json .HostConfig.Resources}}'kubectl describe pod <pod>常见差异： 现象 解释 容器内看不到宿主机进程 PID namespace 容器内 CPU 核数不同 cgroup 或 runtime 暴露方式 容器内 hostname 变化 UTS namespace 容器写入重启后消失 可写层未持久化 宿主机内存正常但容器被杀 memory limit 19.10 systemd 与 cgroup查看服务层级：systemctl status appsystemd-cglssystemd-cgtop资源限制：[Service]CPUQuota=200%MemoryHigh=4GMemoryMax=6GTasksMax=1024IOWeight=100systemd 会把服务放入 cgroup，方便聚合观察和限制资源。19.11 常见案例容器内存 OOMKilledkubectl describe pod <pod>cat /sys/fs/cgroup/<path>/memory.eventscat /sys/fs/cgroup/<path>/memory.stat分析 anon、file、slab 和 workingset。CPU 延迟高但使用率不满cat /sys/fs/cgroup/<path>/cpu.statkubectl get pod <pod> -o jsonpath='{.spec.containers[0].resources.limits.cpu}'如果 throttled_usec 增长，说明限流。容器无法看到挂载盘docker inspect <container> --format '{{json .Mounts}}' | jq .kubectl describe pod <pod>检查 volume、bind mount、subPath 和挂载 namespace。本章小结Namespace 提供视图隔离，cgroup 提供资源限制。容器排障要同时看宿主机全局视角和容器内部视角。CPU throttling、memory events、PID 1 信号处理和可写层持久化是生产高频问题。思考题 PID namespace 为什么会让容器内进程显示为 PID 1？ cgroup v1 和 v2 的组织方式有什么差异？ cpu.max=200000 100000 表示多少 CPU？ memory.max 和 memory.high 有什么区别？ 为什么容器入口脚本要转发信号？
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Linux 网络栈从网卡收包开始，经过中断、软中断、协议栈、socket、进程读写，再到路由和发包。应用网络慢可能是协议问题，也可能是丢包、队列、conntrack、CPU 或缓冲区问题。18.1 收发包路径NIC -> DMA / Ring Buffer -> Hard IRQ -> Soft IRQ -> IP / TCP / UDP -> Socket Receive Queue -> Application read发包：Application write -> Socket Send Buffer -> TCP / IP -> QDisc -> NIC Ring -> Send18.2 基础命令地址与路由：ip -br addrip routeip -s linkethtool eth0ethtool -S eth0连接：ss -sss -antpss -lntpss -tiss -m统计：netstat -snstat -azcat /proc/net/softnet_statcat /proc/net/snmp18.3 网卡统计ethtool -S eth0 | grep -Ei 'drop|err|fifo|miss|overflow'ip -s link show eth0常见字段： 指标 含义 rx_dropped 採收丢弃 tx_dropped 发送丢弃 rx_errors 接收错误 tx_errors 发送错误 rx_missed Ring Buffer 缺失 rx_no_buffer 缓冲不足 不同网卡驱动字段名称可能不同。要关注持续增长值，而不是只看单次累计值。18.4 软中断查看：mpstat -P ALL 1cat /proc/interruptscat /proc/net/softnet_statwatch -n1 'cat /proc/softirqs'softnet 第二列丢弃：cat /proc/net/softnet_stat处理方向： 开启 RSS / 多队列； 调整队列亲和； 增加缓冲； 降低单 CPU 中断压力； 扩容或限流。18.5 Ring Buffer 与队列查看：ethtool -g eth0ethtool -l eth0ethtool -x eth0调整：sudo ethtool -G eth0 rx 4096 tx 4096RSS：cat /proc/irq/<irq>/smp_affinity_listecho 2 | sudo tee /proc/irq/<irq>/smp_affinity_list增大缓冲会增加内存和排队延迟，必须结合延迟指标评估。18.6 TCP 缓冲与拥塞查看：ss -tiss -msysctl net.core.rmem_maxsysctl net.core.wmem_maxsysctl net.ipv4.tcp_rmemsysctl net.ipv4.tcp_wmemsysctl net.ipv4.tcp_congestion_control关键观察： 字段 含义 cwnd 拥塞窗口 ssthresh 慢启动阈值 retrans 重传 rto 重传超时 rtt 往返时间 Send-Q / Recv-Q socket 队列 网络参数优化必须基于路径 RTT、丢包率和吞吐目标，不能照抄所谓万能参数。18.7 防火墙与 conntrack查看：sudo iptables -L -n -vsudo nft list rulesetsudo conntrack -Ssudo conntrack -Csysctl net.netfilter.nf_conntrack_max表满时新建连接可能失败：dmesg -T | grep -i conntrack处理： 监控使用率； 评估表上限； 缩短不合理超时； 优化规则顺序； 控制短连接风暴。18.8 Loopback 与本地通信ip addr show loss -lntupcurl -v http://127.0.0.1:8080/healthz本地通信仍会经过协议栈和 socket。排查时可用：sudo tcpdump -i lo -nn port 8080strace -e trace=network -p <pid>18.9 eBPF 与高级观测常用工具： 工具 场景 tcpretrans TCP 重传 tcplife 连接生命周期 tcpconnect 主动连接 tcpaccept 被动连接 biolatency IO 延迟 execsnoop 新进程 opensnoop 文件打开 安装：sudo apt install bpfcc-toolssudo dnf install bcc-tools工具名在不同包中可能带 -bpfcc 后缀。18.10 常见故障丢包ip -s link show eth0ethtool -S eth0cat /proc/net/softnet_statnstat -az | grep -Ei 'drop|err'定位层次：网卡 / 驱动 -> softirq -> conntrack / firewall -> socket buffer -> application连接队列溢出ss -lntnetstat -s | grep -Ei 'listen|overflow'sysctl net.core.somaxconnsysctl net.ipv4.tcp_max_syn_backlog处理： 增大应用 accept backlog； 调整系统 backlog； 优化应用 accept 速度； 扩容。重传高nstat -az | grep -i retransss -timtr -rwzc 100 <peer>区分本机丢包、路径丢包和对端处理慢。本章小结Linux 网络栈排障要沿收发包路径分层：网卡、中断、协议栈、conntrack、socket 和应用。ethtool 看设备层，ss 看连接和缓冲，netstat / nstat 看协议统计，tcpdump 和 eBPF 提供证据。调优前必须先定位丢包和队列瓶颈。思考题 硬中断和软中断分别做什么？ rx_dropped 和 Listen Overflows 有什么区别？ Ring Buffer 增大会带来什么权衡？ conntrack 表满会表现为什么？ 如何证明一次重传发生在本机、路径还是对端？
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。IO 栈连接文件系统和块设备。应用一次 write 可能经历页缓存、文件系统、通用块层、IO 调度器、设备驱动和云存储。定位 IO 问题要区分慢在应用、文件系统、块设备还是远端存储。17.1 IO 栈全景Application -> System Call -> VFS -> File System -> Page Cache -> Block Layer -> IO Scheduler -> Device Driver -> Disk / SSD / Cloud Disk同步 IO：调用线程等待 IO 完成异步 IO：提交 IO 后继续执行 -> completion notification17.2 指标延迟： 指标 含义 await IO 平均等待时间 r_await 读等待 w_await 写等待 svctm 旧指标，现代工具不推荐单独依赖 吞吐： 指标 含义 r/s、w/s IOPS rkB/s、wkB/s 带宽 rrqm/s、wrqm/s 合并请求 队列： 指标 含义 aqu-sz 平均队列深度 rareq-sz 平均读请求大小 wareq-sz 平均写请求大小 util 设备忙碌时间占比 iostat -xz 117.3 iostat 解读示例：Device r/s w/s rkB/s wkB/s await aqu-sz utilvdb 100 500 800 8000 20.00 10.0 95.00判断： 现象 方向 await 高、util 高 设备压力高或规格不足 IOPS 高、吞吐低 小 IO 吞吐高、IOPS 低 大块顺序 IO util 100% 但 await 低 SSD 并行能力强，util 语义有限 单进程 bo 高 应用刷盘或日志 util 在多队列设备上不能简单理解为“磁盘满”。要结合延迟、队列和容量指标。17.4 进程 IOpidstat -d 1iotop -P -d 2cat /proc/<pid>/io/proc/<pid>/io 常见字段： 字段 含义 read_bytes 实际读块设备字节 write_bytes 实际写块设备字节 syscr 读系统调用次数 syscw 写系统调用次数 cancelled_write_bytes 被截断等方式抵消的写 应用写页缓存成功不代表已经落盘。17.5 块大小与对齐查看：blockdev --getbsz /dev/vdbblockdev --getss /dev/vdbstat -f /data影响： 数据库 page size； 文件系统分配组； RAID 条带大小； 小 IO 合并效率； 云盘性能规格。生产不建议盲目手工调块大小，应以数据库、文件系统和存储厂商建议为准，并用真实 workload 验证。17.6 IO 调度器查看：cat /sys/block/vdb/queue/schedulerlsblk -D常见策略： 策略 特点 none / noop 尽量不重排 mq-deadline 面向延迟目标 bfq 面向公平和交互 kyber 面向低延迟 修改：echo mq-deadline | sudo tee /sys/block/vdb/queue/scheduler云盘和 NVMe 设备常有默认优化策略。没有压测证据时不要随意修改。17.7 直 IO 与缓冲 IOBuffered IO：write -> page cache -> writebackDirect IO：write -> block device特点： 模式 优点 代价 Buffered 命中快、接口简单 双缓存、回写时机不确定 Direct 应用自控缓存、减少拷贝 对齐要求高、实现复杂 数据库引擎通常按自身配置决定 direct IO、fdatasync、O_DSYNC 等策略。17.8 预读查看：cat /sys/block/vdb/queue/read_ahead_kbblockdev --getra /dev/vdb调整：sudo blockdev --setra 4096 /dev/vdb顺序扫描可能受益，随机读可能浪费缓存。调整后必须用真实业务压测验证。17.9 压测与验证fio 示例：sudo fio --name=rand-read \ --filename=/data/fio.test \ --direct=1 \ --rw=randread \ --bs=4k \ --ioengine=libaio \ --iodepth=32 \ --numjobs=4 \ --runtime=60 \ --time_based \ --group_reporting写测试：sudo fio --name=rand-write \ --filename=/data/fio.test \ --direct=1 \ --rw=randwrite \ --bs=8k \ --ioengine=libaio \ --iodepth=64 \ --numjobs=4 \ --runtime=60 \ --time_based \ --group_reporting注意： 只在测试盘执行； 写测试会破坏数据； 记录文件系统和云盘规格； 记录队列深度和块大小； 和数据库真实模型分开评估。17.10 常见故障数据库写入延迟高iostat -xz 1pidstat -d 1cat /proc/meminfo | grep -E 'Dirty|Writeback'检查： checkpoint； redo 刷盘； 云盘规格； 快照并发； 同宿主机干扰； 慢 SQL 放大读。应用 fsync 慢strace -T -e trace=fsync,fdatasync -p <pid>iostat -xz 1评估： 存储延迟； fsync 频率； 批量提交能力； 持久化语义； 文件系统行为。NFS 延迟高mount | grep nfsnfsstat -rcping -c 100 <nfs-server>mtr -rwzc 100 <nfs-server>本章小结IO 分析要把延迟、IOPS、吞吐、队列和进程写入对应起来。await 是核心指标，util 只能作参考。生产优化前先确认存储规格和真实 workload，再用压测验证调度器、预读、直 IO 和应用刷盘策略。思考题 IOPS 和吞吐分别适合评估什么 workload？ await 高说明什么？ buffered IO 和 direct IO 有什么差异？ 为什么 fsync 频繁会造成延迟？ 设计一个数据库盘的 fio 测试方案。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。VFS 是 Linux 给不同文件系统提供的统一接口。应用调用 open/read/write/close，底层可能是 ext4、XFS、NFS、tmpfs、overlay 或 procfs。理解 VFS 有助于分析缓存、写放大、容器镜像、虚拟文件和 IO 延迟。16.1 VFS 位置Application -> System Calls -> VFS |-- ext4 |-- xfs |-- tmpfs |-- procfs / sysfs |-- overlayfs +-- NFS -> Page Cache / Block Layer统一接口： 操作 示例 open 打开文件 read 读文件 write 写文件 fsync 刷盘 mmap 映射到地址空间 stat 读取元数据 unlink 删除目录项 16.2 页缓存读路径：read() -> page cache hit -> copy to user -> miss -> block IO -> cache -> copy to user写路径：write() -> page cache dirty -> writeback by kernel -> block device观察：free -hcat /proc/meminfo | grep -E 'Cached|Dirty|Writeback'vmstat 1关键指标： 指标 含义 Cached 页缓存 Dirty 待回写页 Writeback 正在回写页 bi / bo 块读写 大量脏页集中回写可能造成延迟抖动。数据库和消息队列通常会显式控制刷盘策略。16.3 procfs 与 sysfsproc 示例：cat /proc/meminfocat /proc/loadavgcat /proc/self/statusls -l /proc/<pid>/fdcat /proc/<pid>/iosys 示例：ls /sys/class/netcat /sys/class/net/eth0/mtucat /sys/fs/cgroup/cpu.max这些文件不占普通磁盘数据块，读取时由内核动态生成。16.4 tmpfs查看：df -hT | grep tmpfsmount | grep tmpfs创建：sudo mount -t tmpfs -o size=2G tmpfs /mnt/cache特点： 数据在内存和 swap 中； 重启后丢失； 写入会消耗内存； 适合临时缓存和低延迟文件。不适合存储不可恢复数据。使用前应限制大小。16.5 overlayfs容器镜像常见分层：lowerdir 只读镜像层upperdir 可写层merged 容器看到的统一视图查看：mount | grep overlaydocker inspect <container> --format '{{json .GraphDriver.Data}}' | jq .写行为： 操作 行为 读 lower 直接读 写 lower copy-up 到 upper 删除 whiteout 标记 写新文件 写 upper 容器内大量写入会放大可写层增长。持久数据应使用 volume 或 bind mount。16.6 文件与描述符查看：lsof -nP -p <pid>ls -l /proc/<pid>/fdcat /proc/<pid>/limits | grep 'open files'常见 fd：0 stdin1 stdout2 stderr3+ files, sockets, pipes, epoll...进程持续打开文件不释放，会导致 Too many open files。处理要回到代码资源关闭逻辑，而不是只调大 limit。16.7 fsync 与持久化示例：syncsync -f /data应用写文件不等于落盘。崩溃一致性需要结合 fsync、目录 fsync、原子 rename 和文件系统语义。安全写入模式：1. 写临时文件2. fsync 临时文件3. rename 到目标4. fsync 目录数据库、消息队列和配置发布都依赖类似的原子替换语义。16.8 文件锁查看：fuser -v /data/filelsof /data/fileC 示例：flock /tmp/app.lock -c '/opt/app/bin/job.sh'常见问题： 锁文件残留； NFS 锁语义差异； 多实例没有共享锁； 锁释放和进程退出异常； 只锁文件不锁业务状态。分布式多节点任务应使用数据库锁、分布式锁或编排系统的 Leader Election。16.9 NFS 与网络文件系统查看：df -hTmount | grep nfsnfsstat -srpcinfo -p nfs-server常见问题： 现象 常见原因 ls 卡住 服务不可用或硬挂载 权限不一致 root_squash 和 UID 映射 写入延迟高 网络或服务端压力 文件锁异常 锁服务或实现差异 生产数据库通常不直接使用 NFS，应选择数据库兼容的存储和网络方案。16.10 常见故障删除文件但空间不释放lsof +L1du -sh /datadf -hT /data原因：目录项已删除，进程仍持有 fd。Too many open filescat /proc/<pid>/limitsls /proc/<pid>/fd | wc -llsof -p <pid> | awk '{print $5}' | sort | uniq -c | sort -nroverlay 可写层过大docker system dfdu -sh /var/lib/docker/overlay2处理： 修改应用日志输出； 使用 volume； 清理临时文件； 控制镜像层数和大小。本章小结VFS 让应用用统一接口访问不同文件系统，同时带来页缓存、写回、overlay copy-up、网络文件系统等行为差异。可靠写文件要考虑原子替换和 fsync；容器持久数据不应写在镜像可写层。思考题 页缓存对读和写分别有什么影响？ /proc 为什么能动态生成内容？ overlayfs 的 copy-up 会带来什么成本？ 为什么配置文件写入常用临时文件加 rename？ 多节点任务为什么不能只依赖本地文件锁？
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Linux 内存管理包括虚拟内存、页表、缺页、文件页缓存、匿名页、swap、OOM 和 cgroup 限制。理解这些概念，才能解释“free 里 available 才是关键”“进程 RSS 为什么持续增长”“容器内存为什么会被杀”。15.1 free 输出free -hfree -mcat /proc/meminfo示例： total used free buff/cache availableMem: 15G 8G 1G 6G 6GSwap: 4G 1G 3G关键指标： 指标 含义 free 完全未使用内存 buff/cache 内核页缓存和缓冲 available 估算可供新进程使用 swap 交换分区使用 Linux 会把空闲内存用作页缓存，所以 free 低不等于内存不足。判断压力应看 available、swap in/out、缺页、回收和 OOM 事件。15.2 虚拟内存Virtual Address Space |-- code |-- data |-- heap |-- shared libraries |-- stack+-- mmapped files / anonymous memory进程视角：cat /proc/<pid>/status | grep -E 'Vm|Rss'cat /proc/<pid>/smaps_rolluppmap -x <pid>指标： 指标 含义 VmSize / VSS 虚拟地址空间大小 VmRSS / RSS 常驻物理内存 PSS 按共享比例分摊后的内存 USS 进程独占内存 Swap 已换出内存 容量评估优先看 PSS，而不是只看 VSS。15.3 页类型 页类型 说明 回收方式 File-backed page 文件页缓存 可丢弃或回写 Anonymous page 堆、栈等 需写 swap 或压缩 Locked page mlock 等 通常不回收 Slab 内核对象缓存 按对象回收 观察：cat /proc/meminfo | grep -E 'Cached|Buffers|AnonPages|SReclaimable|SUnreclaim'vmstat 115.4 缺页与交换vmstat 1cat /proc/vmstat | grep -E 'pgfault|pgmajfault|pswpin|pswpout'关键指标： 指标 含义 bi / bo 块设备读写 si / so swap in / out majflt major fault 判断： 现象 方向 si/so 持续大于 0 内存压力明显 majflt 高 文件页未命中 available 低 接近容量 OOM 日志 已发生牺牲 15.5 OOM Killer查看：dmesg -T | grep -Ei 'out of memory|oom|killed process'journalctl -k --since today | grep -i oomOOM 会根据内存压力和 oom_score 选择牺牲进程：cat /proc/<pid>/oom_scorecat /proc/<pid>/oom_score_adj调整：echo -500 > /proc/<pid>/oom_score_adj生产重点不是调整分数，而是： 控制内存上限； 修复泄漏； 设置水位告警； 保证关键服务有逃生容量； 通过编排重启策略恢复。15.6 内存泄漏排查进程级：watch -n 5 'grep -E "VmRSS|VmSwap" /proc/<pid>/status'pidstat -r -p <pid> 5smem -rk | head -20系统级：ps -eo pid,user,%mem,rss,cmd --sort=-rss | head -20slabtopcat /proc/meminfo应用侧： Java 使用 heap dump 和 GC 日志； Go 使用 pprof； C/C++ 使用 valgrind、ASan 或 core； Python 使用 tracemalloc。RSS 持续增长不一定是泄漏，也可能是缓存增长。要结合配置上限和业务请求量判断。15.7 cgroup 内存查看：cat /sys/fs/cgroup/<path>/memory.currentcat /sys/fs/cgroup/<path>/memory.maxcat /sys/fs/cgroup/<path>/memory.stat关键项： 指标 含义 anon 匿名页 file 文件页 slab 内核 slab pgfault 缺页 pgmajfault major fault workingset_refault 工作集回取 容器内存达到 hard limit 时可能被杀。判断要看 cgroup 事件和编排系统状态：kubectl describe pod <pod>docker inspect <container> --format '{{.State.OOMKilled}}'Java 容器应让 JVM 感知容器限制，并保留堆外内存和元空间余量。15.8 透明大页查看：cat /sys/kernel/mm/transparent_hugepage/enabledcat /sys/kernel/mm/transparent_hugepage/defrag常见值：alwaysmadvisenever数据库通常关注 THP 对延迟抖动的影响，具体推荐以数据库和发行版文档为准。修改前要记录默认值和回滚方式。15.9 内存调优原则先消除问题，再考虑参数：1. 确认内存压力证据2. 定位进程或内核内存3. 区分缓存增长和泄漏4. 修复应用配置和代码5. 评估容量和限流6. 调整缓存大小7. 最后评估 swap 和内核参数常用参数：sysctl vm.swappinesssysctl vm.overcommit_memorysysctl vm.min_free_kbytesswappiness 不是百分比开关，语义和效果依赖 workload。不要脱离压测直接照抄。15.10 常见案例案例一：available 低free -hvmstat 1ps -eo pid,rss,cmd --sort=-rss | headcat /proc/meminfo处理： 定位大进程； 检查缓存上限； 重启或扩容前评估影响； 增加提前告警。案例二：Java 容器 OOMKilledkubectl describe pod <pod>kubectl top pod <pod>方向： -Xmx 过大； 堆外内存或线程栈增长； limit 太小； 内存泄漏； 请求量超容量。案例三：机器有 swap 但延迟抖动vmstat 1grep -E 'pswpin|pswpout' /proc/vmstat如果 si/so 持续，说明应用工作集超过物理内存。应扩容或降低内存消耗，而不是只调大 swap。本章小结Linux 会把空闲内存用作缓存，判断内存压力要看 available、swap、major fault、回收和 OOM。进程内存要区分 VSS、RSS 和 PSS；容器要区分应用使用、页缓存和 cgroup hard limit。内存治理重点是容量预算、泄漏定位和水位告警。思考题 free 和 available 有什么区别？ RSS 高是否一定代表泄漏？ cgroup memory.max 达到后会发生什么？ swap 的价值和风险分别是什么？ 为 Java 容器设计内存 limit 和 JVM 内存参数。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。CPU 问题不只是“核数不够”。可能是单线程瓶颈、锁竞争、进程数过多、容器限流、NUMA 不亲和、IO 等待或内存回收。本章从 CPU 指标、进程状态、调度器、优先级、亲和性和容器限制讲起。14.1 常用指标系统：uptimetopvmstat 1mpstat -P ALL 1进程：pidstat 1pidstat -u -p <pid> 1top -H -p <pid>ps -T -p <pid>关键指标： 指标 含义 us 用户态 CPU sy 内核态 CPU id 空闲 wa 等待 IO st 虚拟化被抢占，常见于虚拟机 ir 硬中断 cs 每秒上下文切换 runq 运行队列 load average 包含可运行任务和不可中断任务。因此高 load 不一定等于 CPU 忙，还要看 us/sy/wa 和 D 状态进程。14.2 CPU 信息lscpunproccat /proc/cpuinfocat /proc/loadavg关注字段： 字段 含义 CPU(s) 逻辑 CPU 数 Thread(s) per core 每核线程数 Core(s) per socket 每颗 CPU 核数 NUMA node(s) NUMA 节点 Model name CPU 型号 MHz 当前频率 容器内 nproc 可能受 namespace 和运行时影响。资源容量应以编排系统声明的 limit 和宿主机指标共同确认。14.3 进程状态与运行队列ps -eo pid,ppid,user,stat,%cpu,%mem,etime,cmd --sort=-%cpu | head -20vmstat 1 5典型判断： 现象 可能方向 R 多、us 高 CPU 密集 R 多、sy 高 系统调用、锁、调度或内核路径 D 多、wa 高 IO 或存储异常 cs 很高 频繁切换、线程过多 st 高 宿主机资源竞争 查看 D 状态：ps -eo pid,stat,wchan:32,cmd | awk '$2 ~ /^D/'14.4 调度器基础Linux 使用完全公平调度 CFS 思想。每个可运行任务按权重分配 CPU 时间，而不是严格轮流。Runnable tasks -> runqueue per CPU -> scheduler picks task -> context switch -> user / kernel execution相关工具：nice -n 10 ./batch-jobrenice -n 10 -p <pid>taskset -pc <pid>chrt -p <pid>普通在线服务不要随意使用实时调度策略，误用可能让系统无法响应。14.5 上下文切换查看：vmstat 1pidstat -w 1perf stat -p <pid> -- sleep 10关注： 指标 含义 cs 总上下文切换 involuntary ctxt switches 非自愿切换 voluntary ctxt switches 自愿等待 非自愿切换高说明 CPU 时间片竞争强；自愿切换高可能是锁、IO 或 sleep 频繁。14.6 CPU 使用率分析定位进程：toppidstat 1 5ps -eo pid,user,%cpu,cmd --sort=-%cpu | head定位线程：top -H -p <pid>ps -T -p <pid> -o pid,tid,%cpu,stat,comm --sort=-%cpuJava 线程栈关联：printf '%x\n' <tid>jstack <pid> | grep -A 20 'nid=0x<hex-tid>'生成火焰图可使用 perf、async-profiler 或运行时自带工具。容器内采集要注意权限和符号。14.7 CPU 限流传统工具：cpulimit -l 50 -p <pid>cgroup v2：cat /sys/fs/cgroup/<path>/cpu.maxcat /sys/fs/cgroup/<path>/cpu.statKubernetes：kubectl get pod <pod> -o jsonpath='{.spec.containers[0].resources}'kubectl top pod限流表现： 应用内部延迟升高； 宿主机 CPU 不满，但容器 throttled 增长； GC 或事件循环变慢； 请求超时增加。排查：cat /sys/fs/cgroup/cpu.statgrep -E 'nr_throttled|throttled_usec' /sys/fs/cgroup/cpu.stat不同内核和容器运行时路径可能不同，以上是 cgroup v2 的常见位置。14.8 NUMA 与亲和性查看：lscpu | grep NUMAnumactl --hardwarenumastat绑定：taskset -c 0-3 ./servertaskset -pc 0-3 <pid>numactl --cpunodebind=0 --membind=0 ./serverNUMA 策略能减少跨节点访问，但手工绑核会降低弹性。数据库等特定 workload 应结合压测和厂商建议设置。14.9 perf 分析安装：sudo apt install linux-tools-common linux-tools-$(uname -r)sudo dnf install perf常用：perf stat -p <pid> -- sleep 10perf topperf record -F 99 -p <pid> -g -- sleep 30perf report容器和云主机可能限制 PMU 访问。无法采样时，可使用应用运行时 profiler 或 eBPF 工具。14.10 常见案例案例一：us 高pidstat -u 1top -H -p <pid>方向： 单线程算法瓶颈； 业务流量上升； 序列化反序列化； GC； 正则或加密算法。案例二：sy 高strace -cp <pid>perf topvmstat 1方向： 系统调用过多； 小包网络； 频繁线程切换； 锁竞争； 内存页缺失。案例三：容器 CPU 未满但延迟高kubectl top podcat /sys/fs/cgroup/cpu.stat结论可能是 CPU limit 触发限流。处理： 提高 limit； 优化算法； 降低单实例流量； 扩容； 调整线程数。本章小结CPU 分析先看整体利用率、运行队列、iowait、steal 和上下文切换，再定位进程和线程。高 load 不一定是 CPU 不足，D 状态和 IO 等待同样会推高 load。容器环境必须同时看宿主机和 cgroup 限流指标。思考题 load 高但 idle 也高，可能是什么原因？ us、sy、wa、st 分别说明什么？ 如何把 Linux 线程 ID 关联到 Java 线程栈？ CPU throttling 为什么会造成延迟上升？ 设计一套服务 CPU 水位和容量告警。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。环境变量影响命令查找、语言 locale、代理、密钥注入、运行时参数和容器配置。它也是生产问题的高发点：本机能跑、systemd 起不来；终端里有代理、服务里没有；CI 有变量、线上没有。本章讲清环境变量的作用域、加载顺序和治理方式。13.1 基本操作查看：envprintenvecho "$PATH"echo "$HOME"echo "$LANG"设置：export APP_ENV=productionexport JAVA_OPTS="-Xms1g -Xmx1g"仅当前命令生效：APP_ENV=production ./serverLANG=C sort file.txt删除：unset APP_ENV只对当前 Shell 生效。终端关闭后消失。13.2 Shell 变量与环境变量app=orderexport appenv | grep '^app='区别： 类型 当前 Shell 子进程 Shell 变量 可见 不可见 环境变量 可见 可见 查看进程环境：tr '\0' '\n' < /proc/<pid>/environ进程启动后修改 Shell 环境不会影响已启动进程。13.3 PATH查看：echo "$PATH"type javawhich javacommand -v java临时添加：export PATH="$PATH:/opt/app/bin"优先级按目录顺序决定：/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin安全原则： 不把 . 放入 PATH； 不把可写目录放在高优先级； 使用绝对路径执行关键命令； 检查命令别名； 不信任来路不明的 PATH。检查别名：aliastype -a ls13.4 登录 Shell 加载顺序Bash 常见顺序：/etc/profile -> ~/.bash_profile 或 ~/.bash_login 或 ~/.profile -> interactive non-login 时读取 ~/.bashrc常见文件： 文件 场景 /etc/profile 系统全局登录 /etc/profile.d/*.sh 软件包或团队全局配置 ~/.bash_profile 用户登录 ~/.profile 兼容登录 ~/.bashrc 交互非登录 验证当前 Shell：echo "$0"shopt login_shellSSH 登录、su、cron、systemd、容器入口的加载路径不同。服务变量应在服务配置中显式声明。13.5 systemd 环境变量方式一：[Service]Environment="APP_ENV=production"Environment="JAVA_OPTS=-Xms1g -Xmx1g"方式二：[Service]EnvironmentFile=/etc/order/env文件格式：APP_ENV=productionJAVA_OPTS=-Xms1g -Xmx1gDB_PASSWORD_FILE=/run/secrets/db_password查看：systemctl show app -p Environmentsudo systemd-run --wait --property=EnvironmentFile=/etc/order/env env修改后：sudo systemctl daemon-reloadsudo systemctl restart app13.6 cron 环境cron 环境通常比登录 Shell 精简，PATH 和 Shell 可能不同。导出任务环境：crontab -l示例：SHELL=/bin/bashPATH=/usr/local/bin:/usr/bin:/binMAILTO=""30 2 * * * /opt/scripts/backup.sh >> /var/log/backup.log 2>&1脚本内部不要假设交互 Shell 环境，必要时显式 source 可信配置或直接写绝对路径。13.7 容器环境变量Docker：docker run \ --env APP_ENV=production \ --env-file ./prod.env \ my-app:1.0.0查看：docker inspect <container> \ --format '{{range .Config.Env}}{{println .}}{{end}}'docker exec <container> envKubernetes：apiVersion: apps/v1kind: Deploymentspec: template: spec: containers: - name: order image: registry.example.internal/order:1.0.0 env: - name: APP_ENV value: production - name: DB_PASSWORD valueFrom: secretKeyRef: name: order-db key: password不要把数据库密码写进镜像层、Deployment YAML 或命令历史。13.8 敏感信息治理常见错误： 做法 风险 写入 Dockerfile ENV 进入镜像历史 写入 Git 明文配置 泄露和审计困难 写入命令行参数 进入进程列表和 Shell 历史 全局 export 影响范围过大 团队共享账号 无法追责 推荐： 使用 Secret Manager 或 Kubernetes Secret 加访问控制； 只注入需要的进程； 定期轮换； 审计访问； 日志脱敏； 本地开发使用独立示例配置。13.9 locale 与时区查看：localetimedatectldatecat /etc/timezone设置：sudo localectl set-locale LANG=en_US.UTF-8sudo timedatectl set-timezone Asia/Shanghai容器：docker run --env TZ=Asia/Shanghai my-app:1.0.0多语言和排序结果受 locale 影响。数据库、日志采集器和应用应统一字符集与时区。13.10 代理变量常见变量：HTTP_PROXY=http://proxy.internal:3128HTTPS_PROXY=http://proxy.internal:3128NO_PROXY=.example.internal,127.0.0.1,10.0.0.0/8使用：export HTTPS_PROXY=http://proxy.internal:3128curl -v https://example.com取消：unset HTTP_PROXY HTTPS_PROXY ALL_PROXY代理配置只对尊重这些变量的工具生效。系统 DNS、某些运行时和数据库驱动可能需要单独配置。13.11 排障案例systemd 服务找不到命令systemctl cat appsystemctl show app -p Environmentjournalctl -u app -n 100command -v java修复：[Service]Environment="PATH=/opt/java/bin:/usr/local/bin:/usr/bin:/bin"ExecStart=/opt/java/bin/java -jar /opt/app/app.jar终端正常，cron 失败grep -R 'PATH' /etc/crontab /var/spool/cron 2>/dev/nullbash -x /opt/scripts/job.sh常见差异： PATH； HOME； LANG； TERM； 交互初始化文件； sudo 环境。容器变量没有生效docker inspect <container> --format '{{json .Config.Env}}' | jq .kubectl get pod <pod> -o jsonpath='{.spec.containers[0].env}'kubectl describe pod <pod>检查： 变量名大小写； Pod 是否重建； ConfigMap 或 Secret 是否更新； 应用是否启动时读取； 挂载路径和 key 是否正确。本章小结环境变量有明确作用域：命令、Shell、用户、systemd、cron、容器和编排系统不同。生产服务应在 systemd unit、容器声明或 Secret Manager 中显式配置，不依赖登录 Shell。敏感变量要控制注入范围、轮换和审计。思考题 Shell 变量和环境变量的区别是什么？ 为什么 systemd 服务不能依赖 ~/.bashrc？ cron 任务为什么常常因 PATH 失败？ 容器 ENV 为什么不适合保存数据库密码？ 设计一个服务的配置与环境变量分层方案。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Shell 脚本把命令、判断、循环和函数组合成可重复执行的自动化流程。好的脚本能减少误操作；坏脚本可能把一次小故障放大成全网事故。本章聚焦 Bash 的可靠写法、参数校验、错误处理、日志、并发和发布脚本设计。12.1 第一个脚本创建 healthcheck.sh：#!/usr/bin/env bashset -euo pipefailurl="${1:?Usage: $0 http://host:port/healthz}"timeout="${2:-3}"curl --silent --show-error --fail \ --connect-timeout "$timeout" \ --max-time "$timeout" \ "$url" >/dev/nullecho "OK $url"执行：chmod 750 healthcheck.sh./healthcheck.sh http://127.0.0.1:8080/healthz建议： 显式 #!/usr/bin/env bash； 使用 set -euo pipefail； 参数必须校验； 外部依赖显式声明； 输出适合日志采集。12.2 set 选项 选项 作用 -e 命令失败时退出 -u 未定义变量报错 -o pipefail 管道中任一命令失败则整条失败 -x 打印执行命令 组合：set -euo pipefail调试：bash -x script.sh在脚本内开启：set -xset +xset -e 对条件命令、命令替换和某些复合命令有细节差异。关键逻辑应显式判断退出码。12.3 变量与参数变量：app_name="order-service"readonly app_nameport="${APP_PORT:-8080}"echo "$app_name:$port"参数： 变量 含义 $0 脚本名 $1 到 $9 参数 ${10} 第十个参数 $# 参数数量 $@ 所有参数，推荐加引号 $* 所有参数合并为单字符串 示例：for arg in "$@"; do echo "$arg"done安全默认值：env_name="${ENV_NAME:?ENV_NAME is required}"timeout="${TIMEOUT:-5}"12.4 判断数值比较：if (( timeout > 10 )); then echo "timeout too large"fi字符串：if [[ "$env" == "prod" ]]; then echo "production"fi文件： 表达式 含义 -e file 存在 -f file 普通文件 -d file 目录 -r file 可读 -w file 可写 -x file 可执行 -s file 非空 示例：conf="/etc/app/app.yml"if [[ ! -r "$conf" ]]; then echo "cannot read $conf" >&2 exit 1fi[[ ]] 是 Bash 推荐写法；跨 POSIX Shell 应使用 test 或 [ ]。12.5 循环与函数循环：for host in web01 web02 web03; do ssh "$host" hostnamedonefor i in {1..5}; do echo "$i"donewhile read -r line; do echo "$line"done < hosts.txt函数：log() { printf '%s [%s] %s\n' "$(date -Is)" "$1" "$2"}wait_http() { local url="$1" local retry="${2:-30}" local i for ((i = 1; i <= retry; i++)); do if curl -sf --max-time 2 "$url" >/dev/null; then log INFO "$url ready" return 0 fi sleep 1 done log ERROR "$url not ready" return 1}函数内局部变量使用 local，避免污染全局状态。12.6 命令替换与退出码命令替换：current_dir=$(pwd)today=$(date +%F)files=$(find . -type f | wc -l)退出码：if command -v jq >/dev/null 2>&1; then echo "jq found"else echo "jq not found" >&2 exit 127fi显式处理：if ! mkdir -p "$backup_dir"; then echo "mkdir failed: $backup_dir" >&2 exit 1fi12.7 输入与临时文件读取 stdin：while read -r line; do printf '%s\n' "$line"done读取配置：source /etc/app/envsource 会执行文件内容，只能加载可信文件。配置解析优先使用专用工具。临时文件：tmpdir=$(mktemp -d)cleanup() { rm -rf "$tmpdir"}trap cleanup EXIT不要使用 /tmp/app.$$ 这种可预测路径写敏感文件。12.8 并发控制简单后台任务：pids=()for host in web01 web02 web03; do ssh "$host" sudo systemctl reload nginx & pids+=("$!")donefor pid in "${pids[@]}"; do wait "$pid" || exit 1done限制并发：max_parallel=5semaphore="$tmpdir/sem"mkfifo "$semaphore"exec 3<>"$semaphore"for ((i = 0; i < max_parallel; i++)); do printf '\n' >&3donefor host in $(cat hosts.txt); do read -r _ <&3 { ssh "$host" hostname printf '\n' >&3 } &donewait也可以使用 xargs -P、GNU parallel 或 Ansible。并发要设置批次和超时，避免把目标系统打满。12.9 远程执行ssh app@web01 'hostname'scp app.tar.gz app@web01:/tmp/rsync -av --delete --exclude logs/ release/ app@web01:/opt/app/current/批量执行建议：while read -r host; do ssh -o BatchMode=yes -o ConnectTimeout=5 \ "deploy@${host}" \ 'sudo systemctl restart app'done < hosts.txt当脚本超过远程控制、幂等、错误传播、并发和审计这些能力时，应迁移到 Ansible。12.10 幂等与回滚幂等示例：ensure_dir() { local dir="$1" if [[ ! -d "$dir" ]]; then mkdir -p "$dir" fi}发布脚本骨架：#!/usr/bin/env bashset -euo pipefailapp_dir=/opt/apprelease_id="${1:?release id required}"release_dir="$app_dir/releases/$release_id"current="$app_dir/current"[[ -d "$release_dir" ]] || { echo "release not found" >&2; exit 1; }ln -sfn "$release_dir" "$app_dir/current.next"mv -T "$app_dir/current.next" "$current"sudo systemctl restart appif ! curl -sf --max-time 3 http://127.0.0.1:8080/healthz; then ln -sfn "$app_dir/previous" "$app_dir/current" sudo systemctl restart app exit 1fi实际发布还要处理版本记录、串行批次、服务注册中心摘流和人工确认。12.11 脚本测试与审计语法检查：bash -n script.shshellcheck script.sh推荐工具： 工具 用途 bash -n 语法检查 shellcheck 静态分析 shfmt 格式化 bats 脚本测试 审计要求：[ ] 脚本在仓库中管理[ ] 变更有评审[ ] 生产先 dry-run[ ] 支持回滚[ ] 输出带时间日志[ ] 不输出明文密码[ ] 锁定适用主机范围[ ] 保留执行记录本章小结可靠脚本的核心是显式、可预期、可重复、可回滚。使用 set -euo pipefail、参数校验、局部变量、函数、trap 清理、超时和日志。复杂度上升后，应把 Shell 脚本迁移到 Ansible 或编程语言，并保留审计和测试。思考题 set -e 和 set -o pipefail 分别解决什么问题？ $@ 为什么要加引号？ 为什么临时文件推荐 mktemp？ 如何限制脚本并发数？ 设计一个支持健康检查和回滚的发布脚本。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。磁盘问题通常表现为空间不足、IO 延迟高、文件系统只读、挂载丢失或数据损坏。本章从设备识别、分区、格式化、挂载、交换分区、LVM、RAID、IO 指标和故障处理讲起。11.1 存储栈Application -> File System -> LVM / Software RAID -> Block Device -> Device Mapper -> Disk / SSD / Cloud Disk不同层次的问题表现不同： 层 常见现象 应用 写放大、锁文件、慢日志 文件系统 只读、元数据慢、inode 耗尽 块设备 IO error、延迟高 云盘 / RAID 容量、IOPS、吞吐限制 网络 存储链路抖动 11.2 设备识别块设备：lsblklsblk -flsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTblkidsudo fdisk -lsudo parted -l云服务器常见命名： 名称 常见含义 /dev/vda virtio 磁盘 /dev/sda SCSI / SATA /dev/nvme0n1 NVMe /dev/xvda Xen 虚拟盘 /dev/mapper/vg-lv LVM 逻辑卷 设备名在重启或变更后可能变化。fstab 推荐使用 UUID 或稳定标识。查看 UUID：blkid /dev/vdb1lsblk -fp11.3 分区与格式化查看分区表：sudo parted /dev/vdb printsudo fdisk -l /dev/vdbparted 示例：sudo parted -s /dev/vdb mklabel gptsudo parted -s /dev/vdb mkpart primary xfs 1MiB 100%sudo parted /dev/vdb print格式化：sudo mkfs.xfs /dev/vdb1sudo mkfs.ext4 /dev/vdb1查看文件系统信息：sudo xfs_info /datasudo tune2fs -l /dev/vdb1格式化会清除数据，执行前必须确认设备路径和分区号。11.4 挂载与 fstab临时挂载：sudo mkdir /datasudo mount /dev/vdb1 /datadf -hT /data卸载：sudo umount /datasudo umount -l /dataumount -l 是懒卸载，只作为特殊场景处理，不是常规操作。开机自动挂载：# /etc/fstabUUID=12345678-1234-1234-1234-123456789012 /data xfs defaults,nofail 0 0校验：sudo findmnt --verifysudo mount -a常用选项： 选项 含义 defaults 常见默认组合 nofail 设备缺失时不阻塞启动 noatime 减少访问时间更新 ro / rw 只读 / 读写 _netdev 等待网络 关键数据盘建议加 nofail，避免单块数据盘异常导致整机无法启动。11.5 文件系统选择 文件系统 特点 常见用途 ext4 成熟稳定 通用数据盘 XFS 大文件、高并发写性能好 数据库、大文件 btrfs 快照、压缩等能力 场景化使用 tmpfs 内存文件系统 临时缓存 overlay 容器镜像分层 容器运行时 数据库选型应结合 workload、备份工具、云厂商能力和团队经验，不只看单项参数。11.6 容量与 inode容量：df -hTdf -kTdu -sh /data/*du -h --max-depth=2 /data | sort -hinode：df -ihfind /data -xdev -type f | wc -l常见问题： 现象 原因 空间满但 du 不大 已删除文件仍被占用 inode 满 海量小文件 写入卡住 IO 队列高或存储故障 只读文件系统 错误后自我保护 处理：lsof +L1sudo journalctl --disk-usagefind /data -type f -size +1G -printf '%s %p\n' | sort -nr | head11.7 Swap查看：free -hswapon --showcat /proc/swapscat /proc/sys/vm/swappiness创建 swap 文件：sudo fallocate -l 4G /swapfilesudo chmod 600 /swapfilesudo mkswap /swapfilesudo swapon /swapfile开机启用：# /etc/fstab/swapfile none swap sw 0 0关闭：sudo swapoff /swapfilesudo rm /swapfile数据库等服务通常要谨慎使用 swap，重点还是控制内存和监控水位。swap 是缓冲手段，不是常态内存方案。11.8 LVM概念：Physical Volume PV -> Volume Group VG -> Logical Volume LV -> File System查看：sudo pvssudo vgssudo lvs创建：sudo pvcreate /dev/vdbsudo vgcreate datavg /dev/vdbsudo lvcreate -n datalv -L 100G datavgsudo mkfs.xfs /dev/datavg/datalvsudo mount /dev/datavg/datalv /data扩容：sudo lvextend -L +50G /dev/datavg/datalvsudo xfs_growfs /dataext4：sudo lvextend -L +50G /dev/datavg/datalvsudo resize2fs /dev/datavg/datalv缩容风险高，XFS 通常不支持在线缩容。生产应优先规划扩容和备份，而非临时缩容。11.9 RAID常见级别： 级别 特点 容错 RAID 0 条带，性能高 无 RAID 1 镜像 一块 RAID 5 分布式校验 一块 RAID 6 双校验 两块 RAID 10 镜像加条带 每组一块 查看软件 RAID：cat /proc/mdstatsudo mdadm --detail /dev/md0云盘和硬件 RAID 通常由平台或 RAID 卡暴露为块设备，应结合厂商工具监控健康状态。RAID 不是备份。误删除、文件损坏、逻辑错误和安全事件仍需要独立备份。11.10 文件系统检查unmount 后检查：sudo umount /datasudo fsck -n /dev/vdb1sudo fsck /dev/vdb1ext4：sudo e2fsck -f /dev/vdb1XFS：sudo xfs_repair -n /dev/vdb1sudo xfs_repair /dev/vdb1只读修复：sudo xfs_repair -L /dev/vdb1-L 会清空日志，可能丢数据，只能作为最后手段并在备份、变更评审和专家确认后执行。11.11 IO 指标iostat -xz 1iostat -dx 1 /dev/vdbvmstat 1pidstat -d 1iotop -P -d 2关键指标： 指标 含义 r/s、w/s 每秒读写次数 rkB/s、wkB/s 每秒读写数据量 await 平均 IO 等待 r_await、w_await 读写等待 aqu-sz 队列深度 util 设备忙碌度 iowait CPU 等待 IO 占比 判断：await 高 + util 高 -> 存储能力或 workload 问题iowait 高 + iostat 不高 -> NFS、内存压力或调度问题，需要继续分层单个进程 w/s 高 -> 应用写放大或日志刷盘11.12 云盘与性能云盘常见限制： 资源 说明 容量 最大和最小规格 IOPS 随容量或类型变化 吞吐 MB/s 上限 突发 有限时长 并发连接 多盘挂载能力 排查前先确认：lsblkdf -hTiostat -xz 1再对照云平台当前规格。云盘性能指标和实现随厂商变化，不要只凭经验判断。11.13 故障案例案例一：根分区写满df -hT /du -sh /var/* /tmp /root 2>/dev/nullsudo journalctl --disk-usagelsof +L1常见来源： journal 过大； core dump； 应用日志； 包缓存； 临时文件； 容器镜像和卷。根分区写满可能导致 SSH、cron、日志和数据库异常，应设置提前告警。案例二：文件系统只读dmesg -T | tail -100findmnt -no TARGET,OPTIONS /datasudo touch /data/test常见原因： 磁盘 IO 错误； journal 损坏； 存储链路断开； 人为只读挂载。处理前先保存日志，再评估备份和修复方案，不要直接重启。案例三：数据库盘延迟高iostat -xz 1 /dev/vdbpidstat -d 1sudo lsblk -o NAME,SIZE,TYPE,MOUNTPOINT检查： 云盘规格； checkpoint 和刷盘； 日志写入量； 快照或备份并发； 同宿主机干扰； 应用是否有批量扫描。本章小结磁盘排障要先分层：容量、inode、挂载、块设备、IO 指标和云盘规格。df 看文件系统，du 和 find 定位空间，iostat 看设备压力，dmesg 看内核错误。LVM 提供扩容灵活性，RAID 提供硬件冗余，但它们都不能替代备份和容量预测。思考题 df 和 du 的统计口径有什么不同？ /etc/fstab 使用 UUID 有什么优势？ XFS 和 ext4 在扩容、缩容上的差异是什么？ iostat 的 await 和 util 如何解读？ 设计一个数据库磁盘的容量、水位和 IO 监控方案。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。日志是排障和审计的证据。Linux 日志涉及内核 ring buffer、systemd journal、syslog、应用文件日志、容器 stdout、日志轮转和集中采集。治理日志要同时回答：写在哪里、能留多久、是否结构化、如何脱敏、如何报警。10.1 日志全景Kernel -> dmesg / journaldsystemd service -> journald -> stdout / stderrrsyslog / syslog-ng -> /var/log/messages -> /var/log/syslog -> remote syslogApplication -> file -> stdout -> collectorContainer runtime -> stdout / stderr -> kubelet / container log driver常见路径： 路径 内容 /var/log/messages RHEL 系常见通用日志 /var/log/syslog Debian 系常见通用日志 /var/log/auth.log Debian 系认证日志 /var/log/secure RHEL 系认证日志 /var/log/dmesg 启动时内核日志快照 /var/log/nginx/ Nginx 日志 /run/log/journal/ 运行时 journal /var/log/journal/ 持久 journal 发行版差异明显，以实际配置为准。10.2 内核日志实时查看：dmesg -wdmesg -Tdmesg -T --level=err,warn重点关键字：dmesg -T | grep -Ei 'oom|out of memory|killed process'dmesg -T | grep -Ei 'error|fail|timeout|i/o'dmesg -T | grep -Ei 'conntrack|nf_conntrack'常见信息： 关键字 方向 Out of memory 内存压力和 OOM I/O error 磁盘或存储链路 EXT4-fs error 文件系统异常 XFS XFS 文件系统信息 blocked for more than 120 seconds IO 阻塞 conntrack: table full 连接跟踪表满 segfault 进程非法内存访问 10.3 journalctl服务：journalctl -u appjournalctl -u app -fjournalctl -u app -n 200 --no-pagerjournalctl -u app --since '2026-08-25 10:00'journalctl -u app --since '1 hour ago' -p warning系统：journalctl -bjournalctl -b -1journalctl --since todayjournalctl -p errjournalctl --disk-usageJSON 输出：journalctl -u app -o json-pretty -n 1磁盘治理：sudo journalctl --vacuum-size=2Gsudo journalctl --vacuum-time=14d10.4 rsyslog配置文件：/etc/rsyslog.conf/etc/rsyslog.d/*.conf传统规则：facility.priority actionauth.* /var/log/auth.log*.info;mail.none /var/log/messages示例：把应用 local1 日志写入独立文件：# /etc/rsyslog.d/30-app.conflocal1.* /var/log/app/syslog.log& stop重启：sudo systemctl restart rsyslog发送远端：*.* @@log.example.internal:6514一个 @ 常见为 UDP，两个 @ 常见为 TCP；TLS 需要额外模块和证书配置。10.5 应用日志设计日志级别： 级别 用途 TRACE 细粒度跟踪，默认关闭 DEBUG 开发诊断，生产谨慎开启 INFO 关键业务动作和状态 WARN 可恢复异常、降级、重试 ERROR 影响请求或功能的错误 FATAL 进程即将退出 推荐字段：{ "ts": "2026-08-25T10:00:00.123+08:00", "level": "ERROR", "service": "order", "trace_id": "7f3a", "span_id": "01", "user_id": "10001", "method": "POST", "path": "/api/orders", "status": 500, "latency_ms": 120, "error_type": "DbTimeout", "message": "create order failed"}原则： 时间带时区； 输出结构化 JSON； 每个请求有 trace_id； 异常带类型和堆栈； 不记录明文密码、密钥、身份证号； ERROR 对应可行动事件； 避免 ERROR 洪水。10.6 日志轮转logrotate 配置目录：/etc/logrotate.conf/etc/logrotate.d/*Nginx 示例：/var/log/nginx/*.log { daily rotate 14 missingok notifempty compress delaycompress dateext create 0640 www-data adm sharedscripts postrotate [ -f /var/run/nginx.pid ] && kill -USR1 $(cat /var/run/nginx.pid) endscript}测试：sudo logrotate -d /etc/logrotate.d/nginxsudo logrotate -f /etc/logrotate.d/nginx-d 是 dry run，-f 是强制轮转。应用自身有轮转能力时，避免和应用内轮转、logrotate 重复治理。10.7 容器日志查看：docker logs <container>docker logs -f --tail 100 <container>kubectl logs <pod>kubectl logs -f <pod> -c <container>kubectl logs --previous <pod>推荐容器应用输出到 stdout / stderr，由容器运行时和采集器统一处理。不推荐： 容器内写无限增长文件； 依赖手工 docker exec 看日志； 把敏感信息打印到 stdout； 单行日志超过过大尺寸； 无日志上限的本地 JSON 文件驱动。10.8 集中采集常见链路：App / journald / file -> Fluent Bit / Filebeat / Vector -> Kafka -> Loki / Elasticsearch / OpenSearch -> Grafana / Kibana采集关注： 项目 说明 位置 file offset、journal cursor 解析 JSON、多行堆栈 脱敏 密码、token、手机号 路由 按服务和环境 缓冲 本地缓冲和背压 丢失策略 崩溃、磁盘满、远端不可用 时区 统一时区 多行日志示例：ERROR order create failedjava.lang.NullPointerException at com.example.order.Service.create(Service.java:20)必须把堆栈归并到同一事件，否则搜索和统计都会失真。10.9 日志检索技巧错误：grep -E 'ERROR|FATAL' app.logjournalctl -u app -p err --since '1 hour ago'时间范围：sed -n '/2026-08-25 10:00/,/2026-08-25 10:10/p' app.log按 trace：grep 'trace_id=7f3a' app.logjq 'select(.trace_id == "7f3a")' events.json压缩日志：zgrep ERROR app.log.2.gz注意日志时间可能来自不同机器，需要确认 NTP 或 chronyd 状态。10.10 日志告警告警类型： 类型 示例 错误率 5 分钟 ERROR / 总请求 关键字 OOM、certificate expired 缺失 心跳日志超过阈值未出现 延迟 日志时间与采集时间差距大 容量 采集器队列积压 审计 root 登录、sudo 失败 告警要能行动：告警名称 -> 影响什么 -> 可能原因 -> 排查入口 -> 处理手册链接不要把所有 ERROR 都设为电话告警，先按业务影响分级。10.11 生产案例案例一：磁盘被日志占满df -hTdu -sh /var/log/*ls -lh /var/log/appcat /etc/logrotate.d/app处理： 紧急清理已轮转压缩文件； 修复轮转配置； 降低 DEBUG 输出； 增加容量告警； 接入集中日志后缩短本地留存。案例二：看不到服务日志systemctl status appjournalctl -u app -n 100systemctl cat appls -l /proc/$(systemctl show -p MainPID --value app)/fd可能原因： StandardOutput 被丢弃； 应用写到文件； 日志级别配置错误； 服务实际没有起来； journald 限制或采集器失败。案例三：多行堆栈被拆散检查采集器 multiline 配置：以非 ERROR/WARN//INFO 开头的行 -> 归并到上一条日志同时设置最大归并时长和最大行数，防止异常日志无限合并。本章小结Linux 日志由内核、journal、syslog、应用和容器多个来源组成。生产日志要结构化、带链路 ID、可轮转、可采集、可脱敏、可告警。排障时先按时间和服务缩小范围，再从系统日志进入应用日志，最终形成完整证据链。思考题 dmesg 和 journalctl 分别适合看什么？ 日志轮转后为什么需要通知应用或 Nginx？ 容器应用为什么推荐输出 stdout？ 如何设计敏感信息脱敏？ 设计一个服务错误率告警，包含排查入口和处理手册。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。systemd 是多数主流 Linux 发行版的 init 系统和服务管理器。它负责启动服务、管理依赖、收集日志、限制资源、隔离进程树。现代后端服务应优先使用 systemd 或容器编排，而不是手工 nohup。9.1 systemd 组成systemd |-- systemd(1) 主进程 |-- unit 配置 |-- journald 日志 |-- logind 登录管理 |-- timedated 时间管理 +-- cgroup 资源分组查看：ps -p 1 -o pid,comm,argssystemctl --versionsystemctl --no-pager --type=service9.2 常用 systemctl 命令服务：sudo systemctl start nginxsudo systemctl stop nginxsudo systemctl restart nginxsudo systemctl reload nginxsudo systemctl try-restart nginxsudo systemctl enable nginxsudo systemctl disable nginxsudo systemctl daemon-reload状态：systemctl status nginxsystemctl is-active nginxsystemctl is-enabled nginxsystemctl list-units --type=servicesystemctl list-units --failedsystemctl list-unit-files --type=service查看配置：systemctl cat nginxsystemctl show nginxsystemctl show nginx -p MainPID -p ActiveState -p SubState修改配置后：sudo systemctl daemon-reloadsudo systemctl restart appdaemon-reload 重新读取单元文件，不等于重启服务。9.3 Unit 类型 类型 后缀 用途 service .service 服务 socket .socket socket 激活 timer .timer 定时任务 target .target 一组 unit mount .mount 挂载 path .path 路径变化触发 slice .slice 资源分组 单元路径：/etc/systemd/system 管理员配置，优先级高/run/systemd/system 运行时配置/usr/lib/systemd/system 软件包安装覆盖配置推荐使用：systemctl edit nginx它会生成 drop-in 文件，避免直接修改包管理的原始单元。9.4 服务单元示例[Unit]Description=Order ServiceDocumentation=https://example.internal/docs/orderWants=network-online.targetAfter=network-online.target[Service]Type=simpleUser=appGroup=appWorkingDirectory=/opt/orderEnvironment=JAVA_OPTS=-Xms1g -Xmx1gEnvironmentFile=-/etc/order/envExecStart=/usr/bin/java $JAVA_OPTS -jar app.jarExecReload=/bin/kill -HUP $MAINPIDRestart=on-failureRestartSec=5sTimeoutStartSec=60sTimeoutStopSec=30sKillSignal=SIGTERMKillMode=mixedLimitNOFILE=65535UMask=0027NoNewPrivileges=truePrivateTmp=trueProtectSystem=strictReadWritePaths=/var/log/order /opt/order/data[Install]WantedBy=multi-user.target安装：sudo cp order.service /etc/systemd/system/order.servicesudo systemctl daemon-reloadsudo systemctl enable --now order.service9.5 Type 与启动状态 Type 判定方式 simple ExecStart 启动即认为主进程启动 exec ExecStart 执行成功后进入启动 forking 子进程分离，依赖 PIDFile 或推断 notify 应用主动调用 sd_notify oneshot 一次性任务，退出后进入 inactive 或 dead Java 应用常使用：Type=simpleExecStart=/usr/bin/java -jar app.jar需要等待就绪时，可用 Type=notify，但应用必须支持 sd_notify；也可通过健康检查系统处理，而不是让 systemd 猜测业务就绪。9.6 依赖关系[Unit]Wants=network-online.targetAfter=network-online.targetRequires=postgresql.serviceBindsTo=nginx.service语义： 指令 行为 Wants 弱依赖，失败也启动自己 Requires 强依赖，被依赖失败则自己失败 Requisite 必须已激活，否则不启动 BindsTo 自己随被依赖停止 After 在指定 unit 后启动 Before 在指定 unit 前启动 After 只定义顺序，不自动创建依赖。需要同时写 Requires 或 Wants。9.7 重启策略Restart=noRestart=on-successRestart=on-failureRestart=alwaysRestart=on-abnormalRestart=on-watchdog常用：Restart=on-failureRestartSec=5sStartLimitIntervalSec=60sStartLimitBurst=5如果服务不断崩溃，自动重启只是掩盖问题。应检查退出原因、资源限制和依赖状态。查看失败：systemctl status appjournalctl -u app -n 200systemctl show app -p Result -p ExecMainStatus9.8 资源限制文件与进程：LimitNOFILE=65535LimitNPROC=4096LimitCORE=infinityCPU 与内存：CPUWeight=100CPUQuota=200%MemoryHigh=4GMemoryMax=6GTasksMax=1024查看：systemctl show app -p MemoryMax -p CPUQuota -p TasksMaxcat /proc/$(systemctl show -p MainPID --value app)/limits内存硬限制达到时，内核可能杀掉进程；限制应低于机器容量，并保留系统余量。9.9 journald 日志查看服务日志：journalctl -u nginxjournalctl -u nginx -fjournalctl -u nginx -n 100 --no-pagerjournalctl -u nginx --since todayjournalctl -u nginx --since '2026-08-25 10:00' --until '2026-08-25 11:00'按优先级：journalctl -p errjournalctl -p warning -u app按 PID：journalctl _PID=<pid>查看磁盘占用：journalctl --disk-usage清理：sudo journalctl --vacuum-time=14dsudo journalctl --vacuum-size=2G长期配置：# /etc/systemd/journald.conf[Journal]Storage=persistentSystemMaxUse=2GMaxRetentionSec=30day9.10 Timer 定时任务示例 /etc/systemd/system/backup.service：[Unit]Description=Nightly Backup[Service]Type=oneshotUser=backupExecStart=/opt/scripts/backup.sh示例 /etc/systemd/system/backup.timer：[Unit]Description=Run backup nightly[Timer]OnCalendar=*-*-* 02:00:00Persistent=trueRandomizedDelaySec=300[Install]WantedBy=timers.target启用：sudo systemctl daemon-reloadsudo systemctl enable --now backup.timersystemctl list-timers backup.timer相比 crontab，timer 更容易纳入 systemd 依赖、日志和资源控制。9.11 排障案例服务启动失败systemctl status app --no-pagerjournalctl -u app -n 200 --no-pagersystemctl cat appsudo -u app /opt/app/bin/start --checkss -lntp常见原因： ExecStart 路径错误； User 无权限； 配置不存在； 环境变量缺失； 端口冲突； 单元语法错误； 依赖未就绪。修改单元不生效systemctl cat appsudo systemctl daemon-reloadsudo systemctl restart app检查是否被 drop-in 覆盖：systemctl show app -p FragmentPath -p DropInPaths服务被 OOM 杀掉journalctl -u app --since todaydmesg -T | grep -i 'out of memory'systemctl show app -p MemoryMax处理： 区分 cgroup 限制和机器内存； 检查内存泄漏； 调整应用内存参数； 评估扩容； 增加水位监控。本章小结systemd 用 unit 描述服务，用依赖控制启动顺序，用 cgroup 管资源，用 journald 收日志。生产服务应显式配置用户、目录、环境、重启策略、停止超时、文件数限制和日志留存。修改单元后要 daemon-reload，并用状态、日志和业务健康检查闭环。思考题 daemon-reload 和 restart 有什么区别？ Wants、Requires 和 After 分别解决什么问题？ Restart=always 可能掩盖什么问题？ systemd timer 相比 crontab 有哪些优势？ 为 Java 服务写一个包含资源限制和优雅停机的 unit。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。信号是 Linux 向进程传递异步事件的机制。优雅停机、配置重载、故障转储、脚本中断，都依赖信号。理解信号的发送、阻塞、默认行为和继承规则，才能设计可靠的服务生命周期。8.1 信号是什么kill / kernel / terminal | v signal | vtarget process | +-- default action +-- ignore +-- custom handler查看信号：kill -lman 7 signal常用信号： 信号 默认行为 常见用途 SIGHUP 终止 终端断开；很多守护进程用它重载配置 SIGINT 终止 Ctrl+C SIGQUIT 终止并 core 调试转储 SIGILL 终止并 core 非法指令 SIGABRT 终止并 core abort SIGFPE 终止并 core 算术错误 SIGKILL 终止 强制杀死 SIGSEGV 终止并 core 非法内存访问 SIGPIPE 终止 写已关闭管道或 socket SIGALRM 终止 定时器 SIGTERM 终止 优雅终止 SIGUSR1 终止 应用自定义 SIGUSR2 终止 应用自定义 SIGCHLD 忽略 子进程状态变化 SIGCONT 继续 恢复执行 SIGSTOP 暂停 强制暂停 SIGTSTP 暂停 Ctrl+Z SIGWINCH 忽略 终端窗口变化 8.2 发送信号按 PID：kill <pid>kill -TERM <pid>kill -15 <pid>kill -KILL <pid>按名称或命令行：pkill -TERM nginxpkill -TERM -f 'java -jar order.jar'killall -TERM nginx给进程组发送：kill -TERM -<pgid>负号表示进程组 ID。使用前必须确认范围，避免误杀其他服务。查看进程组：ps -eo pid,pgid,sid,stat,cmdps -o pid,pgid,sid,cmd -p <pid>8.3 默认行为与处理进程可以选择：1. 执行默认动作2. 忽略信号3. 捕获信号并执行处理函数SIGKILL 和 SIGSTOP 不能被捕获、阻塞或忽略，这是内核保底能力。C 示例：#include <signal.h>#include <stdio.h>#include <unistd.h>volatile sig_atomic_t running = 1;void handle_term(int signo) { running = 0;}int main(void) { struct sigaction sa; sa.sa_handler = handle_term; sigemptyset(&sa.sa_mask); sa.sa_flags = 0; if (sigaction(SIGTERM, &sa, NULL) != 0) { perror("sigaction"); return 1; } while (running) { pause(); } puts("graceful shutdown"); return 0;}信号处理函数中应尽量避免调用非异步信号安全函数。复杂清理应设置标志，由主循环处理。8.4 优雅停机理想流程：1. 负载均衡摘除实例2. 停止接收新请求3. 发送 SIGTERM4. 等待存量请求完成5. 关闭资源：连接、文件、锁、队列6. 输出退出原因7. 超时后由编排系统 SIGKILLNginx：sudo nginx -s reloadsudo nginx -s quitreload 通常重读配置并平滑拉起 worker，quit 通常等待请求结束后退出。具体行为以当前版本文档为准。systemd 停止：sudo systemctl stop appsudo systemctl kill -s SIGTERM app超时配置：[Service]TimeoutStopSec=30sKillSignal=SIGTERMKillMode=mixed8.5 SIGPIPE 问题进程向已关闭的管道或 socket 写数据时可能收到 SIGPIPE。很多网络服务会忽略 SIGPIPE，并在写调用处处理 EPIPE 错误。处理原则： 不要让连接关闭直接杀死服务； 写失败要记录上下文； 关闭对应连接； 不掩盖真实 bug； 按语言和框架的推荐方式处理。Java 中对已关闭 socket 的异常处理与 C 不同，应结合具体运行时分析。8.6 Core DumpCore dump 是进程异常退出时的内存镜像，用于定位崩溃。查看限制：ulimit -ccat /proc/sys/kernel/core_pattern临时开启：ulimit -c unlimitedcore 文件路径由 core_pattern 控制，可能由 systemd-coredump、apport 或 abrt 接管，发行版差异较大。systemd：coredumpctl listcoredumpctl info <pid>coredumpctl gdb <pid>生产注意： core 可能包含敏感数据； 大内存进程文件很大； 存储位置要有空间； 需要保留二进制和符号； 采集流程要受控。8.7 信号与 Shell 脚本捕获信号：#!/usr/bin/env bashset -euo pipefailtmpfile=$(mktemp)cleanup() { rm -f "$tmpfile"}trap cleanup EXIT INT TERMecho data > "$tmpfile"sleep 30trap EXIT 会在脚本退出时执行。多个信号的处理顺序和脚本当前命令有关，退出前要保证清理逻辑幂等。忽略 Ctrl+C：trap '' INT恢复默认：trap - INT关键任务不要随意忽略终止信号，应实现可中断的检查点。8.8 信号常见问题kill 没反应ps -o pid,stat,cmd -p <pid>cat /proc/<pid>/status | grep Statedmesg -T | tail -100常见原因： 进程处于 D 状态，等待 IO 返回； 僵尸进程，等待父进程回收； PID 1 实现特殊； 命令拼写或目标错误； 权限不足； 内核或存储异常。重载配置无效nginx -tsudo systemctl reload nginxjournalctl -u nginx -n 100检查： 配置文件路径； 是否 reload 到主进程； 是否还有独立 worker 未退出； 配置是否实际命中当前 server 块； 是否需要重启而非 reload。容器停止很慢SIGTERM 未被应用处理 -> 编排等待 termination grace period -> 超时后 SIGKILL检查应用是否监听 SIGTERM，以及入口脚本是否会转发信号。本章小结信号是进程生命周期控制的基础。生产服务要正确处理 SIGTERM，实现摘流、停止接流、处理存量请求和释放资源。SIGKILL 是保底手段，不是日常操作。Core dump 有助于崩溃定位，但必须治理大小、安全和留存。思考题 为什么 SIGKILL 不能被捕获？ 设计一个 Java 服务的优雅停机流程。 KillMode=control-group 和 mixed 有什么差异？ 哪些信号适合用于重载配置？ 脚本中如何保证临时文件被清理？
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。进程是 Linux 资源分配的基本单位。服务为什么启动失败、CPU 为什么高、进程为什么退出、僵尸进程从哪里来，都需要从进程状态、父子关系、环境和信号入手。7.1 进程基础查看进程：ps auxps -efps -eo pid,ppid,user,stat,%cpu,%mem,etime,cmd --sort=-%cpups -p <pid> -o pid,ppid,user,stat,cmd动态观察：tophtop进程树：pstree -appstree -ap -s <pid>进程关键属性： 属性 含义 PID 进程 ID PPID 父进程 ID UID 运行用户 STAT 状态 %CPU CPU 使用率 %MEM 物理内存占比 nice 调度优先级 cmdline 启动命令 7.2 进程状态ps 常见状态： 状态 含义 R 运行或等待 CPU S 可中断睡眠 D 不可中断 IO 等待 Z 僵尸进程 T 暂停 I 空闲内核线程 附加位： 位 含义 s 会话首进程 l 多线程 + 前台进程组 < 高优先级 N 低优先级 D 状态常见于 IO 或存储异常，通常不能被普通信号杀死。大量 D 状态要检查磁盘、文件系统和内核日志。7.3 查看进程详情cat /proc/<pid>/statuscat /proc/<pid>/cmdlinecat /proc/<pid>/environls -l /proc/<pid>/cwdls -l /proc/<pid>/exels -l /proc/<pid>/fdcat /proc/<pid>/limitscat /proc/<pid>/io示例：tr '\0' '\n' < /proc/<pid>/environ | grep JAVA_HOMEreadlink -f /proc/<pid>/cwdreadlink -f /proc/<pid>/exe排查要点： 进程到底在哪里运行； 使用哪个二进制； 环境变量是否正确； 打开了哪些文件； 限制是否足够。7.4 前台、后台与作业启动后台任务：./server &查看作业：jobs -l切换：fg %1bg %1暂停：Ctrl+Z脱离当前终端继续运行：nohup ./server > server.log 2>&1 &disown -h %1生产服务不要长期用 nohup 管理，应使用 systemd 或容器编排。7.5 信号查看信号：kill -l常用信号： 信号 数字 含义 SIGHUP 1 挂起，也常用于重载配置 SIGINT 2 中断，通常是 Ctrl+C SIGQUIT 3 退出并可能生成 core SIGTERM 15 正常终止，推荐 SIGKILL 9 强制杀死 SIGSTOP 19 暂停 SIGCONT 18 继续 发送信号：kill <pid>kill -15 <pid>kill -TERM <pid>kill -9 <pid>pkill -TERM -f 'java -jar app.jar'killall -TERM nginx优先顺序：SIGTERM -> 等待应用清理并退出 -> 超时后 SIGKILL不要一上来就 kill -9，否则可能丢数据、留下锁或半写状态。7.6 退出与等待查看退出码：trueecho $?falseecho $?常见退出码： 退出码 含义 0 成功 1 常见通用错误 2 命令用法错误 126 无权限执行 127 命令不存在 130 Ctrl+C 中断 137 通常对应 SIGKILL，128 + 9 143 通常对应 SIGTERM，128 + 15 脚本判断：command || exit 1command && echo OK7.7 僵尸进程僵尸进程是已经退出，但父进程尚未回收退出状态的进程。查找：ps -eo pid,ppid,stat,cmd | awk '$3 ~ /^Z/'处理： 修复父进程的资源回收逻辑； 父进程可响应时重载或重启； 孤儿进程通常由 init / systemd 收养并自动回收。僵尸本身不占用大量内存，但大量堆积说明父进程实现有问题。7.8 进程优先级查看：nice -n 10 ./batch-jobrenice -n 10 -p <pid>ionice -c2 -n7 -p <pid>取值范围和默认值与系统实现有关。普通用户通常只能降低自己的优先级，即数值变大。批处理任务建议：nice -n 19 ionice -c2 -n7 ./batch-job避免离线任务和在线服务抢占关键资源。7.9 /proc 与 cgroup 视角查看 cgroup：cat /proc/<pid>/cgroupls /sys/fs/cgroup查看服务归属：systemctl status <service>systemctl show <service> -p MainPID -p Cgroup容器中常见两个视角： 视角 命令 说明 宿主机全局 ps aux 看到所有进程 容器 namespace docker top <container> 或容器内 ps 看到容器内视图 排查 Java 应用 CPU 高时，要区分是容器限流还是宿主机整体繁忙。7.10 常见故障启动失败systemctl status appjournalctl -u app -n 200 --no-pagersystemctl cat appcat /proc/$(systemctl show -p MainPID --value app)/limits 2>/dev/null常见原因： 二进制不存在或无执行权限； 配置文件权限错误； 端口占用； 用户或目录错误； 环境变量缺失； 文件数或进程数限制； 应用自身校验失败。进程消失journalctl -u app --since '1 hour ago'dmesg -T | grep -Ei 'oom|killed process'systemctl show app -p ExecMainStatus -p ResultOOM：内核根据内存压力选择牺牲进程 -> dmesg 出现 Out of memory -> 进程退出码可能是 137CPU 高top -H -p <pid>ps -T -p <pid>pidstat -t -p <pid> 1先定位线程，再转换为应用线程栈。Java 可结合 jstack 分析。本章小结进程管理要理解 PID、PPID、状态、环境、打开文件、信号和退出码。生产终止流程应优先 SIGTERM，等待应用清理，超时后再 SIGKILL。服务长期运行应交给 systemd 或容器编排，而不是 nohup。思考题 D 状态和 R 状态分别说明什么问题？ kill -15 和 kill -9 的核心差异是什么？ 退出码 137 和 143 通常代表什么？ 僵尸进程的根因在哪里？ 服务启动失败时，你会按什么顺序收集证据？
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。日志、配置、CSV、JSON、命令输出都是文本。Linux 提供了一组小而强的工具：grep 查、sed 改、awk 切、sort 排、uniq 统计、cut 取列。组合它们，可以在几分钟内完成大量定位工作。6.1 查看与统计cat app.logless app.loghead -n 100 app.logtail -n 100 app.logtail -F app.logwc -l app.logwc -c app.logless 常用操作： 按键 作用 /word 向下搜索 ?word 向上搜索 n 下一个 N 上一个 G 到文件末尾 g 到文件开头 q 退出 编码问题：file app.logiconv -f GBK -t UTF-8 old.log > new.log6.2 grep 详解基础：grep ERROR app.loggrep -i error app.loggrep -n ERROR app.loggrep -v DEBUG app.loggrep -E 'ERROR|WARN' app.loggrep -F '10.20.30.40' access.loggrep -c ERROR app.loggrep -r "listen 80" /etc/nginx上下文：grep -A 5 ERROR app.loggrep -B 5 ERROR app.loggrep -C 10 ERROR app.log文件过滤：grep -r --include='*.log' ERROR /var/loggrep -r --exclude='*.gz' ERROR /var/log正则示例：grep -E '^[0-9]{4}-[0-9]{2}-[0-9]{2}' app.loggrep -E 'status=[45][0-9]{2}' access.loggrep -E '\btimeout\b' app.loggrep 按行匹配，不适合解析复杂嵌套 JSON。结构化数据优先使用 jq。6.3 cut 与 awkcut 适合简单分隔符：cut -d: -f1 /etc/passwdcut -d, -f1,3 users.csvcut -c1-20 app.logawk 按字段处理：awk '{print $1}' access.logawk -F: '{print $1, $7}' /etc/passwdawk -F, '{print $1, $3}' users.csvawk 'END {print NR}' app.log条件：awk '$9 >= 500 {print $1, $7, $9}' access.logawk '/ERROR/ {print $1, $5}' app.logawk -F, '$3 > 100 {sum += $3} END {print sum}' orders.csv格式化：awk '{printf "%-20s %10s\n", $1, $7}' access.log内置变量： 变量 含义 NR 当前行号 NF 当前字段数 FS 输入分隔符 OFS 输出分隔符 FILENAME 当前文件名 示例：awk -F'|' 'BEGIN{OFS=","} {print $1, $3, $5}' events.log6.4 sed 详解替换：sed 's/ERROR/error/' app.logsed 's/ERROR/error/g' app.logsed 's/port=8080/port=9090/' app.confsed -i 's/port=8080/port=9090/' app.conf删除：sed '/^#/d' app.confsed '/^$/d' app.confsed '1d' users.csvsed '$d' users.csv显示：sed -n '10,20p' app.logsed -n '/ERROR/p' app.log插入：sed '/^\[server\]/a listen=9090' app.inised '1i # generated by ops' app.conf安全修改：cp app.conf app.conf.baksed -i 's/debug=true/debug=false/' app.confdiff -u app.conf.bak app.confGNU sed 与其他平台的参数细节可能不同。跨平台脚本应先测试。6.5 sort 与 uniq排序：sort app.logsort -r app.logsort -n sizes.txtsort -h sizes.txtsort -t, -k2 users.csvsort -u ips.txt统计：sort ips.txt | uniq -csort ips.txt | uniq -c | sort -nrsort ips.txt | uniq -dsort ips.txt | uniq -u经典统计：访问次数前 10 的 IP：awk '{print $1}' access.log | sort | uniq -c | sort -nr | head -10uniq 只合并相邻重复行，所以通常要先 sort。6.6 join 与 diffjoin 合并两个已排序文件：join -t, -1 1 -2 1 users.csv orders.csvdiff 比较差异：diff -u old.conf new.confdiff -rq /opt/app/releases/v1 /opt/app/releases/v2配置发布前建议保存差异：diff -u /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf6.7 正则表达式常用元字符： 符号 含义 . 任意单个字符 * 前一个元素零次或多次 + 一次或多次，扩展正则 ? 零次或一次，扩展正则 ^ 行首 $ 行尾 [abc] 字符集合 [^abc] 排除字符 \b 单词边界 () 分组 | 或 示例：grep -E '^2026-08-25.*(ERROR|WARN)' app.loggrep -E 'user_id=[0-9]+' app.logsed -E 's/([0-9]{3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})/<ip>/g' access.log日志脱敏要在采集或展示层统一实现，不能只依赖临时命令。6.8 jq 处理 JSON安装：sudo apt install jqsudo dnf install jq格式化：echo '{"id":1,"status":"PAID"}' | jq .jq . events.json取字段：jq '.status' event.jsonjq '.user.id' event.jsonjq '.items[0].sku' event.json数组：curl -s http://localhost:8080/api/users | jq '.[] | {id, name}'jq '[.[] | select(.status == "PAID")]' orders.jsonjq 'length' orders.json统计：jq -r '.[] | .city' orders.json | sort | uniq -cjq -r '.[] | [.id, .amount] | @tsv' orders.json6.9 xargs 与并行xargs 把输入变成命令参数：cat hosts.txt | xargs -n1 ping -c1find /var/log -name '*.gz' | xargs ls -lhfind /tmp -name '*.tmp' | xargs rm处理空格和特殊字符：find /opt/app -type f -name '*.log' -print0 | xargs -0 grep ERROR并行：cat hosts.txt | xargs -P 10 -n1 ping -c1删除类命令先预览：find /tmp -name '*.tmp' -printfind /tmp -name '*.tmp' -print0 | xargs -0 rm6.10 生产日志案例案例一：统计错误分布grep -E 'ERROR|WARN' app.log | awk -F'|' '{print $2}' | sort | uniq -c | sort -nr | head -20案例二：定位某用户请求grep 'userId=10001' app.loggrep 'trace_id=7f3a' app.log案例三：压缩日志查找zgrep ERROR app.log.gzzcat app.log.gz | grep ERRORzless app.log.gz案例四：统计 HTTP 状态awk '{print $9}' access.log | sort | uniq -c | sort -k2nNginx 日志格式不同时，字段位置可能不同，应先看日志格式定义。6.11 性能与边界大文件处理： 先缩小时间范围； 再按关键字过滤； 避免无意义的全量 cat； 压缩日志用 zgrep； 超大文本考虑日志平台或数据库。示例：grep '^2026-08-25 10:' app.log | grep ERROR复杂需求不要无限堆管道。当脚本超过一定复杂度，改用 Python、Go 或日志平台更清晰。本章小结文本处理遵循“过滤、切分、排序、统计、输出”的思路。grep 找行，awk 处理字段，sed 做流编辑，sort 和 uniq 完成统计，jq 处理 JSON，xargs 把文本转成参数。临时命令高效，但长期方案应沉淀到脚本、监控和日志平台。思考题 为什么 uniq 之前通常要 sort？ sed -i 修改文件前应做什么？ 如何安全处理包含空格的文件名？ grep 和 jq 各适合什么数据格式？ 设计一条管道统计 Nginx 日志中 5xx 响应最多的 URL。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。软件包管理负责安装、升级、回滚、依赖解析和仓库配置。不同发行版使用不同工具，但核心问题一致：软件从哪里来，版本是什么，依赖是否完整，升级是否可回滚。5.1 包管理体系 发行版 底层工具 高层工具 包格式 Debian / Ubuntu dpkg apt .deb RHEL / CentOS / Rocky / Alma rpm dnf / yum .rpm Alpine apk apk .apk openSUSE rpm zypper .rpm 底层工具直接操作包文件，高层工具会处理仓库和依赖。日常安装优先使用高层工具。5.2 APT 常用操作更新索引：sudo apt update查看可用升级：apt list --upgradable升级：sudo apt upgradesudo apt full-upgrade安装与删除：sudo apt install nginxsudo apt install nginx=1.24.0-1sudo apt reinstall nginxsudo apt remove nginxsudo apt purge nginxsudo apt autoremove查询：apt search redisapt show nginxdpkg -l | grep nginxdpkg -L nginxdpkg -S /usr/sbin/nginxdpkg -s nginx清理缓存：sudo apt cleansudo apt autoclean保存下载包：/var/cache/apt/archives/5.3 DNF / YUM 常用操作sudo dnf check-updatesudo dnf updatesudo dnf install nginxsudo dnf reinstall nginxsudo dnf remove nginxsudo dnf autoremove查询：dnf search redisdnf info nginxdnf list installed | grep nginxdnf repoquery -l nginxdnf provides '*/nginx'rpm -qa | grep nginxrpm -qi nginxrpm -ql nginxrpm -qf /usr/sbin/nginx历史与回滚：sudo dnf historysudo dnf history info <id>sudo dnf history undo <id>回滚会重新计算依赖，不一定总是可用。关键服务升级前必须准备独立回滚方案。5.4 仓库与优先级APT 配置：/etc/apt/sources.list/etc/apt/sources.list.d/*.list查看仓库：grep -R '^deb ' /etc/apt/sources.list /etc/apt/sources.list.dDNF 配置：/etc/yum.repos.d/*.repo查看仓库：dnf repolistdnf repoinfo启用或禁用仓库：sudo dnf config-manager --set-enabled extrassudo dnf config-manager --set-disabled extras不同版本 DNF 的配置命令参数有差异，以当前系统文档为准。生产原则： 使用可信内部镜像源； 固定基础镜像； 关键组件版本显式声明； 避免混用不稳定第三方仓库； 仓库变更走配置管理； 保留离线安装包。5.5 本地包安装APT：sudo apt download nginxsudo dpkg -i nginx.debsudo apt -f installDNF：sudo dnf download nginxsudo dnf install ./nginx.rpmRPM 直接安装：sudo rpm -ivh nginx.rpmsudo rpm -Uvh nginx.rpm推荐使用 dnf install ./file.rpm，让工具自动处理依赖。5.6 版本锁定APT：sudo apt-mark hold nginxapt-mark showholdsudo apt-mark unhold nginxDNF：sudo dnf install versionlocksudo dnf versionlock add nginxsudo dnf versionlock listsudo dnf versionlock delete nginx锁定可以防止意外升级，但不能替代变更管理。安全补丁仍需按流程评估。5.7 验证包完整性APT：apt-key listsudo apt update新版 APT 使用签名文件，不建议继续新增 apt-key 管理密钥，具体以发行版文档为准。DNF：rpm --import repomd.xml.keyrpm -checksig nginx.rpmrpm -K nginx.rpm校验已安装文件：rpm -V nginxdpkg --verify nginx输出差异可能来自配置变更，也可能是入侵痕迹。对系统二进制被修改的情况，应按安全事件处理。5.8 源码与二进制安装常见方式：系统包 -> 官方二进制包 -> 容器镜像 -> 源码编译源码编译流程：./configure --prefix=/opt/appmake -j"$(nproc)"sudo make install源码安装的问题： 不进入包管理数据库； 依赖和补丁难治理； 升级和卸载成本高； 编译参数容易漂移； 安全漏洞难跟踪。如果必须源码安装，应记录：源码版本下载地址与校验值编译参数编译环境安装路径回滚方式5.9 生产升级流程升级前：1. 明确目标版本和变更窗口2. 阅读官方 changelog 和 breaking change3. 确认依赖影响4. 测试环境验证5. 备份配置和数据6. 准备回滚包7. 确认监控和值班人员升级中：dpkg -l | grep nginxsudo cp -a /etc/nginx /etc/nginx.bak.$(date +%F-%H%M)sudo apt install nginx升级后：nginx -tsystemctl status nginxjournalctl -u nginx -n 100ss -lntp | grep ':443'验证：1. 进程正常2. 端口监听3. 健康检查通过4. 核心接口成功5. 错误率无异常6. 性能指标无异常5.10 容器中的包管理Dockerfile 示例：FROM ubuntu:24.04RUN apt update && \ apt install -y --no-install-recommends curl ca-certificates && \ rm -rf /var/lib/apt/lists/*原则： 基础镜像固定摘要或版本； 清理包缓存； 合并安装层； 不在运行容器里长期手工装包； 镜像构建可重复； 依赖变更走代码评审。5.11 常见问题依赖冲突sudo dnf checksudo apt --fix-broken installdnf repoquery --requires nginxapt show nginx处理前不要强行删除基础库，应先确认冲突仓库和目标版本。磁盘不足df -hsudo dnf clean allsudo apt clean包被进程占用lsof | grep /usr/sbin/nginxsystemctl status nginx多数包管理器会安排服务重启或提示。生产升级应显式控制重启时机。本章小结软件包管理的核心是可重复、可验证、可回滚。APT、DNF、RPM 和 dpkg 的命令不同，但都要回答版本、来源、依赖、配置文件和回滚方式。生产环境应使用可信仓库、固定关键版本、锁定不需要自动升级的包，并通过测试和监控完成升级闭环。思考题 为什么日常安装优先用 apt / dnf 而不是 dpkg / rpm？ remove 和 purge 的区别是什么？ 如何查询某个文件属于哪个包？ 版本锁定有哪些收益和风险？ 设计一个 Nginx 安全补丁的升级和回滚流程。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Linux 的安全边界建立在用户、组、文件权限、sudo 和审计之上。生产事故里，很多问题不是复杂漏洞，而是 root 直接运行业务、配置文件权限过大、sudo 规则过宽或共享账号导致无法追责。4.1 用户与组查看身份：idwhoamigroupswhowlast用户信息：getent passwd appgetent group appcat /etc/passwdcat /etc/group/etc/passwd 示例：app:x:1001:1001:Order Service:/opt/app:/sbin/nologin字段含义： 字段 含义 name 用户名 password 历史密码字段，通常为 x uid 用户 ID gid 主组 ID gecos 描述 home 家目录 shell 登录 Shell 服务账号常使用 /sbin/nologin 或 /usr/sbin/nologin，路径因发行版可能不同。4.2 用户管理创建用户：sudo useradd -m -s /bin/bash dev01sudo useradd -r -s /sbin/nologin -d /opt/app app设置密码：sudo passwd dev01sudo passwd -l appsudo passwd -u dev01修改用户：sudo usermod -aG docker dev01sudo usermod -s /sbin/nologin appsudo usermod -L old-user删除用户：sudo userdel dev01sudo userdel -r dev01userdel -r 会删除家目录和邮箱。生产环境更常见的做法是先锁定账号，确认无资源归属后再删除。4.3 组管理sudo groupadd releasesudo groupadd -g 2000 datasudo gpasswd -a dev01 releasesudo gpasswd -d dev01 releasesudo groupdel release查看成员：getent group releaselid -g release-aG 中的 a 很重要：sudo usermod -aG docker dev01漏掉 a 可能覆盖用户所属组，造成权限丢失。4.4 文件属主与权限ls -l app.confstat app.conf修改属主：sudo chown app:app app.confsudo chown app app.confsudo chgrp app app.confsudo chown -R app:app /opt/app修改权限：chmod 640 app.confchmod 750 deploy.shchmod u+x deploy.sh常用基线： 对象 建议 配置文件 640 或更严格 私钥 600 可执行脚本 750 应用目录 750 日志目录 属组可写或应用可写 Web 根目录 避免应用可写执行同时开放 私钥权限过宽时，SSH 通常会拒绝使用：chmod 600 ~/.ssh/id_ed255194.5 umask查看：umaskumask -S常见值：umask 022目录初始权限 777 - 022 = 755文件初始权限 666 - 022 = 644umask 027目录初始权限 777 - 027 = 750文件初始权限 666 - 027 = 640设置：umask 027服务进程的 umask 应在 systemd、启动脚本或应用配置中显式设置，不要依赖登录 Shell 的默认值。systemd 示例：[Service]UMask=00274.6 ACL传统权限只有一套属主、属组和其他人。ACL 可以给多个用户或组设置不同规则。getfacl app.confsetfacl -m u:dev01:r app.confsetfacl -m g:audit:r app.confsetfacl -x u:dev01 app.confsetfacl -b app.confsetfacl -R -m g:release:rwX /srv/share查看：ls -l app.confgetfacl app.conf权限位末尾出现 + 表示有 ACL：-rw-r-----+ 1 app app 1024 Aug 25 10:00 app.confACL 适合临时协作和例外授权。长期权限模型仍应优先使用属组和目录规划。4.7 sudo查看当前用户可用权限：sudo -l常见命令：sudo systemctl restart nginxsudo -u app /opt/app/bin/server --checksudo -isudo -s推荐使用 sudo -u app 验证应用用户视角：sudo -u app cat /opt/app/conf/app.ymlsudo -u app /opt/app/bin/healthcheck.sh最小授权示例：dev01 ALL=(app) /opt/app/bin/deploy.shops01 ALL=(root) /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx不推荐：dev01 ALL=(ALL) NOPASSWD: ALLsudo 规则文件建议放在：/etc/sudoers.d/<team-or-role>不要直接用普通编辑器修改 /etc/sudoers。修改后必须校验语法：sudo visudo -f /etc/sudoers.d/releasesudo visudo -c4.8 切换用户与审计su - appsudo -iu appsudo -u app bash区别： 命令 行为 su - app 需要目标用户密码，加载登录环境 su app 切换用户，保留部分当前环境 sudo -iu app 用 sudo 授权，加载登录环境 sudo -u app bash 以指定用户执行命令 审计关注：sudo journalctl -t sudo --since todaysudo grep sudo /var/log/auth.logsudo grep sudo /var/log/secure日志文件名因发行版而异。4.9 资源限制与 PAM查看限制：ulimit -nulimit -uulimit -a临时修改：ulimit -n 65535服务建议使用 systemd 管理：[Service]LimitNOFILE=65535LimitNPROC=4096PAM 提供认证、授权、会话和密码策略模块。常见配置目录：/etc/pam.d//etc/security/limits.conf/etc/security/limits.d/修改 PAM 前必须保留会话并演练，错误配置可能导致无法登录。4.10 生产权限模型一个典型的应用部署模型：发布账号 release |-- 可写发布目录 |-- 可执行部署脚本 +-- 不能直接读数据库密码应用账号 app |-- 运行服务 |-- 读写应用数据和日志 +-- 无登录 Shell运维账号 ops |-- 登录跳板机 |-- 受限 sudo +-- 操作有审计目录示例：sudo mkdir -p /opt/app/{conf,logs,run}sudo chown -R app:app /opt/appsudo chmod -R 750 /opt/appsudo chmod 640 /opt/app/conf/*原则： 一个应用一个账号； root 不运行业务； 密钥最小可读； sudo 按命令授权； 变更可追踪到人； 权限由配置管理维护。4.11 常见问题排查Permission deniedidls -ld /opt/app /opt/app/confls -l /opt/app/conf/app.ymlgetfacl /opt/app/conf/app.ymlsudo -u app cat /opt/app/conf/app.yml检查路径上每一级目录的执行权限。无法通过 SSH 登录sudo journalctl -u ssh --since todaysudo grep sshd /var/log/auth.logsudo passwd -S dev01sudo chage -l dev01常见原因： 账号锁定； 密码过期； Shell 为 nologin； SSH 禁用密码或 root 登录； 家目录权限异常； 密钥权限过宽。sudo 报不是 sudoerssudo -lsudo visudo -cgetent group wheelgetent group sudo处理时应通过配置管理修改授权，而不是临时加入过宽组。本章小结用户和组定义身份，文件权限定义资源访问边界，sudo 提供受控提权，审计回答“谁在何时做了什么”。生产环境应坚持独立应用账号、最小权限、无共享账号、密钥文件严格权限和可回滚的配置管理。思考题 usermod -G 和 usermod -aG 有什么区别？ 为什么 /etc/sudoers 必须用 visudo 校验？ ACL 和传统属组权限各适合什么场景？ 应用进程的文件数限制应该在哪里配置？ 为一个 Java 服务设计用户、目录和 sudo 权限方案。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Linux 以统一目录树组织所有资源。理解文件类型、目录结构、链接、元数据、时间戳和 inode，是排查“文件删了但磁盘没释放”“目录无法进入”“硬链接和软链接差异”等问题的前提。3.1 目录结构回顾/|-- bin -> usr/bin|-- boot|-- dev|-- etc|-- home|-- opt|-- proc|-- root|-- srv|-- sys|-- tmp|-- usr+-- var常见目录： 目录 用途 /etc 配置 /home 普通用户家目录 /root root 家目录 /var/log 日志 /var/lib 服务状态数据 /opt 第三方软件 /srv 服务数据 /tmp 临时文件 /dev 设备 /proc 进程与内核信息 /sys 设备与内核参数 不要把业务大文件随意放在 /root 或 /tmp。/tmp 可能被清理策略影响。3.2 查看与创建查看：pwdls -lahls -ld /opt/appstat app.conffile app.bin创建与删除：mkdir deploymkdir -p app/conf/app-configtouch app.logrmdir empty-dirrm app.logrm -r old-app复制与移动：cp app.conf app.conf.bakcp -a /opt/app /opt/app.bakcp -r conf /tmp/confmv app.log archive/mv old.conf new.confrename 's/.log$/.old/' *.logcp -a 会尽量保留权限、属主和时间戳。跨文件系统时行为可能受支持能力影响。3.3 文件类型ls -lh /dev/sdals -l /etc/nginx/nginx.confstat /var/run首字符含义： 字符 类型 - 普通文件 d 目录 l 符号链接 b 块设备 c 字符设备 s socket p 命名管道 查看进程打开的 socket：ss -lntplsof -nP -p <pid>3.4 inode 与文件名inode 保存文件元数据：inode |-- 文件类型与权限 |-- 属主与属组 |-- 大小 |-- 时间戳 |-- 链接计数 |-- 数据块指针 +-- 指向 dir entry 的文件名在目录项中，不在 inode 中查看 inode：ls -i app.logdf -ihstat app.log典型问题： 现象 常见原因 df -h 有空间，创建文件报错 inode 耗尽 删除大日志后磁盘不释放 文件仍被进程打开 目录有写权限但不能创建 目录执行权限缺失或配额限制 文件名存在但内容异常 应用写入方式或路径错误 处理被进程占用的已删除文件：lsof +L1ls -l /proc/<pid>/fd处理方式通常是重载或重启对应进程，先评估业务影响。3.5 链接软链接示例：ln -s /opt/app/current /opt/app/latestls -l /opt/app/latestreadlink -f /opt/app/latest硬链接示例：echo hello > a.txtln a.txt b.txtls -li a.txt b.txtrm a.txtcat b.txt 特性 硬链接 软链接 本质 指向同一 inode 指向路径 跨文件系统 通常不可 可以 链接目录 一般不允许 可以 目标删除后 数据仍可访问 可能悬空 大小 元数据角度相同 存路径字符串 发布目录常使用软链接：/opt/app/releases/v1/opt/app/releases/v2/opt/app/current -> /opt/app/releases/v2切换时只切换 current，并确保应用按真实路径解析配置。3.6 时间戳stat 常见字段： 字段 含义 Access 访问时间 Modify 内容修改时间 Change inode 元数据变化时间 Birth 创建时间，支持情况与文件系统有关 示例：stat app.logtouch -d '2026-08-25 10:00:00' app.logfind /var/log -type f -mtime +7find /var/log -type f -mmin -60时间可能受 relatime、挂载选项和文件系统实现影响。审计场景要以审计系统和时间同步策略为准。3.7 文件与目录权限drwxr-xr-x| | | || | | +-- others: r-x| | +----- group : r-x| +-------- owner : rwx+---------- directory普通文件权限： 权限 对文件 r 可读内容 w 可修改内容 x 可执行 目录权限： 权限 对目录 r 可列出条目名 w 可创建、删除、重命名条目 x 可进入目录并访问 inode 只给目录读权限时，能看到文件名，但不能读取文件属性和内容。修改：chmod 644 app.confchmod 750 deploy.shchmod u+x deploy.shchmod g-w app.confchown app:app app.confchgrp app app.conf递归修改要谨慎：chown -R app:app /opt/appfind /opt/app -type d -exec chmod 750 {} +find /opt/app -type f -exec chmod 640 {} +3.8 特殊权限Set UID：chmod u+s /usr/bin/passwd执行者临时获得文件属主权限。系统会严格限制这类程序。Set GID：mkdir /srv/sharechgrp app /srv/sharechmod 2775 /srv/share目录中新文件继承目录属组，便于团队共享。Sticky Bit：chmod 1777 /tmpls -ld /tmp常见权限数字： 数字 含义 4755 Set UID + rwxr-xr-x 2775 Set GID + rwxrwxr-x 1777 Sticky + rwxrwxrwx 特殊权限会扩大影响面，业务程序中不应随意使用。3.9 磁盘占用分析df -hTdf -ihdu -sh /var/logdu -h --max-depth=2 /var | sort -hncdu /var排查思路：df 确认文件系统水位 -> du 定位大目录 -> find 定位大文件 -> lsof +L1 检查已删除但被占用文件 -> 确认日志轮转和清理策略示例：find /var -xdev -type f -size +100M -printf '%s %p\n' | sort -nr | head -20删除日志前确认应用轮转策略：ls -lh /var/log/nginxgrep -R 'rotate' /etc/logrotate* 2>/dev/null3.10 压缩与归档tar -czf app-$(date +%F).tar.gz /opt/apptar -xzf app-2026-08-25.tar.gz -C /tmptar -tf app-2026-08-25.tar.gz | headgzip app.loggunzip app.log.gzzcat app.log.gz | headbzip2 app.logxz app.logzip -r app.zip /opt/appunzip app.zip -d /tmp/app常用格式： 格式 命令 特点 .tar.gz tar -czf 兼容好，常见 .tar.xz tar -cJf 压缩率高，耗时更长 .tar.bz2 tar -cjf 介于两者之间 .zip zip 跨平台常见 解包前先查看内容，避免把大量文件直接释放到当前目录。3.11 生产案例案例：磁盘满但找不到大文件现象：df 显示 95%du 汇总明显小于 df排查：df -hTdu -sh /var/* 2>/dev/nulllsof +L1dmesg -T | tail结论：日志文件被删除，但进程仍持有文件描述符。处理： 先确认日志是否仍需要； 通过重载日志组件或滚动进程释放； 必要时安排业务低峰重启； 修复 logrotate 和磁盘告警。案例：软链接悬空ls -l /opt/app/currentreadlink -f /opt/app/currenttest -e /opt/app/current && echo OK || echo BROKEN发布系统应在切换后立即验证链接目标和服务健康状态。本章小结文件系统围绕目录项、inode 和数据块组织。目录权限控制的是条目访问能力，普通文件权限控制的是内容访问能力。软链接适合发布切换，硬链接适合同一文件系统内的多路径引用。磁盘排查要同时看容量和 inode，并注意被进程占用的已删除文件。思考题 为什么删除一个仍在被写入的日志文件，磁盘空间不会立即释放？ 目录的 r 和 x 权限有什么区别？ 硬链接和软链接分别适合哪些场景？ df -h 正常但创建文件失败，还需要检查什么？ 设计一个发布目录结构，支持版本保留和快速回滚。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。命令行是 Linux 的主操作界面。图形界面适合浏览和观察，命令行适合精确、重复、可审计的生产操作。本章把 Shell 提示符、参数、通配符、重定向、管道、历史命令和帮助系统讲清楚。2.1 Shell 提示符常见提示符：[app@web01 ~]$[root@db01 /var/log]#含义： 符号 含义 app / root 当前用户 web01 / db01 主机名 ~ 当前用户家目录 /var/log 当前目录 $ 普通用户 # root 用户 确认环境：whoamihostnamepwdecho "$SHELL"bash --version生产操作前先确认主机名和用户，避免在错误机器上执行变更。2.2 命令格式command [options] [arguments]示例：lsls -lls -lah /var/logtar -czf app.tar.gz /opt/app短选项可以合并：ls -l -a -hls -lah长选项通常不能随意合并：docker ps --alldf --human-readable大小写敏感：lsLS后一个命令通常会报 command not found。2.3 常用命令目录与位置：pwdcd /var/logcd ~cd -cd ..lsls -lahtree -L 2 /opt文件查看：cat app.confless /var/log/sysloghead -n 50 app.logtail -n 50 app.logtail -f app.logwc -l app.logstat app.logfile app.bin时间与系统：datedate -uuptimeuname -acat /etc/os-releasefree -hdf -hTtail -f 适合观察追加日志。查看轮转后的新文件可用：tail -F app.log2.4 通配符与路径绝对路径从 / 开始，相对路径从当前目录开始。/etc/nginx/nginx.conf 绝对路径./conf/nginx.conf 当前目录../shared/config.yml 上一级目录~/deploy.sh 当前用户家目录常用通配符： 符号 含义 示例 * 任意长度字符 *.log ? 一个字符 app?.conf [abc] 一个指定字符 app[12].log {a,b} 多个候选 app.{conf,yml} 示例：ls /var/log/*.logls *.confcp app.{conf,bak}rm app-2026-0[1-3].log危险命令必须先预览展开结果：echo /var/log/*.logls /data/backup/*涉及删除时，不要把未确认的变量直接拼进命令。2.5 引号与转义user=appecho $userecho "$user"echo '$user'echo "PATH=$PATH"echo "name\tvalue"区别： 写法 行为 $user 变量替换 "$user" 变量替换，保留参数边界 '$user' 不替换 \$user 转义 $ `cmd` 命令替换，旧写法 $(cmd) 命令替换，推荐 推荐：today=$(date +%F)echo "backup-$today.tar.gz"包含空格的路径必须加引号：cp "my config.yml" /tmp/find /opt -name '*.log'2.6 重定向标准输入、输出和错误： 描述符 名称 数字 stdin 标准输入 0 stdout 标准输出 1 stderr 标准错误 2 输出：command > out.logcommand >> append.logcommand 2> error.logcommand > all.log 2>&1command &> all.logbash 支持 &>。跨 Shell 脚本更推荐下面的写法：command > all.log 2>&1丢弃输出：command > /dev/nullcommand > /dev/null 2>&1输入：mysql < schema.sqlsha256sum app.tar.gz < checksum.txtHere Document：cat <<'EOF'server: port: 8080EOF带引号的 EOF 不做变量替换，适合写配置模板。2.7 管道管道把前一个命令的标准输出接到后一个命令的标准输入：ps aux | grep java | grep -v grep常用管道：cat access.log | wc -lps aux | sort -nrk 3 | headdu -sh /var/log/* | sort -hjournalctl -u nginx --since today | tail -100错误流不会自动进入管道：command 2>&1 | grep ERROR查看大文件时优先用 less，避免把数十万行刷到终端。2.8 查找与过滤grep：grep ERROR app.loggrep -n ERROR app.loggrep -i error app.loggrep -v DEBUG app.loggrep -r "listen 80" /etc/nginxgrep -E 'ERROR|WARN' app.loggrep -c ERROR app.log常用选项： 选项 含义 -i 忽略大小写 -n 显示行号 -v 反向匹配 -r 递归目录 -E 扩展正则 -c 统计匹配行 -F 按字面字符串匹配 -A/-B/-C 显示后、前、上下文 查找文件：find /etc -name '*.conf'find /var/log -type f -name '*.gz'find /data -type f -size +100Mfind /opt/app -type f -mmin -30find /tmp -type f -delete删除动作要分两步执行：find /tmp -type f -name '*.tmp' -printfind /tmp -type f -name '*.tmp' -delete2.9 历史与补全历史命令：historyhistory | tail -20!$!! Ctrl+R常用快捷键： 快捷键 作用 Ctrl+C 终止前台命令 Ctrl+D 结束输入或退出 Shell Ctrl+R 搜索历史 Ctrl+A 到行首 Ctrl+E 到行尾 Ctrl+U 删除到行首 Ctrl+K 删除到行尾 Ctrl+L 清屏 Tab 补全 历史命令是审计线索，也可能包含敏感参数。不要把密码直接写在命令行里。2.10 获取帮助ls --helpman lsinfo coreutilstype cdwhich nginxwhereis nginxaliasman 常用章节： 章节 内容 1 用户命令 5 配置文件格式 8 管理命令 示例：man 5 crontabman 8 systemctl不同发行版的命令行为可能不同。生产执行前，应以当前系统的 man、--help 和官方文档为准。2.11 生产操作习惯变更前：1. 确认主机、用户、目录2. 备份目标文件3. 预览通配符展开结果4. 确认命令作用范围5. 准备回滚命令变更中：1. 只做计划内操作2. 保留终端输出3. 记录时间戳4. 出现异常立即停止变更后：1. 检查配置语法2. 检查进程和端口3. 观察日志4. 验证业务指标5. 更新工单记录备份配置：cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak.$(date +%F-%H%M)本章小结命令行操作的核心是理解命令、选项、参数、路径、引号、重定向和管道。通配符和变量让操作高效，也让风险放大；生产变更前先预览展开结果，并保留备份与回滚方案。遇到不熟悉的命令，优先查看当前系统的帮助文档。思考题 > 和 >> 的区别是什么？ 为什么 command > log 2>&1 不能写成 command 2>&1 > log 的等价形式？ 单引号和双引号对变量替换有什么区别？ 如何安全执行 find ... -delete？ 设计一条管道统计 Nginx 访问日志中出现次数最多的前 10 个客户端 IP。
• 这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Linux 是互联网后端的主流操作系统。数据库、消息队列、缓存、容器、网关、微服务，几乎都运行在 Linux 上。理解 Linux 能让你把“应用慢”拆成 CPU、内存、IO、网络、进程、锁和调度问题，而不是只重启服务。本章先建立 Linux 的整体视图：系统组成、内核与用户态、文件系统、进程、Shell 和生产运维视角。1.1 Linux 系统组成Hardware -> Kernel |-- Process Scheduler |-- Memory Management |-- Virtual File System |-- Network Stack |-- Device Drivers +-- IPC / Security -> System Call Interface -> User Space |-- Shell |-- System Libraries |-- Daemons +-- Applications 层 职责 硬件 CPU、内存、磁盘、网卡 内核 管理资源、隔离进程、提供系统调用 系统调用 用户态访问内核能力的入口 用户态 Shell、服务进程、应用 内核与用户态分离是为了安全和稳定： 用户进程不能直接访问硬件； 权限通过系统调用检查； 进程地址空间隔离； 异常进程不应直接拖垮系统； 内核态和用户态切换有成本。1.2 Shell 是什么Shell 是命令解释器，也是运维自动化的语言。查看当前 Shell：echo $SHELL常用 Shell： Shell 说明 bash Linux 常见默认 Shell zsh 交互体验好 sh POSIX 基础 Shell fish 语法友好，但兼容性不同 查看系统：uname -acat /etc/os-releaseuptimewhoamipwd1.3 文件系统层级Linux 采用统一目录树。 目录 内容 /bin 基本命令 /boot 启动文件 /dev 设备文件 /etc 配置文件 /home 用户目录 /root root 用户目录 /var 日志、缓存、可变数据 /tmp 临时文件 /opt 第三方软件 /srv 服务数据 /proc 内核和进程信息 /sys 设备与内核参数 查看目录：ls -lah /var/logdf -hTdu -sh /var/log/*/proc 是虚拟文件系统：cat /proc/cpuinfocat /proc/meminfocat /proc/loadavg1.4 一切皆文件Linux 的很多资源都以文件形式暴露： 路径 资源 /dev/sda 磁盘设备 /dev/null 黑洞设备 /proc/self/status 当前进程状态 /etc/nginx/nginx.conf 配置 /var/log/syslog 日志 标准流： 文件描述符 名称 0 stdin 1 stdout 2 stderr 重定向：command > out.logcommand >> append.logcommand 2> error.logcommand > all.log 2>&1管道：ps aux | grep java | head -201.5 进程初步进程是资源分配单位，线程是 CPU 调度单位。查看进程：ps auxps -eftophtop进程状态： 状态 含义 R 运行或可运行 S 可中断睡眠 D 不可中断 IO 等待 Z 僵尸进程 T 暂停 启动后台进程：./server &查看任务：jobsfg %1bg %1终止进程：kill -15 PIDkill -9 PID生产上优先使用 SIGTERM，让应用优雅退出；SIGKILL 不给清理机会。1.6 用户与权限查看当前身份：idwhoamigroups文件权限：-rw-r--r--含义： 位 说明 - 文件 rw- 属主读写 r-- 属组读 r-- 其他人读 修改权限：chmod 644 app.confchmod 750 deploy.shchown app:app /opt/app生产原则： 应用使用独立用户运行； 不用 root 启动业务； 秘密文件最小权限； sudo 需要审计； SSH 禁止 root 远程登录； 权限变更要有配置管理。1.7 系统启动与服务传统 SysV init 逐步被 systemd 取代。systemd 常用命令：systemctl status nginxsystemctl start nginxsystemctl stop nginxsystemctl restart nginxsystemctl enable nginxsystemctl disable nginxjournalctl -u nginx -f一个服务单元示例：[Unit]Description=Order ServiceAfter=network-online.target[Service]User=appWorkingDirectory=/opt/orderExecStart=/usr/bin/java -jar /opt/order/app.jarRestart=alwaysRestartSec=5LimitNOFILE=65535[Install]WantedBy=multi-user.target1.8 生产视角：先看负载登录一台慢服务器，先看：uptimetopfree -hdf -hdmesg -T | tail -100load average 表示系统平均负载：load average: 4.20, 3.80, 3.10判断依据： 和 CPU 核数比较； 看趋势； 区分 CPU 高、IO 等待高还是 D 状态进程多； 结合内存和交换分区； 结合应用日志和监控。查看 CPU 核数：nproclscpu1.9 Linux 学习路线第一阶段：日常操作 文件操作； 文本查找； 权限； 进程； 日志查看。第二阶段：服务管理 systemd； 软件包； 网络； 磁盘； 定时任务； Shell 脚本。第三阶段：性能分析 CPU； 内存； IO； 网络； 进程状态； 火焰图。第四阶段：自动化与安全 Ansible； 审计； 防火墙； 加固； 备份恢复； 故障演练。本章小结Linux 由内核、系统调用和用户态组成。文件、进程、权限和服务是日常运维的核心对象；CPU、内存、IO 和网络是性能分析的四大资源。生产排障应从系统负载和资源指标入手，再进入应用日志和链路追踪。思考题 内核态和用户态分离有什么意义？ /proc 为什么没有真实磁盘占用却能读到进程信息？ kill -9 和 kill -15 有什么区别？ 为什么不建议用 root 运行业务进程？ 服务器 load 高时，如何判断是 CPU、IO 还是不可中断等待？