服务运维 on Zero Day Notes

一次Cron任务因系统时区变更导致凌晨备份任务在业务高峰期执行拖垮MySQL的排查实录

Sun, 05 Jul 2026 07:00:00 +0000

问题背景

公司核心业务系统使用 MySQL 8.0 作为主数据库，单实例部署在 CentOS 7 物理服务器上，数据量约 200GB。为保障数据安全，配置了每天凌晨 02:00 通过 Cron 执行 mysqldump 全量逻辑备份，备份文件写入本地磁盘后再由异地同步脚本上传至对象存储。

这套备份策略稳定运行了一年多，从未出过问题。直到某个周四下午 15:30，运维群突然炸锅——业务方反馈系统响应极慢，订单提交超时，部分页面直接报 502。

故障现象

收到告警后第一时间登录服务器，现象非常直观：

MySQL 进程 CPU 占用 680%（16 核服务器，几乎吃满），磁盘 IO util 100%
SHOW PROCESSLIST 显示大量业务查询处于 Sending data 状态，堆积超过 200 个连接
慢查询日志疯狂刷屏，平时 50ms 以内的查询现在动辄 30s+
最诡异的是：mysqldump 进程正在运行，且已经跑了将近 40 分钟

$ top -p $(pgrep -d',' mysqld)
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 9842 mysql     20   0   58.2g  42.1g  11456 S 678.2 66.1   1423:45 mysqld

$ iostat -x 1
Device   r/s     w/s     rkB/s   wkB/s   await  svctm  %util
sda      1423.0  892.0   185632  92340   45.2   0.44   100.0

问题很明显——mysqldump 全量备份在业务高峰期跑了，把 IO 全部吃光，导致正常业务查询排队阻塞。

排查过程

第一反应：是不是有人手动触发了备份？

检查 mysqldump 进程的父进程：

$ ps -ef | grep mysqldump
mysql     9845  1234  3 14:48 ?        00:42:10 mysqldump --defaults-extra-file=/etc/mysql/backup.cnf ...

$ ps -ef | grep 1234
root      1234     1  0 14:48 ?        00:00:00 /usr/sbin/CRON

父进程是 CRON，说明不是人为手动执行，确实是 Cron 触发的。

第二反应：检查 Crontab 配置

1
2

$ crontab -l -u root
0 2 * * * /usr/local/bin/mysql_backup.sh >> /var/log/mysql_backup.log 2>&1

Crontab 配置写的是 0 2 * * *，即每天凌晨 02:00 执行。但现在是下午 14:48 启动的，完全对不上。

关键发现：系统时间和硬件时钟不一致

$ date
Thu Jul  3 15:15:32 CST 2026

$ hwclock --show
2026-07-03 07:15:38.123456+08:00

$ timedatectl
               Local time: Thu 2026-07-03 15:15:40 CST
           Universal time: Thu 2026-07-03 07:15:40 UTC
                 RTC time: Thu 2026-07-03 07:15:40
                Time zone: Asia/Shanghai (CST, +0800)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

timedatectl 输出看似正常——时区是 Asia/Shanghai，NTP 也同步着。但是「硬件时钟」和「系统时间」差了整整 8 小时：硬件时钟显示的是 UTC 时间 07:15，而系统时间显示 CST 15:15。

此时一个细节引起我的注意——RTC in local TZ: no 表示硬件时钟存储的是 UTC 时间，这本该是对的。但「系统时间」为什么不是从 RTC 加 8 小时偏移算出来的？

进一步分析：Cron 实际执行时间

1
2

$ grep CRON /var/log/cron | grep mysql_backup
Jul  3 14:48:01 server01 CROND[1234]: (root) CMD (/usr/local/bin/mysql_backup.sh)

Cron 日志明确记录：备份脚本是 14:48 启动的，不是 02:00。

等等——如果系统时区是 Asia/Shanghai (UTC+8)，那 Cron 的 0 2 * * * 应该在北京时间凌晨 2 点执行。但为什么实际在 14:48 执行？14:48 如果换算成 UTC 就是 06:48，也不是凌晨 2 点。

这说明 Cron 守护进程使用的时区和系统时区不一致。

验证 Cron 守护进程的时区

1
2

$ cat /proc/$(pgrep cron)/environ | tr '\0' '\n' | grep TZ
(空)

Cron 进程的环境变量中没有设置 TZ，那它应该继承系统时区。

但这是关键线索：Cron 守护进程启动时读取一次系统时区，之后即使系统时区被修改，Cron 不会动态更新。它一直在用启动时的时区运行。

$ systemctl status crond
● crond.service - Command Scheduler
   Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled)
   Active: active (running) since Tue 2026-07-01 22:15:30 CST; 1 day 17h ago

Cron 上次启动是 7 月 1 日 22:15，已经连续运行了将近 2 天。如果在这期间有人修改了系统时区，Cron 是不会感知到的。

追查时区变更记录

1
2
3

$ grep -i timezone /var/log/messages
$ grep -i "time zone" /var/log/secure
$ journalctl --since "2026-07-01" | grep -i "timezone\|timedatectl\|tz"

没有直接日志。继续追查：

1
2

$ last | grep reboot
reboot   system boot  3.10.0-1160.el7. Tue Jul  1 22:13 - 15:22 (17:09)

7 月 1 日服务器重启过。再查 /etc/localtime 文件：

1
2

$ ls -la /etc/localtime
lrwxrwxrwx 1 root root 35 Jul  1 22:14 /etc/localtime -> ../usr/share/zoneinfo/Asia/Shanghai

看起来是对的。但 timedatectl 的输出中 RTC in local TZ: no 和实际系统时间不一致，说明硬件时钟（RTC）和系统时间的对应关系出了问题。

继续查：

$ cat /etc/adjtime
0.0 0 0.0
0
UTC

/etc/adjtime 第三行是 UTC，这是正确的——表示硬件时钟存储 UTC 时间。

找到真凶——CMDB Agent 脚本

就在我一筹莫展的时候，注意到服务器的 CMDB Agent 配置管理脚本在今天下午执行了一次「标准化」操作：

$ journalctl -u cmdb-agent --since "2026-07-03" | grep -i "time\|tz\|clock\|hwclock"
Jul 03 13:22:01 server01 cmdb-agent[8841]: Running compliance check: ntp_sync
Jul 03 13:22:05 server01 cmdb-agent[8841]: NTP offset 0.023s, within threshold
Jul 03 13:22:05 server01 cmdb-agent[8841]: Applying standard timezone config
Jul 03 13:22:06 server01 cmdb-agent[8841]: Executing: /usr/sbin/tzdata-update
Jul 03 13:22:07 server01 cmdb-agent[8841]: Running: hwclock --systohc

在 CMDB Agent 执行标准化时，调用了 hwclock --systohc，将「系统时间」写入硬件时钟。关键在于：

在调用 hwclock --systohc 之前，系统时间已经是错误的。

回看 CMDB Agent 执行的时间线：13:22 执行了 hwclock --systohc。此时系统时间显示 13:22 CST（东八区下午），但它可能只算了 5 个小时的偏移（即 UTC+5），而非正确的 UTC+8。

为什么会这样？再看 CMDB Agent 标准化脚本的内容：

$ cat /opt/cmdb/scripts/ntp_check.sh
#!/bin/bash
# 标准化时区配置
timedatectl set-timezone Asia/Shanghai
# 同步硬件时钟
hwclock --systohc

脚本逻辑本身没问题。但问题出在：在 timedatectl set-timezone 执行的前后，如果 NTP 同步尚未完成或系统时钟已经偏移，hwclock --systohc 就会把错误的系统时间固化到 RTC。

但更微妙的是：CMDB Agent 这次运行是在 13:22，而备份是在 14:48。让我再看时间线：

1
2

13:22 - CMDB Agent 执行标准化，设置时区，同步硬件时钟
14:48 - Cron 触发备份 ← 这正是 "凌晨 02:00 UTC"！

关键推理：

CMDB Agent 在执行过程中可能会短暂地改变系统的时区环境。虽然最终 timedatectl 显示 Asia/Shanghai 是对的，但在 CMDB 脚本执行期间，可能触发了以下连锁反应：

timedatectl set-timezone 执行时触发了某些依赖时区的守护进程重新读取配置
但 crond 不会自动重载时区——它只在启动时读取一次
Crond 启动时（7 月 1 日 22:15），系统的时区可能因为某种原因被识别为 UTC
因此 Cron 的 0 2 * * * 实际上按 UTC 时间 02:00 执行，即北京时间 10:00

等等，让我重新计算。如果 Cron 内部用的是 UTC 时区，那 0 2 * * * 就是在 UTC 02:00 执行，对应北京时间 10:00。但备份实际在 14:48 执行，不是 10:00。这也不对。

重新审视：Cron 到底用的什么时区？

1
2

$ systemctl cat crond | grep -i environment
EnvironmentFile=/etc/sysconfig/crond  # 不存在

Cron 没有自定义的环境文件。默认情况下，Cron 继承 systemd 启动时的环境。

$ timedatectl show
Timezone=Asia/Shanghai
LocalRTC=no
CanNTP=yes
NTP=yes
NTPSynchronized=yes
TimeUSec=Thu 2026-07-03 15:15:40 CST

当前 timedatectl 一切正常。问题肯定出在 Cron 启动时和当前之间发生了变化。

回到 /etc/localtime：

1
2
3

$ md5sum /etc/localtime
$ md5sum /usr/share/zoneinfo/Asia/Shanghai
$ md5sum /usr/share/zoneinfo/UTC

让我对比一下：

$ md5sum /etc/localtime
c4e8e8b2e9e2e9e8b2c4e8e8b2e9e2  /etc/localtime

$ md5sum /usr/share/zoneinfo/Asia/Shanghai  
c4e8e8b2e9e2e9e8b2c4e8e8b2e9e2  /usr/share/zoneinfo/Asia/Shanghai

这两个文件相同，说明 /etc/localtime 确实是 Asia/Shanghai。

回到核心问题

让我重新梳理时间线，用 date 命令直接测试：

Cron 在 7 月 1 日 22:15:30 CST 启动。如果此时 /etc/localtime 是指向 Asia/Shanghai 的，那 Cron 的 0 2 * * * 就应该在北京时间凌晨 2 点执行，即 UTC 前一天 18:00。

但实际它在 14:48 CST 执行了。14:48 - 8 = 06:48 UTC，也不是凌晨 2 点。

除非 Cron 用的是其他时区。

让我用一个更直接的方法来判断：

备份在 14:48 CST 执行。如果 Cron 认为此时是凌晨 2:00，那 Cron 内部的时区比 CST 晚 12 小时 48 分钟… 不合理。

换个思路：备份在 14:48 执行。如果用 UTC+0 来解释，14:48 UTC = 22:48 CST。也不是凌晨 2 点。

重新计算：如果备份在 14:48 CST 执行，且 Cron 配置是 0 2 * * *，那么 Cron 认为 14:48 CST = 02:00，也就是说 Cron 内部时区 = CST - 12.8 小时 ≈ UTC-4.8，这不可能是一个标准时区。

我意识到我的分析方向可能错了。让我检查实际执行备份的 Cron 进程到底读的是什么 crontab。

1
2

$ crontab -l -u root
0 2 * * * /usr/local/bin/mysql_backup.sh >> /var/log/mysql_backup.log 2>&1

等等，我需要检查 /etc/crontab 和 /etc/cron.d/：

$ cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

# For details see man 4 crontabs
  0  2  *  *  * root /usr/local/bin/mysql_backup.sh >> /var/log/mysql_backup.log 2>&1

找到了！ /etc/crontab 里也有一条完全相同的备份任务！而 /etc/crontab 的格式中包含用户名字段（第 6 个字段是 root）。

这意味着同一条备份任务被配置了两遍：一次在 root 用户的 crontab，一次在 /etc/crontab。

但这仍然不能解释为什么在 14:48 执行，而不是 02:00。

最终突破：检查时区变更的精确时间点

$ journalctl -u crond --since "2026-07-01" --until "2026-07-03" --no-pager | head -30
-- Logs begin at Tue 2026-07-01 22:14:01 CST --
Jul 01 22:14:05 server01 systemd[1]: Started Command Scheduler.
Jul 01 22:14:05 server01 crond[982]: (CRON) STARTUP (V5.0)
Jul 01 22:14:05 server01 crond[982]: (CRON) INFO (running with inotify support)

等等，这是 CST 时间。Cron 在 22:14:05 CST 启动。

如果 Cron 使用的时区是 CST（UTC+8），那 0 2 * * * 就应该在每天 CST 02:00 执行。但从 7 月 1 日 22:14 到 7 月 3 日 14:48，中间的 7 月 2 日和 7 月 3 日都有凌晨 2:00。

检查 7 月 2 日凌晨的执行记录：

$ grep "Jul  2" /var/log/cron | grep mysql_backup
（没有记录）
$ grep "Jul  3" /var/log/cron | grep mysql_backup  
Jul  3 14:48:01 server01 CROND[1234]: (root) CMD (/usr/local/bin/mysql_backup.sh)

7 月 2 日没有备份执行记录！这非常奇怪。如果 Cron 正常运行，至少 7 月 2 日凌晨 2:00 应该有一次执行。

检查 Cron 是否在 7 月 2 日凌晨正常运行：

1
2

$ grep "Jul  2 02:00" /var/log/cron
（有其他 Cron 任务，但没有 mysql_backup）

这说明 7 月 2 日凌晨 Cron 确实在运行，但备份任务没有触发。为什么？

再仔细看 /etc/crontab：

1
2
3

$ cat -A /etc/crontab
...
  0  2  *  *  * root /usr/local/bin/mysql_backup.sh >> /var/log/mysql_backup.log 2>&1$

注意到格式问题：/etc/crontab 的时间字段是 6 列的（包括星期），但这里的 0 2 * * * 只有 5 列。在 /etc/crontab（系统级 crontab）中，格式应该是 7 个字段：分时日月星期用户命令。而这里的 0 2 * * * 是 5 列 + root + 命令。

等等，让我重新数：0 2 * * * root /usr/local/bin/mysql_backup.sh...

字段1: 0 (分)
字段2: 2 (时)
字段3: * (日)
字段4: * (月)
字段5: * (星期)
字段6: root
字段7: /usr/local/bin/mysql_backup.sh…

这是正确的 7 列格式。

那为什么 7 月 2 日凌晨没有执行？让我检查系统 crond 是否支持 /etc/crontab：

`1`	`$ systemctl status crond \| grep -i "crontab\\|cron.d"`

实际上，对于这个问题，让我换个思路。让我直接看 /var/log/cron 里 7 月 2 日是否真的没有备份记录。可能日志被轮转了。

我回到排查的主线——当前最关键的问题是：为什么备份在 14:48 而不是 02:00 执行。

真相浮现

我决定用一个简单的方法来验证 Cron 感知的时间：

`1`	`$ echo "* * * * * root date >> /tmp/cron_test.log 2>&1" > /etc/cron.d/test-time`

等了一分钟后：

1
2

$ cat /tmp/cron_test.log
Thu Jul  3 07:19:01 UTC 2026

破案了！ Cron 输出的时间是 UTC！

Cron 运行在 UTC 时区下。所以 0 2 * * * = UTC 02:00 = CST 10:00。

但备份实际在 14:48 CST 执行，按照这个逻辑应该是 UTC 06:48，不是 02:00。

不对，让我再检查一下。可能 Cron 实际使用的时区不是 UTC 也不是 CST。

1
2

$ strings /proc/$(pgrep cron)/environ | grep -i tz
$ cat /proc/$(pgrep cron)/environ | tr '\0' '\n' | grep -i tz

两者都为空——Cron 没有自定义 TZ 环境变量。

让我检查 /etc/localtime 指向的实际文件和 Cron 编译时默认时区的关系：

在 CentOS 7 上，Cron（vixie-cron/cronie）在启动时调用 localtime() 函数来确定时区。如果在启动后 /etc/localtime 被替换，Cron 不会动态感知。

最终假设：服务器在 7 月 1 日重启后，/etc/localtime 曾经在某个时间点被短暂地指向了错误的时区文件，Cron 在这个窗口期启动，然后 /etc/localtime 又被改回了 Asia/Shanghai。最终 Cron 使用的是错误的时区。

验证这个假设——看一下备份从 14:48 开始执行，如果是按某个时区的 02:00 触发，反推：

如果 Cron 内部时区 = X，那么 14:48 CST = 02:00 X → X = CST + 12h48m → X = 02:48 次日（UTC+20:48）——不合理。

换个方向：可能是另一个 crontab 条目在触发。

让我检查所有 cron 配置：

1
2
3

$ grep -r "mysql_backup" /etc/cron* /var/spool/cron/
/etc/crontab:  0  2  *  *  * root /usr/local/bin/mysql_backup.sh >> /var/log/mysql_backup.log 2>&1
/var/spool/cron/root:0 2 * * * /usr/local/bin/mysql_backup.sh >> /var/log/mysql_backup.log 2>&1

两条配置，一天执行两次。但 /etc/crontab 的语法里，0 2 * * * root 这样写其实还有一个坑：如果某个 crond 版本在 /etc/crontab 中按用户 crontab 格式（5 列）解析，root 这个字符串可能被当作第 6 个时间字段（命令）处理，导致永远不匹配。

等等，这就是问题所在吗？ /etc/crontab 有 7 列（含用户名），但如果有某个 bug 或配置导致它按 5 列解析，root 会被误读为时间字段的一部分… 这不太可能。

真正的根因

重新审视所有证据。让我把 crontab 行再仔细看：

`1`	`0 2 * * * /usr/local/bin/mysql_backup.sh`

等等，我又发现一个问题——root 用户的 crontab 中是 0 2 * * *（5 列），/etc/crontab 中是 0 2 * * * root（6 列，root 是用户名）。

实际上让我看看 /var/spool/cron/root 的具体内容，看有没有被额外篡改：

经过反复排查和测试，最终发现的根因如下：

服务器在 7 月 1 日因内核安全补丁重启。重启过程中，systemd 先启动了 crond，随后 NTP 服务完成时间同步。Crond 在启动瞬间读取到的系统时间是一个未与 NTP 同步的、偏移了几个小时的错误时间，导致 Crond 内部的时间基准出现了固定偏差。

验证方法：重启 crond 服务后，再执行之前的测试：

1
2

$ systemctl restart crond
$ echo "* * * * * root date >> /tmp/cron_test2.log 2>&1" > /etc/cron.d/test-time2

等待一分钟后：

1
2

$ cat /tmp/cron_test2.log
Thu Jul  3 15:25:01 CST 2026

重启后 Cron 恢复正常！输出的是 CST 时间。

根因分析

问题出在一个很少有人注意的细节——crond 启动时的时间快照。

Vixie-cron / cronie 在启动时会对系统时间拍一张快照，用于计算任务的「下次执行时间」。正常情况下，crond 会在系统时间变化时（通过 inotify 监控 /etc/localtime 或收到 SIGALRM）重新校正时间。但在 CentOS 7 的特定版本 cronie 中，存在一个边界情况：

系统启动时，crond 在 NTP 同步完成前就已经启动
此时系统时间可能距离正确时间有几个小时的偏差
crond 基于错误的时间计算了「下一次执行时间」
当 NTP 后来将系统时间调准时，crond 的 inotify 只监听了 /etc/localtime 的变更，但 NTP 调时不会触发该文件的变更事件
结果：crond 的计算基准与实际系统时间之间有一个固定偏移

表现为：虽然 crontab 写的是 0 2 * * *（凌晨 2 点），但 crond 实际在他认为的「凌晨 2 点」执行任务。由于 crond 的时钟基准与系统时间存在偏移，导致备份被推迟到了下午 14:48。

解决方案

紧急处理

# 立即杀掉正在运行的备份进程
kill -9 9845

# 重启 crond 服务，让它重新读取系统时间
systemctl restart crond

# 检查 MySQL 是否恢复正常
mysql -e "SHOW PROCESSLIST;"

重启 crond 后，备份调度恢复正常，MySQL 负载逐渐下降。为避免后续再次出现类似问题，同时做了以下优化。

备份策略优化

将全量备份改为 每日增量 + 每周全量 的方式，降低备份对生产的影响：

#!/bin/bash
# /usr/local/bin/mysql_backup_v2.sh

BACKUP_DIR="/data/backup/mysql"
WEEKDAY=$(date +%u)  # 1=周一, 7=周日

if [ "$WEEKDAY" -eq 7 ]; then
    # 周日全量备份
    mysqldump --single-transaction --quick --all-databases \
      | gzip > "$BACKUP_DIR/full_$(date +%Y%m%d).sql.gz"
else
    # 周一到周六增量备份（使用 binlog）
    mysqlbinlog --read-from-remote-server --raw --stop-never mysql-bin.000001 &
fi

关键配置项

在 MySQL 端限制备份对业务的影响：

# my.cnf 增加以下配置
[mysqld]
# 限制 mysqldump 的最大 IO 吞吐（Linux cgroup）
# 使用 ionice 降低备份进程 IO 优先级

在备份脚本中增加保护措施：

# 在 mysql_backup.sh 开头增加
# 1. 检查当前是否为业务低峰期
HOUR=$(date +%H)
if [ "$HOUR" -ge 8 ] && [ "$HOUR" -le 22 ]; then
    echo "$(date): ABORT - peak hours, skipping backup" >> /var/log/mysql_backup.log
    exit 0
fi

# 2. 降低 IO 优先级
ionice -c 2 -n 7 -p $$

# 3. 限制备份超时（超过 2 小时强制终止）
timeout 7200 mysqldump ...

预防措施

调整 systemd 服务启动顺序：确保 crond 在 NTP 同步完成后再启动

# /etc/systemd/system/crond.service.d/override.conf
[Unit]
After=network-online.target chronyd.service ntpd.service
Wants=network-online.target chronyd.service

CMDB Agent 标准化脚本增加保护：在执行 hwclock --systohc 前先验证 NTP 同步状态

# 检查 NTP 同步状态，未同步时拒绝写入硬件时钟
if ! timedatectl show | grep -q "NTPSynchronized=yes"; then
    echo "NTP not synchronized, aborting hwclock write"
    exit 1
fi
hwclock --systohc

备份任务增加时间校验：在备份脚本中显式判断当前时间是否在预期窗口内（如 01:00-05:00）
监控 Cron 执行时间的偏离：在 Cron 日志中添加时间戳对比监控，当任务执行时间与 crontab 定义的预期时间偏差超过 30 分钟时触发告警
数据库备份改为从库执行：避免备份 IO 直接影响主库，备库专门用于备份和只读查询

总结

这次故障表面上是「备份在错误时间执行导致数据库性能下降」，但真正的根因是 crond 启动时与 NTP 同步之间的竞态条件。这类问题是典型的「一切配置都正确，现象却不对」的诡异故障。

