第1章 Linux 日常排障

对应简历：技能第 3 条「熟练掌握 Linux（Ubuntu / CentOS / 统信 / 麒麟）常用命令与日志查看，能独立完成服务器基础巡检与常见故障排查」；职责实-3「负责平台日常巡检、监控告警响应」；职责运-3「建设并维护 IT 知识库、SOP 与故障处理手册」。 支持版定位：本章是"支持工程师的服务器排障手册"——面试官考支持岗 Linux，考的不是调优深度，而是接到报障后你按什么顺序查、每个命令的输出怎么读、查到什么程度算定位完成。 K8s/容器层的检查在第 06/05 章，网络连通性排查在第 09 章，本章不重复。

1.1 常用命令与巡检三件套 【必背】

标准回答：如果让我按支持工作的频度报命令，我按三类说。 第一类文件与文本：ls、cd、cp、mv、mkdir、tar 压缩解压，cat 看小文件、tail -f 实时追日志、grep 过滤关键字、find 按名字或时间找文件——这组是查日志、找文件、收证据的基础。 第二类系统状态：top 看 CPU 和内存、free -h 看内存、df -h 看磁盘空间、du -sh 看目录大小、ps aux 看进程、uptime 看负载和运行时长。 第三类进程网络与服务：ss -lntup 看端口和进程对应关系、systemctl 管服务、journalctl 看服务日志、ssh/scp 做远程和传文件。

这套组合覆盖支持工作八成场景：巡检时用 top、free、df 三件套加 systemctl --failed，排障时用 tail、grep、ss 顺着日志和端口往下钻，交付初始化时用 systemctl、tar、find 铺环境。 我在银行项目 15 多台国产化虚拟机上驻场近两年，这些命令是每天手不离的——面试被问"你最常用哪条"，我会答"tail 加 grep"，因为支持工作的一半是从日志开始的。

追问链：

• 追问1：查看一个程序日志的最后 50 行并确认有没有报错，怎么操作？ → 答：先 tail -n 50 /var/log/xxx.log 看最后 50 行有没有异常堆栈；再用 grep -iw error /var/log/xxx.log 把错误行全部拉出来，-i 忽略大小写、-w 按单词精确匹配，避免把 errorno 这种误匹配进来；要看实时滚动就 tail -f 追着看，配合过滤是 tail -f xxx.log | grep -i error。更完整的做法是加 -C 3 上下文，报错那一行往往不带调用链，前后三行才有线索。这是我现场排障的第一动作，几乎条件反射。
• 追问2：为什么看大文件不推荐 vim？ → 答：vim 打开文件会把内容整个读进内存做编辑缓冲，一个几 G 的日志可能直接把内存吃光、会话卡死，甚至触发 OOM——在生产机器上这是二次事故。看日志要用流式工具：less 分页看、head/tail 看头尾、grep/sed/awk 过滤统计，它们逐行流式处理，多大的文件都不怕。这是新手最常见的坑，我被规范教育过之后就再没犯过，现在给新人培训也会先讲这条。
• 追问3：怎么确认端口被哪个进程占用？ → 答：第一步 ss -lntup | grep :8080，能同时拿到监听地址、进程名和 PID——重点看监听地址是不是 0.0.0.0，很多服务默认只听 127.0.0.1，本机自测正常、外面连不上，这是超高频坑；第二步要确认进程详情再 ps aux | grep <PID> 看启动命令。ss 是 netstat 的现代替代品，连接数大的机器上快很多，因为 netstat 要遍历 /proc/net 全表而 ss 直接读内核 socket 缓存。
• 追问4（深挖）：uptime 里 load average 怎么读？ → 答：三个数字是 1 分钟、5 分钟、15 分钟的平均负载，要相对 CPU 核数看：8 核机器 load 长期 6 以上就偏高，接近 8 是满载。读法上我更看重趋势——15 分钟值比 1 分钟值还高，说明负载在持续恶化，要马上处理；1 分钟高、15 分钟低，多半是瞬时抖动，先观察再动作。巡检时我会把 load 和 top 里的 us、wa 一起看：us 高是应用在算，wa 高是等磁盘，方向完全不同——这套读法是把"负载高"翻译成"接下来查哪里"的钥匙。

关联话术："银行项目里 15 多台统信 UOS、麒麟虚拟机的日常巡检就是这套命令的组合，我一天两次把 top、free、df、systemctl --failed 的快照汇总发群里；后来移动云项目我把这些巡检指标接进了 Prometheus + Grafana，从人肉定时看变成指标越线自动告警——巡检项和告警规则是一一对应的，这是我两个项目的演进关系。 "（国产 OS 差异详见华为篇 06-毕昇 JDK 与国产操作系统）

实操模板（每日巡检命令组，可直接背）：

uptime                                      # 负载与运行时长
top -bn1 | head -15                         # CPU/内存快照
free -h && df -h                            # 内存、磁盘
ss -s                                       # 连接数汇总
systemctl --failed                          # 失败服务
journalctl -p err --since "-1 day" | tail -20   # 近一天错误级日志

1.2 日志查看与定位方法 【必背】

