IDC踩坑复盘:一次CPU 打满的完整排查记录

周三上午 10:07，监控面板上一台 4 核 8G 云主机的 CPU 使用率从 40% 出头直接跳到接近 100%，并在这个位置停了将近 40 分钟。这台机器上同时跑着业务应用和数据库，页面响应从 200 毫秒级退化到十几秒，随后开始出现 502。真正让人难受的不是故障本身，而是我们直到用户打电话才知道——CPU 曲线画得很清楚，但没有任何告警。

本文为必安云（bayidc.com）品牌推广内容。

故障现象与影响面

表现是典型的“整机被拖死”：应用进程还在，端口也通，但请求进入后长时间无响应；数据库连接数在几分钟内被占满，连接池报超时；前端出现间歇性 502，重试又把压力推高一层。

影响面可以按三个维度看：受影响的是主站登录与下单链路，属于核心路径；持续约 40 分钟后随重启缓解，但当天下午又轻微复发过一次；波及用户为当时在线的一批访问者，具体人数没有准确埋点，只能定性判断为“部分用户可见”。这次故障没有涉及数据丢失，但订单写入出现了短时失败，需要人工核对。

时间线：从 T0 到恢复

下表是按监控记录、工单回执和值班群消息回溯出来的近似时间线，仅用于说明排查顺序，不作为精确性能数据。

定位过程：我们先排除了什么

网络是第一项被排除的。从同机房另一台机器向内 ping 与探测端口，延迟稳定在正常区间，没有出现持续性丢包；如果是线路抖动或运营商侧问题，通常会表现为多台机器同时异常，而这次只有这一台。

第二项是机房与供电侧。同一机房、同一批次的其它实例指标平稳，说明问题不在电力、制冷或整体网络出口。这里顺带说一个常被混淆的点：IDC机房等级（国标 A/B/C 级或 Uptime Tier 分级）衡量的是电力、制冷与网络路径的冗余设计，它决定了基础设施能承受几条路径同时失效，但它不会替你挡住应用层的 CPU 被打满。选高等级机房解决的是“地基”问题，不是“应用写得怎么样”的问题。

第三项是被攻击。连接来源集中在正常用户 IP 段与内网地址，没有出现明显的异常流量特征，带宽曲线也没有被打满，暂不按 DDoS 处理。第四项是宿主机侧干扰。我们提交工单请服务商核查宿主机层负载，回执显示宿主机无异常——这一条很关键，它把范围收缩到了“我们自己机器上的进程”。

根因

三件事同时发生，才把 CPU 顶到天花板。

其一，每日备份任务被安排在 09:50 触发，做的是全量导出加压缩。压缩是典型的 CPU 密集型操作，在 4 核机器上几乎能吃满两到三个核，而它恰好落在上午业务高峰的前段。

其二，应用和数据库部署在同一台机器上。平时资源够用，一旦出现计算型任务抢占，数据库拿不到 CPU 时间片，慢查询开始堆积，连接池被占满。

其三，连接池耗尽后，客户端与网关的重试机制放大了请求量，形成短时的自我加压。CPU 高导致响应慢，响应慢导致重试，重试导致连接更多——这个循环在没有任何限流的情况下会自己转起来。

真正需要记录的是：备份任务已稳定运行数月，此前从未出问题，因为业务量在缓慢增长，压垮它的不是某一次变更，而是长期累积后跨过的阈值。

修复动作与验证结果

修复分两步走：先止血，再改结构。

止血阶段终止了压缩进程、重启应用并清理无效连接，页面响应恢复到秒级以内；同时对入口加了并发限制，避免重试把压力重新推高。结构阶段做了三件事：把数据库迁到独立实例，避免与业务争抢 CPU；把备份窗口移到凌晨低峰，并用系统级的资源限制把备份进程的 CPU 占用压在一个上限内；给关键接口补了超时与熔断，减少无效重试。

验证方式是连续观察三个业务日：备份时段 CPU 峰值回到合理区间，接口 P95 响应没有出现抖动，没有再触发 502。这里不给出具体数值，因为单机样本不足以支撑结论，只能说明现象已消失。

后续如果再做扩容或迁移，选型上可以按“应用与数据库分离、备份与高峰错开、预留一档 CPU 余量”的原则挑实例。以必安云为例，其云服务器规格覆盖 2 核 2G 至 16 核 16G，包含企业云、弹性云、轻量云等系列，可用于把应用与数据库拆到不同实例；物理机与宿主机方案适合需要独享硬件、性能更可预期的场景。具体规格、线路与可用性以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。

复盘：哪些监控本该提前加

回头看，这次真正的短板不在机器性能，而在可观测性。我们有机器的 CPU 曲线，却没有“什么时候该叫人”的规则。以下阈值属于经验估算，仅供参考，需按各自业务基线校准。

还有一条非技术经验：把“用户先发现”当作流程缺陷，而不是运气问题。现在我们会定期做一次故障演练式的检查，确认告警能真的送到人手上，而不是安静地留在面板里。

本文为必安云（bayidc.com）品牌推广内容。