核心教训：

crond 的时钟基准在启动时确定，重启后在 NTP 调时前有一个脆弱窗口
不要假设守护进程的时钟和系统时钟始终一致，两者之间可能存在偏移
备份任务应包含自我保护逻辑（时间窗口检查、IO 限制、超时控制）
CMDB/自动化工具的标准化脚本需要增加前置条件检查，避免在系统状态不稳定时执行危险操作

最终的重启 crond 操作只需要 1 秒，但排查过程花了近 2 个小时。希望这篇文章能帮你在遇到类似问题时少走一些弯路。

一次Ansible Playbook变量优先级错误导致批量服务器配置漂移的排查实录

Fri, 03 Jul 2026 06:55:17 +0000

问题背景

事情发生在周二凌晨的变更窗口。我们按计划对一套线上业务集群做例行配置加固，涉及32台Web服务器（Nginx + PHP-FPM + Supervisor）。这批机器跑的是相同的CentOS 7.9镜像，由一套统一的Ansible Playbook管理，日常变更一直比较稳定。

当晚的变更内容并不复杂：根据安全组要求，关闭Nginx版本号显示、统一PHP-FPM的慢日志阈值，并调整Supervisor对子进程崩溃后的自动重启策略。由于变更项较少，值班同事直接用了熟悉的命令行方式触发：

1
2

ansible-playbook -i inventory/production web.yml \
  -e "nginx_server_tokens=off php_fpm_slowlog_timeout=3s supervisor_autorestart=unexpected"

凌晨 01:17 执行完成，playbook 显示所有机器都是 changed=4 ok=28，看起来一切正常。然而早上 08:45 业务方开始在群里反馈：部分接口响应变慢，偶尔出现 502 Bad Gateway，且报错机器不固定。更严重的是，监控显示 PHP-FPM 的 max_children 在几台高并发机器上从 200 变成了 50，连接队列被打满，直接触发告警。

故障现象

故障的典型表现包括：

Nginx 侧：随机 502，且集中在部分机器上。error.log 中出现大量 connect() to unix:/run/php-fpm.sock failed (11: Resource temporarily unavailable)。
PHP-FPM 侧：pm.max_children 被改为 50，而原生产值为 200。慢日志阈值 request_slowlog_timeout 变成了 3s，但部分业务池期望的是 5s。
Supervisor 侧：程序配置中的 autorestart=true 被改成了 unexpected，导致计划内的退出码也触发了重启，日志里出现大量 EXITED 后又被拉起的情况。
监控告警：Zabbix 连续报 PHP-FPM listen queue len > 100；Prometheus 的 phpfpm_active_processes 在几台机器上达到 50/50。

我登录到一台问题机器上查看 PHP-FPM 主配置：

1
2
3

$ cat /etc/php-fpm.d/www.conf | grep -E "pm.max_children|request_slowlog_timeout"
pm.max_children = 50
request_slowlog_timeout = 3s

Nginx 配置也被改了：

1
2

$ cat /etc/nginx/nginx.conf | grep server_tokens
server_tokens off;

server_tokens off 这个变更本身是对的，但问题在于为什么它会把其他配置也一并带偏？Playbook 当晚明明只改了三个变量，为什么 Nginx 的 worker_connections、PHP-FPM 的 pm.max_children、Supervisor 的 autorestart 都出现了非预期变更？

排查过程

第一步：确认变更范围

先通过 Git 查看 Playbook 仓库最近的提交，确认代码层面没有改动。结果显示最近一周只有文档更新，没有角色或变量的变更。那么问题只能出在命令行参数或者环境变量上。

查看值班同事使用的命令历史：

1
2
3

$ history | grep ansible-playbook | tail -5
  ansible-playbook -i inventory/production web.yml \
    -e "nginx_server_tokens=off php_fpm_slowlog_timeout=3s supervisor_autorestart=unexpected"

看起来只传了三个变量，但影响面却大得多。我怀疑 -e 传入的 extra variables 在 Playbook 里被某种方式覆盖或透传到了其他角色。

第二步：检查变量优先级

Ansible 的变量优先级（Variable Precedence）是出了名的复杂。从 Ansible 2.9 官方文档看，extra vars（命令行 -e）处于最高优先级，会覆盖几乎所有其他变量，包括 role defaults、inventory vars、play vars、host vars 等。

但问题不在于 extra vars 本身优先级高，而在于这些变量名恰好和角色内部的变量名一致，且被多个角色共用。

我先检查 group_vars/all.yml：

nginx_server_tokens: "on"
nginx_worker_connections: 4096

php_fpm_slowlog_timeout: 5s
php_fpm_max_children: 200

supervisor_autorestart: true

再检查角色变量。比如 roles/nginx/defaults/main.yml：

1
2

nginx_server_tokens: "on"
nginx_worker_connections: 1024

roles/php-fpm/defaults/main.yml：

1
2

php_fpm_slowlog_timeout: 0
php_fpm_max_children: 50

roles/supervisor/defaults/main.yml：

`1`	`supervisor_autorestart: true`

注意：当命令行传入 php_fpm_slowlog_timeout=3s 时，它确实只覆盖了 PHP-FPM 的慢日志阈值，但 php_fpm_max_children 为什么也被改了？

第三步：定位变量透传路径

继续看 web.yml 这个 Playbook 的结构：

- name: Configure web servers
  hosts: web
  become: yes
  vars:
    php_fpm_max_children: "{{ php_fpm_max_children | default(50) }}"
  roles:
    - role: nginx
    - role: php-fpm
    - role: supervisor

问题立刻暴露：play vars 里使用了和 extra var 同名的 php_fpm_max_children，但它通过 default 过滤器试图回退到 50。extra vars 优先级高于 play vars，但这里有一个坑：当 extra vars 中只显式传了 php_fpm_slowlog_timeout，而 php_fpm_max_children 在 extra vars 中并不存在时，为什么 play vars 里的 default(50) 还会生效？

答案不会是这样。实际上，如果 php_fpm_max_children 在 extra vars 中没有显式传入，那么 play vars 里的 php_fpm_max_children: "{{ php_fpm_max_children | default(50) }}" 会引用自己，导致无限递归？不，Ansible 处理变量时会先找 play vars 的值，模板里再对 php_fpm_max_children 求值，但此时同一作用域里已有定义，所以它会取自身值，结果相当于没有 default 效果，或者报错。

我实际执行了 ansible-playbook --syntax-check 和 debug 任务：

1
2

- debug:
    var: php_fpm_max_children

结果输出为 50。这说明 play vars 的 default(50) 确实生效了，并且覆盖了 group_vars/all.yml 中定义的 php_fpm_max_children: 200。

为什么？因为 Ansible 的变量优先级中，play vars 高于 group_vars 和 host_vars，而 default(50) 只是给模板一个默认值。当 play vars 显式定义了某个变量，无论它是否使用 default，它都会覆盖 group_vars 里的同名词。

第四步：检查其他被影响的变量

回到三个命令行变量：

nginx_server_tokens=off：extra var 最高优先级，覆盖了 group_vars/all.yml 和 role defaults。这是预期变更。
php_fpm_slowlog_timeout=3s：extra var 覆盖了 group_vars 的 5s。这是预期变更，但业务方期望的 5s 被打破了。
supervisor_autorestart=unexpected：extra var 覆盖了 group_vars 的 true，导致计划内退出码也触发重启。

但 nginx_worker_connections 和 php_fpm_max_children 的变更是怎么来的？

继续检查角色模板。在 roles/nginx/templates/nginx.conf.j2 中：

1
2

worker_connections {{ nginx_worker_connections | default(1024) }};
server_tokens {{ nginx_server_tokens | default('on') }};

由于 nginx_worker_connections 只在 group_vars/all.yml 中定义，没有 extra var 覆盖，优先级低于 play vars。但 web.yml 的 play vars 里没有 nginx_worker_connections，那它为什么变成 1024？

回看 roles/nginx/defaults/main.yml 中定义了 nginx_worker_connections: 1024，而 group_vars/all.yml 定义了 4096。按 Ansible 优先级，group_vars 应该覆盖 role defaults。可是实际结果是 1024。

我再用 debug 打印：

1
2

- debug:
    var: nginx_worker_connections

输出居然是 1024！这完全不符合变量优先级表。经过反复核对，我发现 group_vars/all.yml 中这个变量名被同事在月初的某次合并中误删了！Git 记录显示：

`1`	`-nginx_worker_connections: 4096`

也就是说，group_vars 里已经不存在这个变量，role defaults 的 1024 自然生效。但更深层的问题是：为什么组里没有人知道这个变量被删了？因为 Playbook 在每次执行时，Ansible 不会主动告诉你某个变量被 role defaults 回退了多少。

第五步：检查审计与变更流程

这引出了另一个关键问题：为什么一个"只改三个变量"的变更，会触发 Nginx、PHP-FPM、Supervisor 三个角色的重新渲染？

查看 Ansible 执行日志，发现 changed=4 中的 4 个变更分别是：

nginx.conf 被渲染（server_tokens 变化 + worker_connections 回退）
www.conf 被渲染（slowlog_timeout 变化 + max_children 被 play vars 强制为 50）
supervisord.conf 被渲染（autorestart 变化）
重启相关服务

也就是说，Ansible 的 template 模块在每次任务里都会重新渲染整个配置文件，即使只有一处变量变化，也会把模板中所有变量一起带入。如果模板里引用了被 play vars 或 extra vars 覆盖的变量，就会牵一发而动全身。

第六步：确认回滚方案

找到根因后，我需要先止血。由于 group_vars 里的 nginx_worker_connections 已经被误删，且 play vars 中 php_fpm_max_children 被固定为 50，最快的恢复方式是：

先手工恢复 group_vars/all.yml 中缺失的 nginx_worker_connections: 4096。
临时注释掉 web.yml 中 play vars 里的 php_fpm_max_children 行，让 group_vars 的 200 生效。
回滚 supervisor_autorestart 到 true，php_fpm_slowlog_timeout 回滚到 5s，nginx_server_tokens 保持 off（这是安全要求）。

执行命令：

1
2

ansible-playbook -i inventory/production web.yml \
  -e "nginx_server_tokens=off php_fpm_slowlog_timeout=5s supervisor_autorestart=true"

同时，临时把 web.yml 中的 play vars 注释：

1
2

  # vars:
  #   php_fpm_max_children: "{{ php_fpm_max_children | default(50) }}"

重新执行后，检查关键配置已恢复正常：

$ cat /etc/php-fpm.d/www.conf | grep pm.max_children
pm.max_children = 200

$ cat /etc/nginx/nginx.conf | grep worker_connections
worker_connections 4096;

$ cat /etc/supervisord.d/app.ini | grep autorestart
autorestart=true

业务 502 告警在 09:38 开始下降，10:05 完全恢复。

解决方案

这次故障的表面原因是命令行 extra vars 覆盖了不该覆盖的变量，但根因是 Playbook 本身缺乏变量作用域隔离和变更管控。我制定了以下整改方案：

1. 移除 play vars 中的同名变量陷阱

web.yml 中原来的写法：

1
2

  vars:
    php_fpm_max_children: "{{ php_fpm_max_children | default(50) }}"

这种写法有严重歧义：它在 play vars 中定义了一个变量，同时试图引用自身求默认值。修改后，把默认值下沉到角色 defaults，并把业务默认值放到 group_vars 中显式管理：

roles/php-fpm/defaults/main.yml：

1
2

php_fpm_max_children: 50
php_fpm_slowlog_timeout: 0

group_vars/web.yml（新建，专门给 web 主机组）：

1
2

php_fpm_max_children: 200
php_fpm_slowlog_timeout: 5s

web.yml：

- name: Configure web servers
  hosts: web
  become: yes
  roles:
    - role: nginx
    - role: php-fpm
    - role: supervisor

2. 使用变量前缀隔离不同角色的变量

避免不同角色使用完全相同的变量名。例如：

nginx_server_tokens → nginx__server_tokens
php_fpm_max_children → php_fpm__max_children
supervisor_autorestart → supervisor__autorestart

虽然 Ansible 没有强制命名空间，但为角色变量加双下划线前缀（或统一用角色名前缀）可以显著降低误覆盖风险。不过，更好的做法是使用 rolespec 风格或 include_role 的 vars 参数显式传入。

3. 禁止在命令行直接传复杂变量

以后所有变量变更必须通过 group_vars 或 host_vars 文件提交，走 Git 合并请求。临时命令行变更只允许传明确的开关变量，例如 deploy_only=true。

4. 增加配置漂移检查

在 Playbook 最后增加 ansible-playbook --check --diff 的 dry-run 检查，以及每次变更后自动比对关键配置文件的 checksum：

- name: Verify php-fpm max_children
  lineinfile:
    path: /etc/php-fpm.d/www.conf
    regexp: '^pm.max_children\s*='
    line: "pm.max_children = {{ php_fpm_max_children }}"
  check_mode: yes
  register: php_fpm_check
  changed_when: false

- name: Fail if php-fpm max_children drifted
  fail:
    msg: "php-fpm max_children drifted!"
  when: php_fpm_check.changed

5. 把变量定义集中到 inventory 并按环境分组

将生产环境、预发布环境、测试环境的变量分别放到 group_vars/prod_web.yml、group_vars/staging_web.yml 中，避免所有环境共用 group_vars/all.yml 导致一个误删影响全局。

根因分析

根本原因是 Ansible 变量优先级被误用，叠加了三个低级失误：

Playbook 中 play vars 使用了和 group_vars 同名的变量，且通过 default(50) 的方式试图回退，导致 play vars 显式定义了 php_fpm_max_children，其优先级高于 group_vars，覆盖了生产值 200。
group_vars/all.yml 中 nginx_worker_connections 被前序提交误删，没有触发任何告警，role defaults 的 1024 在生产环境生效。
命令行 -e 传入的 extra vars 优先级最高，虽然初衷是只改三个小变量，但因为它可以覆盖 group_vars 和 play vars，业务侧期望的 php_fpm_slowlog_timeout=5s 和 supervisor_autorestart=true 被临时命令行值覆盖。
变更流程缺失 dry-run 和 diff 检查，值班同事没有执行 --check --diff 就跑了生产变更，导致问题未在事前发现。

预防措施

变更前必须执行 dry-run：所有 Ansible 生产变更必须先跑 --check --diff，确认 diff 只包含预期项。这条写进变更 SOP。
禁用无 MR 的变量变更：group_vars/host_vars 的修改必须走 Git 合并请求，至少经过两人 review。禁止临时用 -e 覆盖业务变量。
为每个角色维护独立的变量前缀：新项目统一采用 角色名__变量名 的命名规范，老项目逐步改造。
配置漂移监控：在 Zabbix 和 Ansible 本身增加关键配置项的 checksum 检查，每日比对一次。
Playbook 代码审查清单：每次变更 Playbook 或变量文件，必须检查：变量名是否重复、是否引用了已删除变量、role defaults 是否可能意外生效、extra vars 是否会覆盖 group_vars。
环境变量分层：尽快把 all.yml 拆成 prod.yml、staging.yml、dev.yml，减少一个文件影响所有环境的风险。

总结

这次事故让我重新认识了 Ansible 的"变量优先级"这个看似简单、实则很容易踩坑的话题。很多时候我们以为 -e 只是临时传一个小参数，但它在 Ansible 里处于最高优先级，稍有不慎就会把生产环境的配置整体带偏。

同时也暴露了我们 Playbook 代码本身的问题：同名变量在多个层级出现、role defaults 没有显式审计、group_vars 被误删无人察觉。这些问题单独看都不是致命伤，但叠加在一起，就能在几分钟内把 32 台服务器的关键配置改乱。

最后送给自己和同事三句话：

生产环境的任何变量，都值得被显式管理，而不是靠 default() 兜底。
--check --diff 不是可选步骤，是变更的底线。
临时命令行参数 -e 能救命，也能挖坑，用之前先想清楚它会影响多少模板。

一次服务器CPU软中断飙高导致服务间歇性超时的排查实录

Tue, 30 Jun 2026 21:00:00 +0000

一、问题背景

周三下午三点，业务群突然炸锅——客服反馈"工单系统卡得要命，点一个页面转十几秒才出来"。我看了一眼 Grafana，订单服务的 P99 延迟从平时的 120ms 飙到了 8 秒以上，Nginx 的 504 错误率从 0.01% 蹿到了 3.7%。但诡异的是，核心业务服务器（两台 32 核 64GB 的物理机，CentOS 7.9，前面挂 LVS+Keepalived）的 CPU 使用率才 58%~65%，内存也还有 22GB 空闲，磁盘 IO wait 只有 2.3%。看起来哪哪都正常，偏偏服务就是慢。

业务方催得紧，老板在群里 @ 了我三次。这次的排查过程，让我对"CPU 使用率不高就代表没事"这个惯性认知有了全新的认识。

二、故障现象

初步登录服务器后，我快速过了一遍常规指标：

$ top -bn1 | head -15
top - 15:12:34 up 137 days,  2:44,  3 users,  load average: 18.45, 14.22, 11.30
Tasks: 412 total,   1 running, 411 sleeping,   0 stopped,   0 zombie
%Cpu(s): 18.2 us,  8.7 sy,  0.0 ni, 68.1 id,  0.0 wa,  0.0 hi,  5.0 si,  0.0 st
KiB Mem:  65712344 total, 43567112 used, 22145232 free,   512344 buffers
KiB Swap: 16777212 total,  1245000 used, 15532212 free. 32145678 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
17812 appuser   20   0 12.345g 5.231g  28700 S  45.2  8.3  1234:12 java
 5642 nginx     20   0  287456  45678   3200 S  12.3  0.1   345:23 nginx

表面看，Java 进程占 45% CPU、Nginx 占 12%，负载 18.45 对于 32 核来说也不算高——但注意 %Cpu(s) 那行有个不对劲的数字：5.0 si。

这里解释一下 top 中 CPU 状态各字段的含义：

us（user）：用户态进程占用
sy（system）：内核态占用
si（softirq）：软中断占用——这个值是关键线索
hi（hardirq）：硬中断占用

正常情况下，si 在 1% 以下，超过 2% 就要引起警觉，超过 5% 则通常是网卡中断风暴的前兆。

进一步用 mpstat 确认：

$ mpstat -P ALL 2 5
03:15:01 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
03:15:03 PM  all   18.45    0.00    9.12    2.30    0.50   12.35    0.00    0.00   57.28
03:15:03 PM    0    2.12    0.00    1.50    0.00    0.00   92.38    0.00    0.00    4.00
03:15:03 PM    1   35.23    0.00   15.42    0.00    0.00    0.12    0.00    0.00   49.23
03:15:03 PM    2    1.35    0.00    2.34    0.00    0.00    0.08    0.00    0.00   96.23
03:15:03 PM    3   36.12    0.00   14.23    0.00    0.00    0.05    0.00    0.00   49.60
...

真相大白——CPU 0 的 %soft 高达 92.38%，几乎全部被软中断占满！而其他 31 个核心要么在跑业务、要么几乎空闲。32 核的机器，网络中断处理却全部压在 CPU 0 一个核上，形成了典型的"单核处理所有网卡中断"的性能瓶颈。

再查一下网卡中断分布：

$ cat /proc/interrupts | grep -E "CPU0|eth0"
           CPU0       CPU1       CPU2       CPU3  ...    CPU31
 59:   82341456          0          0          0  ...        0   IR-PCI-MSI-edge      eth0-TxRx-0
 60:  102345678          0          0          0  ...        0   IR-PCI-MSI-edge      eth0-TxRx-1
 61:   95678901          0          0          0  ...        0   IR-PCI-MSI-edge      eth0-TxRx-2
 62:   89765432          0          0          0  ...        0   IR-PCI-MSI-edge      eth0-TxRx-3

四队列万兆网卡（Intel X540），四个硬件中断队列（IRQ 59~62）全部绑定在 CPU 0 上。每秒近 4 亿次中断全部由一个核心处理，这个核心在软中断的泥潭里完全无法抽身。

三、排查过程

第一步：排除应用层问题

一开始我以为是 Java 应用有性能瓶颈。先用 Arthas 挂上 Java 进程看了一眼：

1
2

$ arthas-boot
[arthas@17812]$ dashboard

JVM 堆内存使用 62%，GC 频率正常（Young GC 约 15 次/分钟，Full GC 0 次），线程池没有积压。排除 JVM 层面的问题。

再看 Nginx 日志，大量请求的 upstream_response_time 高达 8~~15 秒，但 upstream_connect_time 只有 1~~3ms。说明 Nginx 和后端 Java 应用之间的 TCP 连接建立很快，但数据传输极慢——这直接把矛头指向了内核网络栈的处理性能。

第二步：定位内核层面的瓶颈

top 和 mpstat 已经暴露了软中断问题，但我需要确认它确实是网络软中断，而不是其他类型（如块设备、定时器、RCU 等）：

$ cat /proc/softirqs | head -10
                    CPU0       CPU1       CPU2  ...    CPU31
          HI:          0          0          0  ...        0
       TIMER:  45678901   23456789   21234567  ... 19876543
      NET_TX:    123456        789       1023  ...      567
      NET_RX: 723456789        456        789  ...      345
       BLOCK:      34567       1023       2048  ...     1567
    IRQ_POLL:          0          0          0  ...        0
     TASKLET:    1234567      34567      23456  ...    12345
       SCHED:   12345678    3456789    4567890  ...   2345678
     HRTIMER:    2345678    8765432    7654321  ...   3456789
         RCU:  123456789   45678901   38901234  ...  56789012

CPU 0 的 NET_RX（网络接收软中断） 高达 7.2 亿次，是 CPU 1 的 160 万倍。问题确认：所有网卡接收中断的回调函数 net_rx_action() 全部在 CPU 0 上执行，导致该核心被独占。

第三步：追溯中断亲和性配置

检查网卡中断的 SMP 亲和性（smp_affinity）：

$ cat /proc/irq/59/smp_affinity
00000001
$ cat /proc/irq/60/smp_affinity
00000001
$ cat /proc/irq/61/smp_affinity
00000001
$ cat /proc/irq/62/smp_affinity
00000001

每一个中断的 smp_affinity 都是 00000001，即只允许 CPU 0 处理。这是系统默认行为，网卡驱动加载时 irqbalance 服务没有正确分发中断。

查一下 irqbalance 的状态：

$ systemctl status irqbalance
● irqbalance.service - irqbalance daemon
   Loaded: loaded (/usr/lib/systemd/system/irqbalance.service; enabled)
   Active: failed (Result: exit-code) since Wed 2026-05-14 03:10:23 CST; 1 months 16 days ago

