【Linux】杂项经验与问题整理

一、故障处理顺序：证据 → 限域 → 临时恢复 → 根本原因分析

要我用一句话概括就是：先收证据，再缩小范围，优先让服务恢复，最后再做彻底修复。这些年月里，这个顺序救过我无数次。

举个现实场景：某个服务报 500。我的动作不会是直接重启，而是按顺序做三件事：

先把"现在"的状态抓下来（供事后复盘）：

bash 复制代码

uptime; date
journalctl -u myservice -n 200 > /tmp/myservice.log
ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head -n 30 > /tmp/top.txt
df -hT > /tmp/df.txt
dmesg | tail -n 50 > /tmp/dmesg.txt

根据日志与资源情况快速限域，快速判断是单实例问题、还是整个主机问题？如果是实例级别，优先做"快速恢复"：

bash 复制代码

systemctl restart myservice
journalctl -u myservice -n 200 -f

如果重启后短时间内问题消失，我将把这次操作标记为"临时恢复"，并进入根本原因分析；如果重启无效，则继续扩大排查范围（网络、存储、依赖服务）。

根本原因分析阶段我会对比恢复前后的证据、回溯最近变更（部署、配置、系统补丁）并在低峰做修复或回滚。

这套流程的核心好处是：不做无准备的破坏性操作。很多人习惯"先改再想"，我尽量反其道而行之。

二、变更管理的最小准则（避免背锅）

变更一旦上线就是风险。我把变更管控简化为三条硬规则：

小步快跑：一次只改一件事（配置、版本或参数），并记录改动点和回滚命令。
先在一个镜像环境验证（最好是与生产尽量相似的快照），再上正式环境。
所有变更必须有"回滚预案"，并在变更窗口内可在 15 分钟内执行回退（包括恢复数据/重启服务/替换节点）。

我把这三条套成一个模板写进变更清单里，实际执行时每次都要有 "谁操作、何时操作、如何回滚" 三要素，否则不上线变更。

三、备份与恢复

备份不只是同步文件，关键是能恢复。我的做法很具体：

对文件型数据我用 rsync 做增量镜像，主要做两种备份：本地快照（最近 7 天）和异地备份（每晚一版）。典型命令：

bash 复制代码

rsync -aHAX --delete --info=progress2 /data/ /backup/host1/data/

对数据库（MySQL）按业务需求做物理或逻辑备份。对可接受停机的场景我会做冷备份；对不能停机的场景则用 binlog / wal 流式备份配合基于时间点恢复（PITR）。
定期演练恢复：每两月一次在测试环境跑一次完整恢复（从备份中恢复服务并验证业务链路）。

四、关注会动的指标

监控体系不要追求面面俱到，否则噪声太多。我的经验是抓三类指标：**主机资源（CPU/MEM/Disk I/O）、应用可用性（响应时间、错误率）、关键依赖（数据库连接数、队列长度）。**告警要和运维流程绑定：当告警触发，必须有明确的"谁去做什么"的行动指示。

我用的简单组合是：

主机层面 node_exporter → prometheus → alertmanager；应用层面自写脚本做健康检查。

五、用"时间窗口"缩小范围

故障日志常常巨大，我的方法是直接把时间窗收窄到"告警前后 5 分钟"。很多问题的根信息就在那几行里。实践中我常用这些命令：

bash 复制代码

# 定位时间窗口
journalctl -u myservice --since "2026-02-01 10:12:00" --until "2026-02-01 10:18:00"
# 或实时跟踪并筛错误
journalctl -u myservice -f |& grep -iE "error|failed|trace"

如果单个服务日志不足以判断，我会同时抓取系统级日志（dmesg）与网络抓包（tcpdump）交叉比对，找到是"应用错"还是"系统层面的问题"。

六、性能问题的排查思路

像我这种微型企业，遇到性能问题无非就是以下三条原因：CPU 瓶颈、I/O 瓶颈、资源争用（锁/线程）。我的排查思路很简单：确认瓶颈在哪儿，再定位到进程或 SQL。

像某次出现服务延迟暴增的情况，我会先看 I/O，而不是先扩容：

bash 复制代码

iostat -xz 1 5
iotop -oPa

发现是某个日志轮转脚本在大量 fsync，我把日志分割策略改为异步并加了日志速率限制，延迟即回落。扩容是最后手段，先做"找原因、改策略"。

七、做好风险把控

安全不是一次就能做好的，我一般会把安全变成常规操作来做：

最小权限：服务运行用普通用户（非 root），仅开放必要端口。
SSH：禁用密码登录、只允许密钥、限制来源 IP。
更新策略：非关键组件延后更新，关键安全补丁优先且先在测试环境验证。
备份密钥与证书集中管理（不要把私钥散落在多台机器的家目录里）。

八、自动化与可复现

任何重复做三次以上的任务，我都会写成脚本：环境准备、软件安装、配置部署、证书续期。这样既降低人为错误，也方便后人接手。自动化不只是提高效率，更是可追溯的变更记录。

示例我常用的一个小脚本结构（伪码）：

shell 复制代码

#!/bin/bash
# deploy.sh
git pull origin main
ansible-playbook -i hosts playbook.yml --limit prod --tags deploy
systemctl restart myservice

在生产环境里，我把这些脚本放入 CI 管道，并把执行记录留档。

九、"烂摊子"的处理方式（三例）

磁盘快满，服务抛错：先把日志归档压缩，临时把大文件迁移到备用盘，再规划长期扩容或清理策略。切记不要盲删系统文件。
数据库性能下降：先停止写入，做一次慢查询分析（EXPLAIN/慢查询日志），必要时把热点索引重建或调整查询。扩容读节点或分片是后方案。
服务因依赖升级失败：回滚到上一个可用版本，记录依赖图谱，逐一升级验证。
这些场景里我优先恢复业务可用性，再做技术债清理。