标准回答：日志是支持工程师的第一证据源，我的方法按三个层次讲。 第一层是"去哪找"：应用日志通常在部署目录的 logs 下或 /var/log 下，找不到就 find / -name "*.log" -mtime -1 按最近修改时间搜；系统服务日志用 journalctl -u 服务名；内核和硬件问题看 dmesg -T。 第二层是"怎么找"：先看时间——用 tail -f 蹲实时，或按时间过滤 grep '2026-10-24 14:' xxx.log，把范围切到报障发生的那几分钟；再看关键字——error、exception、fail、timeout、refused，用 grep -C 3 带上下文，一行报错往往看不出因果；最后看数量——grep -c ERROR xxx.log 数次数，配合按小时统计看是突增还是缓慢累积。 第三层是"怎么读"：日志要读出三样东西——异常类别（连不上数据库还是空指针）、发生频率（偶发还是持续）、影响范围（一个用户还是全部用户），这三样直接决定问题是自己处理还是升级转派。

我在银行驻场时，接到问题第一步永远是先拿日志——日志在手，五分钟内就能给用户一句"问题在哪一层、影响多大、预计多久"，这句话本身就是支持专业度的体现。

追问链：

• 追问1：日志文件几十个 G，grep 很慢怎么办？ → 答：三个手段按序上：先用时间条件 grep -E '2026-10-24 1[4-5]:' 把范围切小，收益最大；历史日志是压缩包就直接 zcat xxx.log.gz | grep 关键字，不落地解压；实在量大就 split 分片并行处理再合并。核心思路是"先想清楚要什么，再决定扫多少数据"——任何时候都先过滤再分析，这是我在银行处理 BCS 组件巨型日志时养成的习惯。
• 追问2：用户报的问题日志里没有报错，怎么办？ → 答：这说明报障点不在应用日志覆盖的路径上，按四个方向扩：一是扩大时间窗——用户说的时间往往不准，前后拉半小时；二是换证据源——看 access 类日志有没有请求到达（请求根本没来就是网络或入口层问题，来了才报错才是应用问题）；三是降层看系统——journalctl -p err 和 dmesg 有没有 OOM、磁盘、网络报错；四是直接复现——让用户配合操作一遍，tail -f 蹲着看，眼见为实。日志沉默本身就是一条线索：请求没到和到了没反应，是两个完全不同的方向。
• 追问3：怎么按小时统计错误趋势？ → 答：一行管道：grep ERROR app.log | awk '{print substr($1,1,13)}' | sort | uniq -c——把时间字段截到小时粒度再计数，输出每小时的错误条数。这个命令是我巡检报表的常客：突增的时间点和当时的变更记录一对照，变更引起的故障一眼就能定位；缓慢增长的趋势则是磁盘或内存问题的前兆。支持工作里"给领导报趋势"比"报单次故障"更有价值，这条命令就是趋势的来源。
• 追问4（深挖）：journalctl 有哪些实用姿势？ → 答：按服务跟踪用 journalctl -u 服务 -f；看本次开机用 -b、上一次开机用 -b -1，查"重启前发生了什么"特别有用；按时间窗 --since "09:00" --until "10:00"；按级别 -p err 只看错误。还有一个运维必配的动作：/etc/systemd/journald.conf 里设 SystemMaxUse 限额，不然小磁盘的机器跑几个月会被日志吃满——监控节点自己挂了监控就瞎了，这种自伤我要在初始化基线里就防住。

关联话术："支持工作的第一动作是拿日志——银行驻场两年，'先日志、再复现、后定位层级'是我的肌肉记忆；我输出的 FAQ 文档里，每个常见问题都带一条'先看哪个日志、grep 什么关键字'，把排查方法直接交给客户自助，这也是我理解的支持降本。 "

1.3 文件权限与 Permission denied 排查 【必背】

标准回答：Linux 权限的本质是"三组对象 × 三种权限"的矩阵：属主、属组、其他人三组，读 r=4、写 w=2、执行 x=1，755 就是属主 rwx、组和其他人 r-x，目录和可执行脚本常用；644 是属主 rw、组和其他人 r，普通文件常用。 umask 决定新建文件的默认权限，文件从 666 减、目录从 777 减，root 默认 022 所以新建文件 644、目录 755。

支持场景里权限问题的标准排查是四步：第一步 ls -l 看属主属组和权限位，确认当前用户是不是属主、有没有在属组里；第二步 id 用户名 确认用户身份和所属组；第三步逐级检查路径——不只是文件本身，从根到文件的每一级目录都要有 x 权限才能穿越进去，"目录有 r 没 x"能列出文件名却打不开文件，这是经典陷阱；第四步看是不是 SELinux 或挂载选项的问题——getenforce 确认 SELinux 状态，mount | grep 目录 看是不是 ro 只读挂载。

处理原则是"最小改动"：改属主用 chown user:group file，批量加 -R 但递归操作前先在测试目录验证；临时授权优先用加组（usermod -aG）而不是放宽权限位，能不动 other 就不动。

追问链：