果然——irqbalance 在 5 月 14 日凌晨系统自动安全更新重启后挂掉了，之后再也没起来过。这 47 天里，所有新增的网络中断都堆积在 CPU 0 上，随着业务流量逐步增长（Q2 日均请求从 180 万涨到 310 万），CPU 0 的软中断负担越来越重，直到今天下午流量峰值时彻底撑不住。

第四步：深入理解软中断的处理机制

这里有必要先理清 Linux 网络数据包的接收路径，否则很难理解为什么"一个 CPU 忙、31 个 CPU 闲"也会导致性能问题：

网卡硬件中断 → IRQ handler（极短，记录到 poll_list）
    → 触发软中断 NET_RX_SOFTIRQ
        → net_rx_action() 轮询 poll_list
            → NAPI poll（网卡驱动的 poll 函数）
                → 从 Ring Buffer 取数据包
                → 构建 sk_buff
                → 送入协议栈（IP→TCP→Socket）
                    → 唤醒等待该 Socket 的用户态进程

关键问题在于：用户态进程被唤醒后，内核调度器倾向于将进程调度到"距离数据最近的 CPU"上执行——也就是唤醒它的那个 CPU。如果进程恰好被调度到了 CPU 0（软中断所在核心），而 CPU 0 此时正忙于处理海量软中断（%soft 92%），进程几乎没有 CPU 时间来执行实际业务逻辑。这就形成了一个恶性循环：

软中断占满 CPU 0
    → 用户态进程被调度到 CPU 0（被唤醒）
    → 进程得不到 CPU 时间片（被软中断抢占）
    → 进程处理请求变慢
    → 请求积压、TCP 接收缓冲区塞满
    → 触发更多数据包到达、更多软中断
    → 软中断更重、CPU 0 更忙

如果用 perf 来验证，会更直观：

$ perf top -C 0
Samples: 1M of event 'cpu-clock', Event count (approx.): 123456789000
Overhead  Shared Object          Symbol
  42.35%  [kernel]               [k] net_rx_action
  18.72%  [kernel]               [k] __netif_receive_skb_core
  12.45%  [kernel]               [k] ip_rcv
   8.91%  [kernel]               [k] tcp_v4_rcv
   5.23%  [kernel]               [k] process_backlog
   3.12%  [kernel]               [k] napi_gro_receive
   ...

CPU 0 上 90% 以上的时间都在处理网络协议栈，真正留给用户态进程的时间不到 10%。而一个正常的 Java 请求处理需要经过 JSON 反序列化、业务逻辑计算、数据库查询、结果组装等步骤——被挤压到 10% 的 CPU 时间里，自然慢如蜗牛。

四、解决方案

紧急止血：手动绑定网卡中断到多个核心

业务不能等，先手动把四个网卡中断队列分别绑到不同的 CPU 核心：

# 关闭 irqbalance（防止它反向操作覆盖我们的设置）
systemctl stop irqbalance

# 将中断队列分别绑定到 CPU 0、8、16、24（分散在不同的物理核心和 NUMA 节点上）
echo 00000100 > /proc/irq/59/smp_affinity   # IRQ  59 → CPU 8
echo 00000100 > /proc/irq/60/smp_affinity   # IRQ  60 → CPU 8
echo 00010000 > /proc/irq/61/smp_affinity   # IRQ  61 → CPU 16
echo 01000000 > /proc/irq/62/smp_affinity   # IRQ  62 → CPU 24

smp_affinity 的值是一个 16 进制位掩码，每一位代表一个 CPU。例如 01000000 的二进制表示为 CPU 24。

验证中断分布变化：

$ cat /proc/interrupts | grep eth0 | awk '{print $1, $2, $3, $4, $5, $NF}'
59: 82341456 0 0 0 ... eth0-TxRx-0
60: 102345678 0 0 0 ... eth0-TxRx-1  # 刚改完，历史计数还在
61: 95678901 0 0 0 ... eth0-TxRx-2
62: 89765432 0 0 0 ... eth0-TxRx-3

历史计数不会清零，等待几秒后再次查看，确认新的中断确实在流向指定的 CPU：

`1`	`$ watch -n1 'cat /proc/interrupts \| grep eth0'`

大约 30 秒后，mpstat 确认软中断已分散：

$ mpstat -P 0,8,16,24 1
03:22:30 PM  CPU    %usr   %sys   %soft
03:22:31 PM    0    1.23   2.45    3.12
03:22:31 PM    8    0.56   1.23   18.45
03:22:31 PM   16    0.34   1.56   20.12
03:22:31 PM   24    0.67   1.34   17.89

Nginx 504 错误率应声从 3.7% 跌到 0.02%，P99 延迟从 8 秒回落到 180ms。

长期优化：RPS + RFS 进一步分散软中断

手动中断绑定解决了燃眉之急，但四个硬件队列只能分散到四个核心，对于 32 核机器来说远远不够。更好的方案是启用 RPS（Receive Packet Steering），让内核在软件层面把数据包分发给更多核心处理：

# 启用 RPS：把 CPU 0-31 全部加入 eth0 各队列的处理核心掩码
# ffffffff = 32 个 CPU 全部参与软中断处理
echo ffffffff > /sys/class/net/eth0/queues/rx-0/rps_cpus
echo ffffffff > /sys/class/net/eth0/queues/rx-1/rps_cpus
echo ffffffff > /sys/class/net/eth0/queues/rx-2/rps_cpus
echo ffffffff > /sys/class/net/eth0/queues/rx-3/rps_cpus

# 调整 RPS 流表大小（默认 4096，高并发场景建议 32768）
echo 32768 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt
echo 32768 > /sys/class/net/eth0/queues/rx-1/rps_flow_cnt
echo 32768 > /sys/class/net/eth0/queues/rx-2/rps_flow_cnt
echo 32768 > /sys/class/net/eth0/queues/rx-3/rps_flow_cnt

再启用 RFS（Receive Flow Steering），让内核把同一流的数据包定向到应用所在的 CPU，进一步提升缓存命中率：

# 设置全局 RFS 表大小
echo 32768 > /proc/sys/net/core/rps_sock_flow_entries

# 为每个接收队列设置 RFS 条目数
for i in $(seq 0 3); do
    echo 8192 > /sys/class/net/eth0/queues/rx-$i/rps_flow_cnt
done

持久化这些配置到 /etc/rc.d/rc.local 或 systemd 服务，确保重启后不丢失：

cat >> /etc/rc.d/rc.local << 'EOF'
# RPS/RFS optimization for eth0
for q in /sys/class/net/eth0/queues/rx-*; do
    echo ffffffff > $q/rps_cpus
    echo 32768 > $q/rps_flow_cnt
done
echo 32768 > /proc/sys/net/core/rps_sock_flow_entries
EOF
chmod +x /etc/rc.d/rc.local

修复 irqbalance 服务

根源之一是 irqbalance 挂了没人知道，修复并加固：

# 置入正式的中断绑定策略脚本
cat > /etc/sysconfig/irqbalance << 'EOF'
IRQBALANCE_ARGS="--hintpolicy=exact --banirq=59 --banirq=60 --banirq=61 --banirq=62"
EOF
systemctl enable irqbalance
systemctl start irqbalance

这里用 --banirq 把我们已经手动绑定好的网卡中断排除在 irqbalance 的自动管理之外，避免它反转我们的设置。

五、根因分析

这次问题的根本原因是一个三层连锁失效：

irqbalance 服务静默故障：5 月 14 日的安全更新重启了服务器，irqbalance 因依赖的某些内核模块加载时序问题启动失败，但没有触发任何告警。此后 47 天，服务器一直在"IRQ 全部绑在 CPU 0"的单核中断处理模式下运行。
缺乏软中断监控：我们的 Prometheus 监控采集了 CPU 使用率、内存、磁盘、网络流量等指标，但没有采集 /proc/softirqs 的数据。node_exporter 默认的 --collector.interrupts 参数只采集硬中断（/proc/interrupts），不采集软中断（/proc/softirqs）。这导致 CPU 0 的软中断使用率从 2% 慢慢爬到 92% 的过程中，监控面板一片风平浪静。
业务流量自然增长越过临界点：Q2 日均请求量从 180 万涨到 310 万（+72%），而"单核处理所有网络中断"这个架构的极限大约在日均 250 万请求左右。超过这个临界点后，软中断开始抢占用户态 CPU 时间，性能呈断崖式下跌，而不是线性退化。

六、预防措施

1. 补齐软中断监控

在 node_exporter 启动参数中加入软中断采集：

# /etc/systemd/system/node_exporter.service 修改
ExecStart=/usr/local/bin/node_exporter \
    --collector.interrupts \
    --collector.softirqs \
    --web.listen-address=:9100

对应地，在 Prometheus 中添加告警规则：

# softirq_alerts.yml
groups:
  - name: softirq
    rules:
      - alert: HighSoftirqPerCPU
        expr: rate(node_softirqs_total{softirq="NET_RX"}[5m]) > 100000
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "CPU {{ $labels.cpu }} 网络软中断过高"
          description: "当前速率 {{ $value | humanize }}/s，可能导致服务延迟增加"

2. 建立服务器上线标准模板

今后所有新上线的物理服务器或大规格虚机，必须在初始化阶段完成以下配置：

# 标准网络优化脚本（纳入装机 Kickstart/PXE 模板）
# 1. 启用 RPS
# 2. 设置 Ring Buffer 大小
# 3. 启用 TSO/GRO
# 4. 调整 TCP backlog

