Zero Day Notes

一次Windows组策略文件共享权限误配导致全公司无法访问共享文件夹的排查实录

Sun, 05 Jul 2026 18:49:05 +0000

问题背景

周三上午9点，公司各部门陆续反馈无法打开共享文件夹。财务部最先报告无法访问存放月度报表的共享目录，紧接着人事部、研发部也相继反映同样的问题。影响范围覆盖全公司约200台终端，涉及至少5个核心共享目录——财务报表、人事档案、项目文档、IT工具库和公共模板。

紧急程度极高：财务部当天需要完成月结报表提交，HR部门正处于月底考勤统计关键期，研发部的项目文档目录是日常协作的核心依赖。用户尝试打开共享路径时，Windows弹出"拒绝访问"错误，部分用户甚至连目录都看不见——文件夹图标消失，资源管理器中仅显示空白。

我作为桌面运维负责人，接到工单后立即意识到这不是个别用户问题，而是系统性故障，需要在最短时间内恢复业务。

故障现象

用户端表现：

访问 \\FILE-SVR01\财务报表 时弹出错误："\\FILE-SVR01\财务报表拒绝访问。"部分用户看到的是 "指定的网络名不再可用"
资源管理器中输入共享路径后，目录列表为空，部分共享文件夹图标变成灰色锁状标记
映射的网络驱动器（如Z:、Y:盘）显示"断开"状态，双击后报错 0x80070005 Access Denied

服务器端表现：

FILE-SVR01服务器本身运行正常，CPU、内存、磁盘均无异常
SMB服务（LanmanServer）正常运行，net share 命令可看到所有共享仍在发布
事件查看器中大量出现 Event ID 5168（SMB2协议协商失败）和 Event ID 1006（SMB共享访问被拒绝）

关键日志片段：

Event ID: 5168
Source: Microsoft-Windows-SMBServer
Level: Error
Description: SMB2 connection from client 192.168.10.55 was rejected.
Share: 财务报表
User: DOMAIN\zhangwei
Access Reason: The share permission denies the requested access.

Event ID: 1006
Source: Microsoft-Windows-SmbServer
Description: The server denied access to share "财务报表" for user DOMAIN\zhangwei.
Requested Access: Read
Share Permission: Everyone - No Access

注意最后一行——Everyone - No Access。这直接指向了共享权限层面的问题，而非NTFS权限。

排查过程

第一步：确认故障范围与影响面

我首先在多台终端上测试不同的共享路径，结果如下：

共享名称	管理员账号	普通用户账号	结果
财务报表	可访问	拒绝访问	管理员正常
人事档案	可访问	拒绝访问	管理员正常
项目文档	可访问	拒绝访问	管理员正常
IT工具库	可访问	拒绝访问	管理员正常
Public模板	可访问	拒绝访问	管理员正常

管理员账号（Domain Admins）全部正常，普通用户全部被拒。这初步排除NTFS权限问题——如果NTFS权限出问题，管理员也可能受阻。问题指向**共享权限（Share Permission）**层面。

第二步：检查服务器共享权限配置

登上FILE-SVR01，用 net share 财务报表 查看共享配置：

Share name        财务报表
Path              D:\Shares\Finance
Remark            财务部月度报表共享
Maximum users     No limit
Permissions:
  Everyone,       NO ACCESS
  DOMAIN\FinanceGroup, READ
  DOMAIN\Domain Admins, FULL

问题暴露了——Everyone被设置为NO ACCESS！但根据我的记录，原本Everyone应至少有READ权限（配合NTFS ACL做精细控制），这配置显然被改动了。

继续检查其他共享：

Share name        人事档案
Permissions:
  Everyone,       NO ACCESS
  ...

Share name        项目文档
Permissions:
  Everyone,       NO ACCESS
  ...

所有5个核心共享的Everyone权限都被改为NO ACCESS。谁改的？什么时候改的？

第三步：定位权限变更来源

检查服务器本地操作历史——事件日志中没有手动修改共享权限的操作记录。服务器只有运维组有本地登录权限，近期无人手动操作这台服务器。

那大概率是组策略（GPO）推送导致的。打开GPMC（Group Policy Management Console），查看近期应用到FILE-SVR01的GPO变更记录：

发现前一天（周二晚22:00）有一个新的GPO IT-Security-Baseline-v2被链接到包含FILE-SVR01的OU FileServers。这个GPO是信息安全组新推送的安全基线策略。

打开该GPO的配置，逐项检查：

Computer Configuration >
  Policies >
    Windows Settings >
      Security Settings >
        Local Policies / Security Options

发现关键配置项：
"Network access: Shares that can be accessed anonymously" = None
"Network access: Restrict anonymous access to Named Pipes and Shares" = Enabled

这两项本身没问题，继续深挖——在GPO的用户权限分配和文件共享策略区域，发现了真正的元凶：

Computer Configuration >
  Policies >
    Administrative Templates >
      Network >
        Lanman Server >
          "Set default share access for everyone" = Disabled

这就是根因！这个策略设置为"Disabled"后，相当于将所有共享的Everyone默认权限移除/设置为No Access。在Windows共享权限机制中，共享权限和NTFS权限是叠加取最严格值的逻辑：

共享权限 = Everyone → No Access
NTFS权限 = FinanceGroup → Read

叠加结果 = No Access（因为共享层已经封死了，NTFS层再怎么开放都无效）

第四步：验证GPO应用时间线

用 gpresult /h gpresult.html 在FILE-SVR01上生成策略应用报告，确认：

GPO: IT-Security-Baseline-v2
Applied Time: 2026-07-02 22:00:15
Last Refresh: 2026-07-03 07:30:00 (自动刷新)
Component: Group Policy Registry
Setting: Set default share access for everyone → Disabled

时间线吻合：周二晚22点GPO首次应用，周三早7:30自动刷新再次确认生效，9点用户上班即触发故障。

第五步：确认安全组的原始意图

联系信息安全组负责人，了解到该GPO的意图是按照新版内控审计要求"禁止匿名用户访问共享"，但配置时误将**“Set default share access for everyone"设置为Disabled**。他们以为这只是禁止匿名访问（Everyone在安全语境中常被等同于匿名用户），但实际上这个策略移除的是共享层面Everyone的所有默认访问权限——包括已认证用户的隐式访问通道。

在AD域环境中，已认证用户通过共享访问时，如果共享权限只给了特定组（如FinanceGroup），那该组成员确实能访问。但如果共享权限给了Everyone（包括Read），再由NTFS ACL做精细控制——这是绝大多数企业共享的标准做法。当Everyone被移除后，只有显式在共享权限中列出的组才能通过共享层——而我们的5个共享中，只有Domain Admins被显式授予了FULL权限，其他业务组只在NTFS层有权限，共享层依赖Everyone的Read兜底。

解决方案

紧急恢复（10分钟内完成）

在FILE-SVR01上，手动恢复5个共享的Everyone权限：

# 逐个共享恢复Everyone的Read权限
$shares = @("财务报表", "人事档案", "项目文档", "IT工具库", "Public模板")

foreach ($share in $shares) {
    # 使用net share命令恢复权限
    net share $share /grant:Everyone,READ
}

# 验证权限是否恢复
foreach ($share in $shares) {
    net share $share
}

执行后，各共享的Everyone权限恢复为READ：

Share name        财务报表
Permissions:
  Everyone,       READ
  DOMAIN\FinanceGroup, READ
  DOMAIN\Domain Admins, FULL

用户端测试：普通用户可正常打开共享文件夹，NTFS ACL正常生效（财务组可读写，其他部门只读）。业务恢复。

修正GPO策略

在GPMC中修改 IT-Security-Baseline-v2：

将 "Set default share access for everyone" 改为：
  Not Configured（不配置，保持系统默认）

同时，确保以下策略正确配置：
  "Network access: Restrict anonymous access to Named Pipes and Shares" = Enabled
  "Network access: Shares that can be accessed anonymously" = None

这两项已足够满足"禁止匿名访问"的审计要求，不需要动Everyone的默认共享权限。

修改后强制刷新FILE-SVR01的策略：

1
2

# 在FILE-SVR01上强制刷新组策略
gpupdate /force

验证GPO生效后共享权限未再被篡改——Everyone READ权限保持不变。

长期加固：共享权限规范化

对所有文件服务器共享执行权限审计，建立标准配置模板：

# 标准共享权限配置模板
# 共享层：Everyone=READ（兜底），业务组=CHANGE（如需写入），Domain Admins=FULL
# NTFS层：精细ACL控制（按部门、角色配置读写权限）

# 示例：为财务报表共享配置标准权限
# 1. 共享权限
net share "财务报表" /grant:Everyone,READ /grant:"DOMAIN\FinanceGroup",CHANGE /grant:"DOMAIN\Domain Admins",FULL

# 2. NTFS权限（在D:\Shares\Finance上设置）
icacls "D:\Shares\Finance" /inheritance:r  # 先移除继承
icacls "D:\Shares\Finance" /grant:"DOMAIN\Domain Admins":(OI)(CI)F  # 管理员完全控制
icacls "D:\Shares\Finance" /grant:"DOMAIN\FinanceGroup":(OI)(CI)M  # 财务组修改
icacls "D:\Shares\Finance" /grant:"DOMAIN\AllStaff":(OI)(CI)RX     # 全公司只读
icacls "D:\Shares\Finance" /grant:"CREATOR OWNER":(OI)(CI)IO       # 创建者控制自己文件

核心原则：

共享层做粗粒度控制：Everyone兜底Read，防止策略误配导致全面中断
NTFS层做细粒度控制：按部门角色精确配置读写权限
两层叠加取严格值：共享层Read + NTFS层Modify = 最终Read（共享层更严则生效）

根因分析

问题的根本原因是信息安全组在配置安全基线GPO时，对Windows共享权限机制理解不充分：

策略理解偏差：将"Set default share access for everyone = Disabled"误解为"禁止匿名用户访问共享”。实际上该策略移除的是共享层面Everyone组的所有默认访问权限，不仅影响匿名用户，也切断已认证用户通过Everyone组获取共享层访问的通道。
Windows共享权限叠加机制被忽视：共享权限和NTFS权限是叠加取最严格值。共享层封死（Everyone=No Access）后，NTFS层再开放也无效。安全组只关注了"禁止匿名访问"的目标，没意识到共享权限层是独立于NTFS层的访问控制关卡。
权限架构依赖未被识别：公司现有共享架构采用"共享层Everyone=Read兜底 + NTFS层精细ACL"的标准模式。新GPO未做兼容性测试就直接推送，破坏了这一依赖关系。
缺乏变更评审机制：GPO变更前没有与桌面运维组评审共享权限架构的依赖关系，安全组独立操作后直接推送。

预防措施

1. GPO变更评审流程

建立GPO变更跨组评审机制：

新GPO推送前必须向受影响系统的运维负责人发送变更说明
包含文件服务器、域控、关键业务系统的OU，GPO变更需双人审核
安全基线类GPO必须先在隔离测试OU中验证48小时，确认无副作用后再链接到生产OU

2. 共享权限架构文档化

编写《文件服务器共享权限配置标准》，明确：

共享层：Everyone=READ（最低兜底权限，保证已认证用户至少可通过共享层）
NTFS层：按部门角色配置精细ACL
禁止将共享层Everyone设为No Access——匿名访问控制应通过"Restrict anonymous access"策略实现
所有新增共享必须遵循此标准模板

3. GPO监控告警

在Zabbix中增加对FILE-SVR01的共享权限监控：

# 监控脚本：检查关键共享的Everyone权限
$shares = @("财务报表", "人事档案", "项目文档", "IT工具库", "Public模板")
$alert = @()

foreach ($share in $shares) {
    $perm = (Get-SmbShare -Name $share).GrantAccess | Where-Object { $_.AccountName -eq "Everyone" }
    if (-not $perm -or $perm.AccessControlType -ne "Allow" -or $perm.AccessRight -notmatch "Read") {
        $alert += "$share - Everyone权限异常：$perm"
    }
}

if ($alert.Count -gt 0) {
    Write-Output "ALARM: 共享权限异常 - $($alert -join '; ')"
    exit 1  # Zabbix触发告警
} else {
    Write-Output "OK: 共享权限正常"
    exit 0
}

4. GPO测试环境

搭建独立的GPO测试OU和测试虚拟机，所有新GPO先在测试环境验证：

验证共享访问、域认证、打印机、用户登录等核心功能不受影响
验证48小时后无异常再推送生产环境
记录测试结果，作为GPO发布的前置条件

总结

这次故障的核心教训是：组策略变更必须理解其对现有架构的依赖影响，安全策略的收紧不应以牺牲业务可用性为代价。

Windows共享权限的两层叠加机制（共享层+NTFS层）是很多运维工程师和安全工程师都容易混淆的盲区。共享层是"第一道关卡"——如果共享层封死了入口，NTFS层再怎么精细配置都是无效的。“禁止匿名访问"的正确做法是启用"Restrict anonymous access"策略，而不是粗暴地移除Everyone的共享默认权限。

在排查过程中，关键突破口是事件日志中的 Everyone - No Access 信息——这直接定位了共享权限层的问题。而后通过GPMC追踪GPO变更时间线，找到了策略配置的元凶。整个过程从接报到恢复业务约10分钟，但根因定位和长期加固需要更深入的机制建设。

对于企业运维而言，组策略是强大的工具，也是危险的工具。一条看似简单的策略设置，如果脱离了对业务架构的理解，就可能引发全局性故障。安全与可用性的平衡，永远需要跨组协作和变更评审来保障。

一次OSPF路由震荡导致跨机房业务间歇性中断的排查实录

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

问题背景

周一早晨8:15，IT运维组值班手机开始收到一连串业务投诉——总部办公区（DC-A）用户访问部署在分支机房（DC-B）的ERP系统时，页面每隔5~8分钟就会出现约30秒的"卡死"现象：页面加载超时、报表查询报错、部分用户甚至看到502 Bad Gateway。受影响用户约180人，集中在财务和采购部门，这两个部门对ERP依赖度最高，故障紧急度评级P1。

DC-A与DC-B之间通过10Gbps专线互联，核心交换机之间建立OSPF Area 0邻接关系，各机房内部使用Area 1/2。两机房BGP使用各自AS号（65001/65002），通过OSPF学习对方的互联地址作为BGP下一跳。正常情况下，OSPF邻接稳定，BGP路由下一跳始终可达，跨机房流量畅通无阻。

故障持续时间约2小时，期间ERP服务本身运行正常（DC-B内部用户无任何异常），问题明确指向跨机房网络层面。

故障现象

监控层面：Zabbix采集的ERP前端响应时间曲线呈现明显的周期性尖刺——基线200ms，每5~8分钟突然飙至3000ms以上，持续约30秒后回落。对应时段，Grafana上的跨机房TCP连接数从稳态的120条骤降至0，HTTP 5xx错误率同步跳升。

用户层面：财务部张经理反馈"9:00打开应付账款页面卡了半分钟，刷新后又好了，过几分钟又卡"；采购部多人报告提交采购单时超时报错。

网络层面：在DC-A核心交换机（CE6850-01）上持续观察BGP路由表，发现DC-B侧的172.16.0.0/16网段路由在反复出现和消失：

<CE6850-01> display bgp routing-table 172.16.0.0
  Network          NextHop        Med  LocPrf  Pref  Path
*  172.16.0.0/16   10.0.0.2       0    100     255  65002 I
  // 30秒后路由消失
<CE6850-01> display bgp routing-table 172.16.0.0
  // No entry found
  // 再过20秒路由恢复

BGP路由的下一跳10.0.0.2是DC-B核心交换机的互联地址，通过OSPF学习。当OSPF邻接断开时，10.0.0.2的路由消失，BGP判定下一跳不可达，撤销172.16.0.0/16路由；OSPF邻接恢复后，下一跳重新可达，BGP路由重新生效。这正是典型的"OSPF驱动BGP路由震荡"模式。

排查过程

第一步：确认故障范围与定性

第一时间在DC-A核心交换机上Ping DC-B互联地址：

<CE6850-01> ping 10.0.0.2 repeat 100
  Reply from 10.0.0.2: bytes=64 time=1ms TTL=255
  Reply from 10.0.0.2: bytes=64 time=1ms TTL=255
  Request timeout
  Request timeout
  Request timeout
  Request timeout
  Request timeout
  Reply from 10.0.0.2: bytes=64 time=1ms TTL=255

Ping结果呈现周期性超时——连续5~6个包超时后恢复，与业务监控的尖刺周期吻合。用大包测试进一步确认：

1
2

<CE6850-01> ping 10.0.0.2 size 4000 repeat 50
  // 大包丢包率高达40%，小包丢包率仅8%

小包丢包率远低于大包，这提示物理层可能存在误码问题——小包CRC校验通过的几率更高，大包更容易被误码破坏。

第二步：检查OSPF邻接状态

<CE6850-01> display ospf peer
  Area 0.0.0.0
    Neighbor 10.0.0.2, Interface GE1/0/1
      State: Full  -> 正常时
    // 故障时段观察
    Neighbor 10.0.0.2, Interface GE1/0/1
      State: Init  -> 邻接断开
      State: ExStart -> 正在重建
      State: Full  -> 重新建立

开启OSPF事件调试进一步观察邻接变化细节：

<CE6850-01> debugging ospf event
  OSPF/Event: Nbr 10.0.0.2 state changed: Full -> Down (Receive bad hello seq)
  OSPF/Event: Nbr 10.0.0.2 state changed: Down -> Init (Hello received)
  OSPF/Event: Nbr 10.0.0.2 state changed: Init -> 2-Way (2-Way received)
  OSPF/Event: Nbr 10.0.0.2 state changed: 2-Way -> ExStart (Negotiation done)
  OSPF/Event: Nbr 10.0.0.2 state changed: ExStart -> Exchange (DB exchange)
  OSPF/Event: Nbr 10.0.2 state changed: Exchange -> Full (Adjacency done)

OSPF邻接从Full断到Down再到恢复Full，整个过程约25~30秒，与业务中断时长一致。关键信息是Receive bad hello seq——收到了错误的Hello报文序列号，说明Hello报文在传输过程中被损坏。

第三步：检查物理接口状态

这是最关键的一步。查看互联端口GE1/0/1的统计信息：

<CE6850-01> display interface GE1/0/1
  GE1/0/1 current state: UP
  Last 300 seconds input rate: 854 bits/sec, 3 packets/sec
  Last 300 seconds output rate: 1236 bits/sec, 5 packets/sec
  Input:
    Total packets: 94782
    CRC errors: 3847           <-- 异常！正常应接近0
    Frame errors: 0
    Overrun: 0
  Output:
    Total packets: 94521
    CRC errors: 0
    Collision: 0

CRC错误计数3847，而且每分钟还在增长约50~60个！端口当前状态是UP（没有进入error-disable），但持续增长的CRC误码意味着大量报文在物理层被损坏——OSPF Hello报文、DD报文、LS Update报文都可能被CRC校验失败丢弃，导致邻接关系反复中断。

查看DC-B侧的对应端口，同样有CRC计数增长：

1
2

<CE6850-02> display interface GE1/0/1
  Input CRC errors: 3612       <-- 对端也在涨

双向CRC错误都在增长，基本排除了单端交换机端口硬件故障的可能性，指向中间的物理链路——光纤本身或接头。

第四步：排查光纤链路

DC-A与DC-B之间10G专线通过ODF（光纤配线架）跳接，路径为：CE6850-01 GE1/0/1 → LC光纤 → ODF-A M3/V3 → 室内光缆 → ODF-B M3/V3 → LC光纤 → CE6850-02 GE1/0/1。

先在交换机上开启光功率监测：

<CE6850-01> display interface GE1/0/1 transceiver
  Rx Power: -14.2 dBm     <-- 偏低！10G LR正常范围 -6~-20dBm，但已接近下限
  Tx Power: -2.1 dBm      <-- 正常
  Rx Loss: 12.1 dB        <-- 光衰偏大

<CE6850-02> display interface GE1/0/1 transceiver
  Rx Power: -13.8 dBm
  Tx Power: -2.3 dBm

两端收光功率均偏低约3dBm，光衰偏大。15km LR模块正常光衰应在6~8dB，实测12dB明显偏高。这说明链路中存在额外的光损耗点。

第五步：定位光损耗点

联系机房驻场同事到ODF架现场检查。同事反馈：ODF-A侧M3/V3端口的LC适配器内积有明显灰尘，尾纤插入时感觉松动。用光纤端面检测仪（Fiber Microscope）观察该适配器：

适配器内芯有黑色颗粒污染物
尾纤端面也有轻微划痕和灰尘

这就是CRC误码的物理根因——适配器污染导致光纤端面之间存在空气间隙和散射，部分光信号在接头处被反射和散射（高回波损耗+高插入损耗），接收端收到的光信号功率偏低且带有失真，导致CRC校验失败。

同事用光纤清洁笔（One-Click Cleaner）清洁适配器内芯和尾纤端面后，重新插接：

1
2
3

<CE6850-01> display interface GE1/0/1 transceiver
  Rx Power: -6.8 dBm       <--恢复正常范围！
  Rx Loss: 6.8 dB           <--光衰恢复正常

同时CRC计数停止增长，Ping大包测试丢包率归零：

1
2

<CE6850-01> ping 10.0.0.2 size 4000 repeat 100
  100 packets transmitted, 100 received, 0% loss

OSPF邻接立即恢复稳定：

1
2

<CE6850-01> display ospf peer
  Neighbor 10.0.0.2, State: Full  (stable for 15 min)

BGP路由恢复稳定，ERP访问恢复正常，故障解除。从发现CRC异常到清洁光纤接头，整个过程约40分钟。

解决方案

紧急止血

清洁光纤接头：用One-Click Cleaner清洁ODF-A M3/V3适配器内芯和对应尾纤端面，重新插接后光功率恢复正常，CRC误码消失
重置接口计数器：执行reset counters interface GE1/0/1清零CRC计数，便于后续观察是否复发

根治措施

更换退化适配器：ODF-A M3/V3的LC适配器因长期插拔和污染，内部陶瓷套管已有轻微磨损，更换为新的LC双芯适配器
更换受损尾纤：端面有划痕的尾纤更换为新尾纤，旧尾纤端面划痕无法修复
OSPF稳定性增强：调整OSPF Hello间隔和死亡间隔，增加邻接容错能力：

interface GE1/0/1
  ospf timer hello 15        // 从默认10秒改为15秒，减少Hello报文频率
  ospf timer dead 60         // 从默认40秒改为60秒，给邻接更多恢复窗口
  ospf authentication-mode md5 1 cipher XXXXXX  // 增加认证防止非法报文干扰

BGP震荡抑制：配置BGP路由衰减（route dampening），防止震荡路由反复注入转发表：

1
2

bgp 65001
  route-dampening half-life-reachable 15 half-life-unreachable 15 reuse 750 suppress 2000 max-suppress-time 60

物理层监控：在Zabbix添加CRC计数器监控项，设置阈值告警：

1
2
3