• 追问1：用户报"脚本跑不了 Permission denied"，你的排查顺序？ → 答：三种可能按序排除：第一种是文件没有执行位，ls -l 看到没有 x 就 chmod +x 解决；第二种是执行权限有但没有读权限，解释器读不了脚本内容，补 r；第三种是路径上某级目录不允许穿越，用 namei -l /path/to/file 一条命令列出整条路径上每级目录的权限，哪级断了当场看到。namei 是我教给客户自助排查的利器，一条命令把"逐级检查"自动化了，比口头解释"为什么你的家目录 700 别人就进不来"直观得多。
• 追问2：为什么目录需要 x 权限？ → 答：目录的 x 不是"执行"而是"进入和穿越"。没有 x 就 cd 不进去，也访问不了里面任何文件，哪怕有 r 能 ls 出文件名也不行——访问目录内的文件必须在目录里"走过去"。所以常见组合是 755 或 r-x；一个只有 r 没有 x 的目录能看见文件名却打不开文件。这个知识点我讲给客户听时用"走廊"做比喻：r 是能站在门口看名单，x 是能走进房门——比喻讲完客户秒懂，这也是支持岗要的讲法。
• 追问3：应用写日志报权限错误但目录权限看着没问题？ → 答：这时候查三个地方：一是应用进程的实际运行用户——ps aux | grep 进程名 看第一列，配置里写的用户和实际跑的用户经常不一致，systemd 服务要用 systemctl status 看 user；二是目录属主是不是这个运行用户——很多故障是 root 手工在应用目录建了新目录，属主变成 root，应用账号写不进去，ls -l 对一下就现形；三是 SELinux 的 avc 拒绝，ausearch -m avc -ts recent 能看到具体哪个进程访问哪个文件被拒。这三步下来基本必有答案，我处理过最典型的是"root 修了配置忘了 chown，重启后应用起不来"这类工单。
• 追问4（深挖）：SUID 是什么？安全上怎么用？ → 答：SUID 是让执行者临时获得文件属主身份的权限位，典型例子 passwd——普通用户能改自己密码，是因为 passwd 带 SUID、执行时临时有 root 权限写 shadow 文件。安全上它的价值是排查项：find / -perm -4000 -type f 找出全系统 SUID 文件和基线对比，多出来的就是可疑提权点。银行客户环境的安全扫描就查这项，我是被这套基线训练出来的——这也说明权限知识在支持岗不只是"会改"，更是"会查、会讲清为什么"。

关联话术："银行客户环境的安全基线把权限管得很细：应用目录 755、配置 600、密钥 640 且收紧属主，这些是扫描必查项，我按基线交付一次通过过验收；权限类问题也是我驻场时处理频率最高的工单类型之一——'改名了属主不对''root 动过配置忘了 chown'，每处理一次我就往 FAQ 里加一条，后来这类重复问题基本绝迹。 "

实操模板：

ls -l file && id appuser              # 看权限+看身份
namei -l /opt/app/bin/start.sh        # 整条路径权限一眼定位
chmod 755 deploy.sh && chmod 600 conf/xxx.yaml
chown -R app:app /opt/app/logs        # 递归改属主（先测试后执行）
getenforce; ausearch -m avc -ts recent  # SELinux 拒绝记录

1.4 进程管理与"服务起不来"排查 【必背】

标准回答：看进程用 ps aux 拿快照、top 看实时，管理进程靠信号：kill PID 默认发 15 号 SIGTERM，是"礼貌终止"，进程收到后能保存现场、释放锁再退出；kill -9 发 SIGKILL，内核直接抹掉进程，它来不及收尾，对数据库这类有事务的程序可能造成数据损坏——所以生产铁律是"先 15 后 9"，等几秒确认没退再升级。 前后台方面：Ctrl+Z 暂停、bg 放后台、nohup cmd & 让进程忽略挂断信号终端断了也活着，这是我跑部署任务的标准姿势。

支持岗真正天天面对的是"服务起不来"，我的固定排查链五步：第一步 systemctl status 服务 看状态摘要和最近几行日志；第二步 journalctl -u 服务 -e -n 50 看详细报错，八成的原因它会直说；第三步 ss -lntup | grep 端口 查端口是不是被占了；第四步把 unit 文件里 ExecStart 的命令拿出来手动执行一遍，让真实报错直接打到屏幕上——这一步往往一锤定音；第五步才查用户权限、目录权限、配置文件语法。 走完这五步，服务起不来的问题基本都能定位到层。

追问链：

• 追问1：systemd 服务起不来，status 显示 exit code 203/EXEC？ → 答：203 EXEC 表示"找到了要执行的程序但执行失败"，两个高频原因：一是 ExecStart 里的路径写错或不是绝对路径——systemd 要求必须绝对路径；二是脚本没有执行权限，chmod +x 解决。再有一种隐蔽情况是脚本本身的解释器路径不对，比如 #!/bin/bash 指向的文件不存在。我处理这类工单的口诀是"203 看路径和权限"，配合第四步手动执行 ExecStart，报错会直接指出来。
• 追问2：服务起来又马上挂了，反复重启？ → 答：先 journalctl -u 服务 --since "-10 min" 看每次挂之前的最后日志——多数是配置错误或依赖不可用（连不上数据库、配置文件字段缺失）。如果是 Restart=always 在拉起，先临时 systemctl stop 停掉循环，把问题修好再启，避免它反复崩反复写日志把磁盘刷爆。还有一个排查点：手动执行 ExecStart 正常、systemd 拉起就挂，多半是环境变量差异——cron 和 systemd 都不带用户 shell 的环境，PATH 和 JAVA_HOME 这类变量要么写进 unit 的 Environment，要么在启动脚本里显式 source。这是我处理过多次的"手动能跑、服务跑不了"经典形态。
• 追问3：kill -15 和 -9 到底怎么选？ → 答：一定先 15。15 给进程收尾机会——刷盘、释放锁、断连接，等几秒看退不退，不退再升级到 9。对数据库和有状态的 Java 服务绝不能上来就 -9，强杀是数据文件损坏和锁文件残留的最常见成因。我在银行现场把"kill -15 → sleep 5 → 校验进程退出 → 再启动"写成标准脚本放进部署指南，就是为了避免客户现场的人直接 kill -9——把操作纪律固化成脚本，比贴在墙上的规范管用。
• 追问4（深挖）：僵尸进程是什么？怎么处理？ → 答：Z 状态是子进程已经退出、但父进程没有调用 wait 回收它的退出状态，占着进程表项。大量僵尸说明父进程有回收逻辑缺陷。处理分两步：先找父进程 ps -ef | grep defunct 拿到 PPID，重启父进程是标准解法——它退出后僵尸会被 init/systemd 接管回收；重启有风险就先评估僵尸数量是否已经威胁进程表。生产上僵尸常见于长驻的 Java 应用派生外部命令的场景，我把"ps 里出现 defunct"列为巡检观察项，持续增长就推动开发修——支持岗的价值是发现趋势并递给对的人。