# RPS 在所有队列启用
for q in /sys/class/net/*/queues/rx-*; do
    [ -f $q/rps_cpus ] && echo ffffffff > $q/rps_cpus
    [ -f $q/rps_flow_cnt ] && echo 32768 > $q/rps_flow_cnt
done

# Ring Buffer 拉到最大
ethtool -G eth0 rx 4096 tx 4096

# TCP backlog
sysctl -w net.core.netdev_max_backlog=5000
sysctl -w net.core.somaxconn=4096

3. irqbalance 存活监控

在基础监控中加入 irqbalance 进程存活检测：

# 利用 node_exporter 的 textfile collector
# 或直接用 process_exporter
- alert: IrqbalanceDown
  expr: absent(process_start_time_seconds{process="irqbalance"})
  for: 10m
  labels:
    severity: critical
  annotations:
    summary: "irqbalance 服务未运行"

4. 定期性能基线巡检

每季度对核心服务器做一次性能基线检查，包括中断分布、软中断速率、NUMA 亲和性等——用脚本自动化，而不是靠人记住。

七、总结

这次排查给我上了深刻的一课：“CPU 整体使用率不高"绝对不等于"CPU 没有瓶颈”。top 那行 %Cpu(s) 里面的 si（软中断）字段，平时看起来永远是个位数，以至于大多数人（包括之前的我）都习惯性忽略它。但恰恰是这个不起眼的指标，一旦集中在单核上，就能把整台服务器拖垮。

回顾整个过程，工具链用得并不复杂——top、mpstat、/proc/interrupts、/proc/softirqs、perf top——都是 Linux 自带的基础工具。真正的难点在于思维路径：当 CPU 不高、内存够用、磁盘不忙、网络带宽也充足的时候，你的排查方向应该往哪里走？这次经历让我意识到，中断处理（硬中断 + 软中断）是一个经常被遗漏的排查维度。现代服务器动辄几十甚至上百核，如果中断亲和性配置不当，“一核有难、多核围观"的场面会比想象中更容易出现。

另外，监控的盲区就是事故的土壤。我们花了大量精力监控应用指标、基础设施指标，却偏偏漏掉了软中断这个看似"底层"的指标。47 天的时间里，CPU 0 的软中断从正常慢慢走到极限，如果有哪怕一条与此相关的告警，都不至于等到业务方投诉才发现。

最后抛一个问题给各位同行：你们线上服务器的 /proc/softirqs 分布是什么样的？不妨现在就打开看看，说不定有惊喜。

本文涉及的 /proc 文件系统和 sysfs 接口均为 Linux 标准接口，配置示例基于 CentOS 7.9 和 Intel X540 网卡，其他发行版和网卡型号请根据实际情况调整。

一次Prometheus告警风暴拖垮邮件与企业微信告警通道的排查实录

Sun, 28 Jun 2026 06:55:00 +0000

一、问题背景

周四下午 14:20 左右，公司内部运维群突然开始"刷屏"——每秒钟都有十几条告警消息从企业微信机器人推出来，密密麻麻的红色 ERROR 几乎把群聊淹没。我当时正在处理一个普通的工单，看到群里"炸了"的第一反应是某个核心服务挂了，但仔细扫了几条告警内容后又觉得不对：大量"Redis 慢查询"、“接口 P99 突增”、“磁盘 IO 升高"这种零散的二级告警，没有一条提到核心业务异常。

更诡异的是，我试着登录 Grafana 看核心仪表盘，结果返回 502；打开邮件客户端想看原始告警，登录后邮件列表一直转圈加载不出来。这一刻我才意识到——告警本身把告警通道打爆了。

我们的监控栈是典型的"Prometheus + Alertmanager + 企业微信/邮件"组合，部署在 2 节点的 VM 上，Prometheus 单实例抓取大约 280 个 target，覆盖 12 套业务系统。按理说应该是个很稳的架构，那天下午发生的事情彻底改变了我们对"告警治理"的认知。

二、故障现象

故障爆发后，我开始从外到内逐层观察，记录下的关键现象如下：

1. 企业微信群告警刷屏

群机器人从 14:20 开始以大约 12 条/秒的速率推送告警，告警内容主要分两类：

HighRequestLatency P99 延迟大于 1s（业务接口 50+）
RedisSlowQuery 慢查询大于 100ms（Redis 实例 12+）
ContainerCPUThrottled CPU 限流（Pod 30+）
NodeDiskIOHigh 节点磁盘 IO 高（节点 8+）

但所有告警的 severity 标签都是 warning，没有任何 critical 级别的告警出现。

2. 邮件系统卡死

公司内部邮箱（基于 Postfix + Dovecot 自建）登录后无法加载新邮件，运维组的公共收件箱 ops-alert@company.com 在 10 分钟内收到了 18,742 封邮件。我 ssh 到邮件服务器上看了一眼：

1
2

$ postqueue -p | tail -5
-- 18472 Kbytes in 18742 Requests.

队列里堆了 1.8 万封待发邮件，Postfix 的 qmgr 进程 CPU 占用飙到 380%（多核），active 队列达到 smtp_destination_concurrency_limit 的上限。

3. Grafana 不可达

通过 curl -I http://grafana.internal:3000 测试返回 502。Grafana 后端依赖的 Prometheus 数据源因为查询请求堆积而响应缓慢，Grafana 默认的超时时间是 30 秒，大量仪表盘请求堆积导致前端一直 502。

4. 真正致命的故障被淹没

事后复盘发现，在 14:15 左右（也就是告警风暴前 5 分钟），核心订单数据库的主从复制其实已经中断，从库 Seconds_Behind_Master 飙到 NULL，意味着 IO 线程已经停了。但因为告警风暴期间 Alertmanager 的处理队列被压垮，这条 critical 级别的告警根本没有被发送出来。最终这个故障是业务部门反馈"订单数据不准"后我手动查数据库才发现的，业务受影响时长接近 2 小时。

三、排查过程

我按"告警链路 → 告警源头 → 告警通道"三段式展开排查，整个过程大约用了 40 分钟。

3.1 紧急止血：先让告警通道活过来

第一件事是阻止告警继续刷屏。我直接 ssh 到 Alertmanager 节点，先停掉企业微信机器人的 webhook 投递：

$ systemctl status alertmanager
● alertmanager.service - Alertmanager
   Active: active (running) since ...

# 临时禁用webhook
$ vim /etc/alertmanager/alertmanager.yml
# 在webhook_config前加 - name: 'disabled'
# 注释掉 receivers 段中所有 webhook
$ systemctl reload alertmanager

然后去邮件服务器上把堆积的队列清掉，保留最近的 200 封邮件作为证据：

# 查看队列
$ postqueue -p | head -20
# 把队列里老于30分钟的邮件全部退信
$ postsuper -d ALL deferred
# 或者更精细：只删除30分钟前的
$ find /var/spool/postfix/deferred -type f -mmin +30 -delete

止血操作大约花了 5 分钟，群里的刷屏停了，邮件系统开始慢慢恢复。Grafana 在 2 分钟后也能正常打开。

3.2 查告警源头：为什么这么多告警同时触发？

止血之后开始查根因。打开 Alertmanager 的 Web UI（http://alertmanager:9093），在 Alerts 页面看到 Active 状态的告警有 2,347 条。这显然不正常——我每秒钟大概只有 5~10 个真实异常指标会被触发，绝大部分都是抖动。

我抽样了几条告警，看它们的 Active Since 和 Labels：

告警名称	触发数	Active Since	severity
HighRequestLatency	487	14:18:42	warning
RedisSlowQuery	156	14:19:03	warning
ContainerCPUThrottled	312	14:19:18	warning
NodeDiskIOHigh	88	14:19:31	warning

所有告警的 Active Since 都集中在 14:18~14:19 这 1 分钟内。这说明不是"业务真的出了这么多问题”，而是某个时间点发生了一次"集体抖动"。

接着我去查 Prometheus 的告警规则文件 /etc/prometheus/rules/，发现一个被忽视的配置：

# rules/business.yaml
- alert: HighRequestLatency
  expr: |
    histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[1m])) by (le, service)) > 1
  # 缺失 for 字段!
  labels:
    severity: warning
  annotations:
    summary: "接口 P99 延迟高"

for 字段是告警持续多久才真正发送的关键参数。我之前为了"新告警规则快速生效"，把 for 字段都删掉了，意图是"指标一超标就告警"，结果就是任何一次 1~2 秒的网络抖动、一次 GC 暂停、一次容器重启，都会被立刻当成告警发送。

我去查了那 1 分钟内发生了什么事，从 Kubernetes 事件里看到：

$ kubectl get events --sort-by=.lastTimestamp | head -20
14:18:35  Normal   ScalingReplicaSet   deployment/order-service
14:18:38  Normal   Pulling              pod/order-service-7d8f9-xnz2j
14:18:40  Normal   Scheduled            pod/order-service-7d8f9-abcde
14:18:42  Normal   Created              pod/order-service-7d8f9-abcde
14:19:15  Normal   Started              pod/order-service-7d8f9-abcde

14:18 左右，业务团队发布了一版新服务，Deployment 滚动更新导致 30+ Pod 同时重启、镜像拉取、初始化，Prometheus 在这 1 分钟内采集到了大量瞬时高 CPU、高延迟、慢查询指标，所有缺 for 的告警规则同时被触发。

3.3 查 Alertmanager 配置：为什么告警没有被合并？

光解释清楚了告警源头还不够——为什么 2347 条告警没有按"业务系统"、“告警类型"分组到一起，而是被一条条推出去？

打开 /etc/alertmanager/alertmanager.yml，看到路由配置是这样的：

route:
  group_by: ['alertname']   # 只按告警名分组!
  group_wait: 5s
  group_interval: 10s        # 太短!
  repeat_interval: 1h
  receiver: 'ops-default'

receivers:
  - name: 'ops-default'
    webhook_configs:
      - url: 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxx'
    email_configs:
      - to: 'ops-alert@company.com'

问题一：group_by: ['alertname'] 意味着所有同名告警会被分到一组，但每条告警的 service、pod 标签还是独立的，会作为多条记录在组里。所以 HighRequestLatency 告警虽然合并成了 1 条群消息，但群消息里包含 487 个 service 实例，消息体超大，企业微信 API 直接报错。

问题二：group_interval: 10s，意味着 Alertmanager 每 10 秒就重新评估并发送一次"组更新"消息。结果就是这 2 分钟内，Alertmanager 给企业微信机器人推送了 12 次/秒的频率。

问题三：企业微信机器人限流，官方限制是每分钟最多 20 条消息。当 Alertmanager 推得比限流还快，HTTP 429 响应导致消息被丢弃，但 Alertmanager 的 retry 机制又会重试，进一步加剧了堆积。

问题四：邮件更是无差别全发，Postfix 没有针对 ops-alert@company.com 这个收件人做 rate limit，所以 1.8 万封邮件在 10 分钟内全部进队列。

3.4 查根因告警：为什么 critical 告警没发出来？

这是最让我后怕的部分。我去 Alertmanager 的日志里翻：

$ journalctl -u alertmanager --since "14:00" | grep -i "notify"
... 14:21:18 notify_loop ... rate limited
... 14:21:19 notify_loop ... rate limited
... 14:21:20 notify_loop ... queue full, drop
... 14:21:21 notify_loop ... queue full, drop
... 14:21:22 notify_loop ... queue full, drop

queue full, drop 才是关键。Alertmanager 的内部通知队列是有上限的（默认 10000 条），当它自己处理不过来时，新来的告警直接被丢弃。也就是说，critical 的 DB 告警不是被"挤到后面”，而是被"丢掉"了。这是最严重的告警可靠性问题。

四、解决方案

针对上面四个层面的问题，我做了一次系统性的整改。

4.1 告警规则层：加 `for` 持续时间和分级

把所有 warning 级别的告警都加上 for 字段，按业务特征选择不同持续时间：

# rules/business.yaml（整改后）
- alert: HighRequestLatency
  expr: |
    histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service)) > 1
  for: 5m           # 持续5分钟才告警
  labels:
    severity: warning
    category: latency
  annotations:
    summary: "接口 {{ $labels.service }} P99 延迟 {{ $value }}s"

- alert: RedisSlowQuery
  expr: |
    rate(redis_commands_duration_seconds_sum[2m]) / rate(redis_commands_duration_seconds_count[2m]) > 0.1
  for: 3m
  labels:
    severity: warning
    category: cache

# critical级别单独写，for 较短但需要更严格的指标
- alert: MySQLReplicationBroken
  expr: |
    mysql_slave_status_slave_io_running == 0
  for: 1m
  labels:
    severity: critical
    category: database

注意 expr 里的 rate 窗口也从 1m 改成了 5m，进一步平滑瞬时抖动。

4.2 Alertmanager 层：精细化路由 + 抑制 + 分级

重写 alertmanager.yml，核心改动：

global:
  resolve_timeout: 5m

route:
  receiver: 'ops-default'
  group_by: ['alertname', 'cluster', 'service']   # 加多维度分组
  group_wait: 30s        # 首次等30s再发，让同组告警合并
  group_interval: 5m     # 组更新间隔拉到5分钟
  repeat_interval: 4h
  routes:
    # critical 走独立通道，避免被warning淹没
    - matchers:
        - severity = "critical"
      receiver: 'ops-critical'
      group_wait: 10s
      group_interval: 1m
      repeat_interval: 1h
      continue: false     # critical 走完后不再往 default 走

    # 业务发布期间静音
    - matchers:
        - category =~ "latency|cache"
      receiver: 'ops-business'
      group_interval: 10m
      repeat_interval: 24h
      active_time_intervals:
        - business_hours

# 抑制规则：critical 告警触发时，抑制相关的 warning
inhibit_rules:
  - source_matchers:
      - severity = "critical"
    target_matchers:
      - severity = "warning"
      - category =~ "latency|cache|io"
    equal: ['cluster', 'service']

receivers:
  - name: 'ops-critical'
    webhook_configs:
      - url: 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=CRITICAL_KEY'
        send_resolved: true
    email_configs:
      - to: 'ops-critical@company.com'

  - name: 'ops-default'
    webhook_configs:
      - url: 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=DEFAULT_KEY'
        # 加重试和限流配置
        max_alerts: 50

  - name: 'ops-business'
    webhook_configs:
      - url: 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=BIZ_KEY'

4.3 告警通道层：企业微信分群 + 邮件限流

企业微信机器人的限流是硬性 20 条/分钟，靠 Alertmanager 自己节流不够，必须在通道层做隔离：

创建 3 个机器人：critical、business、default，各自独立 webhook
创建 3 个群：核心告警群（仅 critical）、业务告警群（warning+）、综合告警群
邮件也分收件人：ops-critical@、ops-business@、ops-default@，分别给 oncall 工程师、业务负责人、邮件组订阅

邮件系统层面，给 Postfix 加上发件限流：

# /etc/postfix/main.cf
smtp_destination_concurrency_limit = 20
default_destination_rate_delay = 1s
smtp_extra_recipient_limit = 50

4.4 可靠性层：告警持久化 + 自监控

为了防止"告警队列满后丢告警"再次发生，做了三件事：

启用 Alertmanager 集群模式：部署 3 个 Alertmanager 节点，Gossip 同步告警状态
加告警自监控：在 Prometheus 里配置一个 meta-alert，监控 alertmanager_notifications_failed_total 是否在涨、alertmanager_notification_queue_capacity 是否接近满
关键告警双通道：critical 告警同时走邮件 + 钉钉 + 电话，缺一不可

五、根因分析

事后复盘总结，根因有四个层面，由浅到深：

1. 告警规则设计缺陷（最直接）——所有 warning 告警缺失 for 持续时间，把"瞬时抖动"当成"持续故障"处理，这是导致 2347 条告警同时触发的直接原因。for 是 Prometheus 告警体系里最容易被忽略、但又最关键的一个参数。

2. Alertmanager 分组策略过粗——group_by: ['alertname'] 看似在合并，实际只是合并了告警名，每条告警的实例标签还是作为多条独立记录存在，结果就是"组很大、消息很胖"。企业微信 API 对单条消息体大小是有限制的（20KB 左右），超长消息会被截断甚至拒绝。

3. 告警通道无分层——所有 severity 都走同一通道，告警风暴时 critical 和 warning 互相挤占资源，企业微信 20 条/分钟的限流被 warning 消息吃光，critical 消息根本发不出去。

4. 缺乏告警自监控——没有监控"告警系统本身是否健康"，导致 Alertmanager 队列满、丢告警这种"次生故障"完全不可见。这是最致命的，因为告警系统一旦失效，整个监控体系等于瞎了。

六、预防措施

针对这次故障，我梳理出 5 条长期预防措施：

1. 告警规则审计常态化

把告警规则检查纳入 PR Review 流程，CI 里加一个 promtool check rules 的检查，确保每条告警都有合理的 for 字段。同时每月做一次告警规则审计，清理长期不触发或永远在触发的"僵尸告警"。

2. 告警分级通道永久隔离

critical / warning / info 必须在 Alertmanager 配置里走完全不同的 receiver 和 webhook，禁止混用通道。任何 critical 告警必须同时配邮件 + 至少一种 IM 通道，且 receiver 配 send_resolved: true 确保恢复时也能收到通知。

3. 告警降级与抑制规则

完善 inhibit_rules，critical 告警触发时自动抑制同服务同 cluster 的 warning 告警，避免"父故障触发一堆子告警"。同时为不同业务系统配置"维护窗口"，在主动发布期间自动静音相关告警（用 mute_time_intervals）。

4. 告警系统自身监控

必须给监控组件本身也加监控，至少包括：

alertmanager_notifications_failed_total 增长率
alertmanager_notification_queue_size / queue_capacity 比值
prometheus_tsdb_head_series 增长趋势
prometheus_target_sync_failed_total

这四个指标任何一个出问题，本身就是 critical 告警。

5. 定期演练"告警风暴"

每季度做一次"告警风暴演练"——人为在测试环境触发一个能产生 1000+ 告警的故障，验证告警系统的承载能力、通道隔离效果、抑制规则是否生效。我后来在测试环境复现了这次的场景，发现 1000 条告警经过新配置后只发出去 23 条，群里完全可控。

七、总结

这次故障给我的最大教训是：告警系统的健壮性是 SRE 工作中最容易被忽视的一环。我们花了大量精力建设监控覆盖度，却很少花时间思考"告警系统本身挂了怎么办"。

几个值得长期践行的原则：

告警是产品质量，不是越多越好。一条没人看的告警比没有告警更糟，因为它会消耗人对告警的敏感度。
for 字段是告警规则的灵魂。没有 for 的告警规则就是定时炸弹，迟早会在某次发布或重启时引爆。
告警通道必须分层。critical 告警是"救命"的通道，绝不能和 warning 混用。
监控监控本身。这是 SRE 领域一个朴素的哲学问题——你必须能监控到你正在监控这件事，否则就是盲人骑瞎马。

故障后我们重写了所有告警规则和 Alertmanager 配置，并补齐了告警自监控。半年后再回头看，告警群里基本只剩下真正需要人介入的告警，告警疲劳感大幅降低，运维同事的"告警响应时间"也从平均 25 分钟缩短到了 6 分钟。投资在告警治理上的时间，绝对是回报率最高的那部分。

一次GitLab CI Runner卡死导致生产部署流水线全停的排查实录

Sat, 27 Jun 2026 16:09:09 +0000

一次GitLab CI Runner卡死导致生产部署流水线全停的排查实录

一、问题背景

下午两点十五分，我正坐在工位上整理上午的网络变更文档，钉钉群里突然炸开了一连串告警信息。运维总监@我说：“线上部署流水线全挂了，研发提交了 7 个 Merge Request 等着合并发布，紧急发布也被卡住了，抓紧处理！“这是我们最核心的生产部署链路——从代码合并到镜像构建再到 K8s 滚动发布，全部跑在自建的 GitLab CI 上。一旦停摆，研发一天的工作量就没法上线。

我们公司自建了一套 GitLab（社区版 15.8.0）做代码托管，CI 部分使用了 3 台自建 Runner（其中 2 台是共享 Runner，1 台是项目级 Runner），部署在机房内部，配置是 4 核 8G 的虚拟机。平时每天大约跑 200~300 个 Pipeline，主要场景包括 Java 后端服务构建、Node 前端构建、Docker 镜像打包和 Helm Chart 同步等。系统从上线以来一直很稳定，从未出现过这么严重的全停故障。

紧急程度 P0——这意味着研发部门所有人在下班前都没办法发布代码，且因为关联到生产环境，可能影响晚上的业务运营。务必在 30 分钟内恢复。

二、故障现象

2.1 现象一：Pipeline 任务全部 pending

`1`	`This job is stuck, because you have no active runners online`

但诡异的是，GitLab 的 Admin → Runners 页面里，这 3 台 Runner 的状态都是 绿色的"绿点”，并没有显示"never contacted"或者"paused”。

2.2 现象二：Runner 进程 CPU 100% 占用

SSH 到 Runner 机器（10.20.30.51）上执行 top：

top - 14:18:21 up 42 days,  3 users,  load average: 31.27, 28.95, 26.13
Tasks: 247 total,   3 running, 244 sleeping
%Cpu(s): 99.3 us,  0.4 sy,  0.0 ni,  0.3 id,  0.0 wa,  0.0 hi,  0.0 si
KiB Mem :  8009532 total,  2145720 free,  4883216 used,   980596 buff/cache

  PID USER      PR  NI    VIRT    RES  RES  SHR S  %CPU %MEM     TIME+ COMMAND
 8721 gitlab-r  20   0 3821044 4.6g  4.6g  12m R  98.7 59.2   1438:22 gitlab-runner
24109 gitlab-r  20   0  412180  31872  31872  4248 S   1.3  0.4   0:00.23 gitlab-runner
24110 gitlab-r  20   0  412180  31744  31744  4244 S   1.0  0.4   0:00.19 gitlab-runner

可以看到 gitlab-runner 进程 CPU 占用 98.7%，内存吃掉了 4.6G（总共才 8G），load average 飙到了 31，但实际只有 1 个进程在真正吃 CPU。系统的 free 内存显示还有 2.1G，磁盘也没满。

2.3 现象三：日志显示连接数异常

查看 Runner 的日志（/var/log/gitlab-runner/gitlab-runner.log），看到大量重复告警：

ERRO[0145] Failed to process job                           builds=37 duration=12.4s err="context canceled"
WARN[0145] Job's log limit reached                          job=4218 limit=4194304
ERRO[0148] Failed to request job                           status=500 Job request timed out
WARN[0152] Runner lost contact with GitLab server          runner=xxxxxx
ERRO[0156] Failed to process runner                       accepts=0 builds=0
ERRO[0158] Runner is not healthy                          cpu_usage=98.7% memory_usage=59.2%

关键报错：Failed to request job status=500 Job request timed out——Runner 在向 GitLab Server 拉取 Job 的时候出现超时。也就是说，Runner 没有真正"死掉"，而是处于一种"假活"状态：进程在、端口在，但拿不到新任务。

三、排查过程

3.1 第一步：检查 Runner 与 GitLab Server 的连通性

先排除网络层问题。从 Runner 机器 ping 和 curl GitLab Server：

$ ping -c 4 gitlab.example.com
PING gitlab.example.com (10.20.30.10): 56 data bytes
64 bytes from 10.20.30.10: icmp_seq=0 ttl=64 time=0.124 ms
64 bytes from 10.20.30.10: icmp_seq=1 ttl=64 time=0.131 ms
64 bytes from 10.20.30.10: icmp_seq=2 ttl=64 time=0.118 ms
64 bytes from 10.20.30.10: icmp_seq=3 ttl=64 time=0.121 ms

$ curl -v http://gitlab.example.com/-/health
< HTTP/1.1 200 OK
{"status":"ok"}

网络通畅，GitLab Server 健康检查通过。问题不在网络层。

3.2 第二步：重启 Runner 服务试试

既然 CPU 100%，第一直觉是 Runner 内部出问题。先尝试软重启：

$ sudo gitlab-runner stop
$ sudo gitlab-runner start
$ sudo gitlab-runner status
gitlab-runner: Service is running!

重启后查看 top，CPU 占用短暂降到了 5%，load average 也开始回落。我以为问题解决了，结果不到 2 分钟，CPU 又飙回了 100%。这说明重启只是暂时缓解，根因没有解除。

3.3 第三步：抓 Runner 的 Goroutine 栈

GitLab Runner 是用 Go 写的，CPU 100% 一定是某个 goroutine 死循环或者阻塞。给它发 SIGQUIT 让它 dump goroutine 栈：

$ sudo kill -QUIT 8721
$ ls -lh /var/log/gitlab-runner/
-rw-r--r-- 1 root root 23M Jun 27 14:25 gitlab-runner.log
-rw-r--r-- 1 root root 8.2M Jun 27 14:25 stacktrace-20260627-1425.log

打开 stacktrace-20260627-1425.log，这是一个 8.2MB 的文本文件，里面有几十万个 goroutine。我用文本编辑器打开后搜索 “JobRequest”，看到有大量重复的 goroutine：

goroutine 1423857 [running]:
runtime/internal/syscall.Syscall6(...)
  github.com/aymerick/douceur/parser.parseDeclaration(0xc00a4d2000, 0xc0007e6000, 0x400, 0x400, 0xc00a4d2000, 0x400)
  github.com/aymerick/douceur/parser.parseRule(0xc00a4d2000, 0xc00a4d2000, 0x400, 0x400, 0x4, 0x0)
  github.com/aymerick/douceur/parser.Parse(0xc00a4d2000, 0x4, 0xc00a4d2000, 0x400, 0x4, 0x0, 0x0, 0x0)
  github.com/aymerick/douceur/css.Parse(0xc00a4d2000, 0x4, 0x0, 0xc00a4d2000, 0x4, 0x0, 0x0, 0x0)
  ...

虽然大部分栈都是 douceur 这个 CSS 解析库在干重活（巨量的 CSS 解析 goroutine 阻塞），但这不是根因。真正的问题在别处。我继续往下翻，发现关键信息：

goroutine 1 [running]:
main.runWait()
  /go/src/gitlab.com/gitlab-org/gitlab-runner/cmd/gitlab-runner/main.go:108
runtime.gopark(...)
runtime.selectnbrecv(...)
main.(*Runner).requestJob(0xc0001ce000)
  /go/src/gitlab.com/gitlab-org/gitlab-runner/runner.go:312
main.(*Runner).requestJob(0xc0001ce000)
  /go/src/gitlab.com/gitlab-org/gitlab-runner/runner.go:412

关键信息：在 requestJob 函数的 for 循环里累积了大量残留状态。继续翻看代码，我意识到问题可能与 Runner 工作目录里堆积了大量未清理的 Job 有关。

3.4 第四步：检查 builds 目录

GitLab Runner 默认会在 /var/lib/gitlab-runner/builds/ 下为每个 Job 创建一个工作目录。Job 完成后，目录理论上应该自动清理。但查看：

$ sudo ls /var/lib/gitlab-runner/builds/ | wc -l
237

$ sudo du -sh /var/lib/gitlab-runner/builds/
78G    /var/lib/gitlab-runner/builds/

**237 个 Job 目录，78G 磁盘占用！**这些目录有的是 2 个月前留下的。怪不得内存吃紧、CPU 打满——Runner 启动时会扫描所有这些目录，尝试加载历史 Job 状态做清理。

继续翻看 config.toml：

concurrent = 4
check_interval = 0

[[runners]]
  name = "shared-runner-01"
  url = "http://gitlab.example.com/"
  token = "glrt-xxxxxxxx"
  executor = "docker"
  builds_dir = "/var/lib/gitlab-runner/builds"
  cache_dir = "/var/lib/gitlab-runner/cache"
  [runners.docker]
    pull_policy = "if-not-present"
    privileged = false
    volumes = ["/cache"]
    shm_size = 0
  [runners.cache]
    Type = "s3"
    Path = "gitlab-ci-cache"
    [runners.cache.s3]
      ServerAddress = "minio.example.com:9000"

concurrent = 4 表示这台 Runner 最多同时跑 4 个 Job。但日志里显示 builds=37——说明有 37 个 Job 处于"已请求但未完成"的状态！也就是说，Runner 内部的状态机和磁盘上的 Job 目录完全对不上。

3.5 第五步：查 Sentry 找到已知 Bug

继续翻 Runner 的日志，看到一条关键的 Warning：

`1`	`WARN[0234] Runner builds=37 limit=4`

这是来自 Runner 自身的健康检查日志。我去 GitLab 官方 Issue 搜索 builds=37 limit=4，发现这是一个 GitLab Runner 15.5 ~ 15.10 之间的已知 Bug（issue 编号 #27895）。核心问题：

Runner 进程会维护一个内存中的 builds map，记录所有正在运行的 Job 状态。
当 Runner 与 GitLab Server 通信超时或网络抖动时，部分 Job 会被标记为"已 unregister"但 builds map 中并未真正删除。
这个 map 没有 LRU 或者 TTL 清理机制，导致残留对象会一直累积。
当残留 Job 数量接近或者超过 concurrent 配置值时，Runner 内部的 jobSlot 信号量被永久占满，新的 JobRequest 永远拿不到 slot。
表现为：Runner 进程 CPU 100%、新的 Job 全部 pending、JobRequest 超时。

我们的 3 台 Runner 全部是 15.8.0 版本，全部中招。

四、解决方案

4.1 紧急止血：清空 builds 目录 + 升级版本

由于这是已知 Bug，单纯的清目录只能解决一部分问题，必须升级 Runner。执行：

# 1. 停止所有 Runner
sudo gitlab-runner stop

# 2. 备份并清空 builds 目录（保留 cache 目录）
sudo mv /var/lib/gitlab-runner/builds /var/lib/gitlab-runner/builds.bak.20260627
sudo mkdir -p /var/lib/gitlab-runner/builds
sudo chown -R gitlab-runner:gitlab-runner /var/lib/gitlab-runner/builds

# 3. 升级到 15.11.2（修复 Bug 的版本）
curl -LJO "https://packages.gitlab.com/runner/gitlab-runner/packages/debian/bookworm/gitlab-runner_15.11.2_amd64.deb/download.deb"
sudo dpkg -i gitlab-runner_15.11.2_amd64.deb

# 4. 启动新版本
sudo gitlab-runner start
sudo gitlab-runner verify --delete  # 删除已 unregister 的 runner 缓存

升级完成后，CPU 立即降回 5% 以下，新提交的 Pipeline 在 30 秒内开始正常运行。builds= 日志恢复正常值 0。

全部 3 台 Runner 重复上述操作后，部署流水线完全恢复。

4.2 调优 Runner 配置

修改 /etc/gitlab-runner/config.toml，做几项关键调优：

concurrent = 4
check_interval = 5
log_level = "info"

[[runners]]
  name = "shared-runner-01"
  url = "http://gitlab.example.com/"
  token = "glrt-xxxxxxxx"
  executor = "docker"
  builds_dir = "/var/lib/gitlab-runner/builds"
  cache_dir = "/var/lib/gitlab-runner/cache"
  # 增加 Job 超时保护
  environment = ["GIT_CLEANUP=false"]
  pre_cleanup_script = "docker system prune -af --volumes --filter 'until=24h'"
  post_cleanup_script = "docker system prune -af --volumes --filter 'until=1h'"
  [runners.docker]
    pull_policy = "if-not-present"
    privileged = false
    volumes = ["/cache"]
    shm_size = 0
    network_mode = "bridge"
    # 限制 Docker 容器资源，避免某个 Job 吃光资源
    mem_limit = "2g"
    mem_swap_limit = "2g"
    cpu_limit = "1.5"
  [runners.cache]
    Type = "s3"
    Path = "gitlab-ci-cache"
    [runners.cache.s3]
      ServerAddress = "minio.example.com:9000"

关键点：

check_interval = 5：每 5 秒检查一次 Job 状态，比默认值（0）更容易发现问题。
pre_cleanup_script：每个 Job 开始前清理 24 小时前的 Docker 资源。
post_cleanup_script：每个 Job 结束后清理 1 小时前的 Docker 资源。
mem_limit / mem_swap_limit / cpu_limit：防止单 Job 资源失控。

4.3 加监控告警

在 Prometheus 监控里加上 GitLab Runner 的关键指标：

# prometheus.yml
- job_name: 'gitlab-runner'
  static_configs:
    - targets: ['10.20.30.51:9252', '10.20.30.52:9252', '10.20.30.53:9252']

监控的关键指标：

runner_concurrent_limit：配置的并发数。
runner_limit_used：当前在用的并发数（接近 limit 时应告警）。
gitlab_runner_jobs_total：Job 总数。
process_cpu_seconds_total：Runner 进程 CPU 使用。
process_resident_memory_bytes：Runner 进程内存。

在 Grafana 里配置告警规则：

# CPU 持续 5 分钟 > 80%
100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80

# builds 数量异常（> concurrent 的 1.5 倍）
runner_jobs_active > (runner_concurrent_limit * 1.5)

# 健康检查失败
up{job="gitlab-runner"} == 0

4.4 加自动清理 Cron

为了防止 builds 目录再次无限膨胀，加一个 cron：

# /etc/cron.daily/gitlab-runner-cleanup
#!/bin/bash
BUILD_DIR="/var/lib/gitlab-runner/builds"
# 只删除 7 天前且非活跃的目录
find "$BUILD_DIR" -maxdepth 2 -type d -mtime +7 -exec rm -rf {} + 2>/dev/null
# 清理孤儿 Docker 容器
docker container prune -f --filter "until=24h" 2>/dev/null
# 清理大体积 build cache
docker builder prune -f --filter "until=48h" --keep-storage=10GB 2>/dev/null

五、根因分析

本次故障的根本原因有两个层面：

直接原因：GitLab Runner 15.5~15.10 版本存在已知 Bug（issue #27895），Runner 内部 builds map 在 Job 状态异常时不会自动清理，导致残留对象无限累积。当残留数量超过 concurrent 配置值时，jobSlot 信号量被永久占满，新 JobRequest 永远拿不到 slot，从而引发 CPU 100% 和 JobRequest 超时。

间接原因：

缺乏 builds 目录的定期清理机制：GitLab Runner 本身不保证历史 Job 目录一定能被清理，必须有外部脚本兜底。
没有针对 Runner 自身状态的监控告警：CPU/内存/并发使用率无任何监控，故障积累 2 个月才被察觉。
Runner 版本长期未升级：社区版 Runner 升级对业务无影响，但运维团队未建立定期升级机制，错过 5 个 Bug 修复版本。

六、预防措施

为了避免类似问题再次发生，我们做了如下改进：

建立 Runner 版本升级 SOP：每季度（3/6/9/12 月）评估 Runner 新版本，根据官方 Release Notes 决定是否升级。升级前在测试 Runner 上跑一遍冒烟测试。
builds 目录自动清理：增加 cron 每天清理超过 7 天的历史 Job 目录，超过 50GB 立即告警。
健康检查多维度监控：CPU、内存、builds 数量、jobSlot 占用率、JobRequest 失败率 5 个维度全部纳入监控。关键指标持续 3 分钟异常即触发 P2 告警。
Runner 容量规划：原来 4 核 8G 跑 4 并发捉襟见肘（高峰期 CPU 经常 60%+），扩容到 8 核 16G 跑 6 并发，预留 50% 余量。
CI 任务 Quota 机制：在 GitLab 项目级别配置 pipeline_triggers 限速，避免研发短时间大量提交触发雪崩。
建立 Runner 故障 Runbook：将本次排查过程整理为内部 Runbook，SRE 团队 7×24 共享，新人入职必读。

七、总结

这次故障的教训很深刻：

版本升级不能忽视：GitLab Runner 这类基础设施软件，官方版本迭代很快，每 1~2 个版本就有重要 Bug 修复。运维团队必须建立主动跟踪机制，而不是等到出事才升级。
状态泄漏是分布式组件的通病：任何带"内置状态机 + 外部存储"的服务（Runner、Agent、Worker），都必须有外部状态对账机制。我们缺少 builds 目录的定期清理，本质上是信任了组件内部的清理逻辑，而没有做兜底。
监控告警要前置：CPU 100% 是故障的"果"，不是"因"。真正该监控的是早期信号——builds 数量、jobSlot 占用率、JobRequest 失败率。如果这些指标 2 个月前就告警，我们有充足的时间优雅处理。
应急操作要分级：本次紧急止血时"清空 builds 目录"是有风险的（可能丢失正在运行的 Job），幸亏我们是在业务低谷期操作。生产环境操作前，务必先评估"破坏半径"。

CI/CD 是研发的生命线，保障它的稳定性是 SRE 团队的核心职责。下次遇到类似问题，第一时间定位到 Bug 版本和 Issue，比盲目重启有效得多。

一次Linux服务器文件系统inode耗尽导致磁盘有空间却无法写入的排查实录

Sat, 27 Jun 2026 06:55:00 +0000

一、问题背景

周三上午10点左右，公司核心交易系统的Web层突然开始大量报错。监控平台连续发出"应用日志写入失败"和"业务健康检查超时"的告警，短短5分钟内收到的告警从0飙升至47条。

受影响的是部署在阿里云ECS上的Spring Boot交易网关服务，共3个节点，运行在CentOS 7.9系统上。该服务负责接收前端交易请求并将处理日志写入本地文件，再由Filebeat采集发送到ELK。因日志写入失败，服务开始返回HTTP 500错误，交易成功率从99.8%骤降至73%。

前一天运维同事刚做过一次应用版本发布，第一反应是"新版本有bug"。但在回滚到上一版本后问题依旧，才意识到这很可能不是代码问题，而是基础设施层面的故障。

二、故障现象

登录问题节点后，首先检查应用日志：

$ tail -f /var/log/trade-gateway/application.log
2026-06-27 10:03:42.127 ERROR [pool-3-thread-7] c.t.g.service.OrderService - Failed to write operation log
java.io.IOException: No space left on device
    at java.base/java.io.FileOutputStream.writeBytes(Native Method)
    at java.base/java.io.FileOutputStream.write(FileOutputStream.java:354)
    at java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81)
    ...

“No space left on device”——这个报错非常明确：磁盘没空间了。

习惯性地先查磁盘空间：

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        80G   45G   31G  60%  /
devtmpfs        7.8G     0  7.8G   0%  /dev
tmpfs           7.8G   16K  7.8G   1%  /dev/shm
tmpfs           7.8G  1.2M  7.8G   1%  /run

看得我一愣——根分区总共80G，使用了45G，还有31G可用空间。磁盘并没有满。

不信邪，手动创建文件试试：

$ touch /tmp/test_write
touch: cannot touch '/tmp/test_write': No space left on device

$ echo "test" > /var/log/test.log
-bash: /var/log/test.log: No space left on device

磁盘明明有31GB空闲，却无法创建任何文件。这就是典型的"文不对题"——报错说没空间，df却说空间充裕。此时心里已经有了方向：大概率是inode耗尽了。

三、排查过程

3.1 确认inode使用情况

遇到"磁盘有空间但无法创建文件"，第一个要检查的就是inode：

$ df -i
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/vda1     5242880 5242880      0  100%  /
devtmpfs      2039552    407 2039145    1%  /dev
tmpfs         2041888     19 2041869    1%  /dev/shm
tmpfs         2041888    833 2041055    1%  /run

真相大白。根分区一共5242880个inode，全部耗尽，IUse% = 100%。文件系统已经没有可用的inode来创建新文件了，哪怕磁盘物理空间还有大量剩余。

3.2 定位inode消耗大户

接下来的任务是找出哪些目录消耗了大量inode。先对整个根目录做一级统计：

$ for dir in /*; do
    if [ -d "$dir" ]; then
        count=$(find "$dir" -xdev -printf '.' | wc -c)
        echo "$count  $dir"
    fi
done | sort -rn | head -10

4892012  /tmp
247163   /var
89321    /usr
31002    /opt
...

接近490万个inode集中在/tmp目录下，几乎占了全部inode的93%。这个发现让排查目标变得非常明确。

3.3 深入/tmp目录分析

进入/tmp目录，用ls看看情况：

1
2

$ cd /tmp && ls | wc -l
4850000

四百八十五万个文件！这个数字令人震惊。进一步查看文件类型分布：

$ ls -lh /tmp | head -20
-rw-r--r-- 1 appuser appuser    0 Jun 24 03:00 .trade_lock_20260624_030001_8372
-rw-r--r-- 1 appuser appuser    0 Jun 24 03:00 .trade_lock_20260624_030002_9104
-rw-r--r-- 1 appuser appuser    0 Jun 24 03:00 .trade_lock_20260624_030003_2841
...
-rw-r--r-- 1 appuser appuser    0 Jun 27 10:00 .trade_lock_20260627_100001_5539

全是以.trade_lock_开头的隐藏文件，大小全部为0字节。这些是应用用于进程互斥的锁文件。

查看文件的创建时间分布：

$ find /tmp -name '.trade_lock_*' -printf '%TY-%Tm-%Td\n' | sort | uniq -c | sort -rn
1520000 2026-06-25
1438000 2026-06-24
1087000 2026-06-26
 696000 2026-06-23
 104000 2026-06-22
...

这批锁文件从6月22日开始累积，最近3天每天产生超过100万个。但关键问题是：为什么这些临时锁文件没有被清理？

3.4 追查清理机制

查了一下项目内部的定时任务和代码逻辑：

1
2
3

$ crontab -l -u appuser
# 每天凌晨3点清理/tmp下超过24小时的临时文件
0 3 * * * find /tmp -name '.trade_lock_*' -mtime +1 -delete

crontab里有一条清理任务：每天凌晨3点删除/tmp下24小时以前的锁文件。逻辑看起来没问题。

手动验证清理逻辑：

1
2

$ find /tmp -name '.trade_lock_*' -mtime +1 | wc -l
4870000

这个结果非常奇怪——几乎全部文件都满足"-mtime +1"条件，说明它们超过24小时了，但cron任务却没能清理掉它们。

继续深挖，查看cron的执行日志：

1
2

$ grep "find /tmp" /var/log/cron | tail -5
Jun 27 03:00:01 trade-gw-01 CROND[19238]: (appuser) CMD (find /tmp -name '.trade_lock_*' -mtime +1 -delete)

cron确实按时执行了。那为什么没删掉？把命令抄出来单独跑一下：

1
2

$ find /tmp -name '.trade_lock_*' -mtime +1 -delete
-bash: /usr/bin/find: Argument list too long

破案了！“Argument list too long”——find命令在内部处理-delete操作时，对于数百万级别的文件，exec的参数列表超出了系统限制。

补充说明：find 的 -delete 参数会尝试在内部批量调用 unlink()，当匹配到的文件数量极其庞大时，仍然可能触发内核的 ARG_MAX 限制（可以通过 getconf ARG_MAX 查看，通常为2MB）。这个限制不仅影响 -exec ... {} \+ 的显式调用，在文件基数达到百万级时也可能影响 -delete。

3.5 定位cron失败的根本原因

进一步验证：

$ getconf ARG_MAX
2097152

$ find /tmp -name '.trade_lock_*' -mtime +1 | wc -c
195482103

所有过期文件路径的总长度约186MB，远超ARG_MAX的2MB限制。find命令在执行-delete时一次性匹配的文件太多，路径总长度超过了内核参数上限，导致删除操作完全失败。

这也解释了为什么故障出现在周三——锁文件从上周日开始累积，到了周三总量突破500万，find -delete彻底失效形成"死锁"：cron定时删→delete失败→文件继续累积→下一次cron更不可能成功→恶性循环，直到inode彻底耗尽。

四、解决方案

4.1 紧急止血

当务之急是让服务恢复。不能直接用rm -rf /tmp/*——/tmp下还有其他进程的运行时文件。需要精准批量删除：

1
2

# 用find配合xargs分批删除，避免ARG_MAX限制
$ find /tmp -name '.trade_lock_*' -mtime +1 -print0 | xargs -0 -n 1000 rm -f

执行过程中持续监控inode恢复情况：

`1`	`$ watch -n 2 'df -i / \| tail -1'`

删除持续了约12分钟，inode使用率从100%降至8%。服务随即恢复正常。

4.2 修复清理机制

原有的cron删除命令需要改造，核心思路是让find通过管道将文件列表传给xargs分批处理，彻底绕过ARG_MAX限制：

修改crontab：

1
2
3

# 将原来的单条find -delete
# 改为 find + xargs 分批删除模式
$ crontab -e -u appuser

1
2

# 每天凌晨3点清理/tmp下超过24小时的锁文件（xargs分批避免ARG_MAX）
0 3 * * * find /tmp -name '.trade_lock_*' -mtime +1 -print0 | xargs -0 -n 500 rm -f

4.3 调整inode监控

在Prometheus中添加inode监控告警规则：

groups:
  - name: filesystem_alerts
    rules:
      - alert: InodeUsageHigh
        expr: (node_filesystem_files_free / node_filesystem_files) * 100 < 10
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "文件系统inode使用率超过90%"
          description: "主机 {{ $labels.instance }} 上 {{ $labels.mountpoint }} 的inode使用率为 {{ $value | humanize }}%，仅剩 {{ $value }}% 可用。"
      
      - alert: InodeUsageCritical
        expr: (node_filesystem_files_free / node_filesystem_files) * 100 < 5
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "文件系统inode使用率超过95%，即将耗尽！"
          description: "主机 {{ $labels.instance }} 上 {{ $labels.mountpoint }} 的inode仅剩 {{ $value }}%，请立即处理。"

同时配置Node Exporter采集inode指标，确保node_filesystem_files和node_filesystem_files_free指标正常上报。

五、根因分析

这个问题的根本原因有三层：

第一层（直接原因）：应用代码使用File.createTempFile()创建的锁文件没有在进程退出时正确清理。代码中虽然注册了deleteOnExit()，但当进程被kill -9强制终止时，JVM的shutdown hook不会执行，锁文件被遗留在磁盘上。

第二层（放大因素）：cron清理脚本使用find -delete一次性处理百万级文件时触发了ARG_MAX限制，导致清理完全失效。一旦清理失败一次，后续每次cron执行都面临更多的文件，形成"越积越多、越积越难清"的死循环。

第三层（监控缺失）：监控体系中只覆盖了磁盘空间（df -h），从未关注inode使用率（df -i）。运维团队直到故障发生才意识到inode是一个独立的资源维度。

六、预防措施

6.1 应用层面

将锁文件从/tmp迁移到应用专属的工作目录，并在应用启动脚本中增加自清理逻辑：

# 在应用启动前清理过期锁文件（配合xargs分批处理）
cleanup_locks() {
    local LOCK_DIR="/data/app/trade-gateway/locks"
    local MAX_AGE_MINUTES=60
    find "$LOCK_DIR" -name '.trade_lock_*' -mmin "+${MAX_AGE_MINUTES}" -print0 \
        | xargs -0 -n 500 rm -f 2>/dev/null
}

同时修改Java代码，使用try-finally确保锁文件在finally块中释放，搭配FileLock机制代替纯文件存在性判断做互斥。

6.2 操作系统层面

调整/tmp的挂载参数，限制inode使用上限：

1
2

# /etc/fstab 中为 /tmp 增加nr_inodes限制
tmpfs /tmp tmpfs defaults,size=4G,nr_inodes=500000 0 0

另外，如果业务允许，可以将频繁产生小文件的目录单独分区并分配更多inode：

1
2

# 创建文件系统时指定更多inode（默认情况下每16KB分配1个inode）
mkfs.ext4 -i 4096 /dev/vdb1  # 每4KB分配1个inode，inode数量变为默认的4倍

6.3 监控层面

强制要求所有生产服务器部署inode监控告警，与磁盘空间监控同等对待。告警阈值：inode使用率 > 80% 预警，> 90% 严重告警，> 95% 紧急告警。

同时建立巡检制度，每周检查一次所有生产服务器的inode使用趋势，提前发现异常增长：

# 巡检脚本示例
for host in $(cat /etc/ansible/hosts | grep '\[prod\]' -A 100 | grep -v '\['); do
    echo "=== $host ==="
    ssh $host "df -i / /data 2>/dev/null | grep -v '^Filesystem'"
done

6.4 清理工具加固

将cron清理脚本统一升级为带有结果校验的版本：

#!/bin/bash
# /usr/local/bin/cleanup_tmp_locks.sh
LOCK_DIR="/tmp"
PATTERN=".trade_lock_*"
MAX_AGE="+1"
BATCH_SIZE=500
ERROR_LOG="/var/log/tmp_cleanup_error.log"

# 分批删除
DELETED=0
while IFS= read -r -d '' file; do
    rm -f "$file" && ((DELETED++))
done < <(find "$LOCK_DIR" -name "$PATTERN" -mtime "$MAX_AGE" -print0 2>/dev/null)

# 结果校验
REMAINING=$(find "$LOCK_DIR" -name "$PATTERN" -mtime "$MAX_AGE" 2>/dev/null | wc -l)

if [ "$REMAINING" -gt 0 ]; then
    echo "$(date): 清理不完整！已删除 $DELETED 个文件，仍有 $REMAINING 个过期文件未清理。" >> "$ERROR_LOG"
fi

七、总结

这次故障给我最大的教训是：运维监控不能只盯着"磁盘空间"这一个维度。

Linux文件系统中的inode和blocks是两个独立的资源。df -h只看blocks（数据块），df -i看inodes（索引节点）。很多运维工程师只关注前者，直到某天服务器磁盘"明明有空间却写不进去"才恍然大悟——原来还有inode这回事。

这次排查也让我意识到ARG_MAX这个内核参数在批量文件操作中的真实影响。日常运维中find -delete用得很多，通常不会出问题，但当文件数量达到百万级时，它就会成为隐藏的炸弹。xargs分批处理是一个简单而有效的解决方案，成本极低但能把系统稳定性提升一个量级。

最后，“能写文件的磁盘就是好磁盘"是一个危险的假设。生产环境中，inode的消耗通常比blocks更隐蔽、更难以发现，因为小文件对物理空间的占用微乎其微，但每个文件都必须消耗一个inode。对于频繁创建临时文件的应用，inode耗尽的速度可能远超你的想象。

一次Kafka消费者Rebalance风暴导致业务数据延迟2小时的排查实录

Thu, 25 Jun 2026 07:00:00 +0000

问题背景

凌晨 03:15，监控平台推送告警：订单实时处理链路中 Kafka Consumer Group order-realtime-processor 的消费延迟（Consumer Lag）飙升至 2300 万条，下游数据仓库的 T+0 实时看板数据停止更新，BI 同事反馈今天上午 9 点要汇报的数据完全拿不到。

这条链路是整个订单系统的核心——订单服务的每条状态变更（创建/支付/发货/签收/退款）都会写入 Kafka Topic order_status_change（30 分区，3 副本），由 6 个消费者实例组成的 Consumer Group 消费后写入 ClickHouse 宽表，供 BI 报表和数据看板查询。延迟意味着一线运营和财务都无法看到最新的业务数据。

凌晨是我方值班，接到电话后立刻开始排查。

故障现象

初步检查发现几个关键异常：

1. Consumer Lag 曲线异常

打开 Kafka 监控（用的是 Burrow + Grafana），Consumer Lag 图表显示从 02:48 开始，Lag 从正常的 200~500 条开始陡峭爬升，到 03:15 时已经接近 2300 万，曲线几乎没有回落趋势。

# 通过 kafka-consumer-groups 查看具体 lag
$ kafka-consumer-groups --bootstrap-server kafka-broker-1:9092 \
  --group order-realtime-processor --describe

GROUP                    TOPIC              PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG
order-realtime-processor order_status_change 0          15233456780    15256689120     23232340
order-realtime-processor order_status_change 1          15211234560    15234456900     23222340
...

所有 30 个分区的 lag 都接近 2300 万，说明不是单个分区热点问题，而是整个 Consumer Group 集体"罢工"了一段时间。

2. Consumer Group 状态不稳定

Consumer Group 的成员列表在 Burrow 中频繁变化，每隔 2~3 分钟就能观察到一次 Rebalance 事件：

NOTICE [2026-06-25 02:48:12] Group order-realtime-processor REBALANCE: 
  member-1 left group, reassigning partitions
NOTICE [2026-06-25 02:49:33] Group order-realtime-processor REBALANCE: 
  member-3 left group, reassigning partitions
NOTICE [2026-06-25 02:51:56] Group order-realtime-processor REBALANCE: 
  member-5 joined group, reassigning partitions

持续的 Rebalance 意味着消费者在这个时间段内基本无法正常消费消息——每次 Rebalance 期间所有分区消费都会暂停。

3. 消费者实例 OOM 重启

查看 Kubernetes 中 6 个消费者 Pod 的日志，发现其中 3 个在 02:45 到 03:10 之间反复重启：

2026-06-25 02:45:23.456 WARN  [Consumer clientId=consumer-order-realtime-3] 
  This member will leave the group because consumer poll timeout has expired. 
  This means the time between subsequent calls to poll() was longer than the 
  configured max.poll.interval.ms, which typically implies that the poll loop 
  is spending too much time processing messages.

2026-06-25 02:45:23.789 INFO  [Consumer clientId=consumer-order-realtime-3] 
  Member consumer-order-realtime-3 sending LeaveGroup request to coordinator

关键：消费者因为两次 poll() 调用间隔超过了 max.poll.interval.ms（默认 5 分钟），被 Group Coordinator 主动踢出，触发了 Rebalance。

排查过程

第一步：确认消费逻辑是否有死循环或慢处理

先拉取消费者 Pod 的最近一次 GC 日志和 JVM 堆栈：

# 查看 GC 情况
$ kubectl logs order-consumer-3 --tail=500 | grep "GC"

2026-06-25 02:44:18.123 [GC (Allocation Failure)] 1254K->984772K(2048M), 0.452s
2026-06-25 02:44:45.567 [Full GC] 1876543K->1592340K(2048M), 12.345s
2026-06-25 02:44:58.234 [Full GC] 1892345K->1792340K(2048M), 15.234s

Full GC 耗时 12~15 秒，堆内存几乎全部占用（堆上限 2GB，老年代接近 1.8GB），GC 之后没有明显释放。典型的内存泄漏导致 GC 阻塞，处理时间被无限拉长。

1
2

# 查看堆栈确认卡在哪里
$ kubectl exec order-consumer-3 -- jstack $(pidof java) | head -200

堆栈显示大量线程卡在 HashMap.put() 和 ArrayList.add() 操作上，调用链指向业务代码的 OrderEventAggregator.aggregateByCity() 方法。

第二步：定位内存泄漏的根因

查看 OrderEventAggregator 的源码：

public class OrderEventAggregator {
    
    // 问题代码：用于按城市聚合订单金额的 Map 没有清理机制
    private final Map<String, BigDecimal> cityAmountMap = new HashMap<>();
    
    public void aggregateByCity(OrderEvent event) {
        String city = event.getCity();
        BigDecimal amount = event.getAmount();
        
        cityAmountMap.merge(city, amount, BigDecimal::add);
        
        // 每批处理完后写入 ClickHouse，但 Map 永远不清空！
        if (batchCount >= batchSize) {
            writeToClickHouse(cityAmountMap);
            batchCount = 0;
            // BUG: 这里应该 cityAmountMap.clear()，但被遗漏了
        }
    }
}

这个 cityAmountMap 以城市名为 key，每来一条订单就累加金额。问题是业务跑了几个月，城市维度越来越多（市级/区级/县级加起来上千个），而且每次 writeToClickHouse 之后忘了调用 clear()，导致 Map 无限膨胀。

几个月的订单数据累积下来，cityAmountMap 里每个城市的 BigDecimal 值越来越大，最终撑爆了 2GB 的堆。

第三步：为什么 Rebalance 会持续震荡？

这里有个典型的 Kafka Consumer 配置冲突问题。看一下消费者的配置：

# 问题配置组合
max.poll.records=2000          # 每批拉取大量消息
max.poll.interval.ms=300000    # 两次 poll 间隔上限 5 分钟
session.timeout.ms=30000       # 心跳超时 30 秒
heartbeat.interval.ms=3000     # 心跳间隔 3 秒
enable.auto.commit=false       # 手动提交

当内存接近爆满时，消费者处理 2000 条消息变得越来越慢，从正常的 8~10 秒逐渐拉长到几十秒甚至超出一分钟。更致命的是 Full GC 停顿时消费者线程被挂起：

GC 停顿 15 秒 → 心跳线程无法发送 heartbeat → session.timeout.ms 30 秒内没收到心跳 → Group Coordinator 认为消费者挂掉 → 触发 Rebalance
Rebalance 完成后分区重新分配 → 消费者重新开始 poll，又拉回 2000 条消息 → 处理中又触发 Full GC → 心跳又超时 → 又开始新一轮 Rebalance

这就形成了"消费 → Full GC → 心跳超时 → Rebalance → 重新消费 → Full GC"的死循环，每次 Rebalance 期间所有 30 个分区都停止消费，而生产者持续写入，Lag 自然就爆炸式增长。

第四步：确认是否有新增城市维度导致数据膨胀

查 ClickHouse 看看 cityAmountMap 到底存了多少键：

SELECT 
    toDate(event_time) AS dt,
    uniqExact(city) AS city_count
FROM order_status_change 
WHERE dt >= '2026-06-01'
GROUP BY dt
ORDER BY dt DESC
LIMIT 10;

结果发现 6 月初城市维度才 800 多个，最近因为业务扩展到下沉市场 + 拆分区县级行政编码，已经膨胀到了 3400+ 个维度，每个维度的 BigDecimal 对象体积也在持续增长。

解决方案

紧急止血（凌晨 03:30 执行）

1. 重启消费者并降低单批拉取量

由于代码修复需要走 CI/CD 流程，先通过环境变量降低 max.poll.records 来快速止血：

# 修改 Deployment 环境变量
kubectl set env deployment/order-realtime-consumer \
  KAFKA_MAX_POLL_RECORDS=500

# 滚动重启
kubectl rollout restart deployment/order-realtime-consumer

500 条消息处理完大约 3~5 秒，即使有 Full GC 停顿也不会轻易超过 max.poll.interval.ms 的 5 分钟上限，Rebalance 旋涡被打破。

2. 临时调整 session.timeout.ms

同时把 session.timeout.ms 从 30s 上调到 60s，给 GC 停顿留出缓冲空间：

1
2

session.timeout.ms=60000
max.poll.records=500

重启后，Consumer Lag 曲线在 03:42 开始回落，到 04:12 恢复正常水平。

根治方案（当天上午完成）

1. 修复内存泄漏代码

public class OrderEventAggregator {
    
    // 使用有上限的 LRU Map
    private final Map<String, BigDecimal> cityAmountMap = 
        Collections.synchronizedMap(new LinkedHashMap<String, BigDecimal>(16, 0.75f, true) {
            @Override
            protected boolean removeEldestEntry(Map.Entry<String, BigDecimal> eldest) {
                return size() > 5000;  // 最多保留 5000 个城市维度
            }
        });
    
    public void aggregateByCity(OrderEvent event) {
        String city = event.getCity();
        BigDecimal amount = event.getAmount();
        
        cityAmountMap.merge(city, amount, BigDecimal::add);
        
        if (batchCount >= batchSize) {
            writeToClickHouse(new HashMap<>(cityAmountMap));
            cityAmountMap.clear();  // 关键修复：写入后清空
            batchCount = 0;
        }
    }
}

两处改动：

用 LinkedHashMap + removeEldestEntry 增加容量上限，防止无限膨胀
每批写完 ClickHouse 后显式调用 clear() 清空 Map

2. 优化 Kafka Consumer 参数

# 推荐的生产配置
max.poll.records=500                   # 降低单批拉取量，加快处理速度
max.poll.interval.ms=600000            # 提升到 10 分钟，给 GC 兜底
session.timeout.ms=60000               # 60 秒心跳超时
heartbeat.interval.ms=10000            # 10 秒心跳间隔
max.partition.fetch.bytes=10485760     # 10MB 每分区拉取上限
enable.auto.commit=false               # 保持手动提交

关键调整逻辑：

max.poll.records 从 2000 降到 500：减少单批处理时间，避免卡在 poll() 处理块内
max.poll.interval.ms 从 300s 上调到 600s：即使 GC 停顿也能留出足够的时间窗口
session.timeout.ms 从 30s 上调到 60s：给 GC 引起的短暂心跳丢失留出容忍度

3. 增加 JVM 监控和 GC 告警

在 Prometheus 中补充了 JVM 相关告警规则：

groups:
  - name: kafka-consumer-jvm
    rules:
      - alert: ConsumerHighHeapUsage
        expr: jvm_memory_used_bytes{area="heap"} / jvm_memory_max_bytes{area="heap"} > 0.85
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Consumer {{ $labels.pod }} 堆内存使用率超过 85%"
          
      - alert: ConsumerFrequentFullGC
        expr: rate(jvm_gc_pause_seconds_count{action="end of major GC"}[5m]) > 2
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Consumer {{ $labels.pod }} Full GC 频率异常（>2次/5min）"

根因分析

这次事故表面上是 Kafka Rebalance 风暴导致消费延迟，但本质上有两层根因：

直接原因：OrderEventAggregator 中的 cityAmountMap 缺少清理机制，随着业务城市维度增长，Map 中累积的数据量超过 JVM 堆上限，触发频繁 Full GC。Full GC 停顿导致消费者心跳超时，触发 Rebalance，而 Rebalance 期间消费者被踢出后重新加入又会拉取新一批消息继续触发 GC，形成恶性循环。

配置层面：max.poll.records=2000 与 session.timeout.ms=30000 的组合过于激进。当消费者处理能力因 GC 下降时，2000 条消息的处理时间远超预期，而 30 秒的心跳超时没有给 GC 停顿留出任何缓冲空间。

流程层面：代码中没有对 Map/Set/List 等集合型成员变量做容量上限保护，Code Review 时只关注了业务逻辑正确性，没有关注资源使用风险。同时 JVM 堆内存使用率一直偏高但没有告警，属于监控盲区。

预防措施

1. 代码规范层面

所有有状态的 Bean（如 Aggregator/Accumulator/Collector）中使用的集合类成员变量必须设置容量上限或显式清理逻辑
Code Review Checklist 增加"资源泄露检查"专项：集合类是否有限制、流/连接是否正确关闭、本地缓存是否有过期策略

2. 配置规范层面

制定 Kafka Consumer 参数配置基准：
- max.poll.records 建议 200~500（视单条消息处理复杂度调整）
- session.timeout.ms 至少为 GC 预期停顿的 3 倍以上
- max.poll.interval.ms 至少为单批最大处理时间的 2 倍
所有 Consumer Group 上线前须通过配置审查

3. 监控层面

对所有 Kafka Consumer Pod 补充 JVM 堆内存 / GC 频率 / GC 耗时的 Prometheus 监控
Consumer Lag 告警阈值从当前的 100 万条下调到 5 万条，更早发现消费异常
新增 Rebalance 频率告警：15 分钟内超过 3 次 Rebalance 即告警

4. 测试层面

在 CI 流水线中增加消费者压测步骤：用生产流量的 10 倍速率灌入测试 Topic，观察消费者内存增长曲线
跑 24 小时长期稳定性测试，观察内存是否持续上涨

总结

这次故障给我最大的教训是：Kafka 消费者不只是消息处理逻辑，更是一个需要精细调校的分布式组件。

三个看似独立的问题——内存泄漏、不合理的 Consumer 参数、缺失的 JVM 监控——在凌晨 02:48 不约而同地交汇在一起，形成了一个从内存逐步溢出到集群级消费瘫痪的连锁反应。

过往我们的关注点总是在 Consumer Lag 这个结果指标上，当 Lag 飙升时第一反应是"是不是生产者突发流量"。但这次事故说明，消费端的处理能力衰减同样是导致 Lag 的重要原因，而这种衰减往往是渐进式的——内存泄漏不是一瞬间发生的，而是日积月累的，直到某个临界点被突破，所有预警信号同时出现。

运维同学在接入 Kafka 时，Consumer 的参数配置不应该只抄一个"常见配置"就上线，而应该根据自己的消息处理逻辑做针对性调优。尤其是 max.poll.records、session.timeout.ms、max.poll.interval.ms 这三个参数的关系一定要理解透——它们共同决定了消费者在处理能力波动时是会触发 Rebalance 还是能自我恢复。

一次MySQL主从同步因大事务延迟导致订单数据不一致的排查实录

Mon, 22 Jun 2026 07:00:00 +0000

问题背景

周一早上 9 点 17 分，我刚端着咖啡走到工位，客服总监的电话就打了过来：“有客户投诉，昨天凌晨下的订单到现在还显示’待付款’，但钱已经扣了。再这样下去要上 12315 了。”

我们做的是 B2B 商城系统，订单链路是标准的"主库写入 → 从库读取"分离架构。业务侧前端订单查询全部走从库，结算、支付回调走主库。按理说，正常的几条订单写入，从库延迟顶多几百毫秒。

但这次不一样——运维群里同事反馈，从库 Seconds_Behind_Master 指标在凌晨 2 点之后就开始飘红，目前还在 40 分钟以上。也就是说，用户今天看到的订单状态，其实是凌晨 2 点之前的老数据。

影响范围：所有 C 端订单查询接口（订单列表、订单详情、物流状态）。涉及用户：约 1.2 万。紧急程度：P1（业务受损，尚未扩散到资损，但已接到投诉）。

故障现象

1. 从库延迟（Seconds_Behind_Master）

从凌晨 2:00 开始延迟曲线从 0.5s 拉升，到 9:00 仍是 2400s（40 分钟），曲线呈"阶梯式上升"：

02:00  delay=0.8s
02:10  delay=45s
02:30  delay=320s
03:00  delay=980s
05:00  delay=2100s
07:00  delay=2350s
09:00  delay=2412s

2. 主库写入流量

Com_update 计数显示凌晨 1:55 - 2:35 之间有 2.3 亿行 UPDATE 操作集中在主库执行，binlog 产生量约 8.6 GB。

3. 错误日志

从库的 mysqld.log 里有大量 Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage 警告——这说明从库尝试一次性应用一个超大事务时，binlog cache 不够用。

4. 业务报错

部分订单详情接口偶发返回 ERROR 1213 (40001): Deadlock found when trying to get lock，但这是次要现象，主要问题还是延迟。

排查过程

第一步：确认从库状态

登录从库查看复制状态：

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Log_File: mysql-bin.000128
              Read_Master_Log_Pos: 523847212
                 Relay_Log_File: relay-bin.000089
              Relay_Log_Pos: 480123441
      Seconds_Behind_Master: 2412
Slave_SQL_Running_State: Reading event from the relay log

Seconds_Behind_Master 还在涨，但 Slave_SQL_Running_State 显示"Reading event from the relay log"——意味着 SQL 线程并没有卡死，是在持续追。这是典型的"大事务回放慢"症状。

第二步：定位主库上的大事务

登录主库，用 mysqlbinlog 工具扫 binlog 找最长的几个事务：

mysqlbinlog --no-defaults -v -v \
  --base64-output=DECODE-ROWS \
  --start-datetime="2026-06-22 01:55:00" \
  --stop-datetime="2026-06-22 02:35:00" \
  mysql-bin.000127 mysql-bin.000128 | head -200

很快就看到了一段超长事务——一个跑批任务（订单超时自动关闭）在 1:57 开始，到 2:28 结束，持续 31 分钟，涉及 800 万行订单的 UPDATE：

# at 12345678
#260622  1:57:14 server id 1  end_log_pos 12345890 CRC32 0xabcdef   Query thread_id=123456
SET TIMESTAMP=1761119834
BEGIN
...
# at 12345900
#260622  1:57:14 server id 1  end_log_pos 12346100  Table_map: `order`.`t_order` mapped to number 123
#260622  1:57:14 server id 1  end_log_pos 12346200  Update_rows: table id 123 flags: STMT_END_F
### UPDATE `order`.`t_order`
### WHERE
###   @1=1000001
###   @2='PENDING_PAY'
###   @3='2026-06-21 10:23:11'
###   ...
### SET
###   @1=1000001
###   @2='CLOSED_TIMEOUT'
###   @3='2026-06-22 01:57:14'
... (此处省略约 800 万行类似的 UPDATE)

主库这一个事务生成的 binlog 就有 6.2 GB。

第三步：分析大事务为何慢

MySQL 主从复制的原理是：从库 SQL 线程拿到主库的 binlog event 后，单线程回放（默认配置下，MySQL 5.7 没有开启 MTS 多线程回放）。一个事务从主库传到从库，从库必须按顺序完整回放完才能进入下一个事务。

主库上，800 万行 UPDATE 因为聚簇索引和锁的原因花 31 分钟；从库上同样要 800 万行 UPDATE，但因为：

从库硬件配置略低（IOPS 只有主库的 60%）；
sync_binlog=1、innodb_flush_log_at_trx_commit=1 的双 1 配置让每行都强制刷盘；
SQL 线程是单线程，无法并行回放。

所以从库回放速度大约是主库的 1/3 —— 自然就形成了 40 分钟的延迟。

第四步：分析这个事务的合理性

继续看那段 binlog，发现这个"订单超时关闭"任务的 SQL 模式是：

-- 伪代码
BEGIN;
UPDATE t_order SET status='CLOSED_TIMEOUT', close_time=NOW()
WHERE status='PENDING_PAY' AND create_time < DATE_SUB(NOW(), INTERVAL 30 MINUTE);
COMMIT;

单条 SQL 一次更新 800 万行。问题就出在这里——开发同学为了图省事，用一条大 SQL 完成全表批量更新。

解决方案

紧急止血

1. 业务切流：把订单查询从从库切回主库（虽然主库压力大，但此刻一致性更重要）：

# 在 Nginx upstream 中临时调整
upstream order_query {
    # 临时注释从库
    # server 10.0.10.22:3306;
    server 10.0.10.21:3306 max_fails=2 fail_timeout=10s;
}

2. 强制让从库跳过这个大事务（不推荐为常规操作，但紧急情况下可以）：

-- 评估一致性影响后，决定让从库直接跳过该超大事务
-- 因为这个事务是"超时关闭"，本身就是幂等操作，重新跑批会再处理一次
mysql> STOP SLAVE;
mysql> SET GLOBAL sql_slave_skip_counter = 1;
mysql> START SLAVE;

但 SET GLOBAL sql_slave_skip_counter = 1 只能跳一个 event。我这里大事务跨多个文件，最终选择的是：让从库慢慢追回（保守但安全）。

3. 临时调大从库相关参数，提升回放速度：

# my.cnf
innodb_flush_log_at_trx_commit = 2
sync_binlog = 0
slave_parallel_workers = 8
slave_parallel_type = LOGICAL_CLOCK

重启从库后，回放速度从 5000 行/秒提升到 18000 行/秒，2 小时内追平延迟。

长期修复

1. 业务侧：大事务拆小

推动开发同学把"订单超时关闭"改为分批 + 循环：

// 优化后的跑批代码
int batchSize = 1000;
int affected;
do {
    // 每次只更新 1000 行
    affected = jdbcTemplate.update(
        "UPDATE t_order " +
        "SET status='CLOSED_TIMEOUT', close_time=NOW() " +
        "WHERE status='PENDING_PAY' " +
        "AND create_time < ? " +
        "LIMIT " + batchSize,
        expireTime
    );
    // 每批之间 sleep 100ms，给从库喘息
    Thread.sleep(100);
} while (affected > 0);

这样每个事务只更新 1000 行，单事务 binlog 不到 1 MB，从库回放几乎无感知。

2. MySQL 配置：开启多线程复制

从库永久开启 MTS：

1
2
3

slave_parallel_workers = 16
slave_parallel_type = LOGICAL_CLOCK
slave_preserve_commit_order = ON

3. 监控告警

添加 Seconds_Behind_Master > 60s 的告警，避免延迟 40 分钟才发现。

4. 架构优化

考虑订单读多写少、且对一致性要求高的特点，引入 ProxySQL 做读写分离，并支持强制走主库的功能（针对订单详情这种对一致性敏感的场景）。

根因分析

这个问题的根本原因是业务开发同学没有"主从复制延迟"的意识，把单实例 MySQL 时代的"一条大 SQL 搞定一切"的习惯带到了主从架构下。

具体三个直接原因：

单条 UPDATE 影响 800 万行 —— 远超单事务合理大小（经验值：单事务 1 万行以内）；
从库默认单线程回放 —— MySQL 5.7 默认 slave_parallel_workers=0，大事务没有并行能力；
未配置主从延迟告警 —— 凌晨 2:00 延迟就开始累积，但 7 小时后才被业务反馈发现。

预防措施

1. 编码规范：禁止大事务

在 Code Review Checklist 中加入：单事务 DML 行数 ≤ 5000，binlog 大小 ≤ 10 MB。可以加 SQL 拦截器：

-- 生产环境拒绝大事务的拦截逻辑（伪代码）
-- 当 row_examined > 10000 时直接 kill
SET @max_rows = 10000;
-- 通过 Performance Schema 或审计插件实现

2. 主从延迟全链路监控

Seconds_Behind_Master 只是粗略值。更准确的方案是使用 pt-heartbeat 工具在主库每秒写一个时间戳，从库对比时间差得到精确延迟：

# 主库
pt-heartbeat -D test --update -h 10.0.10.21
# 从库
pt-heartbeat -D test --monitor -h 10.0.10.22

3. 跑批任务错峰执行

把"订单超时关闭"这种大跑批放在业务低峰（比如凌晨 3:30 - 5:00），并且增加单批 sleep，避免集中打主库。

4. 关键业务强制走主库

对一致性要求极高的接口（订单详情、支付结果、账户余额），在 ProxySQL 规则里强制 mysql-default_session_target_host=master，不走从库。

5. 定期演练

每季度做一次"主库宕机，从库强制提升"演练，验证从库是否能快速接管；同时也验证大事务场景下从库的恢复能力。

总结

这次故障的教训可以总结成三句话：

第一，MySQL 主从架构下，“单条大 SQL"是定时炸弹。开发同学需要从单实例思维切换到"主从延迟敏感"思维，养成"分批 + 循环"的习惯。

第二，监控不能只看"服务是否在线”。Slave_IO_Running=Yes 和 Slave_SQL_Running=Yes 都是 Yes，但延迟可能已经几小时。Seconds_Behind_Master 告警必须配置，且阈值要合理。

第三，对一致性敏感的业务，不要无脑走读写分离。订单详情、支付结果这类场景，宁可让主库扛一部分读流量，也要保证数据一致性。读写分离的规则要细化到表/接口级别，不能一刀切。

最后，事后我和开发 leader 约法三章：所有大表 DML 必须经过 DBA Review，所有新上线的定时任务必须压测确认 binlog 体积。规则定下来了，但更重要的是执行。这次故障的客户投诉虽然已经处理完毕，但给了我们一个深刻的提醒：主从架构不是"装上就完事"的银弹，它是需要业务、运维、DBA 一起维护的契约。

一次Docker容器OOM引发的服务雪崩排查实录

Fri, 19 Jul 2024 08:00:00 +0000

问题背景

周三晚上 8 点 23 分，钉钉群里炸了锅。

“发货中心挂了，后台全部 502！"——运营同事的消息连着发了 5 条。紧接着，运维监控大屏上 3 个核心服务的健康检查指示灯全部由绿转红。

我们平台是一个电商 SaaS 系统，发货服务（delivery-service）是核心链路里的一环，负责生成电子面单、调用快递接口、更新订单状态。晚 8 点到 10 点是发货高峰期，如果这个点挂了——当天的订单基本全积压。

技术栈：Docker Swarm 管理集群，每个服务至少 3 个副本。发货服务是 Java 11 + Spring Boot 2.7，跑在 8 台 16 核 32G 的物理机上。

紧急程度：P0（核心业务中断），运维同事已经开始手动重启容器，但问题是——重启完不到 3 分钟又崩了。

故障现象

第一波告警来自 Nginx 反向代理层：

1
2

2026-06-18 20:23:15 [error] upstream prematurely closed connection while reading response header from upstream
2026-06-18 20:23:16 [error] connect() failed (111: Connection refused) while connecting to upstream

同时，Prometheus 监控面板显示 delivery-service 的可用副本数在 3 → 2 → 1 → 0 之间快速跳变：

20:23：3 个副本正常运行
20:24：delivery-service-2 状态变为 unhealthy，被 Swarm 调度器踢出
20:25：delivery-service-1 也挂了，仅剩 delivery-service-3
20:27：最后一个副本也倒下，所有请求 502

登上管理节点 docker service ps delivery-service 一看：

ID       NAME                  NODE     DESIRED STATE   CURRENT STATE          ERROR
x7a2f3   delivery-service.1    node03   Running         Running 12 seconds ago
8b3k9m   delivery-service.1    node03   Shutdown        Failed 15 seconds ago  "task: non-zero exit (137)"
p1q5r7   delivery-service.2    node05   Running         Running 8 seconds ago
n4j6w8   delivery-service.2    node05   Shutdown        Failed 10 seconds ago  "task: non-zero exit (137)"

Exit code 137 是 Docker 世界的死亡代码——容器被 OOM Killer 干掉了（137 = 128 + 9，SIGKILL）。

更让人头疼的是：delivery-service 挂了之后，同一台宿主机上的 order-service 和 notify-service 也开始出现间歇性 502。问题在蔓延。

排查过程

第一步：止血——先让服务活过来

盲目重启没用，每次启动不到 3 分钟就挂。当务之急是把 delivery-service 的副本数临时扩容，让它至少能扛到我们找到根因：

1
2

# 先用更多副本来分摊压力，争取排查时间
docker service scale delivery-service=6

但这是饮鸩止渴——如果问题是内存泄漏，副本越多，整个集群的内存压力越大。

果然，扩容到 6 个之后，宿主机 node03 上的 order-service 容器直接被 OOM Kill 了。这下确定了一个事实：问题不只是 delivery-service 本身，宿主机的内存也在吃紧。

第二步：看 OOM 日志——谁在吃内存

1
2

# 查看系统 OOM 日志
dmesg -T | grep -i oom | tail -20

输出触目惊心：

[Wed Jun 18 20:23:45 2026] oom-kill:constraint=CONSTRAINT_MEMCG,
  oom_memcg=/docker/abc123def456,
  task_memcg=/docker/abc123def456,
  task=java, pid=28471, uid=0

[Wed Jun 18 20:23:45 2026] Memory cgroup out of memory: Killed process 28471 (java)
  total-vm:12582912kB, anon-rss:9467808kB, file-rss:0kB, shmem-rss:0kB
  oom_score_adj:0

关键数据：anon-rss:9467808kB——这个 Java 进程的常驻内存占了 9.2 GB！

再看容器级别的内存曲线：

1
2
3

# 查看被 Kill 容器的资源使用历史
docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}" \
  | grep delivery

正常启动时，delivery-service 内存使用约 1.2 GB。但每处理一批发货请求，内存就涨一点，从不回落。启动 3 分钟后直奔 9 GB，触发了 Swarm 为这个服务设置的 --memory=10g 上限（已逼近宿主机 32G 总内存的警戒线）。

第三步：抓 Java 堆——确认泄漏对象

在容器还没挂的时候（黄金窗口只有启动后的 2 分钟内），紧急上去抓堆：

# 进入容器
docker exec -it delivery-service.3.abc123 /bin/bash

# 抓 heap dump
jmap -dump:live,format=b,file=/tmp/heap.hprof 1

# 快速看下 top 对象
jmap -histo:live 1 | head -30

histo 输出前三名：

 num     #instances         #bytes  class name
   1:       3284512      262760960  [B
   2:       1558327      174533424  java.util.LinkedHashMap$Entry
   3:       1539820      123185600  com.xxx.delivery.cache.WaybillCache

WaybillCache 这个自定义缓存对象有 150 万个实例，占了约 120MB。但真正吞内存的是 [B（字节数组）——3.2 亿字节、约 250MB 的 byte[]。

WaybillCache 里每个对象都持有一个 byte[]（快递公司返回的面单 PDF 数据），一个面单 PDF 约 80KB。正常业务场景下，面单生成后应该被序列化到 OSS 并从内存中释放，但现在它们全滞留在了 LinkedHashMap 里。

第四步：读代码——缓存为什么不清

找到 WaybillCache 的实现：

@Component
public class WaybillCache {
    // 问题代码：没有大小限制，没有过期策略
    private static final Map<String, byte[]> CACHE = 
        new LinkedHashMap<>();
    
    public void put(String orderNo, byte[] pdfData) {
        CACHE.put(orderNo, pdfData);
    }
    
    public byte[] get(String orderNo) {
        return CACHE.get(orderNo);
    }
    // 没有 remove()，没有 evict()，没有 TTL
}

根因一目了然：

LinkedHashMap 没有任何淘汰策略——没有 removeEldestEntry()，没有最大容量
写入后从不删除——面单生成后存在 Map 里，直到 JVM OOM
没有 TTL——即使订单已经发货完毕，缓存里的 PDF 数据永远不释放

每次发货请求都往这个 Map 里 put 一次。晚高峰每秒 200 单的发货量，1 分钟就是 12000 条记录 × 80KB ≈ 960MB。3 分钟直接撑爆 10G 内存限制。

第五步：验证其他宿主机

检查其他 7 台机器的 OOM 日志，发现 node05、node07 也在同一时刻触发了 OOM。问题不是单机故障，是整个 delivery-service 集群的系统性内存泄漏。

而且，OOM Killer 在回收 delivery-service 时，同一台宿主机的其他容器也会被牵连——内核 OOM 打分机制下，order-service 的 oom_score 也不低，所以出现了连带 Kill。

解决方案

1. 紧急修复——代码热修复 + 重启

运维同事紧急拉了一个 hotfix 分支，把 LinkedHashMap 改成基于 Caffeine 的有界缓存：

import com.github.benmanes.caffeine.cache.Cache;
import com.github.benmanes.caffeine.cache.Caffeine;
import java.util.concurrent.TimeUnit;

@Component
public class WaybillCache {
    private final Cache<String, byte[]> cache = Caffeine.newBuilder()
        .maximumSize(1000)                  // 最多存 1000 条
        .expireAfterWrite(5, TimeUnit.MINUTES)  // 5 分钟过期
        .removalListener((key, value, cause) -> {
            log.info("WaybillCache evicted: {}, cause: {}", key, cause);
        })
        .build();

    public void put(String orderNo, byte[] pdfData) {
        cache.put(orderNo, pdfData);
    }

    public byte[] get(String orderNo) {
        return cache.getIfPresent(orderNo);
    }
}

CI/CD 流水线跑完，重新部署：

# 滚动更新
docker service update --image registry.xxx.com/delivery-service:hotfix-v2 \
  --limit-memory 8g --limit-memory-reservation 4g delivery-service

# 观察启动
docker service ps delivery-service --no-trunc

2. 容器层加固

在 docker-compose / stack 文件里加了硬限制：

services:
  delivery-service:
    image: registry.xxx.com/delivery-service:latest
    deploy:
      replicas: 3
      resources:
        limits:
          memory: 8G        # 硬上限
        reservations:
          memory: 4G        # 软预留
    environment:
      - JAVA_OPTS=-Xms2g -Xmx6g -XX:+UseG1GC
          -XX:MaxGCPauseMillis=200
          -XX:+HeapDumpOnOutOfMemoryError
          -XX:HeapDumpPath=/tmp/heapdump.hprof

要点说明：

-Xmx6g 给 JVM 堆设了明确上限，留 2G 给堆外内存和 OS；
-XX:+HeapDumpOnOutOfMemoryError：再出问题自动 dump，省掉了上去手动 jmap 的黄金窗口压力；
容器 memory: 8G 硬限制，超过直接 Kill，不拖累宿主机上其他容器。

3. 监控告警

在 Prometheus 里加了容器级别的内存告警规则：

groups:
  - name: container_memory
    rules:
      - alert: ContainerMemoryHigh
        expr: container_memory_working_set_bytes{name=~"delivery-service.*"} 
              / container_spec_memory_limit_bytes > 0.8
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "delivery-service 内存使用超过 80%"

      - alert: ContainerOOMKilled
        expr: rate(container_oom_events_total[5m]) > 0
        labels:
          severity: critical
        annotations:
          summary: "检测到容器被 OOM Kill"

根因分析

直接原因：WaybillCache 使用无界 LinkedHashMap 做面单 PDF 数据缓存，写入后从不淘汰，高峰流量下内存持续线性增长直至 OOM。

深层原因有三层：

代码层面：开发同学对缓存基础组件缺乏敬畏，“一个 Map 就是缓存"的认知导致没有考虑淘汰策略和容量上限。任何缓存系统必须回答三个问题：最大容量多少？什么条件下淘汰？淘汰策略是什么？ 用 LinkedHashMap 不代表它就是安全的缓存。
流程层面：这个 WaybillCache 是一个月前由一位离职同事写的，Code Review 时没有人关注缓存的容量和淘汰策略。CR 只看了业务逻辑对不对，没看资源安全和边界条件。
运维层面：容器 OOM 告警缺失。直到用户报障、监控大屏亮红灯才知道出了问题。晚 8 点之前其实内存就在涨了，如果 70% 的时候就有告警，完全可以提前介入。

预防措施

缓存规范：团队内部定了缓存使用规范——禁止裸用 HashMap / LinkedHashMap 做缓存；必须使用有界缓存（Caffeine / Guava Cache），强制设置 maximumSize 和 expireAfterWrite。在 CI 里加了简单的静态检查规则，扫描 new LinkedHashMap 和 new HashMap 出现在 Cache 相关类里会报警。
JVM 参数标准化：所有 Java 服务统一带上 -XX:+HeapDumpOnOutOfMemoryError，生产环境预留至少 20% 容器内存给堆外。
容器资源限制白盒化：在 CI 打包阶段自动校验 Dockerfile 或编排文件里是否声明了 resources.limits.memory，没声明的不允许上线。
监控前置：每条业务线至少配置 3 条基础告警——CPU > 80%、内存 > 80%、容器重启次数 > 0。告警阈值在代码合入 production 分支时自动生成 Ansible playbook 推送到 Prometheus。
压测 + 内存 Profile：所有涉及缓存的模块，要求在上线前做一次至少 30 分钟的压测，附带 JVM 内存趋势图，确认没有持续增长。

总结

这次故障从发现到修复历时 47 分钟，影响订单发货约 12000 单。教训非常深刻：

第一，容器给运维带来了便利，也带来了"邻居效应”。以前物理机部署，一个应用内存泄漏大不了重启自己。Docker 环境下，一个容器的无限制增长会拖累整个宿主机的内存池，OOM Killer 的连带伤害让问题变成雪崩。

第二，缓存不是"先跑起来再优化"的东西。无界缓存在生产环境就是定时炸弹，只是你不知道引线有多长。晚高峰就是那根火柴。

第三，OOM 排查的顺序很重要：先看 dmesg 确认是 OOM → 看 docker stats 确定是哪个容器 → jmap 抓堆确定是什么对象泄漏 → 读代码定位根因。不要跳步，不要上来就怀疑网络、怀疑数据库，exit code 137 就是最诚实的线索。

运维圈有一句话：“没有容量上限的缓存，就是内存泄漏的另一种写法。”

一次SSL证书过期导致内网HTTPS服务全面中断的排查实录

Thu, 05 Sep 2024 08:30:00 +0000

问题背景

某周四早上 8:30，帮助台工单系统开始涌入大量相同类型的工单：员工反映多个内网系统无法访问，浏览器提示"您的连接不是私密连接"或"证书无效"，点击"高级"可以看到错误信息 NET::ERR_CERT_DATE_INVALID。

受影响的系统包括：内网 GitLab、Jira、Confluence、Jenkins、内部文档管理系统等约 12 个 HTTPS 服务，全部托管在内网环境中。

故障现象

浏览器打开内网 HTTPS 地址时报 SSL 证书错误：NET::ERR_CERT_DATE_INVALID
Chrome 错误详情：服务器证书已过期，证书有效期显示截止日期为昨日
影响约 12 个内网 HTTPS 服务
使用 HTTP（非 HTTPS）的内网服务不受影响
外网面向公众的 HTTPS 服务（Let’s Encrypt 证书）不受影响

排查过程

第一步：确认证书过期情况

用 openssl 工具快速检查几个受影响服务的证书：

`1`	`echo \| openssl s_client -connect gitlab.internal.company.com:443 -servername gitlab.internal.company.com 2>/dev/null \| openssl x509 -noout -dates`

输出：

1
2

notBefore=Sep  5 00:00:00 2021 GMT
notAfter=Sep  4 23:59:59 2024 GMT

证书昨日（2024-09-04）到期，今天（2024-09-05）证书已失效。

再检查其他几个受影响的服务：

for host in gitlab jira confluence jenkins docs; do
    echo -n "$host.internal.company.com: "
    echo | openssl s_client -connect "$host.internal.company.com:443" 2>/dev/null | openssl x509 -noout -enddate 2>/dev/null
done

输出：

gitlab.internal.company.com:       notAfter=Sep  4 23:59:59 2024 GMT
jira.internal.company.com:         notAfter=Sep  4 23:59:59 2024 GMT
confluence.internal.company.com:   notAfter=Sep  4 23:59:59 2024 GMT
jenkins.internal.company.com:      notAfter=Sep  4 23:59:59 2024 GMT
docs.internal.company.com:         notAfter=Sep  4 23:59:59 2024 GMT

所有受影响的服务证书到期日期完全一致：2024年9月4日。这说明这 12 个服务使用的是同一张证书，而不是各自独立的证书。

第二步：确认证书类型

`1`	`echo \| openssl s_client -connect gitlab.internal.company.com:443 2>/dev/null \| openssl x509 -noout -text \| grep -A5 "Subject Alternative Name"`

输出：

1
2
3

X509v3 Subject Alternative Name: 
    DNS:*.internal.company.com
    DNS:internal.company.com

这是一张 内网通配符证书（Wildcard Certificate），覆盖所有 *.internal.company.com 的子域名。证书由内部 CA（根证书已部署到公司所有终端的信任链）签发，3 年有效期，上一次签发是 2021 年 9 月，今天正好到期。

第三步：为什么没有收到到期预警？

翻查监控系统配置，发现：

Zabbix 中确实有 SSL 证书到期监控项，但只对公网域名（www.company.com、api.company.com 等）进行监控，内网域名没有加入监控列表
上一任运维工程师（已离职）当时签发这张证书时，没有在日历中设置到期提醒，也没有记录在运维手册中
邮件告警脚本存在，但 3 年前配置后从未验证过是否真正发出了告警

第四步：找到内部 CA

通过证书信息找到签发这张证书的内部 CA：

`1`	`echo \| openssl s_client -connect gitlab.internal.company.com:443 2>/dev/null \| openssl x509 -noout -issuer`

输出：

`1`	`issuer=C=CN, O=Company Internal CA, CN=Company Root CA G1`

查找 CA 证书和私钥的存放位置，询问了老员工，最终找到保存在一台运维管理服务器（mgmt-srv）上的 /etc/pki/internal-ca/ 目录下：

1
2

ls /etc/pki/internal-ca/
# ca.crt  ca.key  ca.srl  issued/

确认内部 CA 私钥存在且有效。

第五步：重新签发证书

重新生成一张 3 年有效期的通配符证书，这次改为 3 年并在交接文档中记录：

# 生成新的私钥
openssl genrsa -out /tmp/wildcard-internal.key 2048

# 生成 CSR（证书签名请求）
cat > /tmp/san.cnf << 'EOF'
[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[v3_req]
subjectAltName = @alt_names
[alt_names]
DNS.1 = *.internal.company.com
DNS.2 = internal.company.com
EOF

openssl req -new -key /tmp/wildcard-internal.key \
  -out /tmp/wildcard-internal.csr \
  -subj "/C=CN/O=Company/CN=*.internal.company.com" \
  -config /tmp/san.cnf

# 使用内部 CA 签发（有效期 3 年）
openssl x509 -req -in /tmp/wildcard-internal.csr \
  -CA /etc/pki/internal-ca/ca.crt \
  -CAkey /etc/pki/internal-ca/ca.key \
  -CAcreateserial \
  -out /tmp/wildcard-internal.crt \
  -days 1095 \
  -extensions v3_req \
  -extfile /tmp/san.cnf

# 验证新证书
openssl x509 -noout -dates -in /tmp/wildcard-internal.crt

输出：

1
2

notBefore=Sep  5 02:10:00 2024 GMT
notAfter=Sep  4 02:10:00 2027 GMT

第六步：更新各服务的证书

将新证书分发到所有受影响的服务器，并替换旧证书：

# 复制到各服务器（以 Nginx 为例）
scp /tmp/wildcard-internal.crt user@gitlab-server:/etc/nginx/ssl/internal.crt
scp /tmp/wildcard-internal.key user@gitlab-server:/etc/nginx/ssl/internal.key

# 重载 Nginx
ssh user@gitlab-server "nginx -t && nginx -s reload"

对所有 12 个服务逐一执行。约 40 分钟后，全部服务恢复正常。

解决方案总结

重签内部通配符证书（有效期至 2027-09-04）
更新所有 12 个内网 HTTPS 服务的证书文件并重载
在 Zabbix 中添加对内网域名的 SSL 证书到期监控（30 天、14 天、7 天分级告警）
建立证书台账，记录所有证书的域名、有效期、存放位置、签发时间

根因分析

根本原因是证书生命周期管理缺失：内网证书的签发、更新、到期预警没有纳入规范化的管理流程。负责人离职后，这段"历史知识"彻底断层，直到证书真正过期才被动发现。

预防措施

1. 全面的证书到期监控

# Zabbix 自定义监控项（检查证书到期天数）
#!/bin/bash
DOMAIN=$1
PORT=${2:-443}
DAYS=$(echo | openssl s_client -connect "$DOMAIN:$PORT" 2>/dev/null \
  | openssl x509 -noout -enddate 2>/dev/null \
  | sed 's/notAfter=//' \
  | xargs -I{} date -d "{}" +%s \
  | xargs -I{} bash -c 'echo $(( ($1 - $(date +%s)) / 86400 ))' - {})
echo $DAYS

将所有内网和外网 HTTPS 域名加入监控。

2. 建立证书台账

在内部 Wiki 或文档管理系统中记录所有证书信息，包括到期时间，设置日历提醒（提前 90 天、30 天各提醒一次）。

3. 考虑迁移到 ACME 协议自动续签

对内网环境，可以搭建内部 ACME 服务（如 step-ca），实现证书自动续签，从根本上消除手动管理的风险。

总结

证书管理是一项容易被遗忘但后果严重的运维工作。3 年有效期的证书，在签发后会很快淡出运维视野，直到某天突然"爆炸"。解决之道不是靠记忆力，而是靠自动化监控和标准化流程。

一次简单的证书过期，影响了 12 个系统、全公司近 300 名员工的工作效率，教训深刻。

一次K8s节点磁盘压力导致Pod批量驱逐的排查实录

Tue, 12 Mar 2024 10:00:00 +0000

问题背景

某日上午 10:00 左右，监控平台开始陆续推送 K8s 集群告警：多个 Pod 处于 Pending 或 Evicted 状态，部分服务出现间歇性不可用。

查看集群状态，发现有 3 个工作节点出现 DiskPressure 状态，kubelet 开始自动驱逐节点上的 Pod 以释放空间，导致相关服务的副本数不足，触发了监控告警。

集群为 K8s v1.26，节点操作系统为 CentOS 7，每个节点配置 100GB 系统盘（/ 分区）。

故障现象

kubectl get nodes 显示 3 个节点状态带有 DiskPressure 条件
受影响节点上的 Pod 被驱逐（Evicted），重新调度到其他节点后其他节点也逐渐出现磁盘压力
kubectl describe node <node-name> 显示：

1
2
3

Conditions:
  Type              Status  Reason             Message
  DiskPressure      True    KubeletHasDiskPressure  imagefs is available: 2% < 10%

被驱逐的 Pod 状态为 Evicted，大量积压：

1
2

kubectl get pods -A | grep Evicted | wc -l
# 输出：127

排查过程

第一步：查看节点磁盘使用情况

登录出现 DiskPressure 的节点（以 node-03 为例）：

df -h

输出：

1
2
3

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        97G   95G  1.8G  99% /
tmpfs            16G     0   16G   0% /dev/shm

系统盘使用率 99%！几乎满了。

第二步：找出磁盘占用大的目录

`1`	`du -sh /* 2>/dev/null \| sort -rh \| head -20`

输出：

1
2
3

42G     /var
38G     /var/log
...

/var/log 占用了 38GB！进入查看：

`1`	`du -sh /var/log/* \| sort -rh \| head -20`

输出：

1
2
3

35G     /var/log/containers
2.1G    /var/log/pods
890M    /var/log/messages

/var/log/containers 占用 35GB，这是容器日志目录。

第三步：分析容器日志目录

`1`	`ls -lhS /var/log/containers/ \| head -20`

发现有几个日志文件异常巨大：

1
2
3

-rw-r----- 1 root root 18G  Mar 12 09:55 business-api-xxx_default_business-api-xxxxxxx.log
-rw-r----- 1 root root  9G  Mar 12 09:48 data-sync-xxx_default_data-sync-xxxxxxx.log
-rw-r----- 1 root root 6.2G Mar 12 08:30 log-collector-xxx_kube-system_log-collector-xxxxxxx.log

business-api 这个容器的日志文件高达 18GB，data-sync 的日志 9GB。

第四步：查看 kubelet 日志轮转配置

K8s 的 kubelet 支持对容器日志进行自动轮转，相关参数为：

`1`	`cat /etc/kubernetes/kubelet-config.yaml \| grep -i log`

输出：

1
2

containerLogMaxSize: "10Mi"
containerLogMaxFiles: 5

等等——配置明明设置了单个日志文件最大 10MB，为什么实际文件有 18GB？

第五步：确认 kubelet 是否真正加载了该配置

`1`	`ps aux \| grep kubelet`

输出：

`1`	`/usr/bin/kubelet --config=/etc/kubernetes/kubelet-config.yaml ...`

看起来配置文件是加载了的，但再仔细检查配置文件：

`1`	`cat /etc/kubernetes/kubelet-config.yaml`

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
containerLogMaxSize: "10Mi"
containerLogMaxFiles: 5
evictionHard:
  memory.available: "200Mi"
  nodefs.available: "10%"
  imagefs.available: "10%"

配置看起来正确……但为什么没有生效？

第六步：深入排查日志轮转未生效的原因

查看 kubelet 的实际运行时日志：

`1`	`journalctl -u kubelet --since "2 hours ago" \| grep -i "log"`

发现一条警告：

`1`	`W0312 09:23:15.123456 1234 kubelet.go:567] "Failed to rotate container log" err="error truncating file: ..." containerID="..."`

日志轮转失败！原因是 error truncating file，进一步查看：

`1`	`journalctl -u kubelet --since "2 hours ago" \| grep -i "truncat"`

`1`	`W0312 ... "Failed to truncate log file" path="/var/log/containers/business-api-xxx.log" err="truncate /var/log/containers/business-api-xxx.log: read-only file system"`

关键信息：read-only file system，磁盘挂载为只读了！

`1`	`dmesg \| tail -50 \| grep -i "error\\|readonly\\|remount"`

1
2

[1234567.890] EXT4-fs error (device sda1): ext4_journal_check_start:61: Detected aborted journal
[1234567.891] EXT4-fs (sda1): Remounting filesystem read-only

根本原因找到了：磁盘写满 → 文件系统出错（journal abort）→ 内核自动将文件系统 remount 为只读 → kubelet 无法轮转日志文件 → 日志文件不断增大（等等，如果文件系统只读，为什么日志还能写入？）

再仔细看：发现这台节点上 business-api 容器使用了 hostPath 挂载，日志输出路径是 /data/logs/，挂载的是另一块数据盘（/dev/sdb），而 /dev/sdb 挂载的 /data 目录没有配置日志轮转，数据盘的日志一直增长，而我们之前找到的 18GB 日志文件是软链接，指向了 /data/logs/ 下的实际文件。

1
2

ls -la /var/log/containers/business-api-xxx.log
# lrwxrwxrwx ... /var/log/containers/business-api-xxx.log -> /data/logs/business-api/app.log

数据盘 /dev/sdb 也满了，但报错发生在系统盘 /dev/sda1。这是两个叠加的问题。

解决方案

立即处理

清理已驱逐的 Pod 记录（Evicted 状态的 Pod 不会自动清除）：

`1`	`kubectl get pods -A \| grep Evicted \| awk '{print $1, $2}' \| xargs -n2 kubectl delete pod -n`

清理超大日志文件（谨慎操作，先确认不影响业务）：

# 对于仍在写入的日志，不要直接 rm，使用截断方式
> /data/logs/business-api/app.log

# 或使用 truncate
truncate -s 0 /data/logs/business-api/app.log

修复系统盘只读问题（需要重启或 remount）：

1
2
3

# 运行 fsck（需要先 umount 或在 rescue 模式下操作）
# 在线 remount（临时恢复读写，不修复 journal 问题）
mount -o remount,rw /

长期修复

1. 为应用容器的 hostPath 日志添加 logrotate 配置：

# 创建 /etc/logrotate.d/business-api
cat > /etc/logrotate.d/business-api << 'EOF'
/data/logs/business-api/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    size 500M
    postrotate
        # 发送 SIGHUP 给应用重新打开日志文件（如应用支持）
        kill -HUP $(cat /var/run/business-api.pid) 2>/dev/null || true
    endscript
}
EOF

2. 对 K8s 容器日志设置合理的 size 限制和 TTL：

在应用的 K8s Deployment 中，使用 terminationMessagePolicy 和日志驱动层面控制。或推荐将应用日志输出到 stdout/stderr，由 kubelet 统一管理轮转（不使用 hostPath）。

3. 扩容数据盘并规划磁盘告警：

在磁盘使用率达到 70% 时告警，不等到 99% 再发现问题。

根因分析

两个问题叠加：

应用日志通过 hostPath 写入数据盘，且没有配置 logrotate，导致日志文件无限增长，最终耗尽数据盘空间
数据盘写满后的错误日志写到系统盘，导致系统盘也快速被填满，触发 EXT4 journal abort 和 read-only remount，引发 kubelet 日志轮转失败，进一步加速了磁盘占用

预防措施

所有使用 hostPath 挂载的应用必须配置 logrotate
容器日志优先使用 stdout/stderr + kubelet 自动轮转，不自行挂载日志目录
节点磁盘使用率告警阈值设置为 70%/85%/95% 三档
定期（每周）扫描所有节点上 /var/log/containers/ 和应用日志目录的大小

总结

K8s 集群中，Pod 驱逐事件往往是表象，真正的根因要深入到节点操作系统层面去排查。这次事件表明，日志管理是 K8s 运维中容易被忽视但影响显著的环节。无论是 kubelet 自带的日志轮转还是应用侧的 logrotate，都需要主动配置和验证，不能假设"默认会管好日志"。

一次Redis内存溢出导致缓存服务全部失效的排查实录

Wed, 22 Feb 2023 15:30:00 +0000

问题背景

某业务大促活动开始后约 2 小时，监控告警系统收到大量告警：

数据库（MySQL）慢查询数量骤增，P99 响应时间从 50ms 升至 8000ms
部分 API 接口 5xx 错误率达到 15%
Redis 实例的 rejected_connections 计数器快速增长

业务团队紧急联系运维排查，此时活动已进入高峰期，影响用户体验，需要快速定位并修复。

故障现象

Redis INFO 命令返回 used_memory 接近服务器总内存
Redis 日志中出现大量 OOM command not allowed when used memory > 'maxmemory' 错误
应用日志中 Redis 写操作报错：COMMAND NOT ALLOWED When Used Memory > 'maxmemory'
MySQL 慢查询日志急剧增多，大量查询耗时 5-10 秒
部分服务接口响应超时，用户请求报 504

排查过程

第一步：确认 Redis 状态

`1`	`redis-cli -h redis-prod-01 -p 6379 -a <password> INFO memory`

关键输出：

used_memory:8388557312          # 约 8GB
used_memory_human:7.81G
maxmemory:8589934592            # 8GB
maxmemory_human:8.00G
maxmemory_policy:noeviction     # ⚠️ 不淘汰策略
mem_fragmentation_ratio:1.23

Redis 已用内存 7.81GB，最大内存限制 8GB，使用率 97.7%，几乎满了。

关键发现：maxmemory_policy 为 noeviction，意味着当内存满时，Redis 不会主动淘汰任何键，而是直接拒绝所有写操作（包括 SET、HSET、LPUSH 等），返回 OOM 错误。

第二步：分析内存占用

查看 Redis 内存使用详情：

`1`	`redis-cli -h redis-prod-01 -p 6379 -a <password> MEMORY DOCTOR`

输出提示内存碎片率正常，但总体内存占用过高。

使用 DEBUG JMAP 或 redis-rdb-tools 分析大 Key：

1
2

# 扫描占用内存最多的 key（生产环境谨慎使用 KEYS，使用 SCAN 替代）
redis-cli -h redis-prod-01 -p 6379 -a <password> --bigkeys

发现几个异常的大 Key：

1
2
3

Biggest string found so far '"product:detail:cache:all"' with 524288000 bytes  # 500MB！
Biggest hash found so far '"user:session:hash"' with 1258291 fields
Biggest list found so far '"activity:log:queue"' with 2847593 elements

product:detail:cache:all 这个 Key 存储了 500MB 的数据，这是一个"全量商品缓存"，是某开发同学为了提高商品详情接口性能，将全部商品数据序列化后存入一个 Redis Key 中。

activity:log:queue 是一个活动日志队列，因为消费者处理不及，积压了将近 300 万条记录。

第三步：追溯大 Key 的产生原因

通过查看应用代码和 Redis 写入监控，发现：

product:detail:cache:all：大促前夕，开发同学为了"预热缓存"，写了一个脚本把全量商品（约 5 万个商品，每个商品序列化后约 10KB）存入一个 String Key。这个 Key 在大促当天被反复覆盖写入（每次预热都覆盖一次），每次写入耗时 2-3 秒，本身就是一个隐患。
activity:log:queue：活动期间消费者处理速度远低于生产速度，积压数百万条未处理的日志条目，占用了大量内存。

第四步：评估立即处理方案

此时有几个选项：

方案 A：调大 maxmemory（临时方案）

风险：服务器本身可用内存只有 12GB，Redis 已用约 8GB，系统还有其他进程，不建议调太高
可临时调至 10GB，争取时间清理大 Key

方案 B：修改 maxmemory_policy 为 allkeys-lru（临时方案）

让 Redis 自动淘汰最近最少使用的 Key
风险：可能淘汰到重要的缓存数据，但好过直接拒绝写入

方案 C：立即删除大 Key（直接处理）

删除大 String Key，释放 500MB 空间
清空或截断积压 List

综合评估后，选择先临时调整 maxmemory_policy，再清理大 Key，最后重新评估内存上限。

解决方案

第一步：临时修改淘汰策略（不重启）

`1`	`redis-cli -h redis-prod-01 -p 6379 -a <password> CONFIG SET maxmemory-policy allkeys-lru`

修改后，Redis 开始主动淘汰冷数据，写操作不再被拒绝，应用侧错误率立即下降。

第二步：删除大 Key（避免直接 DEL，防止阻塞）

直接 DEL 一个 500MB 的 Key 会阻塞 Redis 主线程数秒。使用异步删除：

1
2

# Redis 4.0+ 支持 UNLINK 命令（异步删除）
redis-cli -h redis-prod-01 -p 6379 -a <password> UNLINK "product:detail:cache:all"

UNLINK 命令将 Key 的删除操作交给后台线程，主线程几乎无阻塞。

第三步：截断积压 List

1
2

# 保留最新的 10000 条，其余丢弃（或者清空）
redis-cli -h redis-prod-01 -p 6379 -a <password> LTRIM "activity:log:queue" 0 9999

第四步：修正商品缓存设计

与开发同学沟通，将"全量商品缓存"改为按商品 ID 分散存储：

`1`	`product:detail:{product_id} → 单个商品数据（约 10KB/key）`

并设置合理的 TTL（如 1 小时），避免永不过期。

第五步：修复消费者积压问题

扩容消费者实例数量（从 2 个扩到 8 个），加速消耗积压队列。

根因分析

根本原因：缓存设计不合理 + maxmemory 策略配置错误。

将大量数据存入单个 Redis Key，是典型的大 Key 反模式，不仅占用大量内存，还会导致网络带宽和序列化/反序列化的额外开销。
使用 noeviction 策略对于缓存场景来说是错误选择——它适用于数据不能丢失的持久化场景（如队列），但对于普通缓存应改用 allkeys-lru 或 volatile-lru。
没有预估大促期间的内存需求，也没有设置合理的内存告警阈值（应在 80% 时告警）。

预防措施

1. Redis 内存监控告警

在 80% 使用率时告警，90% 时紧急告警，不等到 OOM 再处理。

2. 大 Key 定期扫描

通过 redis-cli --bigkeys 或 redis-rdb-tools 分析 RDB 文件，定期检查大 Key：

1
2

# 分析 RDB 文件（离线分析，不影响线上）
rdb --command memory dump.rdb | sort -rn -k3 | head -20

3. 禁止大 Key 设计规范

在代码规范中明确：单个 Redis Key 的 Value 大小不超过 1MB，List/Hash/Set 的元素数量不超过 5000。

4. 缓存淘汰策略合理化

纯缓存场景统一使用 allkeys-lru，结合 TTL 管理数据生命周期。

5. 生产变更前做容量评估

大促类活动前，评估 Redis 内存峰值需求，提前扩容。

总结

这次事故表明，Redis 的配置和使用规范同样需要纳入代码审查流程。一个大 Key、一个错误的淘汰策略，在平时可能不显眼，但到了业务高峰期就会变成定时炸弹。

对于 Redis 运维，除了关注可用性，还要重点关注大 Key、热 Key、内存使用率、慢查询这四个维度，建立起常态化的监控和审计机制。

一次VMware ESXi主机紫屏宕机的排查与恢复实录

Tue, 20 Sep 2022 10:45:00 +0000

问题背景

某日凌晨 3:07，监控系统收到大量告警：生产环境中的一台 VMware ESXi 主机（HP ProLiant DL380 Gen10）突然下线，该主机上运行着 12 台虚拟机，包含 ERP 系统、OA 系统、文件服务器等关键业务系统。

早上 8:30 运维人员到岗后发现问题，此时所有虚拟机均已强制关机，现场查看物理服务器，显示屏上出现了 VMware 的紫屏（PSOD，Purple Screen of Death），服务器处于 hung 状态，需要硬重启才能恢复。

紫屏截图如下（关键信息记录）：

VMware ESXi 7.0.3 (VMkernel Release Build 20842708)
HP ProLiant DL380 Gen10
PCPU 12 locked up. Failed to ack TLB invalidate.
0x0000000000000000:[0x4180b22e54b3]...

故障现象

ESXi 主机出现紫屏，物理界面显示 PSOD
12 台虚拟机全部强制关机（非正常关闭）
监控系统在 3:07 开始收到该主机上所有 VM 的 ping 超时告警
vCenter 显示该主机为"未响应"状态

排查过程

第一步：硬重启并收集 PSOD 日志

在确认无法软恢复后，对物理服务器进行硬重启（ILO 远程管理界面操作）。

重启后，立即从 ESXi 主机提取紫屏 dump 文件。VMware ESXi 在 PSOD 时会自动将内存转储到本地磁盘。

SSH 连接到恢复后的 ESXi 主机：

# 查看 VMkernel 日志目录
ls /var/core/
# 输出：
# vmkernel-zdump.0
# vmkernel-zdump.1（如有多次）

# 查看最新的 vmkernel 日志
cat /var/log/vmkernel.log | tail -200

关键日志片段：

2022-09-20T03:07:12.145Z cpu12:2098226)ALERT: PCPU 12 locked up. Failed to ack TLB invalidate.
2022-09-20T03:07:12.145Z cpu12:2098226)Machine check: Bank 5, status 0xBE20000000800400
2022-09-20T03:07:12.145Z cpu12:2098226)Machine check: addr 0x0000000000000000
2022-09-20T03:07:12.146Z cpu12:2098226)NMI IPI: nmiHandler:Dump stack ...

出现了 Machine check 错误，Bank 5 对应内存控制器（Memory Controller），状态码 0xBE20000000800400 是典型的内存 ECC 错误（Uncorrected Error）。

第二步：分析机器检查错误（MCA）

Machine Check Architecture（MCA）是 x86 CPU 的硬件错误上报机制。Bank 5 在 Intel Xeon 平台通常对应内存通道或内存控制器。

状态码解析（0xBE20000000800400）：

Bit 63（VAL）= 1：有效的机器检查错误
Bit 61（UC）= 1：未修正的错误（Uncorrected Error），不可纠正
Bit 57（EN）= 1：已启用错误报告
错误类型：Memory Error

这说明是 内存硬件故障，且是不可纠正的 ECC 错误，直接触发了 CPU 的机器检查中断，进而导致 VMkernel 进入紫屏。

第三步：查看 HP ILO 日志

通过 HP ILO（服务器硬件管理接口）查看服务器事件日志：

1
2

Uncorrectable Memory Error on Slot 0, Bank 0 / Rank 0
DIMM Location: PROC 1 DIMM 3A

明确指出了 PROC 1 DIMM 3A 这根内存条出现了不可纠正的内存错误。

第四步：物理确认故障内存

关机后，打开服务器，按照 ILO 日志标注的位置找到 PROC 1 DIMM 3A 插槽，将这根内存条拔出，仔细检查：

外观：金手指有轻微氧化痕迹
运行时长：该服务器已运行约 4 年

将这根故障内存取出，其余内存条保持原位，重新上电。

第五步：内存 Memtest 验证

在正式上线前，使用 HPE Memory Diagnostics（通过 ILO 的 SPP 工具）对剩余内存条进行检测，结果全部通过。

重新启动 ESXi，主机正常进入系统，无报错。

解决方案

立即处理：

拔除故障内存条（PROC 1 DIMM 3A）
重启 ESXi 主机（此时总内存从 256GB 降至 240GB）
逐步启动各虚拟机，优先恢复 ERP、OA 等关键业务
向厂商提交内存条保修申请（服务器在保修期内）

虚拟机启动顺序：

1
2
3

# 通过 vCenter 或 esxcli 启动关键 VM
vim-cmd vmsvc/getallvms   # 列出所有 VM 及其 VMID
vim-cmd vmsvc/power.on <VMID>

恢复顺序：

ERP 数据库服务器（最高优先级）
ERP 应用服务器
OA 系统
文件服务器
其他非关键系统

全部 VM 在 9:20 前恢复运行，业务中断约 6 小时（3:07 - 9:20）。

根因分析

根本原因：服务器内存条（PROC 1 DIMM 3A）发生硬件故障，产生了不可纠正的 ECC 错误（Uncorrected ECC Error）。

ECC 内存通常能自动纠正单 bit 错误（CE，Correctable Error），但当出现双 bit 或更多 bit 错误时，无法纠正，只能上报给 CPU，CPU 触发 Machine Check Exception（MCE），VMkernel 捕获后生成 PSOD，保护虚拟机数据完整性。

该内存条已运行约 4 年，正处于硬件老化周期，发生故障属于正常硬件生命周期现象。

预防措施

1. 配置 ECC 内存可纠正错误（CE）告警

不等到 UCE 触发宕机，在 CE 频繁出现时就主动更换内存：

在 vCenter 中配置主机硬件健康告警，当 ECC CE 告警达到阈值时通知运维。

2. 接入服务器硬件监控

将 HP ILO / Dell iDRAC 等 BMC 接口接入监控系统（如 Prometheus + ipmi_exporter），实时采集内存、CPU、硬盘健康状态。

3. 制定虚拟机启动优先级 SOP

提前定义好各 VM 的重要程度和启动顺序，避免故障时手忙脚乱。

4. 定期巡检服务器硬件

每季度查看一次 ILO/iDRAC 的事件日志，对已有 CE 记录的内存条提前备件替换，不等到 UCE 再处理。

总结

服务器运维中，硬件故障是无法完全避免的，但可以通过完善的监控和告警机制，将影响降到最低。这次事故之所以造成 6 小时的业务中断，一方面是故障发生在凌晨，另一方面是在日常运维中没有关注到 ILO 里已经存在的 CE 告警（事后查看 ILO 日志，发现事故前两周就已经有 CE 告警，只是没有引起重视）。

要点： ECC 的可纠正错误（CE）是 UCE 和宕机的前兆，一旦出现 CE 告警就应计划更换内存，不要等到 UCE 发生时再被动处理。

一次Nginx反向代理配置错误导致上传文件大小限制失效的排查实录

Tue, 15 Mar 2022 09:30:00 +0000

问题背景

某周一早上刚到公司，业务部门的同事就找过来反映，说他们的内部文档管理系统在上传大于 10MB 的文件时，总是弹出错误提示。之前这个系统运行一直正常，但上周刚完成了一次迁移，把原来跑在 Tomcat 上的应用挪到了新的 Docker 容器里，并在前端新增了一台 Nginx 作为反向代理。迁移完成后做了基本的冒烟测试，上传小文件没问题，但大文件的情况没有测试到，结果今天业务侧才发现问题。

影响范围较大，整个文档管理系统的使用人数大约 60 人，每天有大量合同、图纸、报告需要上传，部分文件超过 10MB，属于正常业务场景。

故障现象

用户在浏览器端上传文件时，当文件大小超过约 8MB 时，页面返回如下错误：

`1`	`413 Request Entity Too Large`

浏览器 Network 面板可以看到请求直接被 Nginx 拒绝，HTTP 状态码 413，没有到达后端应用。

开发同事说他已经在应用的 application.properties 里把 Spring Boot 的上传限制改成了 100MB：

1
2

spring.servlet.multipart.max-file-size=100MB
spring.servlet.multipart.max-request-size=100MB

容器重启后依然报 413，于是找到运维这边来排查。

排查过程

第一步：确认报错来源

先看 Nginx 的 error log：

`1`	`tail -f /var/log/nginx/error.log`

日志输出：

2022/03/15 09:12:43 [error] 1234#1234: *567 client intended to send too large body: 9437184 bytes, client: 192.168.10.88, server: docs.internal.company.com, request: "POST /api/upload HTTP/1.1", host: "docs.internal.company.com"

很明确：是 Nginx 报的错，不是后端应用。说明请求根本没到 Java 应用这层就被 Nginx 拒掉了。

第二步：检查 Nginx 配置

查看当前生效的 Nginx 配置：

`1`	`nginx -T 2>/dev/null \| grep -i "client_max_body_size"`

输出：

`1`	`client_max_body_size 8m;`

找到了！但配置文件里明明应该改过的……继续追查配置文件层级：

`1`	`find /etc/nginx -name "*.conf" \| xargs grep -l "client_max_body_size"`

发现了三处：

/etc/nginx/nginx.conf（http 块）：client_max_body_size 100m;
/etc/nginx/conf.d/default.conf（server 块）：client_max_body_size 8m;
/etc/nginx/conf.d/docs.conf（location 块）：未配置

第三步：理解 Nginx 配置继承规则

这里就需要了解 Nginx 配置的继承机制了。client_max_body_size 可以出现在三个层级：

http {} 块
server {} 块
location {} 块

优先级规则是：子块的配置会覆盖父块。 也就是说，server {} 里配置了 8m，就会覆盖掉 http {} 里的 100m，即使 http {} 里的值更大。

追问负责这次迁移的同事，他说迁移之前的 default.conf 是从旧机器上直接拷过来的，旧环境里这个文档系统并不走那台 Nginx，所以 default.conf 里的 8m 限制之前没有影响，但迁移后新 Nginx 又用了同一个 default.conf，就埋下了这个坑。

第四步：验证其他 server 配置

既然 default.conf 里有残留的 8m 限制，那需要确认这个配置是否影响到了 docs.conf 里的 server 块。

查看 docs.conf：

server {
    listen 80;
    server_name docs.internal.company.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

这个 server {} 块里没有配置 client_max_body_size，按理应该继承 http {} 的 100m。但实际上 default.conf 里的那个 server {} 块只影响它自己，不会影响其他 server {} 块。

那到底是哪里的 8m 在生效？

第五步：再次仔细检查继承关系

重新 nginx -T 全量输出，这次逐段仔细看：

`1`	`nginx -T 2>/dev/null`

在仔细阅读输出后，发现 docs.conf 里其实还有一段被注释掉但没有完全注释干净的配置：

server {
    listen 80;
    server_name docs.internal.company.com;
    client_max_body_size 8m;   # 这行没被注释掉！

    # client_max_body_size 100m;  # 尝试修改，但改错位置了

    location / {
        proxy_pass http://127.0.0.1:8080;
        ...
    }
}

原来，那位同事确实改过，但他把新的值写成了注释，同时没把旧的 8m 那行删掉，导致 8m 依然生效。

解决方案

修改 docs.conf，移除多余的限制配置，直接在 server {} 块里设置正确的值：

server {
    listen 80;
    server_name docs.internal.company.com;
    client_max_body_size 200m;   # 设置为 200m，留足余量

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # 同步设置代理超时，避免大文件上传超时
        proxy_connect_timeout 60s;
        proxy_send_timeout 300s;
        proxy_read_timeout 300s;
    }
}

验证配置语法无误：

`1`	`nginx -t`

输出：

1
2

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

热重载：

`1`	`nginx -s reload`

测试上传 50MB 文件，成功。用户侧验证通过，问题解决。

根因分析

根本原因是配置迁移时遗留了旧配置，且修改时操作不规范（改了注释而没删除旧配置行）。client_max_body_size 8m; 这行代码实际上一直生效，在旧环境中没有问题是因为旧环境的这台 Nginx 不承载文档系统的流量，迁移后该配置直接生效并产生影响。

此外，该同事误认为在 http {} 块设置了 100m 后，server {} 块里的 8m 会被覆盖，对 Nginx 配置的优先级规则理解有误。

预防措施

1. 配置迁移规范化

迁移配置前应先整理清楚每项配置的作用，不应直接拷贝旧配置，特别是对限制类配置（大小、超时、速率）要逐一核对。

2. 搭建迁移验证 Checklist

关键迁移场景（如文件上传、超时、鉴权等）必须列入上线前测试清单，不能只做功能冒烟测试。

3. 定期 nginx -T 全量审计

可通过脚本定期输出 nginx -T 并做配置 diff，发现异常配置：

`1`	`nginx -T 2>/dev/null \| grep -E "(client_max_body_size\|proxy_read_timeout\|proxy_send_timeout)" > /tmp/nginx_limit_audit.txt`

4. 统一配置管理

推荐将 Nginx 配置纳入 Git 版本管理，所有修改通过 MR/PR 审核，避免直接改配置文件后忘记清理。

总结

这次故障表面上是个很简单的 413 问题，但排查过程中踩了两个坑：一是对 Nginx 配置的层级覆盖规则不熟悉，二是配置文件里存在"半改"的残留配置，干扰了判断。

教训：迁移时不要直接照搬旧配置，要理解每一行配置的含义；修改配置时要彻底，不要留注释残骸；上线前的测试场景要覆盖到实际业务的边界情况（比如大文件上传、长时间操作等）。

服务运维 on Zero Day Notes

一次Cron任务因系统时区变更导致凌晨备份任务在业务高峰期执行拖垮MySQL的排查实录

问题背景

故障现象

排查过程

第一反应：是不是有人手动触发了备份？

第二反应：检查 Crontab 配置

关键发现：系统时间和硬件时钟不一致

进一步分析：Cron 实际执行时间

验证 Cron 守护进程的时区

追查时区变更记录

找到真凶——CMDB Agent 脚本

重新审视：Cron 到底用的什么时区？

回到核心问题

最终突破：检查时区变更的精确时间点

真相浮现

真正的根因

根因分析

解决方案

紧急处理

备份策略优化

关键配置项

预防措施

总结

一次Ansible Playbook变量优先级错误导致批量服务器配置漂移的排查实录

问题背景

故障现象

排查过程

第一步：确认变更范围

第二步：检查变量优先级

第三步：定位变量透传路径

第四步：检查其他被影响的变量

第五步：检查审计与变更流程

第六步：确认回滚方案

解决方案

1. 移除 play vars 中的同名变量陷阱

2. 使用变量前缀隔离不同角色的变量

3. 禁止在命令行直接传复杂变量

4. 增加配置漂移检查

5. 把变量定义集中到 inventory 并按环境分组

根因分析

预防措施

总结

一次服务器CPU软中断飙高导致服务间歇性超时的排查实录

一、问题背景

二、故障现象

三、排查过程

第一步：排除应用层问题

第二步：定位内核层面的瓶颈

第三步：追溯中断亲和性配置

第四步：深入理解软中断的处理机制

四、解决方案

紧急止血：手动绑定网卡中断到多个核心

长期优化：RPS + RFS 进一步分散软中断

修复 irqbalance 服务

五、根因分析

六、预防措施

1. 补齐软中断监控

2. 建立服务器上线标准模板

3. irqbalance 存活监控

4. 定期性能基线巡检

七、总结

一次Prometheus告警风暴拖垮邮件与企业微信告警通道的排查实录

一、问题背景

二、故障现象

三、排查过程

3.1 紧急止血：先让告警通道活过来

3.2 查告警源头：为什么这么多告警同时触发？

3.3 查 Alertmanager 配置：为什么告警没有被合并？

3.4 查根因告警：为什么 critical 告警没发出来？

四、解决方案

4.1 告警规则层：加 for 持续时间和分级

4.2 Alertmanager 层：精细化路由 + 抑制 + 分级

4.3 告警通道层：企业微信分群 + 邮件限流

4.4 可靠性层：告警持久化 + 自监控

五、根因分析

六、预防措施

七、总结

一次GitLab CI Runner卡死导致生产部署流水线全停的排查实录

一次GitLab CI Runner卡死导致生产部署流水线全停的排查实录

4.1 告警规则层：加 `for` 持续时间和分级