业务突然不可用，第一时间不是找开发，不是重启服务，而是先做一套标准化自查动作。这套动作决定你是在5分钟内恢复业务，还是把故障拖成事故，顺序错了,补救就慢了。
业务突然不可用先自查什么？按这个顺序不容易漏
系统出问题时，人容易慌，一慌就乱点，乱重启，最后日志也没留，现场也破坏了，正确做法是把自查当成探案，按线索顺序走,别跳步。
第一步：确认影响范围，别急着碰服务器
先问自己三个问题,用笔或记事本记下来：
- 完全不可用还是部分不可用？是所有用户报错，还是只影响某个地区、某个功能模块？
- 你这边能复现吗？自己在测试环境或者线上随便点一个页面，看是白屏、超时、还是报500/502/504。
- 最近一次变更是什么时候？发布过代码、改过配置、动过数据库，哪怕只是改了个字段,都得记下来。
这一步不是让你修，是让你圈定战场，多数情况下，故障定位慢不是因为问题复杂，而是因为一开始就没确认好影响边界,后面全在瞎猜。
第二步：先看监控告警，再决定要不要登服务器
行业共识认为，70%以上的故障在发生前都有预兆，只是告警被忽略或者阈值设太高，所以自查的第二步，是打开你的监控面板,重点看这四类指标：
- CPU使用率：是瞬间飙高还是缓慢爬升
- 内存占用：有没有接近物理上限，SWAP是不是在持续增长
- 磁盘空间：日志盘写满没有，数据盘还剩多少
- 网络带宽：入方向和出方向流量是不是异常
有条件的团队，还能看错误日志的滚动速度、慢查询数量、接口响应时间分位数，监控面板上如果显示某个接口的P99响应时间从200ms变成2000ms,那问题大概率就在那条链路上。
第三步：按优先级执行自查动作
监控没有问题的话，就把下面这张表当成你的自查清单,从上往下逐条过。
| 优先级 | 自查项 | 判断标准 | 动作 |
|---|---|---|---|
| P0 | 局域网/网络连通性 | ping网关通不通 | 不通则检查交换机、防火墙策略 |
| P0 | 核心进程状态 | ps -ef | grep java | 进程不在就拉日志找崩溃原因 |
| P1 | 端口监听状态 |
netstat -anp | grep 8080 |
端口没监听说明应用没起来 |
| P1 | 对外服务首页 | curl -I http://你的域名 | 非200或超时说明入口层出问题 |
| P2 | 业务日志尾部 | tail -200 error.log | 看有没有OOM、连接池耗尽、锁等待 |
| P2 | 数据库连接数 | show processlist; | 连接数跑满说明连接池泄漏或有慢SQL |
不需要全部做完，优先做P0和P1，如果P0和P1都正常,再往应用层深挖。
第四步：记录现场，再动手修复
很多人一上来就重启，以为重启能解决一切，但重启会把崩溃现场的线索全部抹掉,正确的姿势是：
- 先把当前进程的线程栈dump下来：
jstack 进程号 > /tmp/stack.log - 把错误日志和慢日志完整拷一份再动手
- 记录当前时间点和各系统状态截图
做完这些，才允许你重启服务或回滚代码，保存现场是运维的基本功,也是将来复盘和甩锅的关键证据。
系统故障排查：先看业务还是先看服务器
这是个经典问题，也是团队里经常争论的点，我的答案是：先看业务，再看服务器，原因很简单，业务状态是结果，服务器状态是原因之一，你直接看服务器，看到CPU满了，但不知道是为什么满的；但如果你先看业务，看到用户报的是“上传图片超时”，你就能直接联想到存储IO、带宽、或者对象存储服务,排查方向完全不一样。
业务视角：让用户告诉你问题在哪
用户遇到故障时，报上来的信息往往只有一个“打不开”，但你得学会翻译这句话：
- “页面转圈圈” → 前端请求没返回，可能是后端处理慢或网络丢包
- “点按钮没反应” → 可能是前端JS报错，也可能是接口超时
- “提示系统繁忙” → 说明业务层做了降级或限流
- “数据不对” → 大概率是缓存没刷新或数据库主从延迟
把用户描述翻译成技术术语,你的排查范围直接缩小一半。
服务器视角：用命令快速定位资源瓶颈
业务视角圈定方向后，再上服务器验证，我推荐一套黄金命令组合,三分钟能跑完：
uptime # 看负载均值，1/5/15分钟 free -h # 看内存和SWAP df -h # 看磁盘剩余空间 iostat -x 1 3 # 看IO等待时间 top -Hp 应用PID # 看哪个线程在吃CPU
跑完这套命令，你基本能判断出是资源型故障还是逻辑型故障，资源型故障（比如磁盘满、内存溢出）在命令输出里一目了然；逻辑型故障（比如代码死循环、死锁）则需要结合线程栈和日志分析。
业内专家指出，多数线上故障的根源不是硬件，而是代码变更、依赖服务抖动、数据量增长这几类问题，所以服务器检查只是验证手段,别陷在服务器里出不来。
业务不可用损失怎么算？把账摊开再决定下一步
自查过程中，你会面临一个现实问题：这个问题值不值得马上处理，还是可以等一等，别觉得这个问题傻，很多时候业务不可用不算真正的故障，真正的故障是处理过程中误操作把影响面扩大。
按用户量和业务类型先算一笔账
给业务算损失，不需要精确到多少钱,心里有个量级就行：
| 业务类型 | 每小时的估算损失 | 容忍时间 |
|---|---|---|
| 电商交易类 | 较高，直接关联流水 | 最短，分钟级 |
| 内部管理系统 | 偏低，影响内部效率 | 可容忍半个工作日 |
这组数据不是让你做严谨的财务测算，而是帮助你判断要不要冒着风险去线上操作，比如内部系统挂了，即使你排查到了可疑点，也可以选择观察一段时间确认；但如果是核心交易链路断了，哪怕只有一点线索,也得立刻上服务器抓现场。
重启和回滚哪个代价更低
排查到一半，发现可能和最近的发布有关,这时候你要做个抉择：
- 回滚代码：需要重新构建、验证、发版，耗时较长，但治本
- 重启服务：快，但如果问题出在代码逻辑或数据上，很快会再挂
- 摘流量：把故障节点的流量切走，保留现场，适合多实例部署
我的建议是：优先摘流量，其次回滚，最后才重启，摘流量既能让用户恢复访问，又保住了故障现场,是性价比最高的动作。
5分钟自查流程：把零散动作串成实操线
前面讲的是单个动作，这里整合成一条可执行的时间线，当你接到“业务挂了”的通报，照着这条线走，5分钟内你能对故障类型有个基本判断。
0-1分钟：接报与初步确认
- 记录报障人、时间、业务影响范围
- 通过监控面板确认首页、核心接口状态
- 确认是否大面积故障还是个别用户个案
1-3分钟：执行核心命令
按优先级执行P0和P1自查项的检查，执行完记录输出结果，如果发现进程不存在或端口未监听,立刻拉取进程管理日志。
3-5分钟：锁定依赖关系
业务连了多少外部服务？哪些是强依赖？给依赖服务画一条线：
- 数据库：连接池是否占满，主从同步是否延迟
- 缓存：Redis是否命中率骤降，是否大量超时
- 消息队列：积压量是否快速增长，消费者是否离线
- 第三方接口：对方是否回调超时，是否触发熔断
只要有一个依赖在抖动，业务表现出的症状就是“卡顿”或“报错”，把你画出来的链路和当前症状做匹配,多数情况能直接命中问题源头。
5分钟后的处理原则
- 如果是配置或依赖问题，直接改配置或重启依赖，快进快出
- 如果是代码缺陷，能快速定位就摘流量回滚，定位不到就先保留现场，通知开发介入
- 如果是资源瓶颈，扩容、清理日志、加缓存，按不改变业务逻辑的方式优先做
业务突然不可用自查的常见疑问
监控没有告警，就一定不是服务器问题吗？
不是，监控没有告警只能说明监控指标没有超过阈值，不代表一切正常，有些故障是缓慢演进的，比如内存泄漏，它会一点点吃掉内存，到临界点才爆发；还有监控盲区，比如你自己写的JVM参数监控，可能只看堆内存而忽略了元空间，没有告警时，更要注意业务日志里的异常,以及用户侧的报障反馈。
先重启服务还是先查日志？
如果非要说选择，先查日志，再决定重启，重启是最后手段而不是第一手段，日志是故障现场的唯一证据，一旦进程被重启，之前的内存状态、临时文件、线程信息全部丢失，确认日志记录完毕，再执行重启，如果日志量大，可以先cp一份再操作，为了快速恢复而放弃线索,后面要做的事只会更多。
为什么防火墙策略改了，业务立刻就不通了？
防火墙规则在多数Linux发行版里是即时生效的，当你调整了iptables或者安全组规则，改动往往直接作用于正在运行的连接，比如你为了限制某个IP访问，顺手把端口段放行规则改成了拒绝，现有长连接会被立刻断开，新连接也进不来，每次改防火墙之前，先把旧规则备份：iptables-save > /tmp/iptables.rules，改动后30秒内验证业务连通性,不通就快速恢复。