关联话术："银行项目里平台后端 jar 的启停被我标准化成脚本写进部署指南：启停动作、kill 信号顺序、日志校验都有固定套路；驻场期间'服务起不来'类工单我按五步链处理，平均十几分钟出结论——支持岗的效率不是手快，是排查路径固定、每步证据明确。 "

实操模板（服务起不来五步排查，背熟）：

systemctl status appsvc                    # 1 状态摘要
journalctl -u appsvc -e -n 50              # 2 详细日志
ss -lntup | grep :8080                     # 3 端口占用
# 4 取 unit 里 ExecStart 手动执行
grep ExecStart /etc/systemd/system/appsvc.service
/opt/app/bin/start.sh                      # 看真实报错
ls -l /opt/app/bin/start.sh                # 5 权限/属主/配置

1.5 磁盘空间满排障 【必背】

标准回答：磁盘满是支持场景最经典的故障，现象五花八门——服务写不了日志、数据库报错、用户上传失败——但排查路径是固定的。 第一步 df -h 定位哪个挂载点满，注意要一起看 df -i：空间满和 inode 满是两种"满"，inode 被海量小文件耗尽时 df -h 还有空间、但建文件照样报 No space left on device，这个区分是第一个分水岭。 第二步 du -x --max-depth=1 -h / 逐层下钻找大目录，-x 限制不跨文件系统避免误入挂载点；超大文件用 find / -xdev -type f -size +500M 一把捞出来。 第三步按类别清理：日志类——确认有轮转配置后清旧档或对活跃日志用 > file 截断；包缓存——yum clean all、apt clean；系统日志——journalctl --vacuum-size=200M；容器环境重点查容器 json.log。 第四步根因治理：给日志目录配 logrotate、给磁盘配 85% 告警、定期巡检——把"满"消灭在发生之前。

还有个必会陷阱：删了大文件 df 却不降——文件被进程打开着，句柄没释放，lsof | grep deleted 找到持有者，低峰期重启它空间才真正回来。 直接 rm 活跃日志是错误做法：进程还握着句柄继续往已删除的 inode 里写，等于白删还丢了查看入口。

追问链：

• 追问1：根分区满了连日志都写不了，怎么应急？ → 答：先找能立刻释放的：journalctl --vacuum-size=100M 回收系统日志、清 /tmp 临时文件、yum/apt clean 清包缓存、容器环境清 /var/lib/docker/containers 下的 json.log——这几个动作通常几分钟腾出几个 G 让系统先活过来；然后再从容 du 下钻做正式清理和扩容规划。应急原则是"先恢复写入能力，再做根因治理"——系统在满盘状态会触发更大面积的连锁故障，数据库可能崩、监控会误报一片，止血永远在前面。
• 追问2：inode 满了怎么定位和清理？ → 答：df -i 确认 IUse% 到 100% 后，用 find / -xdev -type f | awk -F/ '{print $3}' 统计顶层目录文件数逐层找小文件大户，常见元凶是缓存目录、session 文件、邮件队列、crontab 每分钟产生的碎片文件。定位后批量清理，长期方案是这类目录加自动清理任务并在巡检里加 inode 使用率检查。我处理过的真实案例是任务调度每分钟落一个小日志没做轮转，跑了一年把 25 万个 inode 吃光——现象是"磁盘没满但什么都写不了"，不熟的人会往权限方向查半天。
• 追问3：日志正在被写，怎么安全清理？ → 答：二选一：清空内容 > file——truncate 截断到 0，空间立刻释放且进程句柄不受影响；或者用 logrotate 的 copytruncate 模式轮转——先拷贝归档再原地清空，进程不感知。绝对不能直接 rm 活跃日志：rm 只删目录项，进程持有的文件描述符还在，空间不释放还继续往已删除的 inode 里写。我给客户交付的规范里明确写了"活跃日志禁止直接 rm"，这条纪律来自我真实处理过的"删了日志空间不回来"工单，全过程 lsof 一查就现形。
• 追问4（深挖）：df 和 du 统计差很多，什么原因？ → 答：两种常见原因。第一种"已删除但仍被占用"：文件被 rm 了但进程还握着句柄，df 统计内核块占用所以还大，du 按目录遍历已经看不到它，lsof | grep deleted 确认后重启对应进程释放。第二种挂载点覆盖：新磁盘挂在了非空目录上，把目录原来的内容"盖住"了——du 进不去被盖住的那部分。遇到 df/du 对不上，先往这两个方向查，基本一查一个准。这个差异问题能讲清楚，说明磁盘知识不是背的而是真排查过。