监控项: snmp.get[ifInErrors.{#IFINDEX}]  // CRC错误计数
触发器: CRC错误增量 > 50/分钟 → P2告警
触发器: CRC错误增量 > 200/分钟 → P1告警

光功率监控：通过SNMP采集光模块收发功率，设置偏差告警：

1
2
3

监控项: optical.rxpower[GE1/0/1]
触发器: Rx Power < -10dBm → P2告警（光衰偏高预警）
触发器: Rx Power < -18dBm → P1告警（即将断光）

根因分析

本次故障的根本原因是ODF光纤适配器内芯污染导致的光信号衰减和失真，进而引发CRC误码→OSPF报文丢弃→邻接断建→BGP下一跳可达性波动→路由震荡→业务间歇中断，形成了一条从物理层到应用层的完整故障传导链。

适配器污染的原因有二：

日常维护不规范：机房ODF架近期有其他业务割接施工（周三新增一条2.5G专线），施工人员在ODF架操作时拔插了相邻M3/V3端口的尾纤用于测试，插回时未清洁端面，将手指油脂和灰尘带入适配器内芯
缺乏端面清洁SOP：团队光纤操作规范中没有"插接前必须清洁端面"的强制要求，日常巡检也不检查ODF适配器清洁度

光功率从-6.8dBm退化到-14.2dBm（增加了约7dB损耗），恰好是污染适配器造成的额外插入损耗。这个损耗水平尚在光模块接收灵敏度范围内（-20dBm），所以端口没有down，但信号质量已经劣化到足以产生大量CRC错误——这就是"端口UP但业务断"的典型场景。

预防措施

光纤操作SOP：制定并强制执行《ODF光纤操作规范》——任何拔插光纤操作必须先用One-Click Cleaner清洁端面和适配器，操作前后用端面检测仪确认清洁度。将此规范纳入变更管理流程，割接方案必须包含光纤清洁步骤
ODF适配器防护：空闲端口必须安装防尘帽，施工结束后检查相邻端口防尘帽是否完好。ODF架门保持关闭，减少灰尘侵入
物理层监控体系：将CRC错误计数和光模块功率纳入核心监控，设置分级告警阈值。CRC错误是物理层故障的"早期信号"——远比端口down更早出现，做到故障预警而非故障后才发现
光纤巡检制度化：每季度对所有ODF架做一次光功率测试+端面检测，记录光衰基线数据。光衰异常增长>2dB的链路标记为"需维护"，安排清洁或更换
OSPF/BGP震荡防护：核心互联链路OSPF参数适当放宽（Hello 15秒、Dead 60秒），为物理层短暂抖动提供缓冲窗口；BGP开启route dampening，抑制震荡路由对转发表的反复冲击
跨机房业务连续性增强：评估增加DC-A到DC-B的第二条互联链路（冗余路径），当主链路OSPF震荡时流量自动切换到备用链路，消除单链路故障对业务的影响

总结

这次故障的教训是：物理层的微小退化可以引发网络层的大规模震荡。一个ODF适配器里几粒灰尘，让光衰增加7dB，CRC误码飙升，最终导致180人的ERP服务反复中断2小时。

排查的关键转折点是在接口统计中发现CRC错误计数持续增长——如果只看端口状态（UP），永远找不到根因。这也提醒我们，网络监控不能只盯着"端口UP/DOWN"和"带宽利用率"，CRC错误、光功率这些物理层指标同样是核心监控项，而且往往能提前预警。

OSPF→BGP的震荡传导机制也值得牢记：当BGP下一跳依赖OSPF路由时，OSPF邻接的任何抖动都会直接传导到BGP路由层。在核心互联设计中，要么让BGP下一跳不依赖OSPF（比如用直连地址做下一跳），要么给OSPF足够的容错参数，要么开启BGP dampening抑制震荡——三条防线缺一不可。

最后，光纤端面清洁这个看似琐碎的操作，实际上是机房物理层可靠性的基础。一根未清洁的尾纤，可能就是下一次P1故障的起点。

一次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 个小时。希望这篇文章能帮你在遇到类似问题时少走一些弯路。

一次域控NTP时间源失效导致全公司Kerberos认证大面积失败的排查实录

Sat, 04 Jul 2026 06:55:33 +0000

一、问题背景

周二上午 8:42，IT 服务台工单系统在一分钟内涌入 23 张报修单，内容惊人一致——“域账户无法登录"“开机后一直转圈"“提示用户名密码错误但密码确认是正确的”。8:50 左右又有 4 位同事直接跑到IT办公室门口，手持笔记本当面演示登录失败的界面。

影响范围并非局限于某个楼层或部门：研发部 4 号楼 6 层、财务部 3 号楼 2 层、行政部 1 号楼 1 层均有用户报障。综合判断，这是一个全网级别的域认证问题，而非局部网络故障或个别终端问题。

紧急程度显然拉满——财务部当日上午 9:30 要做月结报表，必须在 30 分钟内恢复。我在企业微信群里发了一条全员公告"域认证异常已收到，正紧急排查”，随后立刻冲向机房。

二、故障现象

2.1 客户端表现

奔赴故障终端实地验证，现象如下：

已登录用户：锁屏后再次解锁提示"用户名或密码不正确”，注销后无法重新登录
新开机用户：登录界面输入密码后，转圈约 15-20 秒，随后弹出错误"该工作站和主域间的信任关系失败"
已运行的应用：Outlook 持续弹窗要求输入密码，文件服务器 \\fileserver\share 访问提示"拒绝访问"

2.2 客户端事件日志

在一台故障终端上打开事件查看器，关键日志如下：

来源: Microsoft-Windows-Security-Kerberos
事件ID: 4
级别: 错误
描述: Kerberos 客户端从服务器 host/fileserver.contoso.com 收到
KDC_ERR_SKEW 错误。目标服务器使用的时区信息指示与这台计算机
的时间差异为 7 分钟以上。

来源: Microsoft-Windows-Security-Kerberos  
事件ID: 7
级别: 错误
描述: 安全帐户管理器无法使用 BOOTKEY 解密位于安全配置引擎中的缓存凭据，失败原因为: 
无法检索到该对象的可接受的 clock skew 时间。

来源: NETLOGON
事件ID: 5719
级别: 错误
描述: 此计算机无法与域 CONTOSO 中的域控制器建立安全会话，原因如下: 
由于时钟偏差，安全通道验证失败。当前时间为 2026-07-04 08:45:13， 
域控制器时间为 2026-07-04 08:53:45。

最后这条 NETLOGON 5719 日志直接点出了根因方向——客户端时间与域控制器时间存在约 8 分 32 秒的偏差。

2.3 域控端表现

登录主域控 DC01（同时也是 PDC 仿真器角色持有者），检查安全日志：

来源: Microsoft-Windows-Security-Auditing
事件ID: 4771
任务类别: Kerberos 身份验证服务
描述: Kerberos 预身份验证失败。
账户信息: 用户: zhangsan
服务名称: krbtgt/CONTOSO
预身份验证类型: 2
失败代码: 0x25

失败代码 0x25 即 KDC_ERR_PREAUTH_FAILED，但在当前上下文中，0x19（KDC_ERR_SKEW）才是更直接的线索导向。进一步查看统计：

# 在域控上查询近1小时 Kerberos 认证失败统计
Get-WinEvent -FilterHashtable @{
    LogName='Security'
    ID=4771
    StartTime=(Get-Date).AddHours(-1)
} | Group-Object -Property @{
    Expression={$_.Properties[0].Value}
} | Sort-Object Count -Descending | Select-Object -First 5

结果触目惊心：过去 1 小时内共 847 次 Kerberos 预认证失败，涉及 312 个不同的用户账户，失败代码 全部为 0x25。

三、排查过程

3.1 时间偏差确认

在 DC01 上检查当前系统时间：

PS C:\> Get-Date
2026年7月4日 8:54:18

PS C:\> w32tm /query /status
跃距计数: 1
 stratum: 4
精度: -6 (每刻度 15.625ms)
根延迟: 0.0042175s
根分散: 7.8792330s
参考 ID: 0x0A006401 (源 IP: 10.0.100.1)
上次成功同步时间: 2026/5/3 3:17:41
源: time.windows.com,0x9
轮询间隔: 15 (32768s)

第一条关键线索浮出水面：上次成功同步时间为 2026年5月3日——距今已有整整两个月。DC01 在过去 62 天里完全依赖本地 CMOS 时钟运行，硬件时钟的漂移累积到了 8 分 32 秒。

3.2 NTP 架构梳理

我们域内的 NTP 架构设计为三层：

外部授时源 (ntp.aliyun.com / cn.pool.ntp.org)
    ↓
PDC 仿真器 (DC01) —— stratum 2, 权威时间源
    ↓
其他域控 (DC02/DC03/DC04) —— 从 DC01 同步 (NT5DS)
    ↓
成员服务器和客户端 —— 从域控同步 (NT5DS)

在 DC01 上检查 NTP 配置：

PS C:\> w32tm /query /configuration

[TimeProviders]
NtpServer (本地)
DllName: C:\Windows\system32\w32time.dll (本地)
Enabled: 1 (本地)
InputProvider: 0 (本地)
AllowNonstandardModeCombinations: 1 (本地)
NtpServer: time.windows.com,0x9 (本地)

VMICTimeProvider (本地)
DllName: C:\Windows\system32\vm32tm.dll (本地)
Enabled: 1 (本地)
InputProvider: 1 (本地)

这里发现了第一个配置异常：DC01 部署在 VMware vSphere 虚拟化平台上，VMICTimeProvider（Hyper-V 时间同步提供程序）处于 Enabled: 1 状态。虽然这台机器跑在 VMware 而非 Hyper-V 上，但该服务仍尝试从虚拟化层获取时间，这在物理机到虚拟机的 P2V 迁移后是一个常见的遗留配置问题。

3.3 NTP 源连通性测试

验证 DC01 到外部授时源的网络连通性：

PS C:\> Test-NetConnection time.windows.com -Port 123
WARNING: TCP connect to (20.189.79.72 : 123) failed

PS C:\> Test-NetConnection ntp.aliyun.com -Port 123  
WARNING: TCP connect to (203.107.6.88 : 123) failed

PS C:\> Test-NetConnection cn.pool.ntp.org -Port 123
WARNING: TCP connect to (120.25.115.20 : 123) failed

所有外部 NTP 服务器的 123/UDP 端口均不通。进一步排查发现，两个月前安全团队在对 FortiGate 防火墙做策略收紧时，新增了一条 ACL：

FortiGate Policy #247 (5月1日生效):
  Source: 10.0.0.0/8 (内部网段)
  Destination: ALL
  Service: HTTP, HTTPS, DNS, ICMP  (白名单模式)
  Action: ACCEPT

注意——这条规则只放行了 HTTP/HTTPS/DNS/ICMP 四种协议，NTP使用的 123/UDP 协议不在白名单中。而全域默认策略为 DENY ALL，所有未被显式放行的流量全部丢弃。

# FortiGate CLI 验证
config firewall policy
    edit 247
        set service "HTTP" "HTTPS" "DNS" "ICMP"
        # --- 缺少: "NTP" ---
    next
end

两个月前的这次安全策略变更，悄无声息地切断了 DC01 与外部 NTP 源的通信。

3.4 为什么两个月后才被发现？

这是排查中最让我困惑的问题：NTP 同步中断 62 天，为什么直到今天才触发大面积故障？

答案在于 Kerberos 协议的时间容差机制。Kerberos v5 默认允许客户端与 KDC 之间存在 5 分钟（300 秒） 的时间偏差。DC01 的 CMOS 时钟每天大约漂移 8-10 秒（这在没有时间同步的服务器上是正常范围），两个月累积偏差达到约 520 秒，刚刚突破 300 秒阈值。

精确计算：

PDC 上次成功同步: 2026-05-03 03:17:41
故障爆发时间: 2026-07-04 08:42:00
间隔: 62 天 5 小时 24 分 ≈ 5,375,400 秒
偏差: 512 秒（8 分 32 秒）
日均漂移: 512 ÷ 62 ≈ 8.26 秒/天

这意味着在 6 月 25 日前后（间隔约 53 天），时钟偏差首次突破 300 秒阈值，但恰逢周末+端午节调休，办公终端使用率低，直到今天（周二）全员到岗时才集中爆发。

3.5 为什么其他域控没有告警？

理论上 DC02/DC03/DC04 从 DC01（PDC）同步时间，DC01 偏差了，其他域控也应该跟着偏差。但检查发现：

# DC02 上检查
PS C:\> w32tm /query /status
源: DC01.contoso.com
上次成功同步时间: 2026/7/4 7:02:15

DC02 确实从 DC01 成功同步，所以它也偏差了 8 分钟。但 DC02 上没有部署任何时间偏差监控，Zabbix 的 system.localtime 监控项只采集了时间字符串而没有与外部权威源做基准比对——只要所有域控时间一致，它就认为一切正常。

四、解决方案

4.1 紧急止血（恢复业务）

在无法立即修改防火墙策略的情况下，采用分步止血方案：

Step 1：为 DC01 临时指定可达的内部 NTP 源

# 先将 DC01 指向一台可访问外网的 Linux 跳板机（已配置 NTP 服务）
w32tm /config /manualpeerlist:"10.0.50.10,0x8" /syncfromflags:MANUAL /reliable:YES /update
net stop w32time ; net start w32time
w32tm /resync

10.0.50.10 是一台运维跳板机，部署了 chrony 且能正常访问 ntp.aliyun.com。执行 resync 后确认：

PS C:\> w32tm /query /status
跃距计数: 1
 stratum: 3
上次成功同步时间: 2026/7/4 9:03:42
源: 10.0.50.10,0x8

DC01 时间已纠正。偏差从 +512 秒恢复到 ±0.5 秒以内。

Step 2：强制其他域控立即同步

1
2

# 在 DC02/DC03/DC04 上执行
w32tm /resync /nowait

Step 3：强制客户端刷新 Kerberos 票据

对于已登录但因时钟偏差导致票据失效的用户，推送以下命令：

1
2
3

# 通过 PDQ Deploy 批量推送到所有客户端
klist purge
gpupdate /force

执行后用户重新登录，域认证恢复正常。9:18 时核心业务恢复，距财务月结截止时间还剩 12 分钟。

4.2 永久修复

修复一：防火墙放行 NTP 协议

# FortiGate 配置
config firewall service custom
    edit "NTP"
        set udp-portrange 123
    next
end

config firewall policy
    edit 247
        append service "NTP"
    next
end

修复二：DC01 NTP 配置标准化

# 使用阿里云 NTP 为主要源，pool.ntp.org 为备用
w32tm /config /manualpeerlist:"ntp.aliyun.com ntp1.aliyun.com cn.pool.ntp.org" /syncfromflags:MANUAL /reliable:YES /update

# 设置合理的同步间隔
reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient /v SpecialPollInterval /t REG_DWORD /d 900 /f

# 禁用虚拟化时间提供程序（VMware 环境不需要）
reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /v Enabled /t REG_DWORD /d 0 /f

net stop w32time ; net start w32time
w32tm /resync

修复三：Windows 防火墙例外

在 DC01 的 Windows 防火墙入站规则中添加 NTP 服务端口例外，防止 Windows 自身拦截 NTP 回复：

`1`	`New-NetFirewallRule -DisplayName "NTP Inbound" -Direction Inbound -Protocol UDP -LocalPort 123 -Action Allow -Profile Domain`

五、根因分析

直接原因一目了然：域控 PDC 仿真器与外部 NTP 授时源失联 62 天，CMOS 硬件时钟漂移累积超过 Kerberos 5 分钟时钟偏差容忍阈值，导致 KDC 拒绝签发 TGT 票据。

但深入拆解，这是一起由三个独立故障叠加引发的连锁事件：

层级	故障点	描述
防火墙	安全策略收紧遗漏 NTP 协议	阻断 DC01 → 外部 NTP 源通信
配置	VMICTimeProvider 启用	虚拟化时间同步争抢 w32time 控制权
监控	时间偏差监控盲区	Zabbix 只做域内相对比对，无外部绝对基准

这三个组件构成了一个经典的故障"瑞士奶酪模型"——每一层都有空洞，恰好对齐时故障穿透。

更深层的组织问题在于：安全团队更改防火墙策略的变更流程中，影响范围评估只关注了业务系统的服务端口（HTTP/HTTPS/DB），没有审视基础设施依赖的基础协议（NTP、SNMP、Syslog）。这是运维与安全职责边界模糊地带的一个典型案例。

六、预防措施

6.1 NTP 冗余架构

将 NTP 架构从单点依赖改造为冗余架构：

            ntp.aliyun.com ──┐
          cn.pool.ntp.org ──┼── 外部冗余（≥3个源）
         ntp.tencent.com ───┘
                   │
          ┌────────┼────────┐
          ↓        ↓        ↓
        DC01     DC02     跳板机
       (PDC)  (备用NTP)  (chrony)
          │        │        │
          └────────┼────────┘
                   ↓
            其他域控 + 成员服务器 + 客户端

在 DC01 不可用或授时异常时，DC02 和跳板机可作为备用时间源，客户端通过 GPO 配置多个 NTP 服务器实现自动切换。

6.2 时间偏差专项监控

在 Zabbix 中添加基于外部权威源的时间偏差监控：

# Zabbix 自定义监控项
Key: w32tm.skew
Type: Zabbix Agent (Active)
Command: powershell -Command "$ref=(Invoke-RestMethod 'http://worldtimeapi.org/api/ip').unixtime;$local=([DateTimeOffset]::UtcNow).ToUnixTimeSeconds();[Math]::Abs($ref-$local)"
Interval: 300s
Trigger: {HOST: w32tm.skew.last()} > 300   # 偏差超过5分钟告警

配合分级告警：

偏差 > 60s：Warning，通知运维组
偏差 > 180s：High，通知运维+值班经理
偏差 > 300s：Disaster，全员通知+自动触发 w32tm /resync

6.3 防火墙变更预检清单

将以下基础设施协议纳入防火墙变更的强制影响范围评估清单：

协议	端口	用途	受影响系统
NTP	123/UDP	时间同步	DC、网络设备、服务器
SNMP	161/UDP	设备监控	交换机、防火墙、UPS
Syslog	514/UDP	日志集中	网络设备、安全设备
LDAP	389/TCP	目录查询	所有域成员
Kerberos	88/TCP,UDP	域认证	所有域成员

任何变更只要触碰到 DENY ALL 前面规则的白名单范围，必须对照此清单逐项确认。

6.4 域控健康基线巡检脚本

将以下内容加入每日健康检查 Cron：

# domain_health_check.ps1
$ntpStatus = w32tm /query /status
if ($ntpStatus -match "上次成功同步时间:\s*(\d{4}/\d{1,2}/\d{1,2})") {
    $lastSync = [datetime]::ParseExact($Matches[1], 'yyyy/M/d', $null)
    $daysSinceSync = ((Get-Date) - $lastSync).Days
    if ($daysSinceSync -gt 1) {
        Send-MailMessage -To "ops@contoso.com" -Subject "DC时间同步异常" `
            -Body "DC01 已 $daysSinceSync 天未成功同步NTP时间"
    }
}

七、总结

这次故障从接到报修到最终定位根因用时约 25 分钟，止血恢复用时约 20 分钟。几个值得复盘的点：

做得好的地方：排查逻辑链条清晰——从客户端事件日志的 KDC_ERR_SKEW → NETLOGON 5719 时钟偏差提示 → DC01 的 w32tm /query /status 上一次同步时间 → 防火墙策略审计，步步可追溯。

暴露的盲区：

监控的"自我欺骗"陷阱——Zabbix 检查域控之间时间一致就认为没问题，却没有和外部绝对时间做比对。监控设计必须考虑"两个时钟都坏掉"的场景
基础设施依赖没有文档化——安全团队不知道域控需要 NTP 协议出站，这不是安全团队的错，是运维没有把自己依赖的基础协议清单化、制度化
变更影响的"静默期"效应——从策略变更到业务可感知故障间隔 62 天，这种超长延迟让变更评审很难建立因果关联

最重要的教训：Kerberos 协议仅给 5 分钟的时钟偏差阈值，对于长期无 NTP 同步的环境来说是一颗定时炸弹。时间同步看起来是运维事务中最"无聊"的一环，但它是整个身份认证体系的基石——基石一旦松动，整栋楼都会摇晃。

一次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 能救命，也能挖坑，用之前先想清楚它会影响多少模板。

一次FortiGate HA主备切换因会话同步不完整导致业务大规模中断的排查实录

Thu, 02 Jul 2026 07:00:00 +0000

问题背景

我们公司总部机房出口部署了两台 FortiGate 600E 防火墙，以 Active-Passive 模式组成 HA 双机热备集群，承载全公司约 1800 人的互联网访问、总部-分支 IPSec VPN 隧道（6 条）、以及 ERP/OA 等业务系统的对外发布。这套 HA 集群已经稳定运行两年多，期间也经历过两次计划内主备切换（固件升级），均未出现异常。

周三上午 9:15，正值上班高峰期，监控平台突然弹出大量告警——6 条 VPN 隧道状态全部变为 Down，ERP 系统外部访问超时，OA 系统邮件收发中断。与此同时，多个分支机构电话涌入，报告无法访问总部内网资源。整个业务中断持续了约 40 分钟，影响了近 800 名在线用户的正常工作，紧急程度极高。

故障现象

故障发生时，现象非常明确且集中：

1. VPN 隧道全部中断

6 条总部到分支的 IPSec VPN 隧道在 9:15 同时从 Phase 2 Up 变为 Down，FortiGate VPN Monitor 页面显示隧道状态为 “Tunnel Down”，但 Phase 1 仍在协商中。各分支的 FortiGate 日志中出现大量：

1
2

ike: IPSec SA negotiation failed: payload malformed
ike: phase 2 negotiation failed due to timeout

2. ERP 和 OA 系统外部连接中断

Nginx 日志中 9:15 之后请求量骤降至零，直到 9:55 才开始恢复。Grafana 监控图上 TCP 连接数从 2300+ 瞬间跌至 12（仅剩防火墙自身管理连接）。

3. 内部用户互联网访问短暂中断后恢复

内部员工的互联网访问在 9:15 中断了约 30 秒后恢复，但所有需要维持长连接的应用（SSH 会话、WebSocket 推送、SIP 语音通话）全部断开，需要重新建立连接。

4. FortiGate HA 状态异常

登录防火墙管理界面后发现：原主设备（FG-600E-01）已变为 Standby，原备设备（FG-600E-02）已变为 Active。HA 切换确实发生了，但业务并未如预期无缝恢复。

关键日志片段（备机升级为 Active 后）：

ha: HA member 1 (FG-600E-01) status changed to standby
ha: HA member 2 (FG-600E-02) status changed to active
ha: HA failover triggered by: member 1 heartbeat lost
ha: Session sync incomplete: 48213/112340 sessions synced (43%)

最后一行日志格外引人注目——会话同步只完成了 43%，意味着超过 6 万条活跃会话在切换时丢失了。

排查过程

第一步：确认 HA 切换原因

首先搞清楚为什么会发生 HA 切换。登录原主设备（现在是 Standby）查看日志：

1
2
3

system: Thermal shutdown triggered: temperature threshold exceeded (65°C > 55°C)
system: Fan 1 status: failed, Fan 2 status: failed
system: HA heartbeat lost, member transitioning to standby

主设备的两个风扇同时故障，导致设备温度超过阈值触发热保护关机。这是个硬件故障，HA 切换本身是正确的保护行为。

在 FortiGate CLI 上进一步确认：

# execute ha peer status
HA Peer Status:
  Member 1 (FG-600E-01): Standby, heartbeat: OK, uptime: 0d 0h 45m (recovered)
  Member 2 (FG-600E-02): Active, heartbeat: OK, uptime: 2y 178d

# get system status
Hostname: FG-600E-01
HA Health Status: Standby
Temperature: 42°C (recovered after fan replacement by auto-restart)

主设备在温度恢复正常后自动重启并重新加入了 HA 集群（作为 Standby），但此时业务中断已经发生了。

第二步：深入分析会话同步率为什么只有 43%

这是核心问题。正常情况下，Active-Passive HA 的会话同步应该是实时进行的——主设备上每建立一条新会话，都会同步到备设备。我们检查了 HA 配置：

# show system ha
config system ha
    set group-id 10
    set group-name "FG-HA-Cluster"
    set mode a-p
    set password "xxxxxxxx"
    set hbdev "ha1" "ha2"
    set session-pickup enable
    set session-pickup-connectionless enable
    set override-disable
    set priority 100 (主) / 50 (备)
end

session-pickup enable 是开着的，session-pickup-connectionless enable 也开着（UDP 等 UDP 类会话也会同步）。配置看起来没问题。

但关键参数我们漏掉了：session-sync-dev 和 ha-session-sync-frequency。

继续查看完整配置：

# show system ha full-configuration
config system ha
    set group-id 10
    set group-name "FG-HA-Cluster"
    set mode a-p
    set password "xxxxxxxx"
    set hbdev "ha1" "ha2"
    set hbdev-vlan-id 0
    set hbdev-peerip 0.0.0.0
    set session-pickup enable
    set session-pickup-connectionless enable
    set session-sync-dev "ha1"    <-- 仅用一条心跳线同步会话
    set ha-session-sync-frequency 50    <-- 每50ms同步一批
    set override-disable
    set priority 100
end

发现了两个问题：

session-sync-dev 仅指定了 ha1——会话同步只通过一条心跳线传输，而我们有两条心跳线（ha1 和 ha2），第二条只用来传心跳，没用来传会话数据。
ha-session-sync-frequency 设为 50ms——这意味着每 50ms 才同步一批会话更新。在高并发场景下（112340 条活跃会话），50ms 的间隔会导致同步队列积压。

第三步：计算会话同步吞吐量瓶颈

FortiGate HA 会话同步的工作机制是：主设备每隔 ha-session-sync-frequency 毫秒，将这段时间内新增/变更的会话打包发送到备设备。每批最大传输约 256 条会话更新（取决于底层 TCP 窗口和 MTU）。

我们来算一下：

同步频率：50ms → 每秒 20 批
每批上限：约 256 条
每秒最大同步速率：20 × 256 = 5120 条/秒

但在上班高峰期，新会话建立速率是多少？我们从监控数据中提取：

1
2
3

# 从 FortiGate 的 session 统计看
Active sessions at 09:14: 112340
New sessions per second (average 09:00-09:15): ~18000

每秒新增约 18000 条会话，但同步速率上限只有 5120 条/秒——同步速率远低于会话创建速率，差距约 3.5 倍。

这意味着在高峰期，主设备上大量会话根本来不及同步到备设备。当切换发生时，备设备上的会话表只是"最近同步过来的那部分"，而不是完整的活跃会话集合。

此外还有一个问题：FortiGate 的会话同步是增量同步，不是全量同步。主设备只在会话建立时发送一次同步消息，后续的状态变更（如 TCP 序列号更新、窗口大小变化）不会再同步。所以即使同步速度够快，长连接的中间状态信息也是缺失的。

第四步：验证心跳通道带宽

两条心跳线分别连接在不同端口上：

1
2

ha1: port3 (1Gbps RJ45)
ha2: port4 (1Gbps RJ45)

心跳线用的是千兆端口，但 session-sync-dev 只指定了 ha1，意味着所有会话同步数据只走 port3 一条链路。实际测量 port3 在高峰期利用率：

1
2
3

# fnsysctl ifconfig port3
port3: TX packets 847320, TX bytes 634MB (09:00-09:15)
port3: RX packets 823100, RX bytes 618MB

15 分钟内 TX 634MB → 平均速率约 7Mbps。对于千兆链路来说带宽远没有用满，但问题不在带宽，而在同步频率太低导致每批数据量不够。

如果把 ha-session-sync-frequency 从 50ms 改为 1ms（最小值），每秒同步频率从 20 批提升到 1000 批，同步速率上限变为 1000 × 256 = 256000 条/秒，远超高峰期新增速率。同时如果把 session-sync-dev 改为同时使用 ha1 和 ha2，吞吐量还能翻倍。

第五步：检查历史切换记录

排查到这里，不禁要问：之前两次计划内切换为什么没出问题？我们查看 HA 事件历史：

# execute ha history
1. 2024-03-15 02:00 - Planned failover (firmware upgrade), session sync: 98.7%
2. 2025-01-10 03:00 - Planned failover (firmware upgrade), session sync: 99.2%
3. 2026-07-02 09:15 - Unplanned failover (thermal shutdown), session sync: 43%

前两次切换都是在凌晨低峰期进行的（凌晨 2-3 点），活跃会话只有约 3000 条，同步完全来得及。而这次切换发生在早高峰，活跃会话 11 万条，同步速率跟不上，就暴露了这个长期存在的隐患。

本质上是：配置在低峰期"够用"，但高峰期不够用，平时根本发现不了。

第六步：查看备机切换后的会话重建情况

备机成为 Active 后，丢失的会话需要由客户端重新建立。我们统计了业务恢复时间线：

时间	事件	活跃会话数
09:15	HA 切换完成	48213（同步过来的）
09:16	VPN Phase 1 重新协商开始	48500
09:20	6 条 VPN 隧道恢复 4 条	52300
09:30	VPN 全部恢复	61200
09:55	业务连接基本恢复	108000
10:20	会话数恢复到正常水平	112000+

从 48213 恢复到正常水平用了约 1 小时，但核心业务（VPN、ERP）在 40 分钟后才基本可用。原因是 VPN 隧道的 IKE 协商需要多轮密钥交换，加上分支 FortiGate 的 DPD（Dead Peer Detection）检测间隔为 30 秒，隧道重建有较长的等待窗口。

解决方案

紧急止血（已完成）

HA 切换已经发生，无法回滚。业务通过自然重连逐步恢复，VPN 隧道在 DPD 触发后自动重建。40 分钟后业务基本恢复，这是本次故障的实际恢复时间。

配置优化（根治）

1. 提升会话同步频率

将 ha-session-sync-frequency 从 50ms 改为 1ms（最小值），大幅提升同步吞吐量：

# FortiGate CLI
config system ha
    set ha-session-sync-frequency 1
end

修改后，同步速率上限从 5120 条/秒提升到 256000 条/秒，完全覆盖高峰期 18000 条/秒的创建速率。

2. 会话同步使用双心跳通道

将 session-sync-dev 改为同时使用 ha1 和 ha2，使会话同步数据可以走两条链路，提供冗余和更高吞吐：

1
2
3

config system ha
    set session-sync-dev "ha1" "ha2"
end

3. 启用 TCP 会话状态同步

FortiGate 7.0+ 版本支持更精细的 TCP 状态同步，可以通过以下配置启用：

config system ha
    set session-pickup enable
    set session-pickup-connectionless enable
    set session-pickup-expected enable     # 启用 expected-session 同步
end

4. 优化 HA 心跳参数

config system ha
    set hb-interval 500    # 心跳间隔从默认2s改为500ms
    set hb-lost-threshold 3  # 丢失3次心跳判定故障（1.5秒而非6秒）
end

这样主设备故障时备机能更快检测到并切换，减少中断窗口。

5. VPN 階道 DPD 间隔优化

各分支 FortiGate 的 DPD 检测间隔从 30 秒改为 5 秒：

# 各分支 FortiGate
config vpn ipsec phase1-interface
    edit "HQ-VPN"
        set dpd on
        set dpd-retryinterval 5
        set dpd-retrycount 3
    next
end

隧道中断后能在 15 秒内检测到并触发重建，而不是等 90 秒。

6.风扇故障修复

联系 FortiGate TAC 更换主设备的两个故障风扇，同时对备设备也做预防性检查。FortiGate 600E 的风扇模块是可插拔的，更换后设备温度恢复正常。

完整优化后的 HA 配置

config system ha
    set group-id 10
    set group-name "FG-HA-Cluster"
    set mode a-p
    set password "xxxxxxxx"
    set hbdev "ha1" "ha2"
    set hb-interval 500
    set hb-lost-threshold 3
    set session-pickup enable
    set session-pickup-connectionless enable
    set session-pickup-expected enable
    set session-sync-dev "ha1" "ha2"
    set ha-session-sync-frequency 1
    set override-disable
    set priority 100
end

根因分析

本次故障的根本原因是 HA 会话同步配置未针对高峰期负载进行优化，形成了"低峰期够用、高峰期不够用"的隐性缺陷。

具体分解：

同步频率过低：ha-session-sync-frequency = 50ms 导致每秒最多同步 5120 条会话，而高峰期每秒新增约 18000 条，差距 3.5 倍。大量会话在主设备上建立但来不及同步到备设备。
同步通道单线传输：session-sync-dev 仅指定 ha1，没有利用第二条心跳线 ha2 的带宽，浪费了冗余资源。
增量同步机制局限：FortiGate 的会话同步只传递会话建立事件，不传递中间状态变更。即使同步速度够快，长连接在切换后的状态信息（TCP 序列号、窗口等）也是不完整的，可能导致部分连接虽然"存在"但无法继续正常通信。
风扇硬件故障是触发因素：两台风扇同时失效导致主设备过热保护关机，触发非计划切换。但风扇故障只是导火索，真正的爆炸点是长期存在的会话同步瓶颈。
缺乏高峰期验证：前两次计划切换都在凌晨低峰期进行，同步率 98%+ 给了团队"HA 配置没问题"的错误信心。从未在高峰期做过 HA 切换演练。

预防措施

1. HA 配置基线标准化

将上述优化后的 HA 配置纳入 FortiGate 标准配置模板，所有新部署和现有集群统一升级。特别关注三个关键参数：

参数	原值	优化值	说明
ha-session-sync-frequency	50ms	1ms	同步频率最大化
session-sync-dev	ha1	ha1+ha2	双通道冗余
hb-interval	2000ms	500ms	快速故障检测

2. 建立 HA 同步率监控

在 Zabbix 中新增 FortiGate HA 同步率监控项：

# FortiGate SNMP/CLI 获取同步会话数
fnsysctl cat /proc/ha_stats | grep "sessions_synced"

# 对应的 Zabbix Item
# Type: SNMP or External Check
# Key: fortigate.ha.session.sync.rate
# Expression: sessions_synced / active_sessions_total * 100
# Trigger: sync rate < 80% for 5 minutes → P1 alert

同步率低于 80% 立即告警，让运维在切换发生前就知道同步不完整。

3. 定期高峰期 HA 演练

每季度一次，在上班高峰期（上午 9-10 点）执行计划内 HA 切换演练，验证：

会话同步率是否 ≥ 95%
VPN 阧道重建时间是否 ≤ 30 秒
业务恢复时间是否 ≤ 60 秒
监控告警是否正常触发

演练流程：提前通知全员 → 手动触发主备切换 → 记录恢复时间 → 回切并验证。

4. 硬件健康监控

FortiGate 600E 支持通过 SNMP 获取风扇状态和温度：

# Zabbix Item
fgFanStatus[port3]  # 风扇运行状态
fgSysTemperature    # 设备温度
# Trigger: fan failed OR temperature > 50°C → P2 alert

风扇故障能在切换前被发现，避免非计划切换。

5. FortiGate 固件升级

当前版本 FortiOS 7.0.13，7.2 版本改进了 HA 会话同步机制（支持更高效的批量同步和 TCP 状态同步）。计划在下个维护窗口升级到 7.2.6。

6. 文档和 SOP 更新

更新以下运维文档：

FortiGate HA 配置标准模板：包含所有优化参数
HA 故障应急预案：明确切换后 5 分钟内检查同步率、10 分钟内评估业务影响
HA 演练 SOP：季度演练流程和验收标准
硬件巡检清单：增加风扇状态、温度、电源冗余检查项

总结

这次故障让我深刻认识到一个教训：HA 双机热备 ≠ 业务零中断，配置"能跑"不等于配置"可靠"。

两年多来 HA 一直"正常工作"，是因为前两次切换恰好在低峰期，同步瓶颈从未被暴露。当真正的非计划切换发生在高峰期时，11 万条会话只同步了 43%，业务中断 40 分钟。这就像一辆车平时在市区 30km/h 没问题，上了高速才发现刹车不够力。

几个关键教训：

HA 配置必须按高峰期负载设计，同步速率要远大于高峰期会话创建速率，留足余量。
HA 演练必须在高峰期做，低峰期演练只能验证切换流程，不能验证业务连续性。
会话同步率必须纳入持续监控，不能等到切换时才发现同步不完整。
硬件故障（风扇、电源、磁盘）是 HA 切换的最常见触发因素，预防性硬件监控比事后切换恢复更重要。

FortiGate HA 的会话同步是个容易被忽视的配置细节，很多团队只关注 session-pickup enable 是否打开，却忽略了同步频率、同步通道、TCP 状态同步这些影响实际同步效果的关键参数。希望这篇排查记录能帮助同行们重新审视自己的 HA 配置，别等到故障发生才追悔莫及。

一次Windows漫游用户配置文件损坏导致终端登录卡死的排查实录

Wed, 01 Jul 2026 07:00:00 +0000

一、问题背景

周一早上 8:47，桌面运维团队的工单系统开始疯狂涌入——短短 15 分钟内收到 23 条报修，全部来自公司总部 6 楼。报修内容高度一致：“电脑开机后一直卡在’正在准备 Windows’界面"“登录进去桌面是黑的，鼠标能动但是什么都点不了"“电脑登录后桌面图标全没了，提示使用临时配置文件”。

受影响用户集中在市场部和行政部，大约 35 台终端。这批用户有一个共同特点：都配置了 AD 域漫游用户配置文件（Roaming User Profile），用户登录/注销时，配置文件会从文件服务器 \\fs01\Profiles$ 同步。

这已经是当天早上的第一波"周一综合征”，而且显然不是普通的"重启试试"能解决的。

二、故障现象

赶去 6 楼实地确认，典型故障表现如下：

现象一：登录界面长时间卡死（最严重）

输入域密码后，屏幕显示"正在准备 Windows”，转圈 20-30 分钟后才进入桌面。进入后发现桌面背景为纯黑色，任务栏无响应，开始菜单无法展开。右键桌面→个性化→主题，显示"此版本的 Windows 尚未激活"——实际上机器是正常激活的，这是 User Profile Service 加载失败的副作用。

现象二：使用临时配置文件登录

部分用户登录后一切正常，但桌面空无一物，弹窗提示：

1
2

您已使用临时配置文件登录。
您无法访问您的文件，注销时将删除在此配置文件中创建的文件。

检查 C:\Users 目录，除了正常用户名 zhangsan 外，多出一个 TEMP.000 或 TEMP.DOMAIN.000 的文件夹。系统无法加载服务器上的漫游配置文件，自动降级为本地临时配置文件。

现象三：事件查看器大量错误

在一台能勉强进入桌面的机器上打开事件查看器（eventvwr.msc），“应用程序和服务日志 → Microsoft → Windows → User Profile Service → Operational” 下连续出现多个错误事件：

Event ID 1521：Windows 无法加载漫游配置文件 \\fs01\Profiles$\zhangsan.v6。详情：拒绝访问。
Event ID 1509：Windows 无法将文件 \\fs01\Profiles$\zhangsan.v6\NTUSER.DAT 复制到 C:\Users\zhangsan。详细信息：文件或目录已损坏且无法读取。
Event ID 1502：Windows 无法加载漫游配置文件，因此正在使用本地配置文件登录。

同时在系统日志中发现：

Event ID 1000, Application Error：explorer.exe 反复崩溃，故障模块 windows.storage.dll。
Event ID 1001, Windows Error Reporting：故障存储段 1977044612335988347，类型 4。

从故障范围看，所有受影响用户漫游配置文件都指向同一台文件服务器 fs01，但 6 楼有线网络和 SMB 共享本身都是通的——用 \\fs01\Profiles$ 可以从其他终端正常访问。

三、排查过程

3.1 排除网络和SMB连通性问题

第一步先把网络层面的嫌疑排除掉。

在受影响终端上执行：

`1`	`Test-NetConnection -ComputerName fs01 -Port 445`

结果：TcpTestSucceeded : True，SMB 端口 445 通。

`1`	`net use \\fs01\Profiles$ /user:domain\adminaccount`

映射成功，可以正常 dir 浏览目录结构。说明不是基本的网络或 SMB 认证问题。

3.2 排查漫游配置文件本身

既然网络层正常，接下来直接检查漫游配置文件服务器端的文件状态。

登录文件服务器 fs01，进入 D:\Profiles$，找到受影响用户（以 zhangsan 为例）的配置文件目录 zhangsan.v6（Windows 10/11 漫游配置文件默认带 .v6 版本后缀）。

`1`	`Get-ChildItem -Path "D:\Profiles$\zhangsan.v6" -Recurse \| Measure-Object -Property Length -Sum`

输出结果令人困惑：

1
2
3

Count    : 11247
Average  : ...
Sum      : 8421162376

——这个用户的漫游配置文件足足 8.4GB！

再检查核心文件 NTUSER.DAT（用户注册表 HKCU 配置单元）：

`1`	`Get-Item "D:\Profiles$\zhangsan.v6\NTUSER.DAT"`

1
2
3

Mode         LastWriteTime       Length Name
----         -------------       ------ ----
-a----  2026/6/27  18:14    3218546688 NTUSER.DAT

NTUSER.DAT 高达 3.2GB！正常情况下，这个文件通常在 1MB 到 30MB 之间。3.2GB 的 NTUSER.DAT 意味着用户注册表配置单元存在严重膨胀——可能是某个应用程序疯狂向注册表写入数据。

3.3 发现关键线索

逐个检查受影响用户后，发现一个规律：

所有受影响用户的 NTUSER.DAT 文件最后修改时间都是上周五（6月27日）18:10~18:20 之间。
其中 5 个用户的 NTUSER.DAT 文件大小为 0 字节——文件已损坏。
其余用户的 NTUSER.DAT 大小从 500MB 到 3.2GB 不等。

这指向一个非常明确的方向：周五下班高峰时段，文件服务器发生了某种写入中断，导致正在同步的漫游配置文件损坏。

接下来排查文件服务器的事件日志：

1
2
3

Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { 
    $_.TimeCreated -gt '2026-06-27T17:00:00' -and $_.TimeCreated -lt '2026-06-27T18:30:00' 
} | Where-Object { $_.LevelDisplayName -eq 'Error' -or $_.LevelDisplayName -eq 'Warning' } | Format-Table TimeCreated, Id, ProviderName, Message -Wrap

关键发现——System 日志中：

2026-06-27 18:12:34  Event ID 129, source: storahci
Reset to device, \Device\RaidPort0, was issued.

2026-06-27 18:12:35  Event ID 153, source: disk
The IO operation at logical block address 0x3a84e200 for Disk 2 (PDO name: \Device\0000003a) was retried.

2026-06-27 18:14:02  Event ID 129, source: storahci
Reset to device, \Device\RaidPort0, was issued.

2026-06-27 18:14:19  Event ID 153, source: disk
The IO operation at logical block address 0x3a84e200 for Disk 2 (PDO name: \Device\0000003a) was retried.

2026-06-27 18:14:21  Event ID 5142, source: ClusSvc
Cluster Shared Volume 'Volume1' ('D:') has entered a paused state because of 'STATUS_CONNECTION_DISCONNECTED(c000020c)'. All I/O will temporarily be queued until a path to the volume is reestablished.

确认根因方向：文件服务器存储控制器发生了故障切换！

在周五 18:12 到 18:14 之间，fs01 文件服务器的 RAID 控制器出现硬件级 IO 错误，触发了 Windows 故障转移集群的 CSV（Cluster Shared Volume）暂停。虽然集群在 18:14:21 之后恢复了路径连接，但在这个 2 分钟的窗口内：

部分正在注销的用户，其终端正在向 \\fs01\Profiles$ 回写漫游配置文件
SMB Write 操作因为底层磁盘 IO 失败而中断
NTUSER.DAT 和其他配置文件的写入处于"半完成"状态
部分文件的元数据（MFT 记录）写入完成但数据块未落盘，导致文件系统层面能"看到"文件，但读取时返回 CRC 错误

3.4 验证客户端注册表

回到受影响终端，进一步验证客户端侧的配置：

`1`	`reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList" /s`

在 ProfileList 下，受影响用户的 ProfileImagePath 指向 C:\Users\zhangsan，但 State 键值为 0x00008000（表示正在使用临时配置文件）。RefCount 和 CentralProfile 子键中的 SMBShare 仍然指向 \\fs01\Profiles$。

同时在 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileGuid 中，找到了损坏配置文件对应的 GUID，Flags 值包含 0x00000004（MANDATORY_PROFILE，强制配置文件标志），进一步证实了系统已将本地临时配置文件设为"强制"模式。

3.5 追问：为什么NTUSER.DAT膨胀到3.2GB？

解决燃眉之急后，顺藤摸瓜追查 NTUSER.DAT 膨胀的原因。用 Sysinternals 的 ProcMon 在重建配置文件后的用户 session 中监控注册表活动，发现一个叫 DataSyncAgent.exe 的服务进程（来自某第三方数据同步软件）以每秒 500+ 次的频率向 HKCU\Software\DataSync\FileHistory\* 写入文件的同步状态记录，每天累积约 200MB 的注册表写入。

这个软件本应把同步状态写入 SQLite 数据库，但配置错误导致它把所有记录写进了 HKCU。NTUSER.DAT 在 3 个月内从正常的 5MB 膨胀到 3.2GB——这是隐患，而磁盘故障只是触发器。

四、解决方案

4.1 紧急止血（周一 9:30）

对于 NTUSER.DAT 为 0 字节的 5 个用户（配置文件已彻底损坏且不可恢复）：

将服务器端的配置文件目录改名备份：

`1`	`Rename-Item "D:\Profiles$\zhangsan.v6" "D:\Profiles$\zhangsan.v6.CORRUPT"`

让用户重新登录，系统自动在服务器端创建全新的漫游配置文件。
从备份目录中手动恢复 Desktop、Documents、Favorites 等关键文件夹。

对于 NTUSER.DAT 巨大但有内容的其他用户（约 30 人）：

在服务器端用 regedit 加载损坏的 NTUSER.DAT 为配置单元，检查是否能正常读取——大部分可以。
用 Windows 内置工具压缩：compact /c /s:"D:\Profiles$\zhangsan.v6"。
在用户终端清理 C:\Users\zhangsan 本地缓存后重新登录，触发从服务器重新同步。

4.2 修复DataSyncAgent注册表泄漏

定位到 DataSyncAgent 的服务配置文件 C:\Program Files\DataSync\config.ini，发现：

1
2

[Storage]
Backend=registry

应改为：

1
2
3

[Storage]
Backend=sqlite
Path=C:\ProgramData\DataSync\sync_history.db

修改后重启 DataSyncAgent 服务。然后编写清理脚本，批量清理受影响用户 HKCU\Software\DataSync\FileHistory 下累积的数百万条过期记录：

Get-ChildItem "D:\Profiles$\*.v6\NTUSER.DAT" | ForEach-Object {
    $hivePath = $_.FullName
    reg load HKLM\TempHive $hivePath
    reg delete "HKLM\TempHive\Software\DataSync\FileHistory" /f
    reg unload HKLM\TempHive
    compact /c /s:$hivePath
}

注意：reg load 操作需要以管理员身份运行，卸载前务必确认无其他进程持有句柄。

4.3 存储硬件修复

fs01 的 RAID 控制器间歇性 IO 错误指向磁盘背板或控制器固件问题。运维团队安排当天晚间窗口更换了 Disk 2（SMART 报告 Reallocated_Sector_Ct=328），升级了 RAID 控制器固件到厂商推荐版本。

五、根因分析

这次故障由两层原因叠加导致：

直接触发原因：文件服务器 fs01 的 RAID 控制器出现硬件级 IO 故障，触发 Windows 故障转移集群 CSV 进入暂停状态。在约 2 分钟的 IO 中断窗口内，正值周五 18:10-18:20 的下班高峰，大量用户同时注销并回写漫游配置文件。SMB Write 请求因底层磁盘 IO 失败而中断，NTUSER.DAT 等核心文件写入半途而废，导致文件损坏（部分为 0 字节，部分内容乱码）。

放大因素（根因）：DataSyncAgent 第三方同步软件错误配置，把每日 200MB 的同步状态记录写入了 HKCU\Software\DataSync\FileHistory，导致 NTUSER.DAT 从正常 5MB 膨胀到 500MB~3.2GB。巨大的 NTUSER.DAT 使得：

正常的登录/注销同步时间从 5 秒增加到 30-120 秒
同步过程中碰到 IO 中断的概率被急剧放大（暴露窗口扩大了 10-100 倍）
文件越大，写入中断后损坏的概率越高

为什么只有 6 楼的用户受影响？ 6 楼市场部和行政部是 DataSyncAgent 软件的重度用户（用于跨终端文件同步需求），其他楼层的用户未安装该软件，NTUSER.DAT 体积正常（5-20MB），虽然也经历了同样的磁盘 IO 中断，但因为文件写入时间极短（不到 1 秒），恰好错过了故障窗口。

六、预防措施

6.1 漫游配置文件优化

通过 GPO 限制漫游配置文件大小和行为：

计算机配置 → 管理模板 → 系统 → 用户配置文件 → 限制漫游配置文件大小：设置为 500MB（NTUSER.DAT 正常情况下不超过 30MB，留充足余量）
用户配置 → 管理模板 → 系统 → 用户配置文件 → 排除漫游配置文件中的目录：添加 AppData\Local;AppData\LocalLow;Downloads;Saved Games
启用文件夹重定向：将 Desktop、Documents、Pictures 通过 GPO 重定向到 \\fs01\Users$，减少漫游配置文件本身的体积

6.2 文件服务器端加固

在 fs01 上启用卷影复制（VSS），设置每天两次的快照计划，保留 14 天
为存储控制器配置主动告警：Event ID 129（storahci reset）和 Event ID 153（disk retry）触发 P1 告警
磁盘 SMART 监控：Reallocated_Sector_Ct、Current_Pending_Sector、Offline_Uncorrectable 任一指标非零即报警
CSV 暂停事件（Cluster Event ID 5142）触发 P0 告警，5 分钟内未恢复则自动电话通知

6.3 第三方软件治理

建立域内终端软件白名单机制：所有写入 HKCU 的应用程序需提供"注册表写入量评估报告"
新软件接入流程增加注册表行为审计环节：用 ProcMon + Sysmon 在测试机上运行 24 小时，分析 HKCU 写入量和频率
DataSyncAgent 问题修复后全网推送，并通过 SCCM 合规基线强制执行 Backend=sqlite 配置

6.4 高可用存储架构改进

虽然当前文件服务器已是双节点 Windows 故障转移集群，但此次事件暴露了一个盲区：故障切换窗口内的 IO 中断无法完全避免。

改进方案：

为漫游配置文件共享启用 SMB 连续可用性（Set-SmbShare -Name Profiles$ -ContinuouslyAvailable $true），结合 SMB Transparent Failover 减少切换期间的 IO 丢失
评估将漫游配置文件后端迁移到 DFS-N + DFS-R，利用多副本降低单点故障影响（虽然 DFS-R 对漫游配置文件有自身限制，需谨慎评估）

七、总结

这次故障表面上是"配置文件损坏"的简单问题，但背后暴露了三个层次的技术债务：

监控盲区：文件服务器存储控制器的 IO 重试和 CSV 暂停事件只有事后查询才知道，缺少实时告警。从故障发生到被发现，间隔了整整 60 个小时（周五晚到周一早）。
配置漂移：DataSyncAgent 软件错误配置 3 个月无人发现，因为 “能用就行"的心态让注册表悄悄膨胀到 3.2GB。
架构薄弱：漫游配置文件把所有用户状态绑定到单一 SMB 共享的单点，且缺少有效的隔离机制——一个应用的注册表泄漏可以拖垮整栋楼的用户登录。

对运维团队最大的教训是：“慢速故障”（Slow Failure）比"硬故障"更具破坏性。 磁盘 IO 偶尔重试没人关注，注册表一点点膨胀没人关注，直到某个周一早上 35 人同时登录卡死，才被一记闷棍打醒。把监控和告警的颗粒度做到"异常即感知”，远比"故障后排查"更划算。

一次服务器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 网卡，其他发行版和网卡型号请根据实际情况调整。

一次RADIUS服务器EAP-TLS证书过期导致全公司802.1X认证大规模掉线的排查实录

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

问题背景

公司办公网采用 802.1X 认证，无线和有线全部走 FreeRADIUS + Microsoft AD CS 颁发的 EAP-TLS 客户端证书，三年前由前同事搭建，当时写了个 openssl 一键生成脚本签了 10 年期的自建 CA，所有终端的根证书、FreeRADIUS 服务器证书、客户端证书全部挂在这棵 CA 下。

2026 年 6 月 28 日上午 9 点 47 分开始，全公司 8 栋办公楼先后出现大规模无线断连和有线认证失败，研发部门、客服中心、工厂车间反馈最为集中。Zabbix 上 AP 的认证成功率从 99.6% 直线掉到 23%，无线控制器每秒钟有 400+ 重新认证请求堆积。我们的 2000+ 员工终端、IoT 设备、IP 电话几乎全部受影响，初步估计单是业务停滞损失每小时就在十万级别。事故发生前一周，刚好有同事反馈"Windows 提示网络证书有问题"，但当时没人在意——这就是典型的预警被忽视引发的连锁反应。

故障现象

9 点 47 分开始，IT 群开始密集弹消息：

【研发2部-工位A12】电脑右下角弹"无法连接到网络 WiFi"
【研发2部-工位A13】重连失败，提示"无法验证服务器身份"
【客服中心】IP电话全部掉线，话机显示注册失败
【6楼车间】扫码枪连不上AP，无法作业
【财务部】连有线网提示"无法完成身份验证"

无线场景：手机和笔记本弹出"无法验证服务器身份 / Unable to verify server identity"，但 SSID 还是能搜到，点击连接后直接失败
有线场景：插了网线的工位弹出黄色感叹号，登录界面反复弹出要求输入域账号但怎么输都通不过
IoT 设备：IP 电话、扫码枪、门禁设备、打印机几乎全部离线

抓包看无线控制器上的 Radius 报文：

[FreeRADIUS log] (5) eap_tls: ERROR: TLS Alert read:fatal:certificate unknown
[FreeRADIUS log] (5) eap_tls: ERROR: TLS_accept: Failed in unknown state
[FreeRADIUS log] (5) eap: ERROR: Failed continuing EAP TLS (13) session
[FreeRADIUS log] (5)     [eap] = reject
[FreeRADIUS log] (5)   [authz] = reject
[FreeRADIUS log] (5) Auth: (5) Login incorrect (eap_tls: Failed to verify certificate):
[FreeRADIUS log] (5) } # server outer-eappeap-inner-tls { ... }

而前一天最后一次成功的认证日志时间戳是 6 月 27 日 23:58:14。问题集中在上午 9 点 47 分之后，所有终端都无法完成 EAP-TLS 握手。

排查过程

第一阶段：现场确认范围

第一反应是 Radius 服务挂了，先用 SSH 登入两台 FreeRADIUS 节点查看服务状态：

# radius01 和 radius02 是 FreeRADIUS 主备集群
ssh radius01 "systemctl status freeradius | head -20"
# ● freeradius.service - FreeRADIUS multi-protocol policy server
#    Active: active (running) since Mon 2024-01-15 14:22:08 CST
# 一切正常

ssh radius01 "radtest test test 127.0.0.1 0 testing123"
# Received Access-Reject
# 嗯,本机 PAP 测试也失败

这个 PAP 测试失败很关键——这意味着不是网络问题、不是设备问题，是 FreeRADIUS 本身拒绝认证。如果 Radius 进程崩溃、配置错误，至少本地 radtest 应该成功。

第二阶段：定位具体错误原因

打开 FreeRADIUS 的详细日志模式：

1
2
3

ssh radius01 "radiusd -X 2>&1 | tee /tmp/radius-debug.log" &
# 模拟一次无线认证
radtest user@corp password 10.1.1.100 0 testing123

详细日志关键片段：

(1) eap_tls: ERROR: SSL says error 10 : certificate has expired
(1) eap_tls: ERROR: TLS Alert write:fatal:certificate expired
(1) eap: ERROR: Failed continuing EAP TLS (13) session
(1)     [eap] = reject

根因锁定：RADIUS 服务器上 EAP-TLS 链路用的证书已经过期。这个证书就是 FreeRADIUS 服务器证书，是当年用自建 CA 签的，签发 10 年有效期，已经在 6 月 28 日 00:00:00 过期。

第三阶段：确认所有关联证书状态

接下来要查清楚：到底过期了哪几张证书，根 CA 有没有一起过期：

ssh radius01 "ls -la /etc/freeradius/certs/"
# total 64
# -rw-r--r-- 1 root root 2151 Jun 15 2024 ca.pem       # CA 根证书
# -rw-r--r-- 1 root root 2200 Jun 15 2024 server.pem   # Radius 服务器证书
# -rw-r--r-- 1 root root 2151 Jun 15 2024 server.crt

# 查看每张证书的过期时间
for cert in /etc/freeradius/certs/{ca,server}.pem; do
  echo "=== $cert ==="
  openssl x509 -in $cert -noout -dates -subject -issuer
done

输出：

=== /etc/freeradius/certs/ca.pem ===
notBefore=Jun 15 14:22:08 2024 GMT
notAfter =Jun 15 14:22:08 2034 GMT        # 根 CA 还有 8 年
subject= /CN=Corp Internal CA
issuer=  /CN=Corp Internal CA            # 自签根

=== /etc/freeradius/certs/server.pem ===
notBefore=Jun 15 14:22:08 2024 GMT
notAfter =Jun 15 14:22:08 2026 GMT        # 昨天 00:00 过期！
subject= /CN=radius.corp.example.com
issuer=  /CN=Corp Internal CA            # 由上面这个 CA 签发

一目了然：根 CA 还在有效期，但服务器证书是 2 年前生成时签了 2 年（前面写的 10 年期是 CA 本身），server.pem 在 6 月 28 日 00:00 过期。我之前对脚本记忆有误，所以忽视了 Server 证书本身的 2 年有效期。

更糟糕的是，这个 server.pem 同时被三处使用：

FreeRADIUS 主配置文件 /etc/freeradius/eap.conf 和 mods-available/eap
FreeRADIUS 的客户端工具（用于向 AD CS 申请证书的 SCEP 接口）
AD CS 上挂的 Web Enrollment / OCSP 服务也用了同一张证书做 SSL 绑定

第四阶段：紧急止血

完全处理需要重新签发服务器证书、推送新的 CA/服务器证书到 2000+ 终端，过程需要数小时。在此之前先用 OpenSSL 临时续签一张短期证书：

# 在 radius01 上生成 CSR，向自建 CA 申请一张 30 天短期证书用于止血
cd /etc/freeradius/certs
openssl req -new -key server.key -out server.csr \
  -subj "/CN=radius.corp.example.com" \
  -addext "subjectAltName=DNS:radius.corp.example.com,DNS:radius01.corp.example.com,IP:10.1.1.100"

openssl x509 -req -in server.csr -CA ca.pem -CAkey ca.key \
  -CAcreateserial -out server.pem -days 30 \
  -sha256 -extfile <(printf "subjectAltName=DNS:radius.corp.example.com,DNS:radius01.corp.example.com,IP:10.1.1.100")

然后重启 FreeRADIUS：

ssh radius02 "systemctl restart freeradius"
ssh radius01 "systemctl restart freeradius"
# 重新测试
radtest test test 127.0.0.1 0 testing123
# Received Access-Accept

但这只是 FreeRADIUS 这一端，终端上的根 CA 信任链没变——终端有之前手工导入的根 CA，CA 还在有效期，EAP-TLS 客户端对服务器证书的校验会校验 issuer 链 + 过期时间。新签的 30 天证书由同一个 CA 签发，CA 链没变，所以理论上已部署过 CA 根证书的终端不需要重新安装 CA。

可是事实是无线终端还是连不上！继续抓 FreeRADIUS 详细日志：

1
2

(1) eap_tls: ERROR: SSL says error 26 : unsupported certificate purpose
(1) eap_tls: ERROR: TLS Alert write:fatal:unsupported certificate

新问题！原因是脚本里签证书时没加 extendedKeyUsage=serverAuth 扩展：

# 第一次签发的命令
openssl x509 -req -in server.csr -CA ca.pem -CAkey ca.key \
  -CAcreateserial -out server.pem -days 30 -sha256
# 没有 extfile 参数

正确的签发方式需要加 EKU 扩展：

cat > /tmp/extfile.cnf <<'EOF'
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:radius.corp.example.com, DNS:radius01.corp.example.com, IP:10.1.1.100
EOF

openssl x509 -req -in server.csr -CA ca.pem -CAkey ca.key \
  -CAcreateserial -out server.pem -days 30 \
  -sha256 -extfile /tmp/extfile.cnf

再次重启后 FreeRADIUS 正常签出 Received Access-Accept，已信任 CA 根证书的终端陆续恢复。

第五阶段：长期解决 - 自动化证书轮换

30 天临时证书只是续命。要根治，必须做完整的自动化证书轮换：

1. 用 AD CS 替代自建 OpenSSL 签发

# radius01 申请新证书时使用 certreq
$inf = @"
[Version]
Signature = "`$Windows NT`$"
[NewRequest]
Subject = "CN=radius.corp.example.com"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
HashAlgorithm = SHA256
[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.1  ; Server Authentication
OID = 1.3.6.1.5.5.7.3.2  ; Client Authentication
[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns= radius.corp.example.com&"
_continue_ = "dns= radius01.corp.example.com&"
_continue_ = "ipaddress= 10.1.1.100&"
[RequestAttributes]
CertificateTemplate = RadiusServerTemplate
"@
$inf | Out-File -Encoding ASCII C:\radius01.inf
certreq -new C:\radius01.inf C:\radius01.req
certreq -submit C:\radius01.req C:\radius01.cer
certreq -accept C:\radius01.cer

2. 写 cron 自动化续签 + 部署

#!/bin/bash
# /usr/local/sbin/radius-cert-renew.sh
# 每 30 天提前 60 天轮换，确保证书永远不会过 60 天有效期
DAYS_BEFORE_EXPIRY=60
CERT_PATH="/etc/freeradius/certs/server.pem"
THUMBPRINT=$(openssl x509 -in $CERT_PATH -noout -fingerprint -sha256 | cut -d= -f2)
EXPIRY=$(openssl x509 -in $CERT_PATH -noout -enddate | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 ))

if [ $DAYS_LEFT -gt $DAYS_BEFORE_EXPIRY ]; then
  echo "[OK] 证书还有 $DAYS_LEFT 天，无需续签"
  exit 0
fi

echo "[WARN] 证书还有 $DAYS_LEFT 天，开始续签流程"

# 1. 备份旧证书
cp -a $CERT_PATH ${CERT_PATH}.bak-$(date +%Y%m%d)
cp -a /etc/freeradius/certs/server.key /etc/freeradius/certs/server.key.bak-$(date +%Y%m%d)

# 2. 通过 certreq 申请（需要 winexe 调 Windows 端 certreq）
winexe -U corp\\admin%password //radius01 "cmd /c certreq -enroll -machine RadiusServerTemplate" 2>/dev/null
# 把新证书导出到 Linux
smbclient //radius01/c$ -U corp\\admin%password -c "cd \ProgramData\Microsoft\Crypto\RSA\MachineKeys; ls" > /dev/null
# ...省略实际取回流程

# 3. 重启 FreeRADIUS
systemctl restart freeradius

# 4. 验证
sleep 5
radtest test test 127.0.0.1 0 testing123 && echo "[OK] 续签完成并通过测试"

3. 终端侧：使用 SCEP/NDES 自动注册

旧流程是 IT 同事手工给每台电脑装 CA 根证书，效率低且容易漏装。改用 NDES + Intune SCEP：

# Intune SCEP 策略自动向 AD CS 申请客户端证书并推送
# 设备配置 - 配置文件 - SCEP 证书
# 证书类型: 设备
# Subject Name Format: CN={{DeviceId}},CN={{AAD_Device_ID}}
# SAN: URI={{DeviceId}}
# Key Usage: KeyEncipherment, DigitalSignature
# Key Size: 2048
# Hash Algorithm: SHA-2
# Extended Key Usage: 1.3.6.1.5.5.7.3.2  (Client Auth)
# SCEP Server URLs: https://ndes.corp.example.com/certsrv/mscep/mscep.dll

解决方案

最终落地的方案分三层：

止血阶段（T+0 ~ 30 分钟）：在 FreeRADIUS 上用 OpenSSL + 自建 CA 临时签发 30 天带 extendedKeyUsage=serverAuth,clientAuth 和 subjectAltName 的服务器证书，重启服务后约 70% 已部署 CA 根证书的终端自动恢复，剩下 30% 是历史装机从未导入过 CA 的工位机，由现场 IT 同事手工导入。

短期修复（T+1 ~ 2 周）：将 FreeRADIUS 证书切到 AD CS 颁发的 5 年期 RadiusServerTemplate 证书（受 5 年 CA 模板限制），由 certreq 自动续签脚本每 30 天检查并续签，提前 60 天主动轮换，避免再出现凌晨过期无人值守的情况。

长期根治（T+1 ~ 2 月）：

CA 侧：把自建 OpenSSL CA 整个迁移到企业 AD CS，使用 5 年期 SubCA 模板并启用 autoenroll，所有 2000+ 终端通过 GPO 自动注册 RootCA 信任
客户端侧：IoT 设备、扫码枪、IP 电话改为 SCEP 自动注册客户端证书，免去手工导入
监控侧：在 Zabbix 上添加对 /etc/freeradius/certs/*.pem 的扫描，所有证书剩余有效期 < 90 天的都触发告警，证书清单每周发邮件给安全组
流程侧：建立"证书生命周期"维基页面，所有证书的签发日期、到期日期、负责人、轮换 SOP 一目了然，离到期 90/60/30/7 天分别触发不同级别告警

根因分析

深挖下来，这次事故有四个相互独立的根因叠加：

EAP-TLS 服务器证书的有效期被脚本写死成 2 年，而前同事把这个脚本注释为"自建 CA 10 年期"，导致后续接手的人（包括我）误以为整套体系都是 10 年一换
没有任何证书过期监控，Zabbix 监控的是 Radius 服务进程存活、AP 认证成功率，但没人意识到"证书"也是一种需要监控的资源
历史装机太松散，CA 根证书在客户端没有强制 GPO 推送，部分工位机是当年实习生手工装的，证书已经丢/坏，并且这个状态在 AP 重新认证时才暴露
缺乏证书全生命周期管理流程，没有 PKI 文档、没有续签 SOP、没有 SCEP/NDES 这种"证书可以自动过期和续签"的设计，本质上还是手工运维的思路在管理 CA

预防措施

基于这次踩坑，建立了下面这套预防体系：

1. 证书全生命周期管理系统

# 每周日凌晨 3 点扫描所有 Radius/网关证书，邮件给安全组
#!/bin/bash
# /usr/local/sbin/cert-watchdog.sh
RECIPIENT="security-team@corp.example.com"
WARN_DAYS=90
CRITICAL_DAYS=30
CERT_DIRS=("/etc/freeradius/certs" "/etc/nginx/ssl" "/etc/strongswan/ipsec.d")

REPORT=""
for dir in "${CERT_DIRS[@]}"; do
  for cert in $dir/*.pem $dir/*.crt; do
    [ -f "$cert" ] || continue
    EXPIRY=$(openssl x509 -in "$cert" -noout -enddate 2>/dev/null | cut -d= -f2)
    [ -z "$EXPIRY" ] && continue
    DAYS_LEFT=$(( ($(date -d "$EXPIRY" +%s) - $(date +%s)) / 86400 ))
    SUBJECT=$(openssl x509 -in "$cert" -noout -subject | cut -d= -f2-)
    if [ $DAYS_LEFT -lt $CRITICAL_DAYS ]; then
      REPORT+="[CRITICAL] $cert 剩 ${DAYS_LEFT} 天 - $SUBJECT\n"
    elif [ $DAYS_LEFT -lt $WARN_DAYS ]; then
      REPORT+="[WARN] $cert 剩 ${DAYS_LEFT} 天 - $SUBJECT\n"
    fi
  done
done

if [ -n "$REPORT" ]; then
  echo -e "证书过期预警:\n$REPORT" | mail -s "【证书过期预警】$(date +%Y-%m-%d)" $RECIPIENT
fi

2. Zabbix 自定义监控项

# /etc/zabbix/zabbix_agentd.d/cert_expiry.conf
UserParameter=cert.expiry[*],openssl x509 -in $1 -noout -enddate 2>/dev/null | cut -d= -f2 | xargs -I{} date -d "{}" +%s
# 触发器: 当 cert.expiry[/etc/freeradius/certs/server.pem] - now() < 7776000 (90天) 时触发 warning
#          < 2592000 (30天) 时触发 high
#          < 604800 (7天) 时触发 disaster

3. 终端 GPO 强制信任企业 CA

Computer Configuration
  → Policies
    → Windows Settings
      → Security Settings
        → Public Key Policies
          → Certificate Services Client - Auto-Enrollment
            ☑ 自动注册证书
            ☑ 续签过期的证书
            ☑ 更新正在使用的证书

4. SCEP/NDES 自动客户端证书

所有域内电脑和受管移动设备通过 Intune SCEP 自动向 AD CS 申请客户端证书，证书有效期 1 年自动续签，永久不需要 IT 同事手工介入。

5. 红蓝对抗演练

每季度模拟"把 Radius server.pem 替换为已过期证书"，演练运维团队的应急响应速度和流程顺畅度，确保事故响应的肌肉记忆。

总结

这次事故最深的教训，是证书这种"非生命体"资源在大多数运维同学的监控盲区里。它不像磁盘、CPU、内存那样有常规的仪表盘告警，往往只在过期那一刻才"砰"地炸出来，但影响范围却是公司级别的。

回头看，EAP-TLS 体系的设计原则应该是"证书全生命周期"——从 CA 设计、模板、签发、续签、客户端分发、信任链维护到过期监控，每一步都要有自动化兜底。任何依赖"人工记得去续签"的设计，最终都会在某个凌晨、某个长假、某个新人接手的时刻翻车。

我们这次虽然用 30 天临时证书快速止血，没有出现业务数据丢失，但这种"凭证类"的故障本应通过前置的告警 + 自动续签 + 监控来彻底规避。建议所有使用 802.1X / EAP-TLS / HTTPS 证书 / IPsec 证书的团队，都把"证书全生命周期管理"作为年度安全审计的必查项，并且把 Zabbix / Prometheus 对证书过期天数的监控当作 P0 级别来对待——这绝不是"锦上添花"，而是"救命的最后一道防线"。

一次交换机物理环路导致整栋楼广播风暴瘫痪的排查实录

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

问题背景

某周一上午9:15，正是全员打卡上班的高峰时段，IT服务台电话瞬间被打爆——6楼整层约120台终端全部断网，OA系统、邮件、ERP一律打不开，连本地文件共享都无法访问。与此同时，5楼和7楼也开始零星报障，部分终端时断时续。

这是一栋12层的办公大楼，核心交换机是两台华为S12700做CSS集群，每层楼一台华为S5735-L48T4X-A做接入，上行10G光纤到核心，接入交换机之间没有横向互联。6楼接入交换机是SW-F6-01，负责6楼全部48个信息点。网络拓扑很标准：核心—接入两层架构，按理说不该出现环路。但事实是——6楼瘫痪了，而且速度极快，从第一个报障电话到整层断网，不到3分钟。

紧急程度：P1——整个楼层业务中断。

故障现象

从监控系统和现场排查来看，故障表现非常典型：

1. 终端侧现象

所有6楼终端Ping网关10.6.254.1丢包率95%以上，偶尔通一个包延迟高达2000ms+
DHCP无法获取地址，已有IP的终端ARP表混乱，网关MAC频繁跳变
部分终端右下角网络图标黄色感叹号，提示"未识别的网络"

2. 交换机侧现象

登录SW-F6-01，CPU利用率飙到99%，命令行响应极慢，display cpu-usage需要30秒才返回
display interface brief看到多个端口流量异常：G0/0/1到G0/0/48中有十几个端口出方向流量持续跑到线速（1000Mbps）
display mac-address表项数量从正常的200条暴涨到64000条（MAC表容量上限），且MAC地址在端口之间疯狂漂移
核心交换机CSS集群CPU也达到78%，6楼VLAN对应的VLANIF接口入方向流量达到8Gbps（正常不到200Mbps）

3. 日志关键信息

SW-F6-01上持续刷出以下日志：

%%01L2IFPPI/4/MAC_FLAPPING_ALARM(l):OID 1.3.6.1.4.1.2011.5.25.160.3.7
MAC address 00e0-fc12-3456 has flapped from GE0/0/5 to GE0/0/22, lasted 2 seconds.
%%01L2IFPPI/4/MAC_FLAPPING_ALARM(l):OID 1.3.6.1.4.1.2011.5.25.160.3.7
MAC address 00e0-fc12-3456 has flapped from GE0/0/22 to GE0/0/5, lasted 1 seconds.
%%01L2IFPPI/4/MAC_FLAPPING_ALARM(l):OID 1.3.6.1.4.1.2011.5.25.160.3.7
MAC address ffff-ffff-ffff in VLAN 206 has flapped from GE0/0/5 to GE0/0/22

核心交换机日志：

1
2

%%01SECE/4/ARPMISS(l):Speed of ARP Miss packets exceeded the configured rate limit.
%%01SECE/4/ARPMISS(l):Speed of ARP Miss packets exceeded the configured rate limit.

MAC地址在GE0/0/5和GE0/0/22之间反复跳变，且出现了全F的广播MAC漂移——这是典型的二层环路广播风暴特征。

排查过程

第一步：确认故障范围

先通过核心交换机确认故障边界。登录核心CSS集群，查看各VLAN接口流量：

<CORE-SW> display interface Vlanif 206
Vlanif206 current state: UP
Line protocol current state: UP
Description: 6F-Office-VLAN
Input bandwidth utilization: 98%    ← 正常应 <5%
Output bandwidth utilization: 3%
Input: 8234567 packets/sec, 8.2 Gbps
Output: 12345 packets/sec, 12 Mbps

VLAN 206（6楼办公VLAN）入方向流量8.2Gbps，而上行10G链路带宽的80%+都被这些垃圾流量吃掉了。其他楼层VLAN流量正常。

结论：故障范围锁定在6楼VLAN 206，且是二层广播风暴。

第二步：判断环路类型

广播风暴的常见原因有三：物理环路、ARP风暴攻击、蠕虫病毒扩散。通过以下特征快速判断：

特征	物理环路	ARP攻击	蠕虫病毒
MAC漂移	两个端口间高频往复	分散，无规律	分散
广播包占比	>95%	ARP包为主	混合流量
全F广播MAC漂移	有	无	偶尔
流量对称性	两个端口双向跑满	单向为主	不定

SW-F6-01的MAC漂移集中在GE0/0/5和GE0/0/22两个端口之间，且双向流量都跑到线速——典型物理环路特征。

第三步：定位环路端口

在SW-F6-01上执行MAC漂移检测，获取精确的环路端口对：

[SW-F6-01] display mac-address flapping
Flapping VLAN 206:
MAC Address    From/To        Flapping Time
00e0-fc12-3456 GE0/0/5  -> GE0/0/22    2026-06-29 09:17:32
00e0-fc12-3456 GE0/0/22 -> GE0/0/5     2026-06-29 09:17:33
00e0-fc89-abcd GE0/0/5  -> GE0/0/22    2026-06-29 09:17:33
00e0-fc89-abcd GE0/0/22 -> GE0/0/5     2026-06-29 09:17:34

MAC地址只在GE0/0/5和GE0/0/22之间跳变，环路就出在这两个端口之间。

第四步：确认物理连接

通过网管系统查看GE0/0/5和GE0/0/22的端口描述信息：

[SW-F6-01] display interface GE0/0/5
GigabitEthernet0/0/5 current state: UP
Description: 6F-MeetingRoom-A

[SW-F6-01] display interface GE0/0/22
GigabitEthernet0/0/22 current state: UP
Description: 6F-MeetingRoom-A-2

两个端口都连着6楼A会议室。联系行政确认：A会议室有6个信息点，4个墙面面板+2个地插。今天早上8:50有一个供应商来会议室做产品演示，需要联网，自行从地插拉了一根网线插到墙面上——他把同一台交换机下的两个端口用一根网线连了起来。

地插（GE0/0/22）——网线——墙面面板（GE0/0/5），物理环路就这样形成了。

第五步：检查STP状态——为什么环路没有自动阻断？

这是最关键的问题。按照我们的网络标准，所有接入交换机都应该启用MSTP，环路应该被STP自动阻断。查看MSTP状态：

[SW-F6-01] display stp interface GE0/0/5 brief
Port           Role   State
GE0/0/5        -      -

[SW-F6-01] display stp interface GE0/0/22 brief
Port           Role   State
GE0/0/22       -      -

端口STP角色显示为空——说明STP根本没在这两个端口上生效。进一步检查全局MSTP配置：

1
2

[SW-F6-01] display stp global
MSTP is disabled globally.

MSTP全局未启用！ 这才是问题的根源——去年6楼交换机因硬件故障更换，新交换机上线时是用的初始配置模板，模板里漏掉了stp enable全局命令。虽然端口下有stp edged-port enable的配置，但全局STP未开启，端口级的STP配置等于白搭。

第六步：紧急止血

必须立即打断环路。有两种方案：

方案A：直接shutdown环路端口——风险低，见效最快 方案B：全局启用STP——在广播风暴期间启用STP，STP报文可能被淹没在风暴中无法正常收发，收敛时间不可控

选择方案A，先shutdown再处理根因：

[SW-F6-01] interface GE0/0/5
[SW-F6-01-GE0/0/5] shutdown
[SW-F6-01-GE0/0/5] quit
[SW-F6-01] interface GE0/0/22
[SW-F6-01-GE0/0/22] shutdown
[SW-F6-01-GE0/0/22] quit

Shutdown后10秒，CPU从99%降到12%，MAC表项从64000条降到180条，6楼网络在30秒内完全恢复。

解决方案

1. 紧急恢复（已完成）

shutdown环路端口，网络恢复正常。通知会议室供应商正确使用单口连接。

2. 根治——全局启用MSTP

在SW-F6-01上启用MSTP并配置最佳实践参数：

# 全局启用MSTP
[SW-F6-01] stp mode mstp
[SW-F6-01] stp enable

# 配置MSTP域（与核心交换机保持一致）
[SW-F6-01] stp region-configuration
[SW-F6-01-mst-region] region-name HQ-OFFICE
[SW-F6-01-mst-region] revision-level 1
[SW-F6-01-mst-region] instance 1 vlan 201 to 210
[SW-F6-01-mst-region] active region-configuration
[SW-F6-01-mst-region] quit

# 核心交换机作为根桥
[SW-F6-01] stp instance 0 root secondary
[SW-F6-01] stp instance 1 root secondary

# 优化STP收敛参数
[SW-F6-01] stp timer hello 2
[SW-F6-01] stp timer forward-delay 15
[SW-F6-01] stp timer max-age 20

3. 接入端口安全加固

对所有接入端口启用BPDU Guard和边缘端口，防止终端侧引入环路：

# 批量配置接入端口
[SW-F6-01] port-group group-member GE0/0/1 to GE0/0/48
[SW-F6-01-port-group] stp edged-port enable
[SW-F6-01-port-group] stp bpdu-protection enable
[SW-F6-01-port-group] quit

# 上行端口保持默认STP参与（不设为边缘端口）
[SW-F6-01] interface XGE0/0/1
[SW-F6-01-XGE0/0/1] undo stp edged-port
[SW-F6-01-XGE0/0/1] quit

BPDU Guard的作用：如果有人在边缘端口上接入了一台交换机（发了BPDU），端口会立即err-down，阻断环路产生。这是防止终端侧环路的最有效手段。

4. 开启环路检测（Loop Detection）作为双保险

即使STP启用，也配置环路检测作为补充防护：

[SW-F6-01] loop-detect enable
[SW-F6-01] loop-detect interval 5
[SW-F6-01] port-group group-member GE0/0/1 to GE0/0/48
[SW-F6-01-port-group] loop-detect action shutdown
[SW-F6-01-port-group] quit

5. 全网排查STP状态

对全部12台接入交换机逐一检查MSTP是否全局启用：

1
2

# 在每台接入交换机上执行
display stp global

发现除了SW-F6-01，SW-F9-01和SW-F11-01也是MSTP全局关闭的——这两台也是去年硬件更换时遗漏的。立即补上相同的MSTP配置。

根因分析

这次故障的根本原因是双重防护缺失：

1. 直接原因：会议室供应商用一根网线连接了同一台交换机下的两个接入端口，形成物理环路，触发广播风暴。

2. 根本原因：SW-F6-01（以及SW-F9-01、SW-F11-01）的MSTP协议全局未启用。去年这三台交换机因硬件故障更换，上线时使用的初始配置模板遗漏了stp enable全局命令。虽然端口下配置了stp edged-port enable，但在全局STP关闭的情况下，端口级STP配置不会生效，等于形同虚设。

3. 管理原因：交换机上线缺少配置合规检查流程。新设备上线后只有Ping通网关的连通性验证，没有协议级检查（如STP状态、LLDP邻居、端口安全策略等），导致配置遗漏长期潜伏。

预防措施

1. 配置基线检查自动化

编写Python脚本，通过NETCONF/SSH批量巡检所有接入交换机的关键配置项，纳入每日自动巡检：

#!/usr/bin/env python3
"""接入交换机配置基线巡检脚本"""
import paramiko
import csv

CHECK_LIST = [
    ("STP全局状态", "display stp global", "MSTP is enabled"),
    ("Loop Detection", "display loop-detect", "Loop detect is enabled"),
    ("NTP同步状态", "display ntp-service status", "clock is synchronized"),
    ("SSH版本", "display ssh server status", "SSH version : 2.0"),
    ("SNMPv3", "display snmp-agent group", "v3"),
]

def check_switch(host, username, password):
    results = []
    ssh = paramiko.SSHClient()
    ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
    ssh.connect(host, username=username, password=password)
    for name, cmd, expected in CHECK_LIST:
        stdin, stdout, stderr = ssh.exec_command(cmd)
        output = stdout.read().decode()
        ok = expected in output
        results.append((name, "PASS" if ok else "FAIL"))
    ssh.close()
    return results

# 批量巡检并输出报告...

将巡检结果接入企业微信告警，任何一台交换机的STP状态变为disabled，5分钟内通知网络组。

2. 交换机上线SOP完善

新增交换机上线检查清单中的必检项：

检查项	命令	期望结果
MSTP全局启用	`display stp global`	MSTP is enabled
MSTP域配置	`display stp region-configuration`	Region与核心一致
BPDU Guard	`display stp bpdu-protection`	至少48个边缘端口启用
环路检测	`display loop-detect`	Loop detect is enabled
端口安全	`display port-security`	已配置

上线后必须由第二人复核并签字确认。

3. 会议室信息点管理

会议室信息点在面板上标注编号，与交换机端口一一对应
地插面板贴上醒目标签：“请勿将网线连接两个网络面板”
非IT人员需要联网时，统一联系IT前台，由IT人员协助接线
对会议室端口启用端口安全（限制MAC地址数量为2个），减少环路风险

4. 网络监控增强

在Zabbix中新增以下监控项：

接入交换机CPU利用率 >70% 触发告警
接入交换机MAC表项数量超过阈值的80%触发告警
单端口出方向流量持续超过800Mbps超过30秒触发告警
STP拓扑变更通知（TCN）次数监控，单台交换机5分钟内超过3次触发告警

总结

这次故障的教训非常深刻：防护机制配置了不等于生效了。端口下写了stp edged-port enable，但全局STP没开，等于白搭。就像买了保险但没激活保单，出事了才发现根本赔不了。

网络运维中，以下几点值得铭记：

全局开关优先于端口配置——STP、DHCP Snooping、环路检测等功能都有全局开关，配置时一定要先确认全局是否启用。这不仅是华为设备的特点，思科、H3C、锐捷等厂商也是同样的逻辑。
配置合规检查要自动化——人工检查永远有遗漏，尤其是批量设备上线的时候。脚本巡检+告警推送，才是可靠的保障。
物理环路是最暴力的故障——一个简单的双头插线操作，就能在几秒内让一台48口交换机的CPU跑到100%，MAC表打满，三层设备也跟着遭殃。二层环路的影响范围和扩散速度远超大多数网络故障，必须把STP当成本命技能来维护。
BPDU Guard是终端接入的最后一道防线——接入端口设为边缘端口+BPDU Guard，一旦有终端侧设备发BPDU就自动err-down，简单粗暴但极其有效。

最终，从故障发生到网络恢复，用时约18分钟。其中5分钟是确认故障范围，3分钟是定位环路端口，2分钟是检查STP状态，1分钟shutdown止血。如果STP正常启用，这个环路从产生到被自动阻断只需要几秒钟，用户甚至不会感知到——这才是网络协议应有的价值。

排查工具备忘：display mac-address flapping、display stp global、display cpu-usage、display interface brief是二层环路排查的四件套，建议熟记。

一次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耗尽的速度可能远超你的想象。

一次IPSec VPN隧道因MTU不匹配导致ERP系统远程访问异常的排查实录

Fri, 26 Jun 2026 07:00:00 +0000

问题背景

公司在全国有8个分支机构，均通过FortiGate防火墙与总部建立IPSec VPN隧道，日常办公依赖总部的SAP ERP系统进行订单录入、库存查询和财务审批。周一上午9点，华南分公司的30多名员工集中登录ERP系统时，纷纷反馈页面加载极慢——登录界面要等2-3分钟才能显示，进入后点击菜单经常卡死超时，只能反复刷新碰运气。

奇怪的是，Ping总部的服务器完全正常，延迟稳定在15ms左右，traceroute也每一跳都通畅。其他通过VPN访问的服务（如邮件OA）虽然也有点慢，但不像ERP这样完全不可用。网络监控平台上VPN隧道状态显示绿灯"Connected"，流量统计正常，没有任何告警。问题持续了整个上午，严重影响了华南分公司的业务运转，紧急程度极高——财务月结审批被迫延迟，客户订单无法及时录入。

故障现象

故障的表现非常"诡异"，具有典型的MTU问题特征——小包通、大包不通：

现象一：Ping正常但ERP不可用

从华南分公司Ping总部ERP服务器10.10.1.100，100字节的小包100%成功，延迟15ms；但当Ping包大小超过1400字节时：

C:\Users\zhao> ping 10.10.1.100 -l 100 -n 10
Reply from 10.10.1.100: bytes=100 time=15ms TTL=62

C:\Users\zhao> ping 10.10.1.100 -l 1500 -n 10
Request timed out.
Request timed out.
Ping statistics for 10.10.1.100:
    Packets: Sent = 10, Received = 0, Lost = 10 (100% loss)

现象二：ERP登录页面加载极慢或超时

浏览器访问https://erp.company.com时，登录页的HTML框架能加载出来（小数据包），但包含CSS/JS资源的大响应体经常卡在"传输中"状态，最终浏览器报ERR_CONNECTION_TIMED_OUT。

现象三：SSH大文件传输失败

通过SSH从华南服务器向总部scp一个50MB的备份文件，传输开始后几秒就卡死：

1
2
3

$ scp backup.tar.gz admin@10.10.1.50:/tmp/
backup.tar.gz                                    0%    0KB   --:-- ETA
# 卡住不动，最终Connection reset by peer

但小文件（几KB的配置文件）可以正常传输。

现象四：TCP连接建立正常但数据传输中断

用Wireshark在华南分公司的客户端抓包，可以看到TCP三次握手顺利完成，客户端发送HTTP GET请求后，服务器回复了第一个数据包（SYN+ACK后的初始窗口），但当服务器连续发送多个满载（满1460字节）的TCP段时，客户端迟迟收不到后续数据，最终触发TCP重传，重传若干次后连接被reset。

关键发现：抓包中看不到任何ICMP Fragmentation Needed消息，说明IP分片所需的通知被某处拦截了。

排查过程

第一步：确认问题范围——是否只影响华南分公司

第一时间联系其他7个分支，发现华东分公司（同样通过IPSec VPN接入）也反馈ERP访问缓慢，但华北分公司（通过专线接入，不走VPN）完全没有问题。这个对比非常关键——专线正常、VPN异常，问题锁定在VPN隧道层面。

第二步：排除ERP服务器本身的问题

直接在总部内网访问ERP服务器，响应迅速，没有任何异常。检查ERP服务器的系统负载、数据库连接池、Web服务器线程池，全部在正常范围内。确认问题不在服务器端。

第三步：排除VPN隧道连通性问题

VPN隧道状态在FortiGate监控面板上显示为绿色"Up"，路由表正确，Ping小包100%通过。初步排除隧道本身断裂的可能。但注意到隧道接口的MTU配置——FortiGate上VPN隧道接口默认MTU值：

# 总部 FortiGate (FGT-HQ)
FGT-HQ # diagnose netlink interface list vpn-tunnel-HN
Name: vpn-tunnel-HN
  MTU: 1436
  Type: IPSec
  Status: up

# 华南 FortiGate (FGT-HN)
FGT-HN # diagnose netlink interface list vpn-tunnel-HQ
Name: vpn-tunnel-HQ
  MTU: 1436
  Type: IPSec
  Status: up

隧道MTU为1436，这是因为IPSec ESP封装会占用额外头部空间（ESP头8字节 + ESP尾2字节 + ICV 12字节 + 外层IP头20字节 = 42字节，1500-42=1458…但实际FortiGate的默认值是1436，预留了更多空间给可能的UDP封装和NAT-T）。隧道MTU本身看起来没有异常。

第四步：用路径MTU探测定位关键问题

使用Linux的tracepath命令进行路径MTU探测：

# 从华南Linux服务器探测到总部ERP
$ tracepath 10.10.1.100
1?: [LOCAL] 10.20.1.10                          mtu=1500
2:  10.20.1.1 (华南FG内网口)                      mtu=1500
3:  no reply
4:  10.10.1.1 (总部FG内网口)                      mtu=1436  ← 链路MTU突降!
5:  10.10.1.100 (ERP服务器)                       mtu=1436

关键发现：数据包经过VPN隧道后，路径MTU从1500降到了1436。这意味着从ERP服务器发往华南客户端的TCP数据包如果满载1460字节，在经过VPN隧道时会被封装成超过1500字节的IP包，需要分片。

第五步：检查TCP MSS协商

查看FortiGate防火墙的TCP MSS配置：

# 华南 FortiGate
FGT-HN # show full-configuration | grep -i mss
    set tcp-mss-sender 0
    set tcp-mss-receiver 0
    # 隧道接口未配置MSS协商

MSS值为0表示"未设置"——FortiGate不会在TCP SYN/SYN-ACK中主动修改MSS值。这意味着TCP连接建立时，ERP服务器（在1500 MTU的内网环境中）会在SYN-ACK中通告MSS=1460（MTU 1500 - 40字节IP+TCP头），华南客户端同理也在SYN中通告MSS=1460。

这就是问题所在：双方协商的MSS=1460，但数据实际要经过MTU=1436的VPN隧道。ERP服务器按MSS=1460发送满载TCP段，封装后IP包总长 = 1460 + 40(IP头) + 42(IPSec封装) = 1542字节，超过了出接口MTU 1500！这要么需要IP分片，要么被丢弃。

第六步：验证——为什么Ping小包通但大包不通

ICMP Echo Request小包（100字节）加上IPSec封装后仍远小于1500，无需分片，顺利通过。但1500字节的Ping包（IP层已达1500）加上IPSec封装后变成1542字节，超过了物理接口MTU，需要分片。

第七步：为什么没有ICMP Fragmentation Needed反馈

正常情况下，当路由器发现出接口MTU不足以转发不分片的包，且包的DF(Don’t Fragment)位为1时，应该返回ICMP Type 3 Code 4（Fragmentation Needed and DF Set）消息，通知发送方降低包大小。但我们在抓包中完全没看到这类ICMP消息！

进一步排查发现两个原因：

FortiGate的IPS策略拦截了ICMP Fragmentation Needed消息——查看IPS Sensor配置，发现有一条默认规则ICMP.DOS.FRGNeeded将其标记为"Drop"，这是误将路径MTU发现的必要ICMP消息当作DOS攻击了。
ERP服务器的Linux内核默认在TCP包中设置DF位——Linux的net.ipv4.tcp_df默认行为倾向于设置DF位以避免分片带来的性能损失。当DF=1的TCP包在VPN封装后超MTU且被FortiGate丢弃时，本应返回ICMP Fragmentation Needed，但被IPS拦截了。

双重打击：服务器设置了DF位禁止分片 → FortiGate需要返回ICMP通知 → IPS策略把ICMP通知拦截了 → 服务器永远不知道自己发的包太大 → 只能不断重传同样大小的包 → 连接卡死。

第八步：确认根因链路

完整的因果链路：

IPSec隧道封装增加42字节开销 → 隀道MTU从1500降到1436
TCP MSS协商未适配隧道MTU → 双方协商MSS=1460（应为1396）
ERP服务器按MSS=1460发送满载TCP段 → IPSec封装后超物理接口MTU
TCP包DF位=1 → 不能分片，由FortiGate丢弃
FortiGate IPS策略拦截ICMP Fragmentation Needed → 发送方收不到PMTU通知
服务器不断重传超大的TCP段 → 连接永远无法完成数据传输
小包（<1436-40=1396字节）不受影响 → Ping小包正常、ERP小响应体能加载

解决方案

紧急止血（5分钟内生效）

方案一：在FortiGate隧道接口上启用TCP MSS协商

这是最标准的修复方式，在VPN隧道接口上设置MSS Sender和MSS Receiver值，让FortiGate在TCP SYN/SYN-ACK经过隧道时自动修改MSS值，将其限制在隧道MTU允许的范围内：

# 华南 FortiGate
config system interface
    edit "vpn-tunnel-HQ"
        set tcp-mss-sender 1396
        set tcp-mss-receiver 1396
    next
end

# 总部 FortiGate
config system interface
    edit "vpn-tunnel-HN"
        set tcp-mss-sender 1396
        set tcp-mss-receiver 1396
    next
end

MSS值计算：隧道MTU 1436 - 40(IP头+TCP头) = 1396。设置后，FortiGate会在TCP SYN经过隧道接口时将MSS Option从1460修改为1396，确保双方协商出的最大段大小不超过隧道承载能力。

修改后立即生效，无需重启隧道，已有连接会在下次TCP握手时使用新MSS值。

方案二：释放IPS对ICMP Fragmentation Needed的拦截

同时修复IPS策略，放行必要的PMTU Discovery ICMP消息：

# 总部 FortiGate IPS Sensor配置
config firewall ips-policy
    edit "default-ips"
        config rule
            edit 1
                set name "allow-pmtu-icmp"
                set signature "ICMP.DOS.FRGNeeded"
                set status disable
                set log enable
                set action pass
            next
        end
    next
end

将ICMP.DOS.FRGNeeded规则从Drop改为Pass，确保路径MTU发现的ICMP消息能正常传递。这是TCP PMTU Discovery机制正常工作的必要条件。

验证修复效果

修改后从华南分公司测试：

# Ping大包测试
C:\Users\zhao> ping 10.10.1.100 -l 1500 -n 10
Reply from 10.10.1.100: bytes=1500 time=16ms TTL=62
Reply from 10.10.1.100: bytes=1500 time=16ms TTL=62
# 100%成功！

# ERP访问测试——登录页面3秒内完整加载，菜单点击秒级响应

# SCP大文件传输测试
$ scp backup.tar.gz admin@10.10.1.50:/tmp/
backup.tar.gz                                   100%   50MB  12.8MB/s   00:03
# 正常完成！

全量修复——所有分支机构VPN隧道

紧急修复华南后，立即对所有8个分支的VPN隧道接口统一配置MSS：

# 批量配置脚本（总部侧）
for tunnel in vpn-tunnel-HN vpn-tunnel-HD vpn-tunnel-HB vpn-tunnel-HX vpn-tunnel-HW vpn-tunnel-HN2 vpn-tunnel-HS vpn-tunnel-HNE; do
    config system interface
        edit "$tunnel"
            set tcp-mss-sender 1396
            set tcp-mss-receiver 1396
        next
    end
done

并在每台分支FortiGate上同样配置对应的隧道接口。

根因分析

问题的根本原因是 IPSec VPN隧道的MTU开销未被TCP层感知和适配，叠加 IPS策略误杀PMTU Discovery的ICMP消息，形成了"黑盒"效应：

核心根因一：TCP MSS未适配隧道MTU

IPSec ESP封装会在原始IP包外增加约42字节的头部开销，导致物理链路上可承载的有效载荷从1500字节降到约1458字节（考虑NAT-T UDP封装则更低）。但TCP层在握手时协商的MSS是基于直连网段MTU 1500计算得出的1460，完全不知道中间有一个MTU更低的隧道。FortiGate的隧道接口默认未开启MSS协商修改功能（tcp-mss-sender/receiver=0），导致这个信息鸿沟无法自动弥合。

核心根因二：IPS拦截ICMP Fragmentation Needed阻断PMTU发现

RFC 1191定义的Path MTU Discovery机制本应作为MSS协商的后备方案——当TCP包因DF位无法分片而被中间路由器丢弃时，路由器应返回ICMP Type 3 Code 4消息通知发送方降低包大小。但FortiGate的IPS默认规则将此类ICMP消息标记为潜在DOS攻击并丢弃，使得PMTU Discovery机制完全失效。

两个根因叠加：TCP不知道隧道MTU限制（MSS过大），又无法通过ICMP得知自己发的包太大（PMTU Discovery被阻断），导致发送方陷入"盲重传"的死循环。

预防措施

1. 标准化VPN隧道TCP MSS配置

制定VPN隧道配置标准，所有新建隧道接口必须设置MSS值：

# FortiGate VPN隧道MSS配置标准
tcp-mss-sender = 隧道MTU - 40
tcp-mss-receiver = 隧道MTU - 40
# 常见值：
#   IPSec ESP (无NAT-T)：MTU=1458 → MSS=1418
#   IPSec ESP (NAT-T/UDP封装)：MTU=1436 → MSS=1396

将此标准纳入VPN隧道配置Checklist，新建或修改隧道时强制执行。

2. IPS策略优化——放行PMTU Discovery ICMP

在所有FortiGate的IPS Sensor中，将以下ICMP规则从默认的Drop改为Pass或至少Disable：

ICMP.DOS.FRGNeeded (Type 3 Code 4 - Fragmentation Needed)
ICMP.Info.SourceQuench (Type 4 - Source Quench，虽已废弃但部分设备仍使用)

这些ICMP消息是IP网络正常运行的必要组成部分，误杀它们会导致PMTU Discovery失效，远比所谓的DOS风险危害更大。

3. 定期路径MTU探测巡检

编写自动化巡检脚本，每周对所有VPN隧道执行路径MTU探测：

#!/bin/bash
# pmtu_check.sh - VPN隧道路径MTU巡检
BRANCHES=("10.20.1.0/24 华南" "10.30.1.0/24 华东" ...)
HQ_ERP="10.10.1.100"
ALERT_THRESHOLD=1400

for branch in "${BRANCHES[@]}"; do
    network=$(echo $branch | awk '{print $1}')
    name=$(echo $branch | awk '{print $2}')
    gw=$(echo $network | sed 's/0\/24/1/')
    
    # 从分支网关探测路径MTU
    pmtu=$(tracepath -n $HQ_ERP 2>&1 | grep "pmtu" | tail -1 | awk '{print $NF}')
    
    if [ "$pmtu" -lt "$ALERT_THRESHOLD" ]; then
        echo "[ALERT] $name 隧道路径MTU异常: $pmtu (期望 >= $ALERT_THRESHOLD)"
    else
        echo "[OK] $name 隧道路径MTU正常: $pmtu"
    fi
done

当路径MTU低于阈值时自动告警，防止MSS配置被意外修改或隧道MTU因封装方式变化而降低。

4. 网络变更流程纳入MTU审查

在FortiGate配置变更审批流程中加入MTU/MSS审查环节：

新增VPN隧道 → 必须检查MSS配置
更改IPSec封装方式（如从ESP改为ESP+UDP封装）→ 重新计算MSS值
修改IPS策略 → 检查是否影响PMTU Discovery ICMP放行
更换ISP或链路类型 → 测试路径MTU是否变化

5. 文档化MTU计算方法

编写内部网络运维手册中的MTU计算章节，记录所有VPN隧道的：

隧道名称	封装方式	预留开销	隧道MTU	MSS值	物理接口MTU
vpn-HN	ESP+NAT-T	64字节	1436	1396	1500
vpn-HD	ESP	42字节	1458	1418	1500

让每位运维工程师都能快速查阅和计算正确的MSS值。

总结

这次故障的排查给我留下了深刻的教训：

教训一：Ping通不代表网络通。 Ping只是ICMP小包测试，它能证明链路可达，但完全不能证明大包传输能力。在涉及VPN隧道的故障排查中，必须用不同大小的Ping包（ping -l 1500）或tracepath进行路径MTU探测，才能发现隐藏的MTU问题。

教训二：MTU/MSS不匹配是VPN环境的"经典杀手"。 IPSec封装带来的MTU缩减是必然的、可计算的，但TCP层对此毫不知情。如果不主动在隧道接口配置MSS协商修改，就等于让TCP盲目发送超大数据包，轻则分片降速，重则完全卡死。这是VPN运维的基本功课，不能等出事了才补。

教训三：IPS策略不能一刀切地拦截ICMP。 安全策略的"拦截一切ICMP"看似防御了ICMP-based DOS攻击，实则破坏了PMTU Discovery这一网络基础机制。安全与可用必须平衡，对于RFC定义的必要ICMP消息（Fragmentation Needed、Time Exceeded等），必须放行。

教训四：故障排查要善于利用"小包通、大包不通"这个特征。 当你发现小请求能成功但大数据传输失败，或者Ping通但应用不通，第一反应就应该是检查MTU/MSS。这个特征太过典型，不必浪费时间去查服务器性能、应用日志、路由表——直接从MTU入手往往能最快定位。

最终，一个1436的隧道MTU和未设置的MSS参数，加上一条过于激进的IPS规则，三者合力制造了一个"Ping正常但业务瘫痪"的经典假象。修复只需两行配置，但理解它需要整个IP/TCP栈的知识。运维不只是改配置，更是理解协议。

一次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 还是能自我恢复。

一次Windows更新后打印机Spooler服务反复崩溃的全网排查实录

Wed, 24 Jun 2026 07:00:00 +0000

一、问题背景

周二早上8:45，我还在喝第一杯咖啡，企业微信突然被财务部的消息轰炸 —— “打印机又坏了"“打不了报销单"“发票打不出来客户等着呢”。财务部向来是公司里对打印需求最密集的部门，每月报销周期前后更是如此。今天正好是月度报销截止前一天，如果不能尽快恢复，影响面会非常大。

我们公司约有200台办公终端，财务部独占12台，使用一台京瓷（Kyocera）TASKalfa 4053ci 企业级多功能一体机，通过TCP/IP网络共享。打印机本身运行稳定，过去两年几乎没有出过硬件故障。但今天的情况不同：不是一个用户、一台电脑的问题，而是财务部全员12台Windows 10/11电脑同时无法打印。紧急程度直接拉满。

二、故障现象

赶到财务部现场，观察到以下现象：

1. 打印任务卡死

任意用户在Word或Excel中点击打印后，任务迅速进入打印队列，状态显示"正在打印”，但打印机没有任何响应。30秒后状态变为"错误 — 正在打印”，再过了十来秒，队列自动清空，什么也没打出来。

2. Print Spooler 服务反复停止

打开服务管理器（services.msc），Print Spooler 服务状态显示"正在运行"，但用不了几秒钟就自动变为"已停止"，然后系统尝试自动恢复，又变成"正在运行"，如此循环。间隔大约30秒。

3. 事件查看器关键日志

在 应用程序 日志中，每30秒准时刷出以下三条：

错误：应用程序错误
    错误应用程序名称: spoolsv.exe
    错误模块名称: KXPDFDRV.dll
    异常代码: 0xc0000005
    错误偏移量: 0x00002e18

信息：Application Popup
    打印机驱动程序 KX Driver for Universal Print 已导致 Spooler 服务崩溃

错误：Service Control Manager
    Print Spooler 服务意外终止。这已经是第 X 次发生。

0xc0000005 是内存访问违规（ACCESS_VIOLATION），KXPDFDRV.dll 是京瓷的 PDF 输出组件，KX Driver for Universal Print 是京瓷的通用打印驱动。

4. 驱动详细信息

在"打印服务器属性"→“驱动程序"中查看，打印机使用的驱动版本为 Kyocera TASKalfa 4053ci KX (8.2.0712)，驱动类型标注为"类型 3 - 用户模式”。在 C:\Windows\System32\spool\drivers\x64\3\ 目录下可以找到所有相关驱动文件。

5. 临时验证

在一台电脑上尝试手动停止 Spooler 服务，清空 C:\Windows\System32\spool\PRINTERS\ 下的临时文件，再启动服务 —— 同样的问题立刻复现，说明不是残留打印任务导致。

三、排查过程

第一轮：隔离变量，缩小范围

先确认问题范围：

所有电脑都受影响：财务部12台Win10/Win11全员中招，排除单机故障
其他部门正常：我让行政部同事测试，他们的HP打印机完全正常
打印机本身正常：从打印机面板直接操作复印、扫描都正常，用手机APP（Kyocera Mobile Print）发送打印也正常

这就把问题锁定在了"电脑端驱动程序"而非打印机硬件或网络。

紧接着我发现一个关键线索：财务部有2台电脑是在上周五正常关机、周一（昨天）开机后开始出问题的；而另外10台电脑是今天早上开机后才出问题。我立刻问了一句：“你们昨天有没有人打印成功过？”

财务主管回忆说：“昨天有同事打印过，是好的。”

“几点？”

“下午三点左右。”

我立刻打开一台电脑的"设置 → Windows更新 → 更新历史记录"，赫然看到：

2026-06-23 自动更新：
  - KB5040427：适用于 Windows 10 的累积更新 (成功安装于 2026/6/23 18:32)
  - KB5039338：.NET Framework 更新
  - Kyocera - Printer - 8.3.1205.0 (成功安装于 2026/6/23 18:33)

Windows Update 推送了一个京瓷打印机驱动更新，版本从 8.2.0712 升级到了 8.3.1205.0！

第二轮：深入驱动分析

我把一台受影响电脑的驱动文件和正常电脑（未安装此更新的其他部门同型号京瓷打印机）的驱动做了对比：

正常驱动 (8.2.0712)：

C:\Windows\System32\spool\drivers\x64\3\
├── KXPDFDRV.dll       (版本 8.2.0712, 1,245,696 bytes)
├── KXDRVUI.dll        (版本 8.2.0712, 2,834,432 bytes)
├── KXPRINT.DLL        (版本 8.2.0712, 891,392 bytes)
└── OEMSETUP.INF

更新后驱动 (8.3.1205.0)：

C:\Windows\System32\spool\drivers\x64\3\
├── KXPDFDRV.dll       (版本 8.3.1205.0, 1,282,048 bytes) — 比旧版大了约36KB
├── KXDRVUI.dll        (版本 8.3.1205.0, 2,920,448 bytes)
├── KXPRINT.DLL        (版本 8.3.1205.0, 905,728 bytes)
└── OEMSETUP.INF

新驱动确实有变化。为了进一步确认，我用 Process Monitor（ProcMon）在打印触发时监控 spoolsv.exe 的行为。过滤条件：

1
2
3

Process Name is spoolsv.exe
Operation is Load Image
Path contains KXPDFDRV

在触发打印后，ProcMon 捕获到 spoolsv.exe 加载 KXPDFDRV.dll 后，紧接着就出现了 Thread Exit 且返回码为 STATUS_ACCESS_VIOLATION (0xC0000005)。观察调用栈，崩溃点位于 KXPDFDRV.dll!RenderToEMF+0x2e18，这是一个与增强图元文件（EMF）渲染相关的函数。

第三轮：核心矛盾

这时候我意识到一个很重要的矛盾：Windows Update 通过 Microsoft Update Catalog 推送的驱动（8.3.1205.0），和京瓷官网上对应 TASKalfa 4053ci 的最新驱动，不是同一个东西。

在另一台电脑上，我从京瓷官网下载了对应型号的专属驱动，版本是 8.4.1102，安装后一切正常。这就说明：Windows Update 推送的"通用驱动"（Universal Print Driver），与特定打印机的专属驱动存在兼容性问题。

通用驱动的设计理念是"一个驱动适配多个型号"，它通过打印机的 IEEE 1284 Device ID 字符串来匹配功能。问题在于，TASKalfa 4053ci 有一些定制的 PDL（Page Description Language）功能和后处理选项（如装订、打孔、折页），这些功能在通用驱动的简化渲染路径中处理不当，导致 RenderToEMF 函数在构造打印作业的 EMF 文件时访问了未初始化的内存区域。

第四轮：为什么是"全员中招"

因为财务部使用的是同一型号打印机，大家的电脑都在同一个 Windows Update 通道（Semi-Annual Channel），都在昨晚下班后（18:33前后）自动安装了同一批更新。所以才会出现"昨天还好好的，今天全挂了"的戏剧性场面。

那两台昨晚开机的电脑之所以"昨天"还能打，是因为他们在18:32安装更新后一直没有触发打印，直到今天早上上班才踩到这个雷。

四、解决方案

短期修复（逐台处理，15分钟/台）

方案A：回滚驱动（最快，如果系统还原点还在）

# 以管理员身份运行 PowerShell
# 1. 列出已安装的打印机驱动包
Get-WindowsDriver -Online | Where-Object { $_.OriginalFileName -like "*kyocera*" }

# 2. 在设备管理器中回滚
# 设备管理器 → 打印队列 → 对应打印机 → 驱动程序 → 回滚驱动程序
# 或通过 pnputil 删除更新驱动包
pnputil /enum-drivers | findstr -i kyocera

# 根据发布名称找到 OEMxx.inf
pnputil /delete-driver oem45.inf /uninstall /force

方案B：手动替换驱动（如果回滚不可用）

# 1. 停止 Spooler
net stop spooler

# 2. 到京瓷官网下载对应型号的专属驱动
# https://www.kyoceradocumentsolutions.com.cn/ → 支持与下载 → TASKalfa 4053ci

# 3. 安装后，在"打印机属性 → 高级 → 新驱动程序"中切换为专属驱动
# 关键：不要选"Kyocera TASKalfa 4053ci KX (Universal)"，
# 选"Kyocera TASKalfa 4053ci KX"（不带 Universal 字样）

# 4. 启动 Spooler
net start spooler

实际上，财务部12台电脑我用了方案A处理了9台（还原点还在），剩下3台因为磁盘清理清掉了还原点，用了方案B。总共花了一个半小时。

长期修复（全网预防）

1. 通过组策略禁止 Windows Update 推送驱动更新

# 域控 GPO 配置路径：
# 计算机配置 → 管理模板 → Windows 组件 → Windows 更新 → 管理从 Windows 更新提供的更新
# 启用 "不要让 Windows 更新提供驱动程序"

# 或者在本地组策略：
# gpedit.msc → 计算机配置 → 管理模板 → Windows 组件 → Windows 更新
# → "不包括适用于 Windows 更新的驱动程序" → 已启用

2. 通过 WSUS 审批驱动更新

如果公司有 WSUS（Windows Server Update Services）服务器，把驱动类更新单独分类，手动审批后再推送：

WSUS 控制台 → 选项 → 产品和分类 → 分类 → 
✓ 关键更新
✓ 安全更新
✓ 更新汇总
✗ 驱动程序  ← 取消勾选，或选择后手动审批

3. 建立打印机驱动测试流程

在推送任何打印机相关更新前，在IT部门的测试机上先验证。特别是对于财务部、人事部这类打印密集型部门，更要谨慎。

五、根因分析

问题的根本原因有三层：

第一层：驱动层面。 Windows Update 推送的 Kyocera Universal Print Driver（通用打印驱动）v8.3.1205.0，在处理 TASKalfa 4053ci 的专有后处理功能（装订/打孔/折页）时，KXPDFDRV.dll 中的 RenderToEMF 函数存在内存访问违规。通用驱动为了适配多种型号，在渲染路径中使用了简化逻辑，没有正确初始化某些专有功能所需的数据结构，导致野指针访问。

第二层：厂商层面。 京瓷将通用驱动提交到 Microsoft Update Catalog 时，标记了声明的设备兼容性列表中包含 TASKalfa 4053ci，但实际上该通用驱动并未针对此型号做充分回归测试。这是一个典型的"硬件兼容性声明不准确"问题。

第三层：运维层面。 桌面运维中，默认允许 Windows Update 自动推送硬件驱动是一个常见但危险的做法。尤其是打印机驱动，种类繁多、厂商质量参差不齐，自动更新带来的兼容性风险远大于收益。正确的做法应该是把驱动更新从自动通道中剥离出来，走手动验证流程。

六、预防措施

GPO统一管控驱动更新：在域控上启用"不要让Windows更新提供驱动程序"策略，全网生效。驱动更新改为从厂商官网/WSUS手动分发。
建立驱动兼容性清单：统计公司内所有打印机型号、固件版本、当前驱动版本，建立台账。每次收到厂商驱动更新通知后，先在测试机验证，确认无问题再小范围灰度。
关键部门设打印备机：财务、人事、法务等打印密集型部门，额外配置一台不同型号的备选打印机。即使主打印机驱动出问题，也能切换到备机应急。
Windows Update 分级策略：
- 安全更新：自动安装（延迟3天）
- 关键更新：自动安装（延迟7天）
- 驱动更新：手动审批
- 功能更新：手动审批，大版本前做兼容性测试
定期备份驱动配置：

# 导出所有打印机配置
Get-Printer | ForEach-Object {
    Export-Printer -Name $_.Name -FilePath "D:\PrinterBackup\$($_.Name).xml"
}
# 导出驱动列表
pnputil /export-driver * D:\DriverBackup\

建立应急通讯模板：当业务系统出问题时，通过企业微信统一通告，避免恐慌性排查。这次财务部12个人同时报修，信息混乱，其实花了不少时间确认"是同一个问题还是多个不同问题"。

七、总结

这次故障从发现到全网恢复，历时约两小时。直接原因是Windows Update自动推送的通用打印驱动与特定型号打印机不兼容，但深层反映的是桌面运维中"自动化更新"和"稳定性"之间的权衡问题。

几点经验教训：

1. 自动更新不是银弹。 尤其是硬件驱动，厂商质量参差不齐，自动推送等于把风险敞口交给外界。安全更新可以自动，驱动更新必须手动。

2. 排查打印机问题先看事件查看器。 spoolsv.exe 崩溃时，应用程序日志里几乎一定会留下模块名和异常代码。0xc0000005 几乎可以确定是驱动层的内存访问问题，不用在硬件和网络上浪费时间。

3. “昨天还能用” 是第一线索。 当我听到这句话，立即检查了Windows更新历史，几分钟就锁定了根因。很多人排查打印机问题时先重启、重装驱动、甚至重装系统，跳过了最简单但最有效的一步：看最近发生了什么变化。

4. 驱动回滚是桌维的救命技能。 如果系统还原点没有被清理，pnputil /delete-driver 加 devmgmt.msc 回滚就是最快的修复手段。平时应该提醒用户不要盲目用磁盘清理工具删除"以前的Windows安装"——那里面可能有救命用的驱动备份。

5. 通用驱动（Universal Driver）是个坑。 厂商为了减少维护成本，倾向于推通用驱动而非专属驱动。但通用驱动在特定型号上的渲染路径可能不完整，容易出问题。桌面运维人员在安装打印机时，务必选择对应型号的专属驱动，而不是图省事选"通用"或"Universal"。

一次BGP双线接入因AS-PATH策略错误导致业务流量全部走错运营商的排查实录

Tue, 23 Jun 2026 06:55:12 +0000

问题背景

总部机房采用"电信+联通"双线BGP接入架构，核心交换机与两家运营商建立eBGP邻居，通过AS-PATH属性和route-map实现流量调度——默认走电信、联通作为备份，特定网段走联通做负载。某周一下午14:30左右，研发同事反映访问部署在阿里云华东节点的多个API接口（用户中心、订单查询、支付回调）出现持续性卡顿，单次请求从正常的80ms飙升到500ms以上，短信网关、第三方支付回调更是出现间歇性超时。客服部门同步反馈多名用户投诉"支付完成但订单状态未更新"。

故障现象

通过Zabbix监控看到关键业务指标异常：

14:32:01  Gateway-IP-Monitor  WARN  核心交换机到阿里云华东(47.110.x.x)延迟 412ms (基线 35ms)
14:32:01  BGP-Session-Monitor  INFO  eBGP 电信邻居 10.10.1.1 Established  (Up 87d 4h)
14:32:01  BGP-Session-Monitor  INFO  eBGP 联通邻居 10.10.2.1 Established  (Up 87d 4h)
14:32:15  Zabbix-Trapper        CRIT  HTTP 业务探测 api.example.com 5xx 告警 (连续3次)
14:32:30  Zabbix-Trapper        CRIT  支付回调响应时间 > 5s (SLA违约)

在核心交换机上查看路由表：

<Switch> display bgp routing-table ipv4 unicast brief
Total Number of Routes: 412,387
Network            NextHop        MED     LocPrf  PrefVal  Path/Ogn

*  47.110.0.0/16     10.10.2.1      0       100     0        4134  ?
*  47.110.0.0/16     10.10.1.1      0       100     0        4134 100 200 ?

诡异的事情出现了：阿里云华东段（47.110.0.0/16）的两条路由都被打上了"无效标记"（问号?），其中电信链路（AS4134 → AS100 → AS200）多了一段莫名其妙的AS-PATH"100 200"，而正常情况下电信学到该网段的AS-PATH应该只显示"4134"或"4134 100"。

排查过程

第一步：确认BGP邻居状态正常

两条eBGP邻居均显示Established，消息收发计数没有异常抖动，说明TCP连接、Keepalive、BGP Open报文一切正常，问题出在路由策略层。

第二步：检查入方向route-map

display current-configuration | include route-map 找到关键策略段：

route-map FROM-TELECOM-IN permit 10
 description Accept legitimate telecom routes
 match as-path 10
!
route-map FROM-TELECOM-IN deny 20
 description Reject transit routes
 match as-path 20
!
ip as-path 10 permit ^(4134_)+$
ip as-path 20 permit _100_200_

看到as-path 20那行瞬间明白问题所在——正则_100_200_会匹配任何包含"100 200"两个相邻AS的路径，包括电信运营商内部传递过来的真实路由。当时我们调度的逻辑是"拒绝任何包含私有AS号100、200的路径"，但忘记了一个事实：电信骨干网在传递某些跨网段路由时，会在AS-PATH中插入"100 200"作为内部标记（这是中国电信AS4134的私有AS号，用于内部选路标记）。

第三步：验证猜想

在核心交换机上抓取近期BGP Update报文，过滤AS-PATH含"100 200"的路由前缀数量：

1
2
3

<Switch> display bgp update-peer-group 10.10.1.1 statistics
...
Prefix count with AS-PATH matched _100_200_: 287,341

近30万条合法路由被这条正则误杀，全部进了BGP RIB-in的"待丢弃"队列，对端却还以为邻居都正常、路由都通告了。

第四步：检查本地注入的BGP路由

为防止出现路由黑洞，运维A同事把核心交换机的LoopBack0（10.255.0.1/32）通过network命令注入BGP，这条命令的下一跳指向10.10.1.1（电信），触发了一段被错误拒绝的AS-PATH。

<Switch> display bgp routing-table 10.255.0.1
BGP local router ID is 10.255.0.1
Status codes: * - valid, > - best, d - damped, h - history,
              s - suppressed, S - stale, i - internal, b - backup
Origin: i - IGP, e - EGP, ? - incomplete

Total Number of Routes: 0

连自己的LoopBack都没被优选——所有从电信学到的路由都被route-map打上"无效"标记，对端联通的路由因为local-preference默认100而进入主表，但很多明细网段联通链路延迟本来就高，导致从核心出去的流量"全跑联通"。

第五步：与运营商侧核对

拨通电信大客户经理电话，对方工程师确认他们在上周末升级了AS4134的出口策略，会在AS-PATH中插入"100 200"作为新引入的BGP选路标记。也就是说不止我们这端，所有走电信BGP接入的企业客户都受到了影响——只是我们这条正则写得太严格。

第六步：临时止血

先把误杀的AS-PATH正则屏蔽掉，恢复路由：

`1`	`no ip as-path 20`

60秒后，路由表刷新，47.110.0.0/16的两条路由恢复正常选路，业务延迟从412ms回到35ms基线。

解决方案

长期方案：改用AS-PATH长度作为判定标准

“100 200"只是运营商内部标记，不能简单粗暴作为业务流的甄别依据。改为基于AS-PATH长度做拒绝：

1
2
3

ip as-path 10 permit ^(4134_)+$
ip as-path 20 permit _(6451[2-9]|6553[0-5])_
ip as-path 30 permit ^[0-9]+$  ! 只允许单一AS的路由（对端直连段）

只拒绝真正属于RFC 6996保留私有AS号的路径，避免误伤。

给route-map加日志计数

route-map FROM-TELECOM-IN deny 20
 description Reject private AS
 match as-path 20
 set traffic-index 99

配合流量监控，一旦被拒绝的路由条目激增立即告警。

增加BGP邻居级监控

在Zabbix上对每个BGP邻居的关键指标做模板化：

指标	告警阈值
收到的BGP路由前缀数	±20% baseline
AS-PATH 拒绝计数	> 0
Update 报文频率	> 1000/分钟
BGP邻居翻动次数	> 0/小时

关键配置变更走代码评审

这条ip as-path 20 permit _100_200_是去年一个临时调试遗留的命令，没有走严格的code review，从那之后就一直在线上跑了——是典型的"运行久了就以为是正确的"陷阱。

根因分析

直接原因：去年临时调试写的ip as-path 20 permit _100_200_正则没有清理，该正则的本意是拒绝经过某些对等AS的路由，但因为AS-PATH正则下划线表示"任意字符串边界”，_100_200_实际匹配的是"含100和200这两个相邻AS号的所有路径"。

深层原因：电信AS4134骨干网升级后，在跨网传递路由时会在AS-PATH中追加"100 200"作为内部标记，这本来是合法的BGP属性，但与我们的策略冲突，导致近30万条路由被误判无效。

运营原因：路由策略类变更缺乏变更评审、回归测试、监控告警机制，“上线即正确"的惯性思维让这条命令在线上跑了8个多月，直到电信骨干网升级才暴露出问题。

预防措施

1. 路由策略变更必须走变更窗口

所有涉及route-map、ip as-path、ip community-list、ip prefix-list的变更，必须在业务低峰期执行，且必须经过至少一名网络架构师评审，并保留前后配置对比。

2. 部署"路由沙盒”

搭建一个隔离的BGP测试环境，使用Bird或FRRouting跑一个真实环境的镜像，配置变更先在沙盒里跑24小时观察，再上生产。

3. 完善BGP监控体系

每分钟采集BGP邻居的Received/Active Routes数量
对AS-PATH regex匹配做计数器
任何route-map的deny规则都应配WELF/Syslog上报

4. 与运营商建立常态化沟通机制

每次运营商侧骨干网升级、AS号调整、出口策略变化，都应在第一时间拿到变更通知单，评估对自有路由策略的影响。

5. 路由策略配置文件纳入Git管理

把核心交换机的配置按以下目录结构纳入Git：

network-config/
├── core-sw-01/
│   ├── bgp.conf
│   ├── route-map.conf
│   └── changelog.md
├── core-sw-02/
└── README.md

每次配置变更都走commit-msg规范，“为什么要这样配"的业务背景要写在commit信息里，避免半年后回看一脸懵。

总结

这次故障给我们最深的教训是：网络策略的"误拒绝"比"误允许"更隐蔽。误允许会立刻有告警（被拒绝的路由完全消失、流量中断），而误拒绝会让路由"看起来还在”（实际被打上无效标记），却悄悄把流量引到错误的路径上，影响业务却难以第一时间定位。

后续我们把"路由策略变更必须配监控"写进了运维SOP：任何新增的deny规则、任何修改的正则表达式、任何调整的local-preference，都必须配套一条监控项，且这条监控的告警接收人是这次变更的提交人本人——谁改的，谁兜底。

BGP是互联网的"神经系统"，容不得半点马虎。

一次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 一起维护的契约。

一次FortiGate防火墙策略配置错误导致内网DNS解析失败的排查实录

Fri, 15 Aug 2025 20:00:00 +0000

一、问题背景

2026年5月中旬，公司新收购的一家分公司完成网络改造，核心交换机升级为华为S7706，出口防火墙替换为FortiGate 100F，由我负责整体网络运维支持。改造完成后前三天网络运行正常，但从第四天开始，陆续有员工反映"网页打开很慢"、“有些网站完全打不开”、“微信能发消息但图片加载很慢”。

由于分公司没有专职网络工程师，问题上报到总部后由我远程协助排查。初期怀疑是ISP链路问题，联系运营商测速后确认出口带宽正常，100M专线上下行均达标，问题指向内网。

影响范围逐渐扩大，到第二天已有约40%的员工反映网络异常，部分关键业务系统（如ERP、OA）访问也出现间歇性超时，情况比较紧急。

二、故障现象

通过远程桌面连接到分公司的一台运维跳板机，我进行了以下几项基础测试，汇总故障现象如下：

1. 网络连通性测试

ping 8.8.8.8 通，延迟约12ms，无丢包；ping www.baidu.com 间歇性超时，大约30%的ICMP包被丢弃，且延迟波动极大（12ms~3000ms）。

2. DNS解析测试

使用 nslookup 测试内网DNS服务器（由AD域控兼做DNS，IP为192.168.10.10）：

C:\> nslookup www.baidu.com 192.168.10.10
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.

多次尝试后偶尔能解析成功，但响应时间普遍超过5秒。换成公共DNS（114.114.114.114）测试，现象一致。

3. HTTP/HTTPS访问测试

用curl测试HTTP访问：

1
2

C:\> curl -w "%{time_total}\n" -o /dev/null -s http://www.baidu.com
5.237

首次访问耗时超过5秒，后续复用连接后有所改善，但刷新页面后问题复现。

4. 关键观察

有一个重要现象：使用IP地址直接访问的业务系统（如 http://10.10.1.20）完全正常，延迟稳定；而使用域名访问的系统（如 http://oa.company.com）则间歇性超时。这进一步将问题范围缩小到DNS解析环节。

三、排查过程

第一步：确认DNS服务器本身是否正常

首先排除DNS服务器（AD域控）自身故障的可能性。远程登录到域控服务器，检查DNS服务状态：

1
2
3

PS> Get-Service DNS
Status   Name   DisplayName
Running  DNS    DNS Server

DNS服务运行正常。进一步检查DNS日志，发现大量"Event ID 4013"和"Event ID 3150"的警告日志，提示"DNS服务器无法解析外部域名，转发器超时"。

查看DNS转发器配置，发现配置了四个转发器：

202.96.128.86（本地运营商DNS）
114.114.114.114
8.8.8.8
8.8.4.4

看起来配置没有问题，但为什么解析会超时？

第二步：抓包分析DNS流量

在域控服务器上启动Wireshark，过滤DNS流量（UDP 53端口），然后进行解析测试：

`1`	`C:\> nslookup www.google.com 192.168.10.10`

抓包结果发现了关键线索：

域控向外网转发DNS查询时，发出的UDP包目标端口53，但完全没有收到响应包
域控随后尝试TCP 53重试，同样没有响应
整个过程中，域控本身可以ping通所有转发器IP，网络层是通的

这说明DNS查询包在出去的路上被丢了，而不是DNS服务器本身的问题。

第三步：检查FortiGate防火墙策略

分公司新上线的FortiGate 100F是本次网络改造的新增设备，重点怀疑对象。通过FortiCloud远程登录FortiGate管理界面，检查防火墙策略。

FortiGate的策略配置相对复杂，新上线时由实施工程师配置，我之前只做了基础验收测试。逐条检查策略，发现了一条当时为"临时测试"创建的策略，规则如下：

Policy ID: 5
Name: DNS_OUT_TEST
Source: all
Destination: all
Service: DNS
Action: DENY
Schedule: always
Log: disable

这条策略的意图是"临时禁止某个测试用的DNS流量"，但配置时Source设成了all，导致所有出站DNS流量（UDP/TCP 53）都被这条策略匹配并丢弃了。

更糟糕的是，这条DENY策略的序列号是5，排在所有ALLOW策略之前（FortiGate策略是自上而下匹配的）。也就是说，任何出站DNS流量在到达后面的ALLOW策略之前，先被这条策略拦截了。

第四步：验证猜测

为了验证是不是这条策略的问题，我先记录当前策略配置，然后临时禁用Policy ID 5，再进行DNS解析测试：

C:\> nslookup www.baidu.com 192.168.10.10
Server:  dc01.company.com
Address:  192.168.10.10

Non-authoritative answer:
Name:    www.a.shifen.com
Addresses:  110.242.68.4
            110.242.68.3
Aliases:  www.baidu.com

解析成功，响应时间不到100ms！进一步测试网页访问、业务系统访问，全部恢复正常。

第五步：追溯策略来源

联系当时负责实施的工程师，了解到这条策略是他做DNS代理测试时创建的，测试完后忘记删除了。由于FortiGate的策略匹配是顺序制的，这条DENY策略插在策略列表靠前的位置，导致所有DNS出站流量被静默丢弃。

之所以前三天没有暴露问题，是因为当时客户端DNS缓存尚未过期，且部分员工使用的是浏览器内置的DNS over HTTPS（DoH），绕过了系统DNS设置，所以问题有延迟才集中爆发。

四、解决方案

问题的根因已经明确，解决步骤如下：

1. 删除错误的测试策略

登录FortiGate，删除Policy ID 5：

1
2
3

config firewall policy
    delete 5
end

2. 优化DNS流量策略

原来策略列表中，DNS出站流量依赖一条"any to any"的通用放行策略，不够精细。新建专用策略，明确允许内网DNS出站：

config firewall policy
    edit 0
        set name "DNS_OUTBOUND"
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "RFC1918"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "DNS" "DNS-TCP"
        set logtraffic all
    next
end

关键点：

明确指定了源接口（internal）和目的接口（wan1）
服务明确限定为DNS（UDP 53）和DNS-TCP（TCP 53）
开启全量日志，便于后续排查

3. 优化DNS服务器转发器配置

原先DNS转发器配置了四个，其中8.8.8.8和8.8.4.4从分公司网络访问延迟较高（分公司出口是电信专线，访问Google DNS需要绕路）。优化后的转发器列表：

优先级	DNS服务器	说明
1	202.96.128.86	本地电信DNS，延迟最低
2	114.114.114.114	国内公共DNS，备用
3	内网根提示	直接迭代查询，最后兜底

4. 在FortiGate上启用DNS过滤的安全功能

FortiGate有内置的DNS过滤功能，可以阻断恶意域名解析。在优化后的策略上启用了此功能：

config firewall policy
    edit 10
        set dnsfilter-profile "default"
    next
end

五、根因分析

本次故障的根本原因是FortiGate防火墙策略配置错误，具体可以拆解为以下几个层面：

直接原因：一条Source为"all"的DNS DENY策略被错误地保留在策略列表中，且序列号靠前，导致所有出站DNS流量被静默丢弃。

间接原因：

策略审查缺失：新设备上线的策略清单没有经过严格的Code Review式审查，测试策略未及时清理
缺乏策略变更管理：FortiGate策略的增删改没有走变更流程，实施工程师可以随意添加策略
监控覆盖不足：FortiGate的DNS流量被DENY的日志没有开启（原策略Log设置为disable），导致无法通过日志快速发现问题
DNS解析超时表现不直观：客户端DNS解析超时后会有重试，ICMP ping通但HTTP慢，这种"半通不通"的现象容易引导排查方向偏离

六、预防措施

针对本次故障暴露的问题，制定了以下预防措施：

1. 建立防火墙策略变更管理流程

所有FortiGate策略变更必须满足：

变更前填写《防火墙策略变更申请表》，注明策略用途、源目地址、服务端口、有效期
测试策略必须设置明确的有效期（通过FortiGate的schedule功能实现自动过期）
变更后由第二人复核策略列表

2. 启用关键策略的日志功能

所有DENY类策略必须开启日志（set logtraffic all），以便在日志中心（FortiAnalyzer或FortiCloud）中监控被拦截的流量，快速发现问题。

3. 部署网络监控告警

在监控系统中增加以下告警项：

DNS解析成功率低于95%时告警
FortiGate策略命中次数异常（如某条DENY策略突然有大量命中）时告警
内网到外网DNS服务器的延迟超过100ms时告警

具体实现可以用Prometheus + Blackbox Exporter做DNS探测，告警推送到企业微信。

4. 标准化新设备上线检查清单

制作了《FortiGate上线检查清单》，包含以下关键检查项：

所有测试策略已清理或设置过期时间
策略序列号经过合理性审查（宽策略在前，窄策略在后）
DENY策略均开启日志
DNS、NTP等关键基础服务的策略已明确配置
保存配置（execute backup）

七、总结

这是一次典型的"配置残留"引发的网络故障。FortiGate作为状态检测防火墙，策略匹配顺序是自上而下，一条配置不当的DENY策略所产生的破坏力，不亚于一次DDoS攻击。

几个值得记取的教训：

测试策略必须有过期机制。FortiGate支持schedule设置策略有效期，所有临时测试策略都应该用这个功能，而不是依赖"记得删除"
DNS是网络的基础中的基础。DNS出问题时的表现非常具有迷惑性——ping IP通但域名不通，很容易被误判为应用层问题
抓包是最直接的排查手段。在本次故障中，Wireshark抓包看到的"有去无回"现象，是锁定问题方向的关键
策略变更要有审计。FortiGate的config revision功能可以定期自动备份配置，建议开启

网络运维工作中，“最小化变更影响"和"可回溯性"是两个核心原则。这次故障如果配置备份和策略审计做到位，本可以在5分钟内定位问题，而不需要花费近2个小时逐步排查。

本文所有IP地址、域名均已脱敏处理，技术细节基于真实案例整理。

AHK实现DD驱动按键连发（v2.0 GUI版）

Fri, 27 Aug 2021 08:13:21 +0000

前言

早在 2021 年就写过一个基于 AHK + DD 驱动的按键连发脚本，当时的版本很简陋——硬编码按键码、固定的间隔、没有任何界面，纯粹是"能用就行"的水平。最近抽空用 AutoHotkey v2.0 全面重写了它，加入了 GUI 界面、按键录制、配置保存等功能，同时也针对反作弊检测做了优化。

如果你不熟悉 DD 驱动：它是一个硬件级的键鼠模拟驱动，走的是内核层的模拟路径，比 AHK 原生的 Send / ControlSend 更底层，某些游戏或软件只认 DD 驱动的模拟输入。

功能概览

功能	说明
GUI 界面	告别纯脚本，可视化操作
按键录制	按一个键即可添加到连发列表，不用查码表
多键连发	支持勾选多个按键同时连发
鼠标支持	支持左键、右键、中键连发
间隔可调	1~9999ms 自由设置
随机抖动	30% 随机延迟，对抗反作弊检测
配置持久化	自动保存到 `config.ini`，重启保留设置
管理员权限	自动检测并提权

实现细节

1. 管理员权限检查

DD 驱动需要管理员权限才能加载，脚本启动时自动检测：

if !A_IsAdmin {
    Run('*RunAs "' A_ScriptFullPath '"')
    ExitApp()
}

如果没有管理员权限，自动以管理员身份重新启动自身。

2. 完整的 DD 键码映射表

初版脚本只硬编码了一个 502（x 键），新版建立了完整的键盘 + 鼠标码表：

DD_KEY_MAP := Map(
    "escape", 100, "f1", 101, "f2", 102, ...
    "q", 301, "w", 302, "e", 303, ...
    "a", 401, "s", 402, "d", 403, ...
    "z", 501, "x", 502, "c", 503, ...
    "lb", 1, "rb", 4, "mid", 16
)

这样用户按任何键都能被正确识别和模拟，不需要手动查码表。

3. 直接加载 DD.dll

废弃了旧版的 Class_DD.ahk 封装，直接通过 DllCall 加载 DLL：

DLL_PATH := A_ScriptDir "\DD.dll"
hModule := DllCall("LoadLibrary", "Str", DLL_PATH, "Ptr")
pDD_key := DllCall("GetProcAddress", "Ptr", hModule, "AStr", "DD_key", "Ptr")
pDD_btn := DllCall("GetProcAddress", "Ptr", hModule, "AStr", "DD_btn", "Ptr")
DllCall(pDD_btn, "Int", 0)  ; 初始化驱动

这样做的好处：

不需要额外的 Class_DD.ahk 文件
加载过程完全可控
加载失败时有明确的错误提示

4. GUI 界面设计

1
2

MyGui := Gui(, "AHK连发")
MyGui.SetFont("s10", "Microsoft YaHei")

界面包含几个核心区域：

间隔设置：输入框，单位毫秒，默认 200ms
按键管理：录制按钮 + 一键添加左右键 + 清空
按键列表：带勾选框的 ListView，打勾即参与连发
启动/停止按钮：大号醒目按钮，红色表示运行中

![界面区域说明](GUI 界面分为间隔设置区、按键管理区、按键列表区、启停控制区四个区域。)

5. 按键录制功能

这是体验提升最大的功能。旧版要手动改代码改键码，新版直接按一下就行：

StartRecord(*) {
    BtnRec.Text := "请按键..."
    ih := InputHook("L1 M T3")   ; 监听一个按键，超时3秒
    ih.KeyOpt("{All}", "E")
    ih.Start()
    ih.Wait()
    
    keyName := StrLower(ih.EndKey ? ih.EndKey : ih.Input)
    if DD_KEY_MAP.Has(keyName) {
        AddKeyItem(keyName)
    } else {
        ToolTip "未定义按键: " keyName
    }
}

使用 InputHook 拦截下一次按键，查码表后自动添加到列表。超时 3 秒无操作自动取消。

6. 反作弊检测对策——随机抖动

很多游戏的 anti-cheat 会检测固定间隔的输入模式。新版加入了 30% 随机抖动：

ScheduleNext() {
    interval := IsNumber(EditMs.Value) ? Integer(EditMs.Value) : 200
    jitter := Random(-interval * 0.3, interval * 0.3)
    delay := Max(10, interval + jitter)
    SetTimer(WorkLoop, -delay)
}

举例：设置 200ms 间隔，实际范围是 140~260ms 之间的随机值。每次触发间隔都不同，有效避免被固定模式检测抓包。

7. 鼠标按键支持

DD 驱动对鼠标按键的处理与键盘不同——键盘用 DD_key，鼠标用 DD_btn：

if (itemName = "lb" || itemName = "rb" || itemName = "mid") {
    DllCall(pDD_btn, "Int", code)       ; 按下
    Sleep 10
    DllCall(pDD_btn, "Int", code * 2)   ; 释放
} else {
    DllCall(pDD_key, "Int", code, "Int", 1)   ; 按下
    Sleep 10
    DllCall(pDD_key, "Int", code, "Int", 2)   ; 释放
}

DD 鼠标的释放码是按下码的 2 倍（例如左键按下=1，释放=2）。

8. 配置持久化

使用 INI 文件保存设置，重启脚本自动恢复：

SaveConfig() {
    IniWrite(EditMs.Value, CONFIG_PATH, "Settings", "Interval")
    keyStr := ""
    Loop LV.GetCount() {
        name := LV.GetText(A_Index, 2)
        state := LV.GetNext(A_Index - 1, "Checked") ? "1" : "0"
        keyStr .= name ":" state ","
    }
    IniWrite(RTrim(keyStr, ","), CONFIG_PATH, "Settings", "Keys")
}

保存格式示例（config.ini）：

1
2
3

[Settings]
Interval=200
Keys=x:1,c:1,lb:0,rb:1

9. 热键

热键	功能
`（反引号，SC029）	启动/停止连发
F12	彻底退出脚本

反引号键放在 ESC 下面，方便左手操作，不影响正常打字。

完整源码

#Requires AutoHotkey v2.0
#SingleInstance Force

; =========================
; 1. 管理员权限检查
; =========================
if !A_IsAdmin {
    Run('*RunAs "' A_ScriptFullPath '"')
    ExitApp()
}

; =========================
; 2. 码表定义
; =========================
DD_KEY_MAP := Map(
    "escape", 100, "f1", 101, "f2", 102, "f3", 103, "f4", 104, "f5", 105, "f6", 106, "f7", 107, "f8", 108, "f9", 109, "f10", 110, "f11", 111, "f12", 112,
    "``", 200, "1", 201, "2", 202, "3", 203, "4", 204, "5", 205, "6", 206, "7", 207, "8", 208, "9", 209, "0", 210, "-", 211, "=", 212, "\", 213, "backspace", 214,
    "tab", 300, "q", 301, "w", 302, "e", 303, "r", 304, "t", 305, "y", 306, "u", 307, "i", 308, "o", 309, "p", 310, "[", 311, "]", 312, "enter", 313,
    "capslock", 400, "a", 401, "s", 402, "d", 403, "f", 404, "g", 405, "h", 406, "j", 407, "k", 408, "l", 409, ";", 410, "'", 411,
    "lshift", 500, "z", 501, "x", 502, "c", 503, "v", 504, "b", 505, "n", 506, "m", 507, ",", 508, ".", 509, "/", 510, 
    "lctrl", 600, "lwin", 601, "lalt", 602, "space", 603,
    "up", 709, "left", 710, "down", 711, "right", 712,
    "numpad0", 800, "numpad1", 801, "numpad2", 802, "numpad3", 803, "numpad4", 804, "numpad5", 805, "numpad6", 806, "numpad7", 807, "numpad8", 808, "numpad9", 809,
    "lb", 1, "rb", 4, "mid", 16
)

; =========================
; 3. 加载 DD 驱动
; =========================
DLL_PATH := A_ScriptDir "\DD.dll"
CONFIG_PATH := A_ScriptDir "\config.ini"

if !FileExist(DLL_PATH) {
    MsgBox "找不到 DD.dll，请确保它与脚本在同一目录下！"
    ExitApp()
}

hModule := DllCall("LoadLibrary", "Str", DLL_PATH, "Ptr")
if !hModule {
    MsgBox "驱动加载失败，可能是架构不匹配或被杀软拦截。"
    ExitApp()
}

pDD_key := DllCall("GetProcAddress", "Ptr", hModule, "AStr", "DD_key", "Ptr")
pDD_btn := DllCall("GetProcAddress", "Ptr", hModule, "AStr", "DD_btn", "Ptr")
DllCall(pDD_btn, "Int", 0)

; =========================
; 4. UI 界面
; =========================
MyGui := Gui(, "AHK连发")
MyGui.SetFont("s10", "Microsoft YaHei")

MyGui.Add("Text", "", "间隔 (ms):")
EditMs := MyGui.Add("Edit", "vInterval x+10 w80", "200")
EditMs.OnEvent("Change", (*) => SaveConfig())

OpFrame := MyGui.Add("GroupBox", "xm w280 h60", "按键管理")
BtnRec := MyGui.Add("Button", "xp+10 yp+25 w90", "录制按键")
BtnRec.OnEvent("Click", StartRecord)
MyGui.Add("Button", "x+5 w50", "+左键").OnEvent("Click", (*) => AddKeyItem("lb"))
MyGui.Add("Button", "x+5 w50", "+右键").OnEvent("Click", (*) => AddKeyItem("rb"))
MyGui.Add("Button", "x+5 w50", "清空").OnEvent("Click", ClearList)

LV := MyGui.Add("ListView", "xm w280 h150 Checked",["", "按键名称"])
LV.ModifyCol(1, 30)
LV.ModifyCol(2, 230)
LV.OnEvent("ItemCheck", (*) => SaveConfig())

BtnToggle := MyGui.Add("Button", "xm w280 h40", "启动 ( `` )")
BtnToggle.SetFont("bold s11")
BtnToggle.OnEvent("Click", ToggleRunning)

MyGui.Add("Text", "xm w280 Center cGray", "F12 彻底退出")
MyGui.OnEvent("Close", (*) => ExitApp())

Global IsRunning := false

LoadConfig()
MyGui.Show()

; =========================
; 5. 功能逻辑
; =========================

StartRecord(*) {
    BtnRec.Text := "请按键..."
    ih := InputHook("L1 M T3")
    ih.KeyOpt("{All}", "E")
    ih.Start()
    ih.Wait()
    
    keyName := StrLower(ih.EndKey ? ih.EndKey : ih.Input)
    BtnRec.Text := "录制按键"
    
    if (keyName == "") {
        return
    }

    if DD_KEY_MAP.Has(keyName) {
        AddKeyItem(keyName)
    } else {
        ToolTip "未定义按键: " keyName
        SetTimer (*) => ToolTip(), -2000
    }
}

AddKeyItem(name, enabled := true) {
    Loop LV.GetCount() {
        if (LV.GetText(A_Index, 2) == name) {
            return
        }
    }
    LV.Add(enabled ? "Check" : "-Check", "", name)
    SaveConfig()
}

ClearList(*) {
    Global IsRunning
    if (LV.GetCount() > 0) {
        LV.Delete()
        SaveConfig()
    }
    if IsRunning {
        ToggleRunning() 
    }
}

ToggleRunning(*) {
    Global IsRunning
    if !IsRunning {
        hasChecked := false
        Loop LV.GetCount() {
            if LV.GetNext(A_Index - 1, "Checked") {
                hasChecked := true
                break
            }
        }
        
        if !hasChecked {
            ToolTip "请先在列表里【打勾】需要连发的按键"
            SetTimer (*) => ToolTip(), -2000
            return
        }

        IsRunning := true
        BtnToggle.Text := "停止 ( `` )"
        BtnToggle.Opt("cRed")
        
        ScheduleNext()
    } else {
        IsRunning := false
        BtnToggle.Text := "启动 ( `` )"
        BtnToggle.Opt("cDefault")
        SetTimer(WorkLoop, 0)
    }
}

ScheduleNext() {
    interval := IsNumber(EditMs.Value) ? Integer(EditMs.Value) : 200
    jitter := Random(-interval * 0.3, interval * 0.3)
    delay := Max(10, interval + jitter)
    SetTimer(WorkLoop, -delay)
}

WorkLoop() {
    Global IsRunning
    Static inLoop := false
    if !IsRunning || inLoop {
        return
    }
    inLoop := true
    
    row := 0
    Loop {
        row := LV.GetNext(row, "Checked")
        if !row {
            break
        }
            
        itemName := LV.GetText(row, 2)
        if !DD_KEY_MAP.Has(itemName) {
            continue
        }
            
        code := DD_KEY_MAP[itemName]
        
        if (itemName = "lb" || itemName = "rb" || itemName = "mid") {
            DllCall(pDD_btn, "Int", code)
            Sleep 10
            DllCall(pDD_btn, "Int", code * 2)
        } else {
            DllCall(pDD_key, "Int", code, "Int", 1)
            Sleep 10
            DllCall(pDD_key, "Int", code, "Int", 2)
        }
    }
    inLoop := false
    if IsRunning {
        ScheduleNext()
    }
}

SaveConfig() {
    if FileExist(CONFIG_PATH) {
        FileDelete(CONFIG_PATH)
    }
    
    IniWrite(EditMs.Value, CONFIG_PATH, "Settings", "Interval")
    
    keyStr := ""
    Loop LV.GetCount() {
        name := LV.GetText(A_Index, 2)
        state := LV.GetNext(A_Index - 1, "Checked") ? "1" : "0"
        keyStr .= name ":" state ","
    }
    IniWrite(RTrim(keyStr, ","), CONFIG_PATH, "Settings", "Keys")
}

LoadConfig() {
    if !FileExist(CONFIG_PATH) {
        return
    }
    
    try {
        iv := IniRead(CONFIG_PATH, "Settings", "Interval", "200")
        EditMs.Value := iv
        
        keysData := IniRead(CONFIG_PATH, "Settings", "Keys", "")
        if (keysData != "") {
            for , item in StrSplit(keysData, ",") {
                if (item = "") {
                    continue
                }
                parts := StrSplit(item, ":")
                if (parts.Length == 2) {
                    AddKeyItem(parts[1], parts[2] == "1")
                }
            }
        }
    }
}

; =========================
; 6. 热键
; =========================
~SC029::ToggleRunning()
F12::ExitApp()

新旧版本对比

维度	旧版 (v1)	新版 (v2)
AHK 版本	v1	v2.0
界面	无（纯脚本）	GUI 界面
按键管理	硬编码键码	录制 + 列表 + 勾选
支持按键数	1 个	不限（多键同时）
鼠标支持	不支持	左/右/中键
间隔调节	固定 20ms	可自定义
反作弊	无	30% 随机抖动
配置保存	无	INI 持久化
DD 加载	Class_DD.ahk 封装	直接 DllCall
权限处理	无	自动提权

使用方法

安装 AutoHotkey v2.0
将 DD.dll 放到与脚本同一目录
双击运行脚本（自动以管理员身份运行）
GUI 界面中：
- 点击「录制按键」然后按一个键，加入列表
- 或直接点「+左键」「+右键」添加鼠标按键
- 在列表中打勾需要连发的按键
- 设置间隔（默认 200ms）
按反引号键（`，ESC 下面那个）启动/停止连发
按 F12 退出

常见问题

Q: 提示"找不到 DD.dll"？
确保 DD.dll 与脚本文件在同一目录下。如果是从别处下载的 DD 驱动，注意区分 32 位 / 64 位版本。

Q: 驱动加载失败？
通常是杀毒软件拦截了 DD.dll。将脚本目录添加到杀软白名单，或临时关闭杀软后再试。

Q: 游戏里没反应？
部分游戏的反作弊系统会拦截 DD 驱动。确认游戏是否允许硬件级模拟输入。

Q: 想换个启动热键？
修改最后一行 ~SC029::ToggleRunning() —— SC029 是反引号键的扫描码。改为 ~F8::ToggleRunning() 就是 F8 键启动。

项目地址

AutoHotkey 官网
脚本源码：见上方完整源码区域

更新于 2026-06-20：从 AHK v1 纯脚本全面升级为 AHK v2.0 GUI 版本。

一次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 就是最诚实的线索。

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

一次DHCP地址池耗尽导致大面积断网的排查实录

Thu, 27 Mar 2025 08:00:00 +0000

问题背景

周一早上 9 点，刚到办公室坐下，内部沟通群里就开始炸了——整层楼的员工纷纷反馈"连不上网"“网页打不开"“钉钉掉线”。我们公司办公区大约 200 人，分布在两个楼层，通过核心交换机连接到上联防火墙出口。网络拓扑相对简单：核心交换机做 DHCP Server，每个 VLAN 对应一个子网，地址池按楼层划分。

我作为网络运维负责人，第一时间意识到这不是个别用户的问题，而是大面积故障。好在服务器区域使用的是静态 IP，不受 DHCP 影响，核心业务系统还在正常运行。但办公网的瘫痪意味着 200 人无法工作，紧急程度属于 P1 级别——必须 30 分钟内恢复。

故障现象

用户反馈的具体表现如下：

新接入设备无法获取 IP：部分刚开机或重新连接的电脑显示"正在获取网络地址”，持续等待后最终提示"无 Internet 连接"，ipconfig /all 显示 IP 为 0.0.0.0。
已在线设备部分正常：之前已经拿到 IP 且租期未过期的设备暂时还能上网，但网络明显变慢， ping 内网网关偶尔出现 50-200ms 的异常延迟。
DHCP 请求超时：在受影响的终端上抓包，可以看到 DHCP Discover 包正常发出，但始终没有收到 DHCP Offer 回应。

关键信息：

核心交换机（华为 S5735-L48T4X）上配置了 VLAN 10（一楼）和 VLAN 20（二楼）的 DHCP 地址池
VLAN 10 地址池：192.168.10.100 - 192.168.10.250，共 151 个地址
VLAN 20 地址池：192.168.20.100 - 192.168.20.250，共 151 个地址
楼层实际办公电脑数量：一楼约 90 台，二楼约 110 台

排查过程

第一步：确认 DHCP 服务状态

登录核心交换机，首先检查 DHCP Server 是否正常运行：

<HX-Switch> display dhcp server statistics
  DHCP Server Statistics:
    Request Received     : 4238
    Offer Sent           : 151
    Ack Sent             : 151
    Discover Received    : 4087
    Offer Failed         : 3936

关键发现：Offer Failed 达 3936 次！ 这意味着交换机收到了大量 DHCP Discover 请求，但无法回复 Offer。这几乎可以确定是地址池出了问题。

第二步：检查地址池使用情况

继续查看地址池的分配状态：

<HX-Switch> display dhcp server ip-in-use pool vlan10
  IP Address       Hardware Address   Lease Expired   Status
  192.168.10.100   00e0-4c68-01a2    2026/06/20 18:00  Used
  192.168.10.101   00e0-4c68-03b5    2026/06/20 18:00  Used
  ...（省略中间）
  192.168.10.250   a860-b117-55c3    2026/06/20 18:00  Used
  Total : 151    Used : 151    Idle : 0

1
2

<HX-Switch> display dhcp server ip-in-use pool vlan20
  Total : 151    Used : 151    Idle : 0

地址池 100% 占用，零空闲！ VLAN 10 和 VLAN 20 的 302 个地址全部被分配。但实际办公电脑只有约 200 台，多出来的 100 多个地址被谁占走了？

第三步：分析 DHCP 租约表

导出完整租约表进行详细分析。我用 Python 脚本处理交换机输出的 MAC-IP 映射：

`1`	`<HX-Switch> display dhcp server ip-in-use pool vlan10 all`

拿到全部 151 条记录后，我重点关注 MAC 地址的前缀（OUI），用来识别设备类型：

MAC 前缀	设备类型	数量
00e0-4c	Realtek（PC 网卡）	68
a860-b1	Apple（iPhone/Mac）	42
dc:a6:32	Raspberry Pi	12
88:15:44	智能家居/IoT 设备	15
ac:de:48	私有 MAC（随机化）	14

发现了！42 台 iPhone + 15 台 IoT 设备 + 12 台 Raspberry Pi + 14 台随机化 MAC 设备 = 83 台非办公设备，它们占用了大量 DHCP 地址。这些是员工个人手机、测试设备以及不明 IoT 设备。

VLAN 20 的情况更严重：二楼有 110 台办公电脑，地址池只有 151 个，被 48 台手机和一堆 IoT 设备挤占后，留给办公电脑的只有不到 100 个——根本不够用。

第四步：定位非法设备的接入端口

接下来需要找到这些非办公设备是从哪些端口接入的。在交换机上查询 MAC 地址表：

<HX-Switch> display mac-address dynamic vlan 10
  MAC Address      VLAN  Port          Type
  a860-b117-55c3   10    GE0/0/15     Dynamic
  a860-b117-66d4   10    GE0/0/15     Dynamic
  a860-b117-78e1   10    GE0/0/15     Dynamic
  ...（多个 Apple MAC 均从 GE0/0/15 学习到）
  dc:a6-32-01-ab   10    GE0/0/22     Dynamic
  dc:a6-32-01-cd   10    GE0/0/22     Dynamic
  88:15:44-xx      10    GE0/0/28     Dynamic

发现规律：

GE0/0/15：会议室区域的大屏和员工手机大量接入（一个端口下挂 AP，AP 下连接了数十个无线设备）
GE0/0/22：研发测试区的交换机下联了 12 台 Raspberry Pi
GE0/0/28：茶水间区域的 IoT 设备（智能灯控、温湿度传感器等）

根本问题很清楚了：无线 AP 没做 MAC 过滤，任何人都可以用手机连上办公 Wi-Fi 拿到 IP；研发区随意接入测试设备；IoT 设备也混在办公 VLAN 里。

第五步：查看 DHCP 租期配置

再看一下租期设置：

1
2
3

<HX-Switch> display dhcp server pool vlan10
  Pool Name      : vlan10
  Lease Day      : 1    Hour : 0    Minute : 0

租期 1 天！ 手机连上 Wi-Fi 后拿到的 IP 要 24 小时才会过期释放，即使手机离开了网络，地址也一直被占着。这进一步加剧了地址池耗尽的问题。

解决方案

紧急恢复（5 分钟内实施）

第一步：清除非法设备的 DHCP 租约，立即释放被占用的地址：

<HX-Switch> system-view
# 批量释放非办公MAC的租约
<HX-Switch> reset dhcp server ip-in-use mac-address a860-b117-55c3 pool vlan10
<HX-Switch> reset dhcp server ip-in-use mac-address a860-b117-66d4 pool vlan10
# ...（按MAC前缀批量清除所有Apple/iOS设备的租约）
<HX-Switch> reset dhcp server ip-in-use pool vlan10 conflict
# 清除冲突地址

由于手动一条条清太慢，我用了更高效的方法——缩短租期到 1 小时，让所有现有租约快速过期：

<HX-Switch> dhcp server ip-pool vlan10
<HX-Switch-vlan10> lease day 0 hour 1 minute 0
<HX-Switch> dhcp server ip-pool vlan20
<HX-Switch-vlan20> lease day 0 hour 1 minute 0

这样 1 小时后所有设备的租约都会到期需要重新续租，到那时我们再通过端口安全策略拦截非法设备。

第二步：临时扩大地址池，缓解当前压力：

<HX-Switch> dhcp server ip-pool vlan10
<HX-Switch-vlan10> network 192.168.10.0 mask 255.255.254.0
# 地址范围从 .100-.250 扩大到 .1-.510（实际可用约 500）
<HX-Switch> dhcp server ip-pool vlan20
<HX-Switch-vlan20> network 192.168.20.0 mask 255.255.254.0

将子网掩码从 /24 改为 /23，地址池翻倍，确保即使有手机接入也不会耗尽。

注意：扩大子网后需要同步更新上联防火墙的路由和 NAT 规则。

约 3 分钟后，用户开始陆续恢复网络连接。紧急恢复完成。

根治方案（当天下午实施）

1. VLAN 隔离——IoT 和访客设备独立网段

<HX-Switch> vlan 30  # IoT专用VLAN
<HX-Switch-vlan30> dhcp server ip-pool iot
<HX-Switch-iot> network 192.168.30.0 mask 255.255.255.0
<HX-Switch-iot> lease day 0 hour 0 minute 30  # IoT设备租期30分钟
<HX-Switch-iot> gateway-list 192.168.30.1

<HX-Switch> vlan 40  # 访客Wi-Fi VLAN
<HX-Switch-vlan40> dhcp server ip-pool guest
<HX-Switch-guest> network 192.168.40.0 mask 255.255.255.0
<HX-Switch-guest> lease day 0 hour 2 minute 0  # 访客租期2小时
<HX-Switch-guest> gateway-list 192.168.40.1

无线 AP 配置双 SSID：Office-WiFi（仅办公设备，绑定 VLAN 10/20）和 Guest-WiFi（访客/手机，绑定 VLAN 40），通过 802.1X 认证区分合法办公设备。

2. 端口安全——限制接入设备数量

<HX-Switch> interface GE0/0/15  # 会议室端口
<HX-Switch-GE0/0/15> port-security enable
<HX-Switch-GE0/0/15> port-security max-mac-num 5  # 最多5台设备
<HX-Switch-GE0/0/15> port-security protect-action shutdown  # 超限则关闭端口

<HX-Switch> interface GE0/0/22  # 研发测试区
<HX-Switch-GE0/0/22> port-security enable
<HX-Switch-GE0/0/22> port-security max-mac-num 20  # 研发区允许较多设备
<HX-Switch-GE0/0/22> port-security protect-action restrict  # 超限仅丢弃新MAC

3. DHCP 租期优化

办工 VLAN：租期从 1 天调整为 8 小时（足够一个工作日，下班后地址自动释放）
IoT VLAN：租期 30 分钟（IoT 设备重启频繁，短租期避免地址浪费）
访客 VLAN：租期 2 小时（访客停留时间有限）

4. DHCP Snooping 防护

<HX-Switch> dhcp snooping enable
<HX-Switch> vlan 10
<HX-Switch-vlan10> dhcp snooping enable
<HX-Switch> interface GE0/0/1  # 上联口（信任口）
<HX-Switch-GE0/0/1> dhcp snooping trust

防止非法 DHCP Server 干扰，同时记录 DHCP 绑定表便于审计。

根因分析

问题的根本原因有三层：

网络架构设计缺陷：所有设备（办公电脑、手机、IoT、测试设备）混在同一个 VLAN 里，没有按设备类型做网络隔离。地址池按"办公电脑数量"规划，完全忽略了无线 AP 下挂的手机和 IoT 设备。
DHCP 租期过长：1 天的租期导致设备断开连接后 IP 仍然被占用长达 24 小时。手机这种高流动性设备（连上 Wi-Fi 就拿 IP，离开后 IP 一直不释放）是地址池耗尽的最大推手。
无线网络缺乏准入控制：办公 Wi-Fi 无认证无过滤，任何人的手机都可以随意接入，等于给 DHCP 地址池开了一个无底洞。

三层因素叠加：架构上没有隔离 → 准入上没有限制 → 租期上没有优化 → 地址池被挤爆。

预防措施

基于这次故障，我们制定了以下长期预防措施：

1. 定期巡检 DHCP 地址池利用率

编写巡检脚本，每小时采集地址池利用率并推送监控：

import paramiko
import re

def check_dhcp_pool(switch_ip, pool_name):
    ssh = paramiko.SSHClient()
    ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
    ssh.connect(switch_ip, username='admin', password='xxx')
    cmd = f'display dhcp server ip-in-use pool {pool_name}'
    output = ssh.exec_command(cmd)[1].read().decode()
    # 解析 Total / Used / Idle
    match = re.search(r'Total\s*:\s*(\d+)\s*Used\s*:\s*(\d+)\s*Idle\s*:\s*(\d+)', output)
    if match:
        total, used, idle = int(match.group(1)), int(match.group(2)), int(match.group(3))
        utilization = used / total * 100
        if utilization > 85:
            send_alert(f'DHCP池 {pool_name} 利用率 {utilization:.1f}%，空闲仅 {idle} 个')
    ssh.close()

# 定时巡检所有地址池
for pool in ['vlan10', 'vlan20', 'iot', 'guest']:
    check_dhcp_pool('10.0.0.1', pool)

2. VLAN 规划标准化

新建网络区域必须遵循 VLAN 隔离原则：

办工设备 VLAN：仅允许通过 802.1X 认证的设备接入
IoT 设备 VLAN：单独隔离，ACL 限制只能访问特定服务器
访客 VLAN：独立 SSID，ACL 限制只能访问 Internet，禁止访问内网资源

3. 地址池容量预留

地址池规划时预留 50% 以上冗余。例如 200 台办公设备，地址池至少 300 个地址。同时预留一个备选子网，在紧急扩容时可快速启用。

4. 无线网络准入强化

办工 Wi-Fi 启用 802.1X 企业认证，绑定 AD 域账号
访客 Wi-Fi 启用 Web 认证（短信验证码或临时账号）
定期审计无线 AP 的关联终端列表，清理异常设备

5. 建立变更审批流程

任何人接入非办公设备（测试服务器、IoT 设备等）必须提前提交网络变更申请，运维团队评估 VLAN 归属和地址池容量后才允许接入。

总结

这次故障从发现到紧急恢复用了约 15 分钟，根治方案在当天下午完成。最大的教训是：网络规划不能只看"有多少台电脑"，要看"有多少台设备会连上来"。

在移动办公时代，每个员工至少有一台手机会连 Wi-Fi，加上各种 IoT 设备和测试设备，实际接入数往往是办公电脑数的 1.5-2 倍。如果地址池按电脑数来规划，必然会被挤爆。

另一个关键认知是：DHCP 租期不是越大越好。长租期在设备稳定的场景（服务器、固定工位）是好实践，但在高流动性场景（手机、访客）就是灾难。不同类型的设备要用不同的租期策略。

最后，网络隔离是最基本的防护——把办公、IoT、访客分到不同 VLAN，不仅仅是为了安全，也是为了资源管理。当你发现一个 VLAN 的地址池快满时，至少不会拖垮其他 VLAN 的正常设备。

AD域环境下打印机批量部署失败的排查手记

Mon, 03 Nov 2025 08:00:00 +0000

问题背景

周二上午9点刚过，行政部的李姐就冲进IT办公室：“王工，3楼、4楼新装的打印机一台都用不了，上周不是已经批量推送过去了吗？”

事情要从一周前说起。我们公司上周搬迁，3楼、4楼办公区新增了6台网络打印机（HP M438n），按计划通过组策略（GPO）批量推送到对应的计算机OU。理论上只要机器重启或者刷新策略，就能自动映射好打印机。但现实是——80台机器里只有30台正常，剩下50台分布在3楼、4楼全部报错。

影响范围不算小：3楼、4楼两个楼层加起来80个工位，行政、财务、销售部门都在这一片，业务基本停摆。紧急程度：P1（影响业务），需要在上午11点前给一个临时方案，下午前彻底解决。

故障现象

正常的那30台机器，登录后能在"设备和打印机"里看到新增的6台打印机，能正常打印。

出问题的50台机器表现完全一致：

打开"设备和打印机"，6台打印机一台都不显示；
手动运行\\printserver\PrintInstaller\setup.exe安装驱动，提示：
1

Windows 无法连接到打印机，操作失败,错误为 0x0000011b
打开printmanagement.msc（打印管理），本机的"打印机"列表是空的，没有任何队列；
事件查看器 → 系统日志里刷出大量红色错误：
1 2

错误 application 0 0 PrintService Spooler 正在关闭。
每隔2-3分钟就重复一次。

看到 0x0000011b 第一反应是今年闹得沸沸扬扬的 PrintNightmare 漏洞补丁导致的打印共享问题。但我们推的是本地驱动直连（IP直连），不应该走 SMB 共享才对。这个直觉告诉我——根因可能和漏洞补丁没关系，得另找思路。

排查过程

第一步：先解决"能不能用"的问题（止血）

50台机器全靠脚本临时修不现实。我先让3楼前台、4楼前台、销售部主管这3台"关键岗"电脑单独处理：

# 临时方案：手动添加打印机
# 走IPP端口直连，不依赖SMB共享
Add-Printer -Name "HP-M438n-3F-01" `
  -DriverName "HP Universal Printing PCL 6" `
  -PortName "IP_192.168.30.201"

测试发现：走IP直连可以装上。所以问题不在打印机本身，也不在网络层面（ICMP、9100端口都通）。问题卡在"批量推送"这个动作上。

第二步：检查GPO是否真的下发到机器

在出问题的机器上跑：

`1`	`gpresult /h C:\gpo_report.html`

打开报告一看——计算机配置里包含了我们那条打印机映射策略，OU归属也正确。策略是有的。

第三步：手动强制刷新策略

`1`	`gpupdate /force`

执行完重启，问题依旧。说明GPO能下发到，但执行动作的时候挂了。

第四步：去看脚本到底干了啥

打印机映射脚本本质上是个开机脚本，用 rundll32 printui.dll 走PointAndPrint模式：

`1`	`rundll32 printui.dll,PrintUIEntry /in /n "\\printserver\HP-M438n-3F-01"`

这里有 \\printserver\！ 也就是说，脚本虽然最终连的是IP直连打印机，但驱动安装阶段还是要回到打印服务器去拉驱动文件。

但前面排过 SMB 没通吗？我们马上测一下：

`1`	`net view \\printserver`

提示：发生系统错误 53。找不到网络路径。

哦豁，问题就出在这。50台机器都 ping 不通 printserver 这个主机名（DNS解析失败），而那30台正常的机器是上个月搬迁前就装好的——它们的本地 DNS 缓存里还残留着 printserver 的旧解析记录（指向搬迁前的服务器IP），所以"看起来"能工作。

第五步：定位 DNS 解析失败原因

在出问题的机器上：

`1`	`nslookup printserver`

1
2
3

服务器:  UnKnown
Address:  192.168.10.5
*** UnKnown 找不到 printserver: Non-existent domain

DNS服务器是我们内部的AD DC（192.168.10.5），正常的。但 printserver 这条A记录不在了。

立即去DNS管理器查看：果然，搬迁那天IT同事在迁移打印服务器到新IP（192.168.30.200）的时候，只改了A记录的IP值，没保存。但诡异的是，有30台机器还能解析出来——后来查证，那30台机器在搬迁当天重启过，本地DNS缓存里有过临时解析，缓存还没过期；剩下50台上周都没重启过，今天一刷新就全暴露了。

第六步：验证修复

DNS 修复后，在一台问题机器上 ipconfig /flushdns，然后 gpupdate /force 重启——打印机全出来了。

解决方案

1. DNS 修复（治本）

在DNS管理器里：

进入 printserver 的A记录，重新保存（值是对的，只是没保存成功）；
顺手在DHCP里给所有客户端推送 DNS 搜索域 corp.local，避免单点主机名解析；
给 printserver 加一条别名（CNAME）：prt，双管齐下防止单点故障。

2. 脚本改造（治标+预防）

把脚本里所有 \\printserver\ 改成 IP 直连（\\192.168.30.200\），或者干脆全部用 Add-Printer 走IPP，彻底摆脱SMB依赖：

# 改造后的脚本（节选）
$printers = @(
    @{Name="HP-M438n-3F-01"; IP="192.168.30.201"},
    @{Name="HP-M438n-3F-02"; IP="192.168.30.202"},
    @{Name="HP-M438n-4F-01"; IP="192.168.30.211"}
)

foreach ($p in $printers) {
    $portName = "IP_$($p.IP)"
    if (-not (Get-PrinterPort -Name $portName -ErrorAction SilentlyContinue)) {
        Add-PrinterPort -Name $portName -PrinterHostAddress $p.IP
    }

    if (-not (Get-Printer -Name $p.Name -ErrorAction SilentlyContinue)) {
        Add-Printer -Name $p.Name `
            -DriverName "HP Universal Printing PCL 6" `
            -PortName $portName
    }
}

3. 应急方案

把上面这个 PowerShell 脚本放到共享路径 \\fileserver\IT\Tools\RepairPrinters.ps1，让有问题的用户右键以管理员运行一次，先把业务恢复。

根因分析

表面看是打印机没装上，根因是变更管理没闭环：

搬迁当天同事修改DNS记录时，没有验证保存结果（UI上点保存和实际写入是有区别的，UAC、域权限、AD复制延迟都可能让"看起来保存了"但实际没生效）；
GPO 推送脚本强依赖主机名 \\printserver\，没有兜底机制；
没有打印机连接状态的监控告警，等到用户主动报障才发现，业务影响已经扩大。

说白了，单点 DNS 故障 + 强依赖主机名 + 零监控，三连击凑齐了，事故只是时间问题。

预防措施

针对这次问题，给后续运维工作立了三条规矩：

变更后必验证：所有 DNS、DHCP、GPO 类变更必须变更前快照 + 变更后 5 分钟内 nslookup 验证，并在群内截图留痕。重要变更申请双人复核；
脚本去单点依赖：所有登录脚本、开机脚本里禁止写裸主机名，必须用 FQDN（printserver.corp.local）或 CNAME 别名，并且关键脚本增加 fallback 逻辑——主路径走不通就走IP直连；
加监控：用 Zabbix 监控关键打印机（IP在线、墨盒、卡纸）和域内关键主机名解析成功率，超过 5% 失败率自动告警。

监控盲区是最贵的盲区，这次等于交了50台机器+1个上午的学费。

总结

这次故障给团队最深的教训是：用户报障的"现象"和"根因"之间，往往隔了 3-4 层跳转。从打印机没装好 → 0x0000011b → GPO没生效 → DNS记录丢失，4步才到根因。如果一开始就盯着打印机本身（驱动、端口、网络），会浪费大量时间。

排查这种"批量出问题"的场景，最快的破局点不是"找正常的30台和异常的50台有什么区别"，而是直接去看"异常的那批，在哪一步出错了"。这次 nslookup printserver 这一下，5分钟定位了根因，比逐个机器查 GPO 应用日志高效得多。

运维老炮都懂的道理：先看 DNS，再看网络，最后看应用。别上来就重启服务。

一次NTP时间同步异常导致Kerberos认证全部失效的排查实录

Mon, 14 Jul 2025 09:15:00 +0000

问题背景

某周一上午 9 点左右，公司 IT 服务台接到多起投诉：员工无法访问共享文件夹（\\fileserver\share），访问内网系统提示"用户名或密码不正确"，即使重新输入正确密码仍无法登录。部分员工的 Outlook 也无法连接 Exchange，提示需要重新输入密码。

受影响人数约 60 人，分布在不同楼层，但有一个共同点：周末期间他们的电脑一直保持开机状态（服务器机房和少量长期开机的办公室电脑）。

故障现象

访问共享文件夹报错：登录失败：目标账户名不正确
Outlook 提示凭据错误，无法连接 Exchange
部分系统登录时报：此计算机上的时钟与主域控制器上的时钟不同步
klist 命令查看 Kerberos 票据，显示无法获取票据：KRB5KRB_AP_ERR_SKEW: Clock skew too great

排查过程

第一步：注意到时间错误提示

一位细心的用户截图发给 IT，截图中包含了一行小字：此计算机上的时钟与主域控制器上的时钟不同步。这个提示是关键线索。

在一台受影响的机器上查看系统时间：

`1`	`w32tm /query /status`

输出：

Leap Indicator: 3(not synchronized)
Stratum: 0 (unspecified)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0000000s
Root Dispersion: 10.0000000s
ReferenceId: 0x00000000
Last Successful Sync Time: 7/11/2025 11:30:45 PM
Source: time.windows.com
Poll Interval: 17 (131072s)

关键发现：Last Successful Sync Time 是 7月11日（周五晚上），已经 3 天没有同步！

再看当前时间与域控的差异：

`1`	`net time \\dc01`

输出：

1
2

Current time at \\DC01 is 7/14/2025 9:23:15 AM
The command completed successfully.

而本机时间：

time /t

`1`	`09:17:42`

本机时间 09:17，DC 时间 09:23，差了约 6 分钟，超过了 Kerberos 允许的最大时间偏差（5 分钟）。

第二步：Kerberos 时间敏感性原理

Kerberos 协议要求客户端和 KDC（Key Distribution Center，通常是域控）之间的时间差不超过 5 分钟（由 MaxClockSkew 参数控制，默认值 5 分钟）。这是 Kerberos 防止重放攻击的安全机制。

当时间偏差超过 5 分钟时：

客户端申请 Kerberos 票据（TGT）时，KDC 会拒绝请求，返回 KRB5KRB_AP_ERR_SKEW
所有依赖 Kerberos 的服务认证失败，包括：共享文件夹访问、Exchange、域控登录、GPO 应用等

第三步：追查 NTP 同步失败的原因

受影响的机器理论上应该从域控同步时间（域成员机器默认时间源是域控）。检查这些机器为什么没有同步：

`1`	`w32tm /query /configuration`

输出发现这台机器的 NTP 源被手动配置为了 time.windows.com（外网 NTP 服务器），而不是使用域的自动配置（NT5DS，从域层次结构同步）。

继续查看其他受影响机器，发现大部分受影响机器的 NTP 配置有问题，要么被手动改过，要么因为某个组策略没有正常应用而导致 NTP 源配置不正确。

进一步查看域控本身的 NTP 配置：

1
2

# 在 DC01 上执行
w32tm /query /status

Leap Indicator: 3(not synchronized)
Stratum: 0 (unspecified)
Last Successful Sync Time: 7/11/2025 11:28:13 PM
Source: ntp.aliyun.com

域控本身也没有同步！ 域控的上游 NTP 服务器（ntp.aliyun.com）从周五晚上开始就无法访问了。

第四步：排查为什么 NTP 服务器不可达

`1`	`ping ntp.aliyun.com`

`1`	`Request timeout for icmp_seq 0`

无法 ping 通。检查防火墙日志，发现周六白天运维团队在做例行防火墙策略清理时，误删了一条允许 UDP 123（NTP 协议端口）出站的规则，导致所有机器无法向外部 NTP 服务器同步时间。

由于周末无人值班，这个问题持续了 2 天多，域控的时间逐渐漂移，到周一早上已经偏差 6 分钟，触发了 Kerberos 认证失败。

完整的故障链： 防火墙误删 UDP 123 规则 → NTP 同步失败 → 域控时间漂移 → 域成员机器时间偏差超 5 分钟 → Kerberos 认证失败 → 大量服务不可访问

解决方案

第一步：恢复防火墙 NTP 规则

在 FortiGate 防火墙上重新添加允许出站 UDP 123 的规则：

策略 → 允许出站 NTP
Source: Internal_Network
Destination: All
Service: NTP (UDP 123)
Action: Accept

第二步：强制域控同步时间

1
2

# 在 PDC（主域控制器）上执行
w32tm /resync /force

等待同步完成：

`1`	`w32tm /query /status`

验证 Last Successful Sync Time 更新为当前时间。

第三步：强制受影响机器同步

在受影响机器上：

# 先停止 W32Time 服务
net stop w32time

# 注册并重新配置为域同步
w32tm /unregister
w32tm /register

# 重启服务
net start w32time

# 强制同步
w32tm /resync /force

# 验证
w32tm /query /status
net time \\dc01

第四步：通过 GPO 批量修复

对于大量受影响机器，通过 PowerShell 远程批量执行：

$computers = (Get-ADComputer -Filter * -SearchBase "OU=Workstations,DC=company,DC=com").Name
Invoke-Command -ComputerName $computers -ScriptBlock {
    Stop-Service w32time -Force
    w32tm /unregister
    w32tm /register
    Start-Service w32time
    w32tm /resync /force
}

处理完成后，相关 Kerberos 错误消失，服务全部恢复正常。

根因分析

根本原因是防火墙变更管理不规范，例行清理操作误删了 NTP 出站规则，且该变更没有经过充分测试和验证，也没有回滚计划。NTP 时间同步失败属于"慢性"故障，不会立即触发告警，而是在时间漂移积累到一定程度后才爆发。

次要原因是缺乏 NTP 同步状态的监控，如果有监控在 NTP 同步失败时立即告警，可以在几小时内发现并修复，而不是等到周一早高峰才被动发现。

预防措施

1. NTP 同步状态监控

在 Zabbix 中添加监控项，监控关键服务器（尤其是域控）的时间同步状态和时间偏差，超过 60 秒偏差时告警：

1
2

# Zabbix Agent 自定义 UserParameter
UserParameter=ntp.offset,w32tm /query /status | grep "Phase Offset" | awk '{print $3}'

2. 防火墙变更双人复核

所有防火墙策略变更必须经过运维负责人审核，变更后验证关键服务（DNS、NTP、AD认证）的可用性。

3. 保留 NTP 备用内网服务器

在内网部署一台 NTP 服务器作为备用，即使出口 NTP 不可达，内网机器也可以从内网 NTP 服务器同步时间。

总结

NTP 是 AD 域环境中"沉默的基础设施"，平时无人关注，一旦出问题却能引发连锁反应。这次事故让我们深刻认识到：越是基础的服务，越需要完善的监控。时钟同步听起来不重要，但在 Kerberos 的世界里，6 分钟的时差就能让整个认证体系瘫痪。

一次员工电脑批量蓝屏的排查实录

Tue, 20 May 2025 14:00:00 +0000

问题背景

某周二上午，IT 服务台在 2 小时内接到 18 个蓝屏相关工单，用户反映电脑突然蓝屏重启，屏幕显示蓝色错误界面后自动重启。部分用户反映重启后又蓝屏，进入死循环，需要 IT 上门处理。

分析工单发现，出现问题的机器主要集中在某一批次（戴尔 OptiPlex 7090），其他机型也有零星案例。所有出现问题的机器有一个共同点：昨天（周一）都收到了一个通过 SCCM（System Center Configuration Manager）推送的驱动更新包。

故障现象

多台机器出现不同的 BSOD 错误码：
- DRIVER_IRQL_NOT_LESS_OR_EQUAL
- SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
- PAGE_FAULT_IN_NONPAGED_AREA
部分机器重启后再次蓝屏，无法正常进入 Windows
出问题的机器集中在昨天收到驱动更新的设备
问题机器操作系统：Windows 10 22H2

排查过程

第一步：收集崩溃转储文件

蓝屏后，Windows 会生成内存转储文件（Minidump）。收集几台典型故障机的转储文件：

`1`	`路径：C:\Windows\Minidump\*.dmp`

使用 WinDbg（Windows 调试工具）分析：

1
2

# 在 WinDbg 中打开 dmp 文件后执行：
!analyze -v

对 3 台不同机器的 dmp 文件分析结果，都指向同一个模块：

`1`	`Probably caused by : e1d65x64.sys ( e1d65x64+XXXXX )`

e1d65x64.sys 是 Intel 网卡驱动（具体型号为 Intel Ethernet Connection I219-LM）。

第二步：确认驱动版本

在一台还能启动的问题机器上查看网卡驱动版本：

`1`	`设备管理器 → 网络适配器 → Intel(R) Ethernet Connection I219-LM → 属性 → 驱动程序`

显示：

驱动版本：12.19.2.45（更新后的版本）
驱动日期：2025-05-19（昨天）

在一台没有收到更新、运行正常的同款机器上查看：

驱动版本：12.18.9.23（旧版本）

第三步：查看 SCCM 更新推送记录

发现昨天推送了一个"Intel 网卡驱动更新包 v12.19.2.45"，部署范围为"所有工作站（Windows 10）"，推送时间为 18:00，因此很多员工是今天上班开机后才开始安装，安装完成重启后触发蓝屏。

受影响范围评估：

昨天收到该更新包的设备：约 240 台
已出现蓝屏的：18 台（均为戴尔 OptiPlex 7090，搭载 Intel I219-LM 网卡）
其他品牌机型：有同款网卡的也出现了少量案例

第四步：查阅驱动版本相关信息

查阅 Intel 官网和微软 WHQL 驱动数据库，以及该版本驱动的发布说明：

在 Intel 社区论坛找到了相关讨论，有其他用户反映 12.19.2.45 版本的驱动在 Windows 10 特定版本上存在兼容性问题，官方正在排查，建议暂时回滚到上一个稳定版本（12.18.9.23）。

第五步：制定处理方案

对于还能启动的问题机器：通过脚本回滚驱动。

对于无法启动的问题机器（重复蓝屏）：需要进入安全模式或 WinPE 回滚驱动。

解决方案

方案一：能正常启动的机器（远程或用户自行操作）

通过 PowerShell 批量回滚网卡驱动：

# 查看当前网卡驱动版本
Get-WmiObject Win32_PnPSignedDriver | Where-Object {$_.DeviceName -like "*Intel*Ethernet*"} | Select-Object DeviceName, DriverVersion, DriverDate

# 回滚驱动（设备管理器操作）
# 或通过命令行卸载当前版本并安装旧版本

手动操作步骤：

设备管理器 → 网络适配器 → Intel Ethernet Connection I219-LM
右键 → 属性 → 驱动程序 → 回退驱动程序
如果"回退驱动程序"按钮灰色不可用（没有备份），则使用旧版驱动安装包手动安装

准备了旧版驱动安装包（12.18.9.23），部署到 SCCM 软件分发，用户可以直接运行安装。

方案二：无法启动的机器（反复蓝屏）

方法一：进入安全模式

强制重启 3 次，Windows 自动进入"高级启动选项"
疑难解答 → 高级选项 → 启动设置 → 重新启动
进入安全模式后，设备管理器回滚网卡驱动，或直接卸载驱动（安全模式下无线网络功能不加载有问题的驱动）

方法二：WinPE 启动盘 对于安全模式也进不去的机器，使用 IT 部门预先制作的 WinPE 启动 U 盘：

1
2

# 在 WinPE 中挂载 Windows 系统分区后，删除问题驱动
dism /image:C:\ /remove-driver /driver:oem12.inf

其中 oem12.inf 对应 Intel 网卡驱动的 INF 文件编号（需在正常机器上预先确认）。

效果： 所有 18 台问题机器在当天下午 3 点前全部恢复正常。

立即在 SCCM 中暂停并撤回该驱动更新

对已推送但还未安装的机器，在 SCCM 中将该部署的状态设置为"不可用"，防止继续安装。

根因分析

根本原因是 SCCM 驱动更新推送前缺乏充分的测试验证，将一个存在兼容性 bug 的驱动版本（Intel 12.19.2.45）直接大批量推送到生产环境，导致大量安装了该驱动的设备出现蓝屏。

次要原因是推送范围过广，没有采用灰度（分阶段）部署策略，第一批应该只推送少量测试机器，验证稳定后再扩大范围。

预防措施

1. 驱动更新分阶段推送

在 SCCM 中创建测试集合（如 20 台代表性机器），先推送测试集合，观察 24-48 小时无问题后，再推送全量。

2. 推送时间选择

避免在下班后推送涉及重启的更新，否则出现问题无人第一时间响应。改为在周三/周四工作时间推送，方便快速响应。

3. 崩溃转储监控

接入 Microsoft Intune 或 SCCM 的设备健康报告，监控 BSOD 发生率。若在 24 小时内某款驱动关联的 BSOD 数量超过阈值，自动暂停相关更新并告警。

4. 维护一个"已验证驱动版本"白名单

对常用驱动（网卡、显卡、声卡等），维护一个经过验证的稳定版本列表，未经测试的新版本不进入大规模推送流程。

总结

批量蓝屏事件对 IT 运维团队来说是高压力事件，尤其是当用户的工作电脑无法正常使用时，会产生大量抱怨和催促。这次事件暴露了我们在软件/驱动更新管理上的薄弱环节。

最重要的教训： 生产环境的变更永远要"小步走"，灰度测试不是可选项，而是必选项。一个小时的测试，可能避免数百台机器同时出问题。

一次AD域控GPO策略推送失败导致终端安全基线不生效的排查实录

Tue, 10 Dec 2024 09:00:00 +0000

问题背景

周一早上九点，安全团队例行检查终端合规率时发现一个严重问题：上周五紧急发布的一条AD域控GPO策略——禁用USB大容量存储设备访问——在全公司约420台终端上竟然无一生效。这条策略是应审计要求必须在本周内落地的安全基线，安全团队已经在合规报告上标注了"已完成部署"，但实际情况却是任何员工插上U盘依然能正常读写。

问题的影响范围覆盖了总部办公区所有域内计算机，紧急程度很高——审计组周三要来复查，如果终端仍然不合规，整年度的ISO 27001认证可能受到影响。作为桌面运维负责人，我立刻被拉进应急排查群。

故障现象

终端侧表现

在多台终端上执行 gpresult /h gpreport.html 生成策略应用报告，发现：

该GPO在"已应用策略"列表中完全不出现——既不在计算机配置中，也不在用户配置中
在"被过滤的策略（未应用原因）“列表中也找不到该GPO的任何记录
gpupdate /force 执行后返回"策略已成功更新”，但再次查看报告，该策略依然不在

关键信息摘录：

C:\> gpupdate /force
正在更新策略...

计算机策略更新已完成。
用户策略更新已完成。

C:\> gpresult /v | findstr "USB"
（无任何输出）

域控侧表现

在GPMC（Group Policy Management Console）中检查：

该GPO 已链接到正确的OU（OU=总部办公终端,DC=corp,DC=local），链接状态为"已启用"
GPO的状态显示为**“已启用”**
安全筛选中仅包含 Authenticated Users，没有额外的WMI筛选器
但在"策略应用结果"模拟（Group Policy Results）中，针对任意一台该OU下的计算机模拟，该GPO均显示"未应用"

更关键的发现：在GPMC中查看该GPO的版本号，计算机配置版本号为 0，用户配置版本号也是 0——这意味着该GPO虽然被创建了，但其策略设置实际上从未被正确写入。

排查过程

排查从终端侧和域控侧同时展开，按照以下思路逐步推进：

第一层：确认GPO链接与作用域

首先确认GPO是否正确链接到目标OU，以及安全筛选是否合理。

打开GPMC，展开 corp.local → 总部办公终端 OU，确认该GPO确实在链接列表中，且链接顺序为第3位（在两条现有GPO之后），链接启用状态为"是"
检查安全筛选：仅包含 Authenticated Users，这是标准配置，没有问题
检查是否有WMI筛选器绑定——确认无WMI筛选器

这一步没有发现配置层面的明显错误，但注意到链接顺序在两条旧策略之后，需要进一步确认是否有策略冲突。

第二层：检查策略冲突与优先级

担心新GPO被更高优先级的策略覆盖：

排在前面两条GPO分别是"桌面基础配置"和"终端监控代理部署"，检查了它们的计算机配置策略设置，没有任何涉及USB存储设备访问控制的条目——不存在策略冲突
检查"阻止继承"（Block Inheritance）——该OU未启用阻止继承
检查"强制"（Enforced）——新GPO未标记为强制，但这不影响其正常应用，只是不保证优先级最高

策略冲突不是根因，继续深入。

第三层：发现GPO版本号异常——策略内容未写入

这是排查的关键转折点。在GPMC中右键该GPO选择"编辑"，打开Group Policy Editor：

计算机配置下 Administrative Templates → System → Removable Storage Access 中所有USB相关策略确实被设置为"已启用/已禁用"——策略设置内容在编辑器中是可见的
但回到GPMC主界面，该GPO的版本号显示为 0/0（计算机配置版本/用户配置版本），而不是预期的 1/1 或更高

正常情况下，一旦在GPO编辑器中修改了设置并保存，GPO的版本号应该自动递增。版本号为0意味着GPO的 GPT.INI 文件中的版本信息没有更新。

手动检查SYSVOL共享中的GPT.INI：

`1`	`\\corp.local\SYSVOL\corp.local\Policies\{GPO-GUID}\GPT.INI`

内容如下：

1
2

[General]
Version=0

而正常已应用的其他GPO的GPT.INI内容为：

1
2
3

[General]
Version=65537
DisplayName=桌面基础配置

关键发现：GPT.INI中Version=0，这意味着客户端在拉取GPO时会认为该策略没有任何变更，跳过应用。

第四层：排查GPT.INI版本号未更新的原因

GPO编辑器中修改了设置，为什么GPT.INI版本号仍然是0？可能的原因有：

GPO编辑过程中连接了不同的域控——如果编辑时连接的是DC01，而GPT.INI只更新在DC01的SYSVOL上，由于DFS复制延迟，DC02上的GPT.INI可能尚未同步
SYSVOL的DFS复制故障——导致DC01上的更新未能传播到其他DC

先检查域控拓扑：

C:\> repadmin /showrepl corp-dc01
... 最近入站复制: 成功

C:\> repadmin /showrepl corp-dc02
... 最近入站复制: DC01 → DC02, 成功, 时间 2026-06-20 14:32

AD复制看起来正常，但SYSVOL使用的是DFS复制（DFSR），与AD复制是独立的两套机制。检查DFS复制状态：

C:\> dfsradmin health new /rgname:"Domain System Volume" /rdname:"SYSVOL Share"
  Domain System Volume - SYSVOL Share
  复制组状态: 正常
  DC01: 运行中, 最后同步 2026-06-20 14:30
  DC02: 运行中, 最后同步 2026-06-19 23:15  ← 异常！

发现：DC02的SYSVOL DFSR最后一次同步时间是6月19日23:15，已经超过12小时未同步！

进一步检查DC02的DFSR事件日志：

事件ID: 5014
描述: DFS Replication服务已成功建立与DC01的连接

事件ID: 5008
描述: DFS Replication服务检测到与DC01的连接上出现错误
错误: 1722 (RPC服务器不可用)

第五层：确认DC02的DFSR服务状态

C:\> sc query dfsr
STATE: 4 RUNNING

C:\> netstat -an | findstr "135"
TCP 0.0.0.0:135 LISTENING

DFSR服务在运行，RPC端口也在监听。但回溯周五晚间的运维日志，发现周五20:00-22:00执行过DC02的补丁更新，期间服务器重启了一次。重启后DFSR服务虽然自动启动，但RPC连接建立存在延迟，且恰好周五晚间网络维护也关闭了部分防火墙端口，导致DC02与DC01之间的DFSR复制通道未能及时重建。

最终在DC02上手动触发DFS复制：

1
2
3

C:\> dfsrdiag pollad /member:corp-dc02
强制DFS Replication服务立即与AD进行同步...
操作成功完成。

复制完成后，DC02上的GPT.INI被正确同步：

1
2
3

[General]
Version=65537
DisplayName=禁用USB大容量存储设备访问

第六层：修复GPO版本号并验证

虽然DFS复制已恢复，但DC01上的GPT.INI版本号仍然是0——这说明问题不仅仅是复制延迟，原始DC01上的GPT.INI在GPO创建时就未被正确更新。

通过GPO编辑器对该GPO做一次微小的修改（添加一条注释级别的无影响设置），然后保存，触发版本号递增：

1
2

[General]
Version=196608

版本号从0变为196608（计算机配置版本2，用户配置版本1，编码为 Version = ComputerVersion * 65536 + UserVersion = 2*65536+1 = 131073… 实际Hex编码方式不同，但关键是Version不再是0）。

等待DFS复制将更新后的GPT.INI同步到DC02，然后在多台终端上执行：

C:\> gpupdate /force
正在更新策略...
计算机策略更新已完成。

C:\> gpresult /h report.html

打开报告，确认GPO"禁用USB大容量存储设备访问"出现在已应用的计算机策略列表中，且USB存储设备访问控制的具体设置条目全部生效。

在物理终端上测试：插入U盘，系统提示"访问被策略阻止"，无法读写——策略已正确生效。

解决方案

最终解决涉及两个层面的修复：

1. 修复SYSVOL DFS复制延迟

确保DC01与DC02之间的DFS复制正常运行：

# 在DC02上强制触发DFS复制同步
dfsrdiag pollad /member:corp-dc02

# 检查DFS复制健康状态
dfsradmin health new /rgname:"Domain System Volume" /rdname:"SYSVOL Share"

# 确认SYSVOL共享内容一致
# 比较两台DC上的GPT.INI版本号
dir \\corp-dc01\SYSVOL\corp.local\Policies\{GUID}\GPT.INI
dir \\corp-dc02\SYSVOL\corp.local\Policies\{GUID}\GPT.INI

2. 修复GPO版本号

对版本号为0的GPO做一次有效修改并保存，触发版本号自动递增：

通过GPMC编辑器打开该GPO
在计算机配置中任意添加一个无害设置（如设置一条已注释的策略），保存退出
GPT.INI中的Version字段自动更新为非0值
等待DFS复制同步到所有DC

3. 在所有终端上强制刷新策略

# 单台终端
gpupdate /force

# 批量刷新（通过PsExec或SCCM推送到所有OU下计算机）
psexec @computer_list.txt cmd /c "gpupdate /force"

根因分析

问题的根本原因是双重故障叠加：

GPO创建时版本号未正确写入（GPT.INI Version=0）：这是最核心的根因。当通过GPMC创建新GPO并编辑设置时，GPO的AD对象（在 CN=Policies,CN=System,DC=corp,DC=local 中）和SYSVOL文件（GPT.INI）应该同步更新版本号。但由于创建该GPO的管理员当时连接的GPMC优先选择了DC02作为编辑目标DC（GPMC会优先连接当前站点最近的DC），而DC02当时正在经历补丁更新后的重启过渡期，导致GPO的SYSVOL部分写入不完整——GPT.INI的Version字段未被更新为预期的初始值。
SYSVOL DFS复制延迟：DC02在补丁重启后DFSR复制通道重建延迟（约12小时），导致即使DC01上如果有正确的GPT.INI也无法及时同步到DC02。而实际情况是DC02本身就是策略编辑的目标DC，文件只存在于DC02的SYSVOL上且版本号错误，复制到DC01后DC01也获得了错误的Version=0。

客户端处理逻辑是：拉取GPO时检查GPT.INI中的Version号，如果Version与上次已应用的版本相同（或为0，等同于"无变更"），则跳过该GPO的应用。这就是所有420台终端均未生效的根本原因。

预防措施

1. GPO操作规范

编辑GPO前确认目标DC状态：在GPMC中通过"更改域控"明确指定一台健康的DC作为编辑目标，避免自动选择正在维护中的DC
创建GPO后立即验证版本号：在GPMC中检查新GPO的版本号是否为非0值，如果版本号异常应立即通过编辑器做一次修改触发版本递增
GPO修改完成后检查SYSVOL一致性：比较所有DC上该GPO的GPT.INI内容，确保版本号和策略内容一致

# 检查所有DC上GPO版本号一致性
$gpoGuid = "{GPO-GUID}"
$dcList = Get-ADDomainController -Filter * | Select-Object -ExpandProperty HostName
foreach ($dc in $dcList) {
    $gptIni = Get-Content "\\$dc\SYSVOL\corp.local\Policies\$gpoGuid\GPT.INI"
    Write-Host "$dc: Version = $($gptIni | Select-String 'Version=' | ForEach-Object { $_.Line.Split('=')[1] })"
}

2. DFS复制监控

建立DFS复制健康状态的定期监控，使用事件ID 5014（成功同步）和5008/5002（同步失败）作为告警指标
服务器补丁更新重启后，在运维流程中增加一步DFSR复制状态确认，确保SYSVOL复制恢复后再进行GPO操作
设置DFSR复制告警阈值：如果某台DC超过4小时未完成SYSVOL同步，自动触发告警通知运维团队

1
2
3

# 定期检查DFSR复制状态（可加入监控脚本）
$dfsrStatus = dfsradmin health new /rgname:"Domain System Volume" /rdname:"SYSVOL Share"
# 解析输出，判断各DC最后同步时间是否在阈值内

3. GPO部署验证流程

GPO发布后，在至少3台不同网段的终端上执行 gpresult /v 确认策略已生效
对安全基线类GPO，增加物理验证环节——实际测试策略约束效果（如插入U盘验证禁用效果）
在GPMC中使用"组策略结果"模拟功能，在策略发布后对目标OU中的样本计算机进行模拟，确认GPO出现在"已应用"列表

4. 补丁维护窗口规范

DC补丁更新应安排在业务低峰期，且一次只维护一台DC，确保至少一台DC的SYSVOL始终可用且同步正常
维护完成后必须验证DFSR复制恢复，并在运维检查清单中记录确认结果
如果DC需要长时间停机维护，应先在GPMC中将"域控操作主机"角色确认转移，避免GPO编辑指向不可用的DC

总结

这次排查给我最大的教训是：GPO的"已创建+已链接"≠“已生效”。在GPMC中看到一个GPO链接到了目标OU并且状态为启用，只是第一步，真正的生效依赖于三个条件同时满足：

GPO的策略内容被正确写入SYSVOL（GPT.INI版本号≠0）
SYSVOL内容在所有DC间通过DFS复制保持一致
客户端能够成功拉取并应用GPO内容

排查时我最初只关注了GPMC界面上的链接和筛选配置，浪费了近一个小时在策略冲突和优先级方向上。直到检查版本号才发现真正的入口。这也提醒我，排查AD域控相关问题时，一定要从底层文件（GPT.INI、SYSVOL共享）和复制机制入手，不要只依赖GPMC的图形界面——界面显示的是AD对象的元数据，而客户端实际读取的是SYSVOL文件，两者之间可能因复制延迟而不同步。

另外一个实操经验：DC补丁维护后必须确认DFSR复制恢复。DFS复制不像AD复制那样有显式的复制失败告警，DFSR可能"静默失效"——服务在运行、端口在监听，但实际复制通道没有重建成功。只有通过 dfsradmin health 或事件日志才能发现问题。以后每次DC维护重启，运维检查清单上必须加上DFSR复制状态确认这一步。

一次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，都需要主动配置和验证，不能假设"默认会管好日志"。

一次办公区无线网络间歇性断连的排查实录

Tue, 07 Nov 2023 11:00:00 +0000

问题背景

近期（大约持续了两周）公司办公区的员工陆续通过工单反馈，说 WiFi 连接很不稳定，主要表现是：

视频会议（腾讯会议、Teams）经常卡顿、掉线
手机和笔记本有时会突然断开 WiFi，重连后几分钟又断
部分区域信号格数显示满格，但实际网速极慢

受影响的主要是 3 楼办公区（约 80 名员工），4 楼相对较少。公司无线网络使用 Aruba 无线控制器（AC）统一管理约 30 台 AP，全部部署在室内天花板。

故障现象

3 楼员工 WiFi 连接不稳定，视频会议频繁卡顿
Windows 任务栏 WiFi 图标有时显示感叹号（受限连接）
手机 WiFi 速度测试：下载约 1-3 Mbps（预期应有 50+ Mbps）
但有线接入的员工完全不受影响，排除上联网络问题

排查过程

第一步：确认问题范围

先用有线和无线各自进行网速测试，有线稳定在 100Mbps 左右，无线只有 2-5Mbps，明确是无线侧的问题。

再确认问题时间规律：工单记录显示，问题主要出现在 9:30-11:30 和 14:00-16:00，正好是员工视频会议的密集时段，早晚时段没有明显问题。

第二步：通过 Aruba AC 查看无线环境

发现 1：AP 3F-01 和 AP 3F-02 关联的设备数量异常多

正常每台 AP 关联设备 20-30 个，而 3F-01 和 3F-02 分别关联了 65 和 58 个设备，远超设计容量。

发现 2：2.4GHz 频段使用率极高

进入 RF（无线射频）监控页面，查看频谱使用情况：

2.4GHz 频段：信道 6 的利用率达到 87%
5GHz 频段：各信道利用率均在 30% 以下

大量设备（尤其是老旧手机和打印机）扎堆连接 2.4GHz，而 5GHz 频段相对空闲。

第三步：扫描无线环境，寻找干扰源

在 Aruba AC 上启用 AM（Air Monitor）模式，对 3 楼进行无线环境扫描，查看附近 AP 的信道分布情况：

扫描结果发现，在信道 6 上，除了我们自己部署的 AP 外，还检测到了 4 个非授权的 SSID：

SSID: TP-LINK_XXXX   信道: 6   RSSI: -65dBm   厂商: TP-Link
SSID: TP-LINK_YYYY   信道: 6   RSSI: -72dBm   厂商: TP-Link
SSID: ChinaNet-ZZZZ  信道: 6   RSSI: -68dBm   厂商: Huawei
SSID: Mi_AABB        信道: 1   RSSI: -71dBm   厂商: Xiaomi

同一频段上存在多个非授权 AP（来自员工自带的路由器或隔壁邻居的家用 WiFi），与我们的 AP 形成同频干扰。

第四步：现场定位非法 AP

通过 Aruba 的 RSSI 强度信息和楼层平面图，大致定位了信号强度最强的两台非授权 AP 来源：

TP-LINK_XXXX（RSSI -65dBm）：信号来自 3 楼东侧某个角落
ChinaNet-ZZZZ（RSSI -68dBm）：信号来自楼下或相邻建筑

到 3 楼东侧排查，在一个储物间里发现了一台员工私自安装的 TP-Link 路由器，他是因为自己工位信号不好，就从家里带了一个路由器来增强信号，接在了墙上的网络接口上，结果反而加剧了干扰。

第五步：分析同频干扰原理

2.4GHz 频段总带宽有限，常用的不重叠信道只有 3 个：1、6、11。当多个 AP 同时使用信道 6 时，它们的信号会相互干扰，设备需要等待信道空闲才能发送数据（CSMA/CA 机制），信道越拥挤，等待时间越长，表现为网速慢、延迟高。

我们的 3F-01、3F-02 都在信道 6，加上 4 个外部 AP 也在信道 6，7 个发射源共享一个 20MHz 宽的信道，效率极低。

解决方案

第一步：移除非法 AP

拔除储物间里员工私装的 TP-Link 路由器，并通知该员工不得私自接入未授权网络设备。告知全体员工相关规定。

第二步：重新规划 2.4GHz 信道分配

重新梳理 3 楼所有 AP 的信道规划：

将同一楼层相邻 AP 分配到不同的不重叠信道（1、6、11 错开分配）
减少信道 6 上的 AP 数量

AP 3F-01  →  信道 1
AP 3F-02  →  信道 11
AP 3F-03  →  信道 6
AP 3F-04  →  信道 1
...（相邻不同信道，避免重叠）

第三步：开启频段引导（Band Steering）

在 Aruba AC 上启用 Band Steering 功能，将支持 5GHz 的设备自动引导到 5GHz 频段：

在 Aruba 管理界面：Configuration → SSID → Advanced → Band Steering → Enable

Band Steering 工作原理：对于同时支持 2.4GHz 和 5GHz 的设备，AP 在 2.4GHz 上延迟响应 Probe Request，促使设备转向 5GHz 关联。

第四步：调整 AP 发射功率

部分 AP 发射功率设置过高，导致信号覆盖区域重叠，加剧同频干扰。将相邻 AP 的发射功率适当降低：

在 Aruba RF Plan 中，将 3 楼各 AP 的 2.4GHz 最大发射功率从 23dBm 调整至 17dBm，覆盖半径缩小，减少同频重叠区域。

第五步：效果验证

调整完成后，次日早上进行测试：

3 楼 AP 2.4GHz 信道 6 利用率从 87% 下降到 41%
各 AP 关联设备数量均匀分布，3F-01 从 65 台降至 28 台
无线下载速度测试：从 2-5Mbps 提升至 45-80Mbps
视频会议测试：连续 1 小时无断线，质量正常

根因分析

根本原因有两个：

同频干扰：3 楼 2.4GHz 频段信道 6 上存在大量 AP（包括外部非授权 AP），信道竞争激烈，设备需长时间等待信道空闲，导致网速下降。
负载不均衡：2.4GHz 频段承载了过多设备，而 5GHz 相对空闲，缺少频段引导机制将设备均衡分流。

预防措施

1. 定期无线环境扫描

每月通过 Aruba AM 或 Wi-Fi Analyzer 扫描一次，及时发现新增的非法 AP 和信道干扰。

2. 非法 AP 检测与告警

开启 Aruba Wireless Intrusion Protection（WIP）功能，自动检测并告警非授权设备接入。

3. 员工教育

通过邮件或公告明确：不得在公司网络上自行接入个人路由器、交换机等设备，违者按公司 IT 使用规范处理。

4. 定期审查 AP 规划

公司扩建或改建后，应重新审查 AP 布点和信道规划，不能使用初始规划一成不变。

总结

无线网络故障相比有线往往更难直接定位，因为很多干扰因素"看不见摸不着"。这次故障的关键排查步骤是借助无线控制器的 RF 监控和频谱扫描功能，量化了信道利用率，并找到了隐藏的非法 AP 干扰源。

经验总结： 对于无线网络性能问题，要重点检查信道规划是否合理、是否存在同频干扰、5GHz 是否被充分利用。同时，员工私接设备的问题在企业网络中极为普遍，需要从技术手段（WIDS）和管理手段双管齐下。

微软输入法快速输入时间

Sat, 26 Aug 2023 22:32:20 +0000

打开用户定义的短语

添加或编辑自定义短语

// 2021-03-05 18:10:03
%yyyy%-%MM%-%dd% %HH%:%mm%:%ss%
// 2021年03月05日 18:09:59
%yyyy%年%MM%月%dd%日 %HH%:%mm%:%ss%

CloudFlare Workers 部署 VLESS 节点

Mon, 14 Aug 2023 16:52:51 +0000

前言

CloudFlare Workers 部署 VLESS 节点

项目地址

zizifn/edgetunnel

Running V2ray inside edge/serverless runtime

Workers代码

// <!--GAMFC-->version base on commit 43fad05dcdae3b723c53c226f8181fc5bd47223e, time is 2023-06-22 15:20:02 UTC<!--GAMFC-END-->.
// @ts-ignore
import { connect } from 'cloudflare:sockets';

// How to generate your own UUID:
// [Windows] Press "Win + R", input cmd and run:  Powershell -NoExit -Command "[guid]::NewGuid()"
let userID = 'd342d11e-d424-4583-b36e-524ab1f0afa4';

let proxyIP = '';


if (!isValidUUID(userID)) {
	throw new Error('uuid is not valid');
}

export default {
	/**
	 * @param {import("@cloudflare/workers-types").Request} request
	 * @param {{UUID: string, PROXYIP: string}} env
	 * @param {import("@cloudflare/workers-types").ExecutionContext} ctx
	 * @returns {Promise<Response>}
	 */
	async fetch(request, env, ctx) {
		try {
			userID = env.UUID || userID;
			proxyIP = env.PROXYIP || proxyIP;
			const upgradeHeader = request.headers.get('Upgrade');
			if (!upgradeHeader || upgradeHeader !== 'websocket') {
				const url = new URL(request.url);
				switch (url.pathname) {
					case '/':
						return new Response(JSON.stringify(request.cf), { status: 200 });
					case `/${userID}`: {
						const vlessConfig = getVLESSConfig(userID, request.headers.get('Host'));
						return new Response(`${vlessConfig}`, {
							status: 200,
							headers: {
								"Content-Type": "text/plain;charset=utf-8",
							}
						});
					}
					default:
						return new Response('Not found', { status: 404 });
				}
			} else {
				return await vlessOverWSHandler(request);
			}
		} catch (err) {
			/** @type {Error} */ let e = err;
			return new Response(e.toString());
		}
	},
};




/**
 * 
 * @param {import("@cloudflare/workers-types").Request} request
 */
async function vlessOverWSHandler(request) {

	/** @type {import("@cloudflare/workers-types").WebSocket[]} */
	// @ts-ignore
	const webSocketPair = new WebSocketPair();
	const [client, webSocket] = Object.values(webSocketPair);

	webSocket.accept();

	let address = '';
	let portWithRandomLog = '';
	const log = (/** @type {string} */ info, /** @type {string | undefined} */ event) => {
		console.log(`[${address}:${portWithRandomLog}] ${info}`, event || '');
	};
	const earlyDataHeader = request.headers.get('sec-websocket-protocol') || '';

	const readableWebSocketStream = makeReadableWebSocketStream(webSocket, earlyDataHeader, log);

	/** @type {{ value: import("@cloudflare/workers-types").Socket | null}}*/
	let remoteSocketWapper = {
		value: null,
	};
	let udpStreamWrite = null;
	let isDns = false;

	// ws --> remote
	readableWebSocketStream.pipeTo(new WritableStream({
		async write(chunk, controller) {
			if (isDns && udpStreamWrite) {
				return udpStreamWrite(chunk);
			}
			if (remoteSocketWapper.value) {
				const writer = remoteSocketWapper.value.writable.getWriter()
				await writer.write(chunk);
				writer.releaseLock();
				return;
			}

			const {
				hasError,
				message,
				portRemote = 443,
				addressRemote = '',
				rawDataIndex,
				vlessVersion = new Uint8Array([0, 0]),
				isUDP,
			} = processVlessHeader(chunk, userID);
			address = addressRemote;
			portWithRandomLog = `${portRemote}--${Math.random()} ${isUDP ? 'udp ' : 'tcp '
				} `;
			if (hasError) {
				// controller.error(message);
				throw new Error(message); // cf seems has bug, controller.error will not end stream
				// webSocket.close(1000, message);
				return;
			}
			// if UDP but port not DNS port, close it
			if (isUDP) {
				if (portRemote === 53) {
					isDns = true;
				} else {
					// controller.error('UDP proxy only enable for DNS which is port 53');
					throw new Error('UDP proxy only enable for DNS which is port 53'); // cf seems has bug, controller.error will not end stream
					return;
				}
			}
			// ["version", "附加信息长度 N"]
			const vlessResponseHeader = new Uint8Array([vlessVersion[0], 0]);
			const rawClientData = chunk.slice(rawDataIndex);

			// TODO: support udp here when cf runtime has udp support
			if (isDns) {
				const { write } = await handleUDPOutBound(webSocket, vlessResponseHeader, log);
				udpStreamWrite = write;
				udpStreamWrite(rawClientData);
				return;
			}
			handleTCPOutBound(remoteSocketWapper, addressRemote, portRemote, rawClientData, webSocket, vlessResponseHeader, log);
		},
		close() {
			log(`readableWebSocketStream is close`);
		},
		abort(reason) {
			log(`readableWebSocketStream is abort`, JSON.stringify(reason));
		},
	})).catch((err) => {
		log('readableWebSocketStream pipeTo error', err);
	});

	return new Response(null, {
		status: 101,
		// @ts-ignore
		webSocket: client,
	});
}

/**
 * Handles outbound TCP connections.
 *
 * @param {any} remoteSocket 
 * @param {string} addressRemote The remote address to connect to.
 * @param {number} portRemote The remote port to connect to.
 * @param {Uint8Array} rawClientData The raw client data to write.
 * @param {import("@cloudflare/workers-types").WebSocket} webSocket The WebSocket to pass the remote socket to.
 * @param {Uint8Array} vlessResponseHeader The VLESS response header.
 * @param {function} log The logging function.
 * @returns {Promise<void>} The remote socket.
 */
async function handleTCPOutBound(remoteSocket, addressRemote, portRemote, rawClientData, webSocket, vlessResponseHeader, log,) {
	async function connectAndWrite(address, port) {
		/** @type {import("@cloudflare/workers-types").Socket} */
		const tcpSocket = connect({
			hostname: address,
			port: port,
		});
		remoteSocket.value = tcpSocket;
		log(`connected to ${address}:${port}`);
		const writer = tcpSocket.writable.getWriter();
		await writer.write(rawClientData); // first write, nomal is tls client hello
		writer.releaseLock();
		return tcpSocket;
	}

	// if the cf connect tcp socket have no incoming data, we retry to redirect ip
	async function retry() {
		const tcpSocket = await connectAndWrite(proxyIP || addressRemote, portRemote)
		// no matter retry success or not, close websocket
		tcpSocket.closed.catch(error => {
			console.log('retry tcpSocket closed error', error);
		}).finally(() => {
			safeCloseWebSocket(webSocket);
		})
		remoteSocketToWS(tcpSocket, webSocket, vlessResponseHeader, null, log);
	}

	const tcpSocket = await connectAndWrite(addressRemote, portRemote);

	// when remoteSocket is ready, pass to websocket
	// remote--> ws
	remoteSocketToWS(tcpSocket, webSocket, vlessResponseHeader, retry, log);
}

/**
 * 
 * @param {import("@cloudflare/workers-types").WebSocket} webSocketServer
 * @param {string} earlyDataHeader for ws 0rtt
 * @param {(info: string)=> void} log for ws 0rtt
 */
function makeReadableWebSocketStream(webSocketServer, earlyDataHeader, log) {
	let readableStreamCancel = false;
	const stream = new ReadableStream({
		start(controller) {
			webSocketServer.addEventListener('message', (event) => {
				if (readableStreamCancel) {
					return;
				}
				const message = event.data;
				controller.enqueue(message);
			});

			// The event means that the client closed the client -> server stream.
			// However, the server -> client stream is still open until you call close() on the server side.
			// The WebSocket protocol says that a separate close message must be sent in each direction to fully close the socket.
			webSocketServer.addEventListener('close', () => {
				// client send close, need close server
				// if stream is cancel, skip controller.close
				safeCloseWebSocket(webSocketServer);
				if (readableStreamCancel) {
					return;
				}
				controller.close();
			}
			);
			webSocketServer.addEventListener('error', (err) => {
				log('webSocketServer has error');
				controller.error(err);
			}
			);
			// for ws 0rtt
			const { earlyData, error } = base64ToArrayBuffer(earlyDataHeader);
			if (error) {
				controller.error(error);
			} else if (earlyData) {
				controller.enqueue(earlyData);
			}
		},

		pull(controller) {
			// if ws can stop read if stream is full, we can implement backpressure
			// https://streams.spec.whatwg.org/#example-rs-push-backpressure
		},
		cancel(reason) {
			// 1. pipe WritableStream has error, this cancel will called, so ws handle server close into here
			// 2. if readableStream is cancel, all controller.close/enqueue need skip,
			// 3. but from testing controller.error still work even if readableStream is cancel
			if (readableStreamCancel) {
				return;
			}
			log(`ReadableStream was canceled, due to ${reason}`)
			readableStreamCancel = true;
			safeCloseWebSocket(webSocketServer);
		}
	});

	return stream;

}

// https://xtls.github.io/development/protocols/vless.html
// https://github.com/zizifn/excalidraw-backup/blob/main/v2ray-protocol.excalidraw

/**
 * 
 * @param { ArrayBuffer} vlessBuffer 
 * @param {string} userID 
 * @returns 
 */
function processVlessHeader(
	vlessBuffer,
	userID
) {
	if (vlessBuffer.byteLength < 24) {
		return {
			hasError: true,
			message: 'invalid data',
		};
	}
	const version = new Uint8Array(vlessBuffer.slice(0, 1));
	let isValidUser = false;
	let isUDP = false;
	if (stringify(new Uint8Array(vlessBuffer.slice(1, 17))) === userID) {
		isValidUser = true;
	}
	if (!isValidUser) {
		return {
			hasError: true,
			message: 'invalid user',
		};
	}

	const optLength = new Uint8Array(vlessBuffer.slice(17, 18))[0];
	//skip opt for now

	const command = new Uint8Array(
		vlessBuffer.slice(18 + optLength, 18 + optLength + 1)
	)[0];

	// 0x01 TCP
	// 0x02 UDP
	// 0x03 MUX
	if (command === 1) {
	} else if (command === 2) {
		isUDP = true;
	} else {
		return {
			hasError: true,
			message: `command ${command} is not support, command 01-tcp,02-udp,03-mux`,
		};
	}
	const portIndex = 18 + optLength + 1;
	const portBuffer = vlessBuffer.slice(portIndex, portIndex + 2);
	// port is big-Endian in raw data etc 80 == 0x005d
	const portRemote = new DataView(portBuffer).getUint16(0);

	let addressIndex = portIndex + 2;
	const addressBuffer = new Uint8Array(
		vlessBuffer.slice(addressIndex, addressIndex + 1)
	);

	// 1--> ipv4  addressLength =4
	// 2--> domain name addressLength=addressBuffer[1]
	// 3--> ipv6  addressLength =16
	const addressType = addressBuffer[0];
	let addressLength = 0;
	let addressValueIndex = addressIndex + 1;
	let addressValue = '';
	switch (addressType) {
		case 1:
			addressLength = 4;
			addressValue = new Uint8Array(
				vlessBuffer.slice(addressValueIndex, addressValueIndex + addressLength)
			).join('.');
			break;
		case 2:
			addressLength = new Uint8Array(
				vlessBuffer.slice(addressValueIndex, addressValueIndex + 1)
			)[0];
			addressValueIndex += 1;
			addressValue = new TextDecoder().decode(
				vlessBuffer.slice(addressValueIndex, addressValueIndex + addressLength)
			);
			break;
		case 3:
			addressLength = 16;
			const dataView = new DataView(
				vlessBuffer.slice(addressValueIndex, addressValueIndex + addressLength)
			);
			// 2001:0db8:85a3:0000:0000:8a2e:0370:7334
			const ipv6 = [];
			for (let i = 0; i < 8; i++) {
				ipv6.push(dataView.getUint16(i * 2).toString(16));
			}
			addressValue = ipv6.join(':');
			// seems no need add [] for ipv6
			break;
		default:
			return {
				hasError: true,
				message: `invild  addressType is ${addressType}`,
			};
	}
	if (!addressValue) {
		return {
			hasError: true,
			message: `addressValue is empty, addressType is ${addressType}`,
		};
	}

	return {
		hasError: false,
		addressRemote: addressValue,
		addressType,
		portRemote,
		rawDataIndex: addressValueIndex + addressLength,
		vlessVersion: version,
		isUDP,
	};
}


/**
 * 
 * @param {import("@cloudflare/workers-types").Socket} remoteSocket 
 * @param {import("@cloudflare/workers-types").WebSocket} webSocket 
 * @param {ArrayBuffer} vlessResponseHeader 
 * @param {(() => Promise<void>) | null} retry
 * @param {*} log 
 */
async function remoteSocketToWS(remoteSocket, webSocket, vlessResponseHeader, retry, log) {
	// remote--> ws
	let remoteChunkCount = 0;
	let chunks = [];
	/** @type {ArrayBuffer | null} */
	let vlessHeader = vlessResponseHeader;
	let hasIncomingData = false; // check if remoteSocket has incoming data
	await remoteSocket.readable
		.pipeTo(
			new WritableStream({
				start() {
				},
				/**
				 * 
				 * @param {Uint8Array} chunk 
				 * @param {*} controller 
				 */
				async write(chunk, controller) {
					hasIncomingData = true;
					// remoteChunkCount++;
					if (webSocket.readyState !== WS_READY_STATE_OPEN) {
						controller.error(
							'webSocket.readyState is not open, maybe close'
						);
					}
					if (vlessHeader) {
						webSocket.send(await new Blob([vlessHeader, chunk]).arrayBuffer());
						vlessHeader = null;
					} else {
						// seems no need rate limit this, CF seems fix this??..
						// if (remoteChunkCount > 20000) {
						// 	// cf one package is 4096 byte(4kb),  4096 * 20000 = 80M
						// 	await delay(1);
						// }
						webSocket.send(chunk);
					}
				},
				close() {
					log(`remoteConnection!.readable is close with hasIncomingData is ${hasIncomingData}`);
					// safeCloseWebSocket(webSocket); // no need server close websocket frist for some case will casue HTTP ERR_CONTENT_LENGTH_MISMATCH issue, client will send close event anyway.
				},
				abort(reason) {
					console.error(`remoteConnection!.readable abort`, reason);
				},
			})
		)
		.catch((error) => {
			console.error(
				`remoteSocketToWS has exception `,
				error.stack || error
			);
			safeCloseWebSocket(webSocket);
		});

	// seems is cf connect socket have error,
	// 1. Socket.closed will have error
	// 2. Socket.readable will be close without any data coming
	if (hasIncomingData === false && retry) {
		log(`retry`)
		retry();
	}
}

/**
 * 
 * @param {string} base64Str 
 * @returns 
 */
function base64ToArrayBuffer(base64Str) {
	if (!base64Str) {
		return { error: null };
	}
	try {
		// go use modified Base64 for URL rfc4648 which js atob not support
		base64Str = base64Str.replace(/-/g, '+').replace(/_/g, '/');
		const decode = atob(base64Str);
		const arryBuffer = Uint8Array.from(decode, (c) => c.charCodeAt(0));
		return { earlyData: arryBuffer.buffer, error: null };
	} catch (error) {
		return { error };
	}
}

/**
 * This is not real UUID validation
 * @param {string} uuid 
 */
function isValidUUID(uuid) {
	const uuidRegex = /^[0-9a-f]{8}-[0-9a-f]{4}-[4][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i;
	return uuidRegex.test(uuid);
}

const WS_READY_STATE_OPEN = 1;
const WS_READY_STATE_CLOSING = 2;
/**
 * Normally, WebSocket will not has exceptions when close.
 * @param {import("@cloudflare/workers-types").WebSocket} socket
 */
function safeCloseWebSocket(socket) {
	try {
		if (socket.readyState === WS_READY_STATE_OPEN || socket.readyState === WS_READY_STATE_CLOSING) {
			socket.close();
		}
	} catch (error) {
		console.error('safeCloseWebSocket error', error);
	}
}

const byteToHex = [];
for (let i = 0; i < 256; ++i) {
	byteToHex.push((i + 256).toString(16).slice(1));
}
function unsafeStringify(arr, offset = 0) {
	return (byteToHex[arr[offset + 0]] + byteToHex[arr[offset + 1]] + byteToHex[arr[offset + 2]] + byteToHex[arr[offset + 3]] + "-" + byteToHex[arr[offset + 4]] + byteToHex[arr[offset + 5]] + "-" + byteToHex[arr[offset + 6]] + byteToHex[arr[offset + 7]] + "-" + byteToHex[arr[offset + 8]] + byteToHex[arr[offset + 9]] + "-" + byteToHex[arr[offset + 10]] + byteToHex[arr[offset + 11]] + byteToHex[arr[offset + 12]] + byteToHex[arr[offset + 13]] + byteToHex[arr[offset + 14]] + byteToHex[arr[offset + 15]]).toLowerCase();
}
function stringify(arr, offset = 0) {
	const uuid = unsafeStringify(arr, offset);
	if (!isValidUUID(uuid)) {
		throw TypeError("Stringified UUID is invalid");
	}
	return uuid;
}


/**
 * 
 * @param {import("@cloudflare/workers-types").WebSocket} webSocket 
 * @param {ArrayBuffer} vlessResponseHeader 
 * @param {(string)=> void} log 
 */
async function handleUDPOutBound(webSocket, vlessResponseHeader, log) {

	let isVlessHeaderSent = false;
	const transformStream = new TransformStream({
		start(controller) {

		},
		transform(chunk, controller) {
			// udp message 2 byte is the the length of udp data
			// TODO: this should have bug, beacsue maybe udp chunk can be in two websocket message
			for (let index = 0; index < chunk.byteLength;) {
				const lengthBuffer = chunk.slice(index, index + 2);
				const udpPakcetLength = new DataView(lengthBuffer).getUint16(0);
				const udpData = new Uint8Array(
					chunk.slice(index + 2, index + 2 + udpPakcetLength)
				);
				index = index + 2 + udpPakcetLength;
				controller.enqueue(udpData);
			}
		},
		flush(controller) {
		}
	});

	// only handle dns udp for now
	transformStream.readable.pipeTo(new WritableStream({
		async write(chunk) {
			const resp = await fetch('https://1.1.1.1/dns-query',
				{
					method: 'POST',
					headers: {
						'content-type': 'application/dns-message',
					},
					body: chunk,
				})
			const dnsQueryResult = await resp.arrayBuffer();
			const udpSize = dnsQueryResult.byteLength;
			// console.log([...new Uint8Array(dnsQueryResult)].map((x) => x.toString(16)));
			const udpSizeBuffer = new Uint8Array([(udpSize >> 8) & 0xff, udpSize & 0xff]);
			if (webSocket.readyState === WS_READY_STATE_OPEN) {
				log(`doh success and dns message length is ${udpSize}`);
				if (isVlessHeaderSent) {
					webSocket.send(await new Blob([udpSizeBuffer, dnsQueryResult]).arrayBuffer());
				} else {
					webSocket.send(await new Blob([vlessResponseHeader, udpSizeBuffer, dnsQueryResult]).arrayBuffer());
					isVlessHeaderSent = true;
				}
			}
		}
	})).catch((error) => {
		log('dns udp has error' + error)
	});

	const writer = transformStream.writable.getWriter();

	return {
		/**
		 * 
		 * @param {Uint8Array} chunk 
		 */
		write(chunk) {
			writer.write(chunk);
		}
	};
}

/**
 * 
 * @param {string} userID 
 * @param {string | null} hostName
 * @returns {string}
 */
function getVLESSConfig(userID, hostName) {
	const vlessMain = `vless://${userID}@${hostName}:443?encryption=none&security=tls&sni=${hostName}&fp=randomized&type=ws&host=${hostName}&path=%2F%3Fed%3D2048#${hostName}`
	return `
################################################################
v2ray
---------------------------------------------------------------
${vlessMain}
---------------------------------------------------------------
################################################################
clash-meta
---------------------------------------------------------------
- type: vless
  name: ${hostName}
  server: ${hostName}
  port: 443
  uuid: ${userID}
  network: ws
  tls: true
  udp: false
  sni: ${hostName}
  client-fingerprint: chrome
  ws-opts:
    path: "/?ed=2048"
    headers:
      host: ${hostName}
---------------------------------------------------------------
################################################################
`;
}

配置

从 https://www.uuidgenerator.net/ 生成一个新的 UUID，然后替换第7行默认的 UUID，然后点击“Save and deploy”按钮，保存代码。

在访问的域名后面加上 /UUID 就可以得到关于 workers 节点的分享链接信息

优选 CloudFlare IP

使用https://github.com/XIU2/CloudflareSpeedTest项目

微软Bing站长使用Python自动提交URL

Thu, 10 Aug 2023 10:07:45 +0000

功能描述

利用crontab定时执行py文件自动提交文章URL给微软bing

配置

新建一个urldelay.py文件

文件内容

import requests
import json
import xml.etree.ElementTree as ET

# 发送HTTP请求获取站点地图内容
sitemap_url = 'https://blog.5772447.xyz/sitemap.xml'
response = requests.get(sitemap_url)

if response.status_code == 200:
    # 解析XML内容
    root = ET.fromstring(response.content)

    url_list = []

    for url_element in root.findall('.//{http://www.sitemaps.org/schemas/sitemap/0.9}url'):
        if len(url_list) >= 10:
            break
        url = url_element.findtext('{http://www.sitemaps.org/schemas/sitemap/0.9}loc')
        if url:
            url_list.append(url)

    # 打印获取到的URL列表
    print(url_list)

    # 构造POST请求的数据
    data = {
        "siteUrl": "https://blog.5772447.xyz",
        "urlList": url_list
    }

    api_key = "自己的微软站长推送api"
    headers = {
        "Content-Type": "application/json; charset=utf-8"
    }

    # 发送POST请求
    submit_url = f"https://ssl.bing.com/webmaster/api.svc/json/SubmitUrlbatch?apikey={api_key}"
    response = requests.post(submit_url, json=data, headers=headers)

    if response.status_code == 200:
        print("URLs提交成功！")
    else:
        print("URLs提交失败。状态码:", response.status_code)
else:
    print('Failed to retrieve sitemap. Status code:', response.status_code)

自行配置代码中的 sitemap_url = ‘https://blog.5772447.xyz/sitemap.xml'

“siteUrl”: “https://blog.5772447.xyz”,

api_key = “自己的微软站长推送api”

PS：自行安装 requests 库，可以使用以下命令：

`1`	`pip install requests`

如果Python环境是通过apt进行管理，的可以使用以下命令：

1
2

apt update
apt install python3-requests

crontab使用配置

将上述文件存于文件夹/home/script，具体地址可以自定义

使用命令

`1`	`crontab -e`

然后在最下面填写

`1`	`0 9 * * * python3 /home/script/urldelay.py >> /home/script/urldelay.log 2>&1`

最后ctrl+X 按y 回车保存

具体执行情况

可以在/home/script/urldelay.log文件中查看

1
2

['https://blog.5772447.xyz/tags/index.html', 'https://blog.5772447.xyz/categories/index.html', 'https://blog.5772447.xyz/posts/973246e2/', 'https://blog.5772447.xyz/posts/29dc6fe8/', 'https://blog.5772447.xyz/posts/29dc6fe9/', 'https://blog.5772447.xyz/posts/c817a32b/', 'https://blog.5772447.xyz/posts/7c4a1a51/', 'https://blog.5772447.xyz/posts/8373160e/', 'https://blog.5772447.xyz/posts/500de237/', 'https://blog.5772447.xyz/posts/c817a34b/']
URLs提交成功！

沛喆PZ-L8路由器刷机教程

Thu, 03 Aug 2023 19:58:25 +0000

前言

沛喆PZ-L8路由器刷机教程

接TTL

插好TTL,路由器主板上有标注引脚,VCC请不要接！！！

上电进u-boot

打开终端软件，配置：115200,8,无,1,无

路由器上电后快速按esc，中断uboot启动

输入smeminfo查看初始分区

IPQ5018# smeminfo
ubi0: attaching mtd1
ubi0: scanning is finished
ubi0: attached mtd1 (name "mtd=0", size 58 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi0: good PEBs: 464, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 5, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 25/11, WL threshold: 4096, image sequence number: 1838781505
ubi0: available PEBs: 0, total reserved PEBs: 464, PEBs reserved for bad PEB handling: 20
flash_type:             0xb
flash_index:            0x0
flash_chip_select:      0x0
flash_block_size:       0x20000
flash_density:          0x80000
partition table offset  0x0
No.: Name             Attributes            Start             Size
  0: 0:SBL1           0x0000ffff              0x0          0x80000
  1: 0:MIBIB          0x0000ffff          0x80000          0x80000
  2: 0:BOOTCONFIG     0x0000ffff         0x100000          0x40000
  3: 0:BOOTCONFIG1    0x0000ffff         0x140000          0x40000
  4: 0:QSEE           0x0000ffff         0x180000         0x100000
  5: 0:QSEE_1         0x0000ffff         0x280000         0x100000
  6: 0:DEVCFG         0x0000ffff         0x380000          0x40000
  7: 0:DEVCFG_1       0x0000ffff         0x3c0000          0x40000
  8: 0:CDT            0x0000ffff         0x400000          0x40000
  9: 0:CDT_1          0x0000ffff         0x440000          0x40000
 10: 0:APPSBLENV      0x0000ffff         0x480000          0x80000
 11: 0:APPSBL         0x0000ffff         0x500000         0x140000
 12: 0:APPSBL_1       0x0000ffff         0x640000         0x140000
 13: 0:ART            0x0000ffff         0x780000         0x100000
 14: 0:TRAINING       0x0000ffff         0x880000          0x80000
 15: rootfs           0x0000ffff        0x4300000        0x3a00000
        ubi vol 0 kernel
        ubi vol 1 wifi_fw
        ubi vol 2 bt_fw
        ubi vol 3 ubi_rootfs
        ubi vol 4 rootfs_data
 16: rootfs_1         0x0000ffff         0x900000        0x3a00000

输入printenv查看初始启动参数

IPQ5018# printenv
baudrate=115200
bootcmd=bootipq
bootdelay=1
done_upgrade=0
eth1addr=xxxx
ethact=eth0
ethaddr=xxxx
fdt_high=0x4A400000
fdtcontroladdr=4a9c4004
flash_type=11
ignore_part=0
ipaddr=192.168.10.10
machid=8040000
mtddevname=fs
mtddevnum=0
mtdids=nand0=nand0
mtdparts=mtdparts=nand0:0x3a00000@0x4300000(fs),
netmask=255.255.255.0
new_rootfs0=1
new_rootfs1=1
partition=nand0,0
rootfs_num=1
serverip=192.168.10.19
soc_hw_version=20180101
soc_version_major=1
soc_version_minor=1
stderr=serial@78AF000
stdin=serial@78AF000
stdout=serial@78AF000
sysfail=0

Environment size: 630/262140 bytes

配置TFTP服务

电脑网卡配置 ip地址：192.168.10.19 掩码：255.255.255.0 关闭防火墙将ubi-JIKEAP_N3000.img固件放入根目录

TTL刷固件

电脑网口接路由器WAN，输入以下命令开始刷机

1
2

tftpboot ubi-JIKEAP_N3000.img   
flash rootfs

提示OK后，断电重启

搞定

备用命令

IPQ5018# nand erase 0x900000 0x3a00000

IPQ5018# setenv bootargs IPQ5018# setenv eth2addr IPQ5018# setenv eth3addr IPQ5018# setenv fsbootargs

IPQ5018# setenv mtdparts mtdparts=nand0:0x3a00000@0x4300000(fs), IPQ5018# setenv mtdparts mtdparts=nand0:0x3a00000@0x900000(fs),

IPQ5018# saveenv

Git上传GitHub常用命令

Sun, 25 Jun 2023 22:30:28 +0000

将本地文件上传到GitHub上的项目

1.在GitHub上创建一个新的仓库（repository）。

2.在本地计算机上使用Git命令行工具或GitHub Desktop等工具初始化一个Git仓库。

3.将本地文件添加到Git仓库中，并提交更改。在Git命令行工具中，可以使用以下命令：

1
2

git add .
git commit -m "Add local file"

4.添加远程仓库的URL。在Git命令行工具中，可以使用以下命令：

`1`	`git remote add origin <remote repository URL>`

5.将本地代码推送到远程仓库。在Git命令行工具中，可以使用以下命令：

`1`	`git push -u origin master`

完成以上步骤后，你就成功将本地文件追踪到GitHub上的项目了。在以后的提交中，只需执行步骤3和5即可将更改推送到远程仓库中。

commit修改成运行时的时间

`1`	`git commit -m "$(date +"%Y-%m-%d %H:%M:%S")"`

这个命令会将当前时间以 YYYY-MM-DD HH:MM:SS 的格式插入到 commit message 中，每次运行脚本都会自动更新 commit message 为当前时间。

向github的分支推送

1.确认当前分支：使用 git branch 命令检查您当前所在的分支。

`1`	`git branch`

2.创建新分支（可选）：如果您需要创建一个新的分支并将更改推送到该分支，则可以使用以下命令创建新分支，并切换到新分支：

`1`	`git checkout -b new-branch-name`

这将创建名为 new-branch-name 的新分支，并切换到该分支。

3.添加更改：使用 git add 命令添加要提交的更改。例如，如果您想要提交名为 index.html 的文件，则可以使用以下命令：

`1`	`git add index.html`

您也可以使用 git add . 命令添加所有已更改或新增的文件。

4.提交更改：使用 git commit 命令提交更改并添加注释。例如，如果您要添加一条注释：“更新首页内容”，则可以使用以下命令：

`1`	`git commit -m "更新首页内容"`

5.推送更改：使用 git push 命令将更改推送到远程仓库。例如，如果您要将更改推送到名为“dev”的分支，则可以使用以下命令：

`1`	`git push origin dev`

在上面的命令中，“origin”表示远程仓库的名称，而“dev”则是要推送的分支。

6.查看更改：在您将更改提交到远程仓库后，在 GitHub 上的仓库页面上查看更改是否已成功推送到分支中。

自用续火花的QQ机器人

Sun, 25 Jun 2023 22:19:00 +0000

项目地址

minibot

功能描述

一款基于nonebot_plugin_firexN自用定时发送QQ消息的机器人

定时早上发一条信息,具有vip联系人以及普通联系人，可以自定义发送消息的内容及时间。

安装以及依赖

1
2
3

git clone https://github.com/maskbugzero/minibot
cd minibot
pip install -r requirements.txt

配置完成后运行

`1`	`nohup python3 bot.py > minibot.log 2>&1 &`

配置

在.env中配置参数说明

1
2

ENVIRONMENT=dev # 配置文件使用.env.dev
DRIVER=~fastapi

新建一个.env.dev文件

在.env.dev中配置参数说明

HOST=0.0.0.0
PORT=8080

fire_vip_users = ["xxx","xxx"]    # 必填 vip联系人QQ
fire_users = ["xxx","xxx"]    # 必填 联系人QQ
fire_sentence_vip_moring = ["句子1","句子2","..."]    # 早上随机发送该字段中的一句
fire_sentence_moring = ["句子1","句子2","..."]    # 早上随机发送该字段中的一句
fire_time_vip_moring = "8 0"    # 选填 早上发送时间默认为7:00            
fire_time_moring = "8 0"    # 选填 早上发送时间默认为7:00

Docker使用配置

将上述.env.dev文件存于文件夹minibot，其中minibot可以自定义

使用命令

`1`	`docker run -d --name minibot --restart=always -v /home/docker/minibot/.env.dev:/app/.env.dev -p 8080:8080 maskbugzero/minibot`

基于

Nonebot2

nonebot_plugin_firexN

JCG Q20路由器刷机教程

Sat, 13 May 2023 11:32:11 +0000

前言

JCG Q20路由器刷机教程，包括刷pb-boot、集客、Padavan、TTL救砖等，同时适配于JCG Q10Pro。

准备工作

备份分区文件

打开putty软件，输入IP地址选择ssh进行登录

登录用户名：root 密码：路由器底下铭牌上登陆密码。

ssh下输入查看分区命令

`1`	`cat /proc/mtd`

所有分区已经列出来了，使用以下命令逐个进行备份

dd if=/dev/mtd0 of=/tmp/Bootloader.bin
dd if=/dev/mtd1 of=/tmp/Config.bin
dd if=/dev/mtd2 of=/tmp/Factory.bin
dd if=/dev/mtd3 of=/tmp/firmware.bin
dd if=/dev/mtd4 of=/tmp/kernel.bin
dd if=/dev/mtd5 of=/tmp/rootfs.bin
dd if=/dev/mtd6 of=/tmp/rootfs_data.bin
dd if=/dev/mtd7 of=/tmp/firmware_backup.bin
dd if=/dev/mtd8 of=/tmp/rootfs_data_back.bin
dd if=/dev/mtd9 of=/tmp/nvram_config.bin

使用文件传输软件WinSCP，文件协议选SCP，主机名输路由器的IP地址，用户名：root 密码：跟SSH一样是路由器底下铭牌上登陆密码。

默认进入的是root目录，返回根目录，打开tmp文件夹将里面备份的文件复制出来，然后删除tmp文件夹内的文件。

原厂系统刷集客

使用的AX1800H固件

集客的测试固件库

选择JIKEAP_AX1800H_MT7621_K4_MT7915DN_WIFI6_NAND_FREE_7.4开头的固件下载

需要在原厂固件下wbe内直刷，重启后就刷机完成了。

刷pb-boot

需要过渡固件，通过过渡固件开启telnet和ssh，再在ssh内刷入pb-boot。

先准备需要的文件：padavan过渡系统固件、pb-boot和刷机工具putty。

下载地址

在原厂固件下选择高级设置——左下角——升级固件——选择过渡固件——升级——等待重启。

待路由器重启后，网页登陆padavan系统的IP地址：192.168.123.1 ，输入账号密码admin登录后台

系统设置——服务——终端服务——启用telnet服务——启用ssh服务——是——保存

使用WinSCP，文件协议选SCP，主机名输路由器的IP地址，账号密码admin登陆。上传pb-boot.img到路由器tmp目录下。

打开putty软件，输入IP地址选择ssh进行登录，账号密码admin登陆。

输入命令刷入pb-boot

`1`	`mtd_write write /tmp/pb-boot.img Bootloader`

拔掉电源，按住重置按钮并插上电源，在8秒后释放重置按钮，网页登陆IP地址192.168.1.1进入pb-boot

可以刷入其它支持pb-boot的固件刷breed的引导程序，在breed下刷固件：选择固件包的时候要注意由于使用了小米CR660X的pb boot，选择的时候也要选择对应小米CR660X的固件，否则无法使用

注意JCG Q20/Q10Pro固件有很多版本，这里借用恩山大佬qquccs的原话：

目前论坛有三类固件，一是匹配原厂uboot的一般叫Q20，一类是匹配小米breed/pb boot的一般叫CR660X，一类是匹配小米breed/pb boot而且针对Q20的灯和wan口进行修改的也可能叫Q20，这个一定要看清楚，原厂uboot只能刷匹配原厂uboot的Q20固件，不然就会变砖!

刷入适配pb boot的Padavan

自编译的适配pb boot的Padavan

项目地址

特点：完美适配灯和wan，无任何插件纯净版，无线800M左右

TTL救砖

准备一个Q20的原厂包，刷入后恢复出厂设置，第一次连接会自动输入密码，更方便

下载:https://wwd.lanzoul.com/i34hT01r0lte 密码:h10f

固件工具

CH340G硬件及驱动文件，插到电脑上安装好驱动待用。

先刷回官方boot，然后将路由器断电，把底部两颗拆掉，然后撬开顶上盖板及两颗螺丝，取出主板拆除天线及散热片。

在设备管理器中确认下ttl的com端口，属性——端口设置——设置好波特率115200

再putty连接，波特率115200，打开

然后给路由通电，这时候因为读不到对应的分区信息，路由会不断重启，在putty窗口不停按回车，进入下图界面

输入mtkautoboot回车

接下来选升级固件（Upgrade fireware）

这时候先把网线连接电脑和路由的lan口，并手动把电脑ip设置成192.168.1.2 掩码 255.255.255.0 网关192.168.1.1

打开tftp,如图设置好，点put

回到putty界面，选tftp 三次回车，输入要刷的固件名，这边是 firmware.bin
等待连接刷入成功

最后将把电脑ip重新设为自动获取，打开路由界面

MTK7621路由器刷Mikrotik rb750gr3固件

Sat, 13 May 2023 09:32:11 +0000

前言

将MTK7621路由器刷成Mikrotik RB750Gr3 的编程器固件

准备工作

1.搜索wr330或wr1200js，下单。

2.下载rb750gr3编程器固件

3.下载wr330的breed文件

刷机

wr330,加电状态下长按wp，恢复出厂设置。

登陆http://192.168.0.1，在管理页面，把账号 admin 改为 root ,密码Admin123并保存。

浏览器打开http://192.168.0.1/adm/telnetd.shtml 点Telnet后面的ON使其变成OFF。

打开cmd ，输入telnet 192.168.0.1 输账号root ，回车，输密码Admin123 回车。

找一个U盘并选FAT16格式化，把“breed-mt7621-pbr-m1.bin”复制到u盘根目录，然后插入wr330 usb口。

telnet下进入u盘根目录

`1`	`cd /media/sda1`

备份原厂编程器固件

`1`	`dd if=/dev/mtd0 of=wr330.bin`

刷入 breed

`1`	`mtd_write write breed-mt7621-pbr-m1.bin Bootloader`

重启路由

reboot

重启的同时，按住 WIFI 键进入 breed。

浏览器打开192.168.1.1进入breed，更新固件，选择编程器固件，去掉 “保留Bootlodert”和“保留eeprom”前面的勾，选择RB750GR3-new.bin，上传，更新。

静待一分钟，就进入routeros了。

授权

https://mikrotik.com/client 注册并登录。

进入后台后，找到Make a demo key 填入Software ID（Software ID在进入ros管理页面时会跳出来），点击生成，就能得到一个L1的Key，粘贴到命令行或在Winbox的system下的License 处粘贴。

结束

45块包邮，mikrotik rb750gr3到手。

备注

中兴E8820S，改16M的SPI NOR闪存，移动板子后面两颗电阻位置，在防火墙设置里添加好fasttrack规则，电信千兆光纤基本可以跑满（注：需加强散热）；友华WR330，刷后很完美，在防火墙设置里添加好fasttrack规则，电信千兆光纤基本可以跑满（注：需加强散热）；中兴E8820 V2，虽然也是7621主控和16M SPI NOR闪存，但用编程器写了固件以后，WinBox无法搜索到；小米路由器PRO（R3P），改16M的SPI NOR闪存，用编程器写了固件以后，WinBox无法搜索到。

—————————————————————————————— 可刷这个固件的机型还有： newifi2 D1 斐讯k2p（A1 A2） BLINK W1200 bufullo wsr-1166dhp toto-link a3004ns 友华 wr1200js

——————————————————————————————