天辰娱乐平台公司运营系统长运故障快速排查处置方法

系统跑着跑着卡死了，页面转圈，数据不动，用户那边电话已经打过来了。这时候别慌，先按顺序来。

排查不是撞大运，是有路子的。下面这套法子，我们用了两年多，救过不少场子。

第一步，先看监控大屏。

别急着翻代码，先看CPU、内存、磁盘IO和网络带宽。四个数里，哪个飙到90%以上，重点就锁定哪个。

CPU高，多半是死循环或者某个统计任务抽风。内存高，八成是缓存没释放，或者查询把数据全捞进内存了。磁盘IO高，看看是不是日志写疯了，或者临时表爆了。网络高，查一下是不是有人在上传大文件，或者接口被刷了。

第二步，看日志，但要会看。

别从头翻到尾，那样眼会瞎。

先找最近五分钟的错误日志，按级别过滤，只看ERROR和FATAL。

看到重复报错，记下时间点和报错代码。

如果是数据库连接池报“连接耗尽”，那就是连接没归还，查一下是不是有事务没提交。

如果是接口超时，就看是慢SQL还是外部调用卡住。

记住，日志是给线索的，不是让你当小说看的。

第三步，查慢查询和锁表。

很多长运故障，根子就在数据库。

开个命令行，跑一下`SHOW PROCESSLIST`，看看有没有长时间卡住的查询。

看到`State`列是`Waiting for table lock`或者`Sending data`超久的，就抓出来。

慢SQL多半是没走索引，或者用了`SELECT *`，或者关联了太多表。

锁表的话，找出持锁的会话，先杀掉，让业务恢复，再回头优化SQL。

记住：先救火，再查原因。

第四步，看外部依赖。

如果系统本身没问题，数据库也正常，那八成是外部服务挂了。

快递接口、支付回调、短信通道，任何一个拖个几十秒，整个链路就堵成粥。

用个简单的探活脚本，curl一下关键依赖的health接口，看响应时间。

超3秒的直接标记为“疑似故障”，超10秒的直接判死刑。

这时候，能做的是降级——把非核心依赖的调用改成异步，或者直接返回缓存数据。

别恋战，先让核心流程跑通。

第五步，回滚最近更新。

如果一切正常，突然长运故障，九成是刚上线的代码惹的祸。

查一下发布记录，看看最近三小时内有没有更新。

有，就果断回滚。

别舍不得，回滚不是认输，是止损。

回滚后观察十分钟，系统稳了，再慢慢去复盘代码哪儿写错了。

记住：线上稳定第一，责任划分第二。

第六步，如果是缓存雪崩或者穿透。

很多时候，长运故障不是真死了，是缓存集体失效，所有请求一起怼到数据库。

这种情况，数据库CPU会瞬间飙高，连接数暴涨。

处置办法：

先限流，把入口流量砍掉一半，让系统喘口气。

再把缓存预热一遍，把热点数据提前塞回去。

末了说检查缓存过期时间，是不是设了统一时间点，比如整点整分。

改成随机过期，比如3600到3900秒之间随机。

第七步，应急脚本要提前备好。

别等到出事了才现写脚本。

平时就准备几个常用的：

• 批量杀连接脚本
• 清缓存脚本
• 重启某个服务的脚本
• 临时降级开关的配置

每季度演练一次，确保脚本能用，路径对，权限够。

出问题时，手忙脚乱翻U盘最耽误事。

第八步，人和流程。

故障处置，最怕的是大家抢着干，结果越搞越乱。

定个规矩：

一个指挥，其他人配合。指挥只下命令，不自己动手。

动手的人只做一件事，做完立刻回报。

每一步操作，都要在群里留个记录，方便事后复盘。

别开电话会吵架，先动手救活系统，再讨论责任。

末了说说一句：长运故障不可怕，可怕的是没章法地瞎试。

按着上面这套路子走，快的十分钟，慢的半小时，基本都能稳下来。

稳下来之后，记得写个故障报告——不用长，就把时间线、根因、处置动作、改进项，四条列清楚。

下次再遇到，照着办就行。