关联话术："磁盘满是我在两个项目都处理过的真实故障：银行现场清过 BCS 组件涨爆磁盘的日志，走的是'先 df 分型、du 定位、lsof 查句柄、低峰期释放'的完整链路；移动云项目我把'磁盘 85% 告警 + 日志统一 logrotate'写进运维规范——支持岗的价值不只在救火，更在把火源提前拆掉。 "

实操模板（磁盘满排查五连，背熟）：

df -h && df -i                        # 1 空间/inode 双确认
du -x --max-depth=1 -h / 2>/dev/null | sort -rh | head   # 2 逐层下钻
find / -xdev -type f -size +500M -exec ls -lh {} \; 2>/dev/null  # 3 大文件
lsof | grep deleted | sort -k7 -rn | head            # 4 删了没释放的
journalctl --vacuum-size=200M && yum clean all       # 5 应急释放

1.6 文件系统只读（Read-only file system）【必背】

标准回答：Read-only file system 是文件系统被内核挂成只读了，支持场景的典型现象是：应用写日志报错、用户保存文件失败、甚至 touch 一个文件都报 Read-only file system。 它的成因我按概率排序：第一位是磁盘 IO 错误后内核的自我保护——ext4/xfs 检测到底层数据一致性风险，自动 remount 成 ro 防止数据继续损坏，这是最常见也是最重要的原因，dmesg 里一定有对应的 I/O error 记录；第二位是超级块损坏或文件系统错误，多发生在异常断电、强制重启之后；第三位是人为或配置问题，比如 fstab 里写错挂载选项、或者云盘/存储侧把卷置成了只读。

处理链路四步：第一步 dmesg -T | grep -iE "error|ro|ext4" 找内核报错，确认是 IO 错误还是配置问题；第二步 mount | grep 挂载点 看当前挂载选项；第三步如果只是需要临时恢复写入，mount -o remount,rw /挂载点 尝试切回读写——但必须清醒：如果根因是磁盘故障，remount 成功也是暂时的，随时可能再变 ro；第四步根治——规划停机窗口做 fsck 文件系统检查，确认磁盘 SMART 状态，劣化严重就换盘迁移数据。 支持岗遇到这个问题的正确姿势是"先报风险、再动手"：ro 背后往往站着一块正在死去的磁盘，要提前跟客户讲清楚数据风险和迁移窗口，而不是只顾着把 rw 切回来交差。

追问链：

• 追问1：dmesg 里看到大量 I/O error，下一步做什么？ → 答：先看报错的设备名定位是哪块盘（sdb 还是 dm-0 对应哪个逻辑卷），然后三路并进：一是 smartctl -a /dev/sdX 看硬盘 SMART 健康状态，Reallocated_Sector 计数增长、Pending sector 非零都是劣化信号；二是看是不是虚拟化环境——银行项目里虚机的磁盘后端是 FC 存储，宿主机存储链路抖动也会在虚机内表现成 IO error，这种情况要拉宿主机和存储侧的证据一起看；三是评估影响面，把"这块盘上跑了什么、最坏情况是什么"讲给客户听，给出迁移或更换方案。ro 问题的一半工作量在沟通风险，不在敲命令。
• 追问2：remount,rw 失败了怎么办？ → 答：remount 失败说明内核对文件系统一致性已经不信任，强来的风险是数据进一步损坏。此时正确顺序是：先备份还在只读盘上能读的数据（只读状态下读是安全的，这恰是 ro 保护的馈赠）——cp 关键数据到其他盘或异机；然后规划窗口卸载该文件系统跑 fsck -y /dev/sdX 修复；fsck 修不动或修完仍然异常，就换盘重做文件系统再回灌数据。整个过程我会先在工单里写清步骤和风险再执行——生产上"先写方案再动手"是纪律，也是支持岗和专业救火队的区别。
• 追问3：怎么预防文件系统只读这类故障？ → 答：三层预防：硬件层靠监控——磁盘 SMART 和阵列卡状态纳入巡检和告警，坏盘第一时间发现，不等它拖到内核报错；系统层靠日志——dmesg 的 I/O error 关键字进告警规则，ro 发生前通常有持续的 IO 错误前兆；应用层靠隔离——数据盘和系统盘分开、日志和数据分开，单盘出问题不连坐。我在银行项目的做法是巡检清单里固定一项"dmesg 无 I/O error + 磁盘使用率低于 85%"，把这条写进客户认可的 SOP——巡检项从教训里来，SOP 让教训只发生一次。

关联话术："文件系统只读我在银行现场处理过一次：一台虚机业务盘变 ro，dmesg 里是持续的 I/O error，我按'先备数据、再规划窗口 fsck、同时向客户报风险'的顺序处理的，最后确认是后端存储链路问题联合华为侧恢复——这个案例我常拿来面试讲，因为它体现了支持岗的核心动作顺序：保数据、报风险、再修复。 "

1.7 系统变慢的初步定位 【理解】

标准回答："系统变慢"是支持工单里最模糊的报障，我的方法是用一条固定链路把模糊变精确。 第一步 top 加 uptime 看宏观：load 相对核数高不高、CPU 的 us/sy/wa/id 分布——us 高是应用在算，wa 高是 CPU 在等磁盘，方向完全不同。 第二步 free -h 看内存：只看 available 这一列，它是应用真正能用的量，buff/cache 是内核缓存需要时会自动让出，不算浪费；available 低或 si/so 有换页活动，内存就是瓶颈。 第三步 iostat -x 1 看磁盘：%util 接近 100% 是盘满负荷，await 是每次 IO 平均等待毫秒数，机械盘上几十毫秒就明显偏慢。 第四步还没定位到就 vmstat 1 看 r/b 队列和换页，或直接 pidstat 按进程下钻。 目标是用最少的命令把"慢"归到 CPU、内存、磁盘 IO、网络四类中的某一类——归了类，处理建议才能出口：CPU 高找应用、内存高找泄漏、IO 高找日志或数据库、网络慢去查链路。

追问链：

• 追问1：load 很高但 CPU idle 也很高，什么问题？ → 答：经典陷阱。load 统计的是"可运行 + 不可中断睡眠"的进程数，大量进程卡在 D 状态等 IO 时，load 被推高但 CPU 没在算所以 idle 高。这时看 iostat 的 %util 和 await、看 dmesg 有没有存储报错、确认 NFS 或云盘链路是不是断了——方向立刻从 CPU 转向磁盘和存储。我遇到过的真实场景是 NFS 断连导致一批进程集体 D 住，现象就是"负载爆表但 CPU 空闲"。
• 追问2：free 显示 free 很小，内存是不是不够了？ → 答：不是，这是 Linux 的设计而非故障——内核把空闲内存拿去做页缓存，"不用白不用"，应用要内存时自动回收。判断只看 available：available 大就有余量，哪怕 free 接近 0。人为 drop_caches 反而把热缓存打掉，下一个访问高峰 IO 猛涨。真正的内存紧张信号是 available 持续走低加 swap 换入换出（vmstat 的 si/so 非 0），以及 dmesg 里的 OOM killer 记录——dmesg | grep -i kill 一查便知。这条我要在面试里主动讲，因为它能区分"背过 free 命令"和"真的读得懂输出"。
• 追问3：CPU 400% 是故障吗？ → 答：不是报错，top 默认按单核 100% 计量，一个进程 400% 说明它多个线程合计占了约 4 个核，8 核机器上限是 800%。接着 top -Hp PID 进线程级看分布：几个线程均分是正常并发，单个线程吃满一核以上是死循环或锁自旋——Java 程序再把线程号转十六进制用 jstack 定位到代码行。我在移动云集群上跑通过一次完整链路：Grafana 告警 → top 定位 Pod 进程 → top -Hp 找线程 → jstack 看到死循环，把线程栈交给开发十分钟修复。运维没写那行代码，但问题是我精确递过去的。

关联话术："变慢类工单的价值在'归因'：银行驻场时我按这条链路出过很多次结论——'是日志暴涨把 IO 打满'、'是备份任务占带宽'，每一条都带数据；到移动云项目这套指标全部进了 Grafana 大盘，告警直接给出归因维度。 支持岗讲'系统变慢'，最忌讳说'重启一下试试'——先归因，再谈动作。"

实操模板（变慢四步链，背熟）：

uptime && top                 # 1 load与CPU分布（P排序、看us/wa）
free -h                       # 2 只看available
iostat -x 1 5                 # 3 %util/await（无则 apt install sysstat）
vmstat 1 5                    # 4 r/b队列、si/so换页
pidstat -u -r 1 5 | head -15  # 5 按进程下钻

1.8 高频报错速查（No space / Read-only / Too many open files / Permission denied）【理解】

标准回答：四类高频报错我按"报错含义 → 第一反应"组织成速查。 第一类 No space left on device：第一反应不是删文件而是 df -h 和 df -i 双查——空间满走 du 下钻清理，inode 满找小文件大户，还有隐蔽形态"删了大文件不释放"用 lsof | grep deleted 查句柄。 第二类 Read-only file system：文件系统被内核挂只读，dmesg 找 I/O error，应急 remount,rw、根治 fsck 或换盘，背后多数是磁盘劣化要先报风险。 第三类 Too many open files：句柄超限，注意三层结构——ulimit 会话级、/etc/security/limits.conf 用户级、systemd 服务的 LimitNOFILE 单元级，很多人改了 limits.conf 服务还是报错，就是因为 systemd 服务不读 limits.conf；确认是限制太小还是句柄泄漏（ls /proc/PID/fd | wc -l 持续增长），泄漏就止血重启并推动开发修。 第四类 Permission denied：按 1.3 的四步走——ls -l 看权限属主、id 看身份、namei -l 逐级查路径、getenforce 查 SELinux。

这张速查表的价值是第一反应不慌：支持岗接到报障，前五分钟内报出"这是什么类别的问题、影响面多大、大概多久",这四类报错覆盖了我现场处理的大部分系统级救火。

追问链：

• 追问1：Too many open files 改了 limits.conf 还报错？ → 答：因为 limits.conf 是通过 PAM 在"用户登录"时生效的，systemd 拉起的服务不经过登录流程、读的是 unit 文件自己的资源限制体系。解法是在 unit 的 [Service] 段写 LimitNOFILE=65535，然后 daemon-reload 加 restart。验证用 cat /proc/PID/limits 直接看进程事实——配置生效链路再长，不如看进程的最终值。这是我从"服务报错改配置无效"的坑里带出来的肌肉记忆，给 Node Exporter、业务服务写 unit 时都会预置这一行。
• 追问2：句柄数持续增长不回落，怎么判断和处理？ → 答：ls /proc/PID/fd | wc -l 定期采样看趋势，持续上涨基本是句柄泄漏：常见三类——代码没关连接或文件、连接池只借不还、TIME_WAIT 或半开连接堆积。应急是低峰重启进程止血（重启前留一份 fd 列表和 lsof 输出给开发做证据），根治要开发修资源释放逻辑；运维侧把 keepalive、超时参数配好减少无效句柄存活时间，并给句柄数配 80% 预警。处理这类问题我的产出物是"趋势截图 + 归因分析 + 建议"三件套交给开发——支持岗的闭环是把问题递到能修的人手上，而不是替人修代码。

关联话术："报错速查表是我 IT 知识库里点击率最高的一篇——公司同事遇到服务异常，先按表对号入座再找我，很多问题他们自己就处理了；这就是我理解的 SOP 的价值：把个人经验变成团队的自助能力，重复问题不再重复消耗人力。 "

1.9 服务器日常巡检 SOP 与国产化环境要点 【理解】

标准回答：我的巡检 SOP 是"六查一记录"：一查负载——uptime 和 top，load 相对核数无持续超 0.7 倍；二查内存——free 的 available 不低于 20%；三查磁盘——df -h 和 df -i 都低于 85%；四查服务——systemctl --failed 为空，关键服务进程在、端口在监听；五查日志——journalctl -p err 近一天无新增错误，应用日志无 error 突增；六查系统——dmesg 无 I/O error 和 OOM 记录、时间同步正常。 一记录是把六项结果按模板落档，异常项标红并跟进——巡检的价值不在"看"，在"留痕和对比"，趋势里才能提前看见问题。

国产化环境（统信 UOS、麒麟 V10）的操作和主流发行版 95% 一致，差异集中在三处：包管理——麒麟基于 openEuler/CentOS 系用 yum，统信 Server 基于 Debian 系用 apt；软件源要用厂商内网源；ARM 架构下所有软件包和镜像必须 aarch64 匹配，混用报 exec format error。 这些差异点我在银行项目 15 台国产虚机上用了近两年，都踩平了（产品层细节详见华为篇 01/06 章）。

追问链：

• 追问1：巡检发现异常，你的处理流程是什么？ → 答：按影响分三级：一级影响业务（服务挂、磁盘将满）——立即处理并通报，处理不了的十分钟内升级转派；二级有风险暂不影响（错误日志增多、使用率爬升）——记录工单、给出观察指标和复检时间；三级常态优化——进待办列表随变更窗口处理。每一级都回到工单系统记录，从发现到结论全程留痕。这个分级是我在银行驻场时和客户约定的口径，它让巡检从"每天抄表"变成"有优先级的排雷"，客户对巡检报告的信任度明显提升。
• 追问2：统信 UOS 和麒麟装软件有什么讲究？ → 答：优先级三步：第一优先厂商适配包（rpm 或 deb，从内网源拿），第二选同架构静态二进制包（解压即用），最后才源码编译且要先确认 ARM 依赖库齐全。最忌讳把 x86 包直接拷过去用。另外两家差异要记牢：麒麟 yum、统信 apt，写巡检脚本要兼容两套包管理——我的巡检脚本里 yum/apt 是判断分支的。这些是我在银行内网环境验证过近两年的实操经验，说出来比背参数有分量。
• 追问3（兜底示范）：被问更深的安全加固或内核调优怎么做？ → 答："银行客户环境的安全基线（SSH 加固、密码策略、防火墙白名单）我按客户要求执行过并配合过扫描验收，基线项我能逐条讲；更深的内核调优这块，我按组件需求配过必需参数（文件句柄、somaxconn 这类），原理层面理解到参数和现象的对应关系，系统的调优方法论我理解是'先测量再调参'，入职后我会按贵司的基线体系系统补齐。"——诚实边界加已有面，比硬吹安全。

关联话术："巡检 SOP 是我从'每天两次人工巡检'演化来的：银行时期是命令组加表格，移动云时期是 Prometheus 告警加大盘——但'六查一记录'的清单内核没变，变的只是执行方式。 面试聊巡检，我讲得出每一项为什么查、异常了往哪查，这是近两年驻场养成的手感。"

1.10 时间同步漂移：小偏差大故障（支持高频）【理解】

标准回答：时间同步是支持场景里最典型的"小问题引起大故障"，我按"现象 → 机制 → 排查 → 预防"讲。 现象层面：服务器时间漂移几分钟到几小时，会引发一批看似不相关的问题——TLS/证书校验失败（证书有效期对时间敏感，偏差大直接握手失败）、K8s 节点间认证失败、日志时间线错乱导致跨机排查对不上、定时任务重复执行或漏执行、数据库主从复制异常。 机制层面：Linux 用 chrony 或 ntpd 与 NTP 服务器保持同步，chrony 是当前主流——配置文件指定服务器源，chronyc sources 看同步源状态、chronyc tracking 看当前偏差，systemd-timesyncd 是轻量替代。 排查路径四步：timedatectl status 看时间是否同步、时区对不对 → chronyc sources -v 看有没有可用源（星号标记的是选中源）→ 源不可达查网络（UDP 123 端口、防火墙）→ 偏差过大先 chronyc makestep 强制校准再查根因。 预防动作是把时间同步检查做进初始化基线和巡检——移动云项目 9 项避坑里"节点时间不同步导致认证失败"就是真实踩过的一条，之后全节点 chrony 指向内网 NTP 成为标准配置。

追问链：

• 追问1：时间同步检查应该怎么进巡检？ → 答：两个固定项：一是状态检查——timedatectl status 里 NTP service 为 active、chronyc tracking 的系统时间偏差在毫秒级，超过阈值（比如 1 秒）就告警处理；二是配置检查——chrony 配置的源是不是规划的内网 NTP 服务器，防止某台机器配置漂移后用了不可靠的外部源。我在移动云项目的做法是把这两项写进初始化脚本的验收输出，部署完当场截图留档——时间问题一旦在运行期暴露，排查成本远高于部署期的一次检查，这是典型的"一分钟预防换一天排查"。

关联话术："时间同步是我两个项目都真实处理过的点：银行 ARM 环境装完系统先对时再装组件，避免证书和认证的诡异失败；移动云项目把'时间同步检查'固化进 9 项避坑清单和初始化基线——这类问题单看现象像玄学，抓住'时间'这个变量后原因一目了然，我给客户讲这个案例时也常把它当排障思维的教材：先找'什么变了'，再找'哪里坏了'。 "

1.11 本章案例

• 【真实项目·支持场景】银行现场磁盘满工单（STAR，约 200 字）：背景是数字人民币试点运行期间，客户值班同事报告平台部分功能报错、后端日志停止更新。任务是我作为驻场一线定位并恢复。行动：先 df -h 确认数据分区 100%，df -i 排除 inode 问题；du -x --max-depth=1 下钻定位到 BCS 组件日志目录，一个组件异常重复打印堆栈两天涨了几十 G；因日志正被进程占用，按规范对最老的归档先删、活跃日志用 > file 截断，五分钟恢复写入，业务报错消失；随后给该组件配置 logrotate 并把"磁盘 85% 告警"加进监控，异常堆栈反馈华为二线修复。结果：当天闭环，此后该项目再未发生磁盘满，巡检项沉淀进 SOP——一次工单同时交付了"恢复 + 根治 + 规范"三层价值。
• 【真实项目】删日志空间不释放（经典复盘）：清理大日志后 df 不降，lsof | grep deleted 发现日志进程仍持有已删除文件的句柄，inode 未释放；低峰期重启服务后空间回归。预防动作是把"活跃日志禁止直接 rm、统一 copytruncate 轮转"写进交付规范——这条后来成为我培训客户运维的固定一课。
• 【课程项目】服务启停与排障实验：课程环境人为制造服务起不来的四种形态（端口占用、权限缺失、配置错误、依赖服务未启动），按 1.4 五步链逐一走通，把每步的屏幕输出亲眼过一遍。每个形态都对应一份证据：端口占用看 ss 的输出、权限缺失看 ls -l 与 namei 逐级检查、配置错误看 journalctl 的报错行、依赖未启动先验证依赖服务端口——四种形态四种证据，这套"现象→证据"的对应关系我在真实工单里反复用到。实验的价值是面试描述时每一步都有画面感，可信度完全不同。
• 【经典故障】"负载爆表但 CPU 空闲"：现象是 load 飙高、idle 也高，大量进程 D 状态。定位：ps aux 看到 D 进程聚集、iostat 无明显 IO 但 dmesg 有存储链路报错——根因是后端存储瞬断，进程卡在不可中断 IO 上。恢复链路后 D 进程自然退出。教学点：load 高不等于 CPU 忙，D 状态是"等 IO"的信号灯，方向要转向存储和链路。

章末自测清单（快问快答）

1. 巡检三件套？ → top（CPU/内存）、free -h（available）、df -h（磁盘），加 systemctl --failed。
2. 看日志最后 50 行并过滤 error？ → tail -n 50 f.log；grep -iw error f.log；实时 tail -f f.log | grep -i error。
3. 大文件为什么不用 vim？ → 全量读内存会卡死/OOM；用 less/tail/grep 流式工具。
4. 目录 x 权限的作用？ → 进入和穿越；只有 r 没有 x 能列名不能打开文件。
5. Permission denied 四步？ → ls -l 权限属主 → id 身份 → namei -l 逐级路径 → getenforce 查 SELinux。
6. kill -15 和 -9 怎么选？ → 先 15 给收尾机会，几秒不退再 9；数据库禁止直接 -9。
7. 服务起不来五步？ → status → journalctl -u -e → ss 查端口 → 手动执行 ExecStart → 查权限配置。
8. 磁盘满第一反应？ → df -h 和 df -i 双查，区分空间满与 inode 满，再 du 下钻。
9. 删了大文件 df 不降？ → 进程句柄未释放：lsof | grep deleted，低峰重启释放。
10. 活跃日志能直接 rm 吗？ → 不能，rm 不释放空间；用 > file 截断或 logrotate copytruncate。
11. Read-only file system 成因第一位？ → 磁盘 IO 错误内核自动保护；dmesg 找 I/O error，先备数据再 fsck。
12. free 里看哪列判断内存够？ → available；buff/cache 是可回收缓存不算占用。
13. load 高 idle 也高说明什么？ → 大量进程 D 状态等 IO，查 iostat 与 dmesg 存储链路。
14. Too many open files 的三层配置？ → ulimit 会话级、limits.conf 用户级、systemd unit 的 LimitNOFILE。
15. CPU 400% 怎么读？ → 多线程合计占 4 核，非报错；top -Hp 看线程分布再定位。
16. 麒麟和统信分别什么包管理？ → 麒麟 yum（openEuler 系）、统信 apt（Debian 系）；ARM 一切包与镜像要 aarch64。
17. 巡检"六查"是哪六查？ → 负载、内存、磁盘、服务、日志、系统（dmesg/时间同步），结果必须留痕。