在运维工作中，故障处理的核心是 “快速定位根因 + 止损恢复 + 预防复发”。以下是运维中最常见的几类故障及标准化处理思路，覆盖服务器、网络、数据库、应用等核心场景：

一、服务器故障

1. 服务器突然宕机（物理机 / 虚拟机）

• 现象：服务器无响应，ping 不通，管理口失联，业务服务全部中断。
• 可能原因：
  • 硬件：电源故障（如电源模块烧毁）、CPU / 内存过热宕机（散热风扇故障）、硬盘物理损坏触发保护。
  • 系统：内核 panic（如驱动冲突、内存溢出）、误操作（如reboot -f被误执行）、虚拟机宿主机资源耗尽。
• 处理步骤：
  1. 快速恢复：
     • 物理机：检查机房电源指示灯，强制重启（按电源键），观察是否能启动；若重启失败，排查电源、主板（需硬件工程师配合）。
     • 虚拟机：检查宿主机状态（是否过载、宕机），在虚拟化平台（如 VMware、K8s）中重启虚拟机，优先恢复业务。
  2. 定位根因：
     • 启动后查看系统日志：/var/log/messages（Linux）、/var/crash（内核崩溃日志），搜索 “panic”“error” 关键词。
     • 硬件层面：通过 IPMI/iDRAC 查看硬件健康报告（如温度、电压、磁盘状态），确认是否有硬件告警。
  3. 预防措施：
     • 部署服务器监控（如 Zabbix、Prometheus），实时监控 CPU 温度、电源状态、内存使用率，设置阈值告警。
     • 虚拟机宿主机预留 20% 以上资源，避免因资源耗尽导致虚拟机宕机。

2. CPU / 内存使用率骤升（接近 100%）

• 现象：服务器响应变慢，业务请求超时，部分进程被 OOM（内存溢出）杀死。
• 可能原因：
  • 进程异常：应用程序内存泄漏（如 Java 程序未释放对象）、恶意进程（挖矿程序）占用资源。
  • 业务突发：流量峰值超出预期（如促销活动未提前扩容）、批量任务（如日志分析）未限制资源。
• 处理步骤：
  1. 快速止损：
     • 定位异常进程：top（按P看 CPU 排序，按M看内存排序），找到高占用进程的 PID。
     • 临时处理：若为非核心进程（如挖矿程序），直接kill -9 PID；若为业务进程，先临时扩容（如增加服务器），再限制其资源（如用cgroups限制 CPU / 内存上限）。
  2. 根因分析：
     • 内存泄漏：通过jmap（Java）、pmap（进程内存映射）分析进程内存分布，结合应用日志定位代码漏洞。
     • 流量问题：查看监控平台（如 Grafana）的流量曲线，确认是否为突发流量，或是否有异常 IP 高频请求（可能是攻击）。
  3. 预防措施：
     • 给核心进程配置资源上限（如 Docker 的--cpus --memory参数），避免单进程占满资源。
     • 部署 OOM 监控（如dmesg | grep OutOfMemory）和进程异常告警（如 CPU 持续 5 分钟 > 80% 触发告警）。

二、网络故障

1. 服务器 / 业务 “网络不通”（单向 / 双向）

• 现象：本地能 ping 通网关，但 ping 不通目标服务器；或服务器能对外访问，但外部无法访问服务器。
• 可能原因：
  • 链路层：网线松动、交换机端口故障、光纤衰减过大。
  • 网络层：IP 地址冲突、子网掩码 / 网关配置错误、路由表异常。
  • 应用层：防火墙（如 iptables、firewalld）规则拦截、安全组策略限制。
• 处理步骤：
  1. 分层排查：
     • 物理层：检查网线接口是否亮灯（绿灯常亮为链路通，黄灯闪烁为有数据），更换网线 / 交换机端口测试。
     • 网络层：
       • 本地：ip addr确认 IP / 子网掩码正确，route -n检查默认网关是否存在。
       • 链路：traceroute 目标IP（Linux）或tracert（Windows）排查哪一跳中断，判断是内网还是公网问题。
     • 应用层：iptables -L（Linux）查看防火墙规则，云服务器需检查安全组是否开放目标端口（如业务用 8080 端口）。
  2. 快速恢复：
     • 若为 IP 冲突：临时更换 IP 并排查冲突源（如arp-scan扫描局域网 IP）。
     • 若为防火墙拦截：临时关闭防火墙（systemctl stop firewalld）测试，确认后调整规则（如iptables -A INPUT -p tcp --dport 8080 -j ACCEPT）。
  3. 预防措施：
     • 网络配置（IP、网关）通过自动化工具（如 Ansible）批量管理，避免手动修改出错。
     • 核心链路做冗余（如双交换机、双网卡绑定），防火墙 / 安全组规则变更前先在测试环境验证。

2. 网络丢包 / 延迟过高（业务卡顿）

• 现象：ping 目标服务器有丢包（丢包率 > 5%），延迟波动大（如正常 10ms，突然跳到 500ms），视频 / 支付等实时业务受影响。
• 可能原因：
  • 带宽过载：某台服务器 / 应用占用大量带宽（如下载大文件、DDoS 攻击）。
  • 链路问题：光纤老化、交换机端口速率不匹配（如一端 100M 另一端 1000M）、路由环路。
  • 服务器负载：服务器 CPU / 内存过高，导致网络处理能力下降（如 TCP 队列满）。
• 处理步骤：
  1. 定位瓶颈：
     • 带宽：iftop（实时流量）、nload查看服务器网卡流量，确认是否达到带宽上限（如 1G 网卡跑满 1G）。
     • 链路质量：mtr 目标IP（持续跟踪丢包和延迟，区分是本地还是中间节点问题）。
     • 服务器网络栈：netstat -s查看 TCP 重传率（retransmits），若过高可能是服务器处理不过来（需优化net.ipv4.tcp_max_syn_backlog等参数）。
  2. 快速处理：
     • 带宽过载：临时限速（如tc命令限制异常进程的带宽），或扩容带宽（联系运营商 / 云厂商）。
     • 链路问题：更换链路（如切换备用光纤），协调网络团队排查交换机配置。
  3. 预防措施：
     • 部署带宽监控（如 Prometheus + node_exporter），设置带宽使用率 > 80% 告警。
     • 关键业务接入 DDoS 高防，定期演练流量清洗流程。

三、数据库故障

1. 数据库连接失败（应用报 “connection refused”）

• 现象：应用无法连接数据库，日志显示 “Can't connect to MySQL server”“connection timeout”。
• 可能原因：
  • 数据库服务未启动（如mysqld进程崩溃）。
  • 端口 / 权限问题：数据库端口未监听（如3306未开放）、用户密码错误、IP 白名单限制。
  • 连接数耗尽：max_connections达到上限，新连接被拒绝。
• 处理步骤：
  1. 检查数据库状态：
     • 服务状态：systemctl status mysqld（Linux），若未启动则systemctl start mysqld，启动失败需看日志（/var/log/mysqld.log）排查原因（如磁盘满、配置文件错误）。
     • 端口监听：netstat -tulnp | grep 3306，确认监听地址为0.0.0.0:3306（允许远程连接）而非127.0.0.1:3306。
  2. 连接数排查：
     • 登录数据库（若能登录）：show variables like 'max_connections';（查看最大连接数），show processlist;（查看当前连接，是否有大量闲置连接）。
     • 临时处理：若连接数满，先杀死闲置连接（kill 进程ID），临时调大max_connections（set global max_connections=2000;），后续优化应用连接池（如减少空闲连接超时时间）。
  3. 权限检查：
     • 确认数据库用户权限：select user,host from mysql.user;（host 是否包含应用服务器 IP），密码是否正确（可重置密码：alter user 'root'@'%' identified by '新密码';）。
  4. 预防措施：
     • 数据库服务配置自启动（systemctl enable mysqld），监控进程状态（进程消失立即告警）。
     • 连接池参数与数据库max_connections匹配（如应用连接池最大 1000，数据库设置 1500，留冗余）。

2. 慢查询堆积导致数据库卡顿

• 现象：数据库响应变慢，简单查询也超时，show processlist显示大量 “Query” 状态的进程，CPU 使用率接近 100%。
• 可能原因：
  • 存在未优化的 SQL（如缺少索引、全表扫描）。
  • 大事务未提交（如begin后未commit，导致表锁 / 行锁阻塞）。
  • 数据库配置不合理（如innodb_buffer_pool_size过小，导致频繁磁盘 IO）。
• 处理步骤：
  1. 紧急止损：
     • 定位慢查询：通过show processlist找到耗时最长的 SQL（Time字段值大），记录 SQL 内容，kill 进程ID终止该查询。
     • 若为锁阻塞：show engine innodb status\G查看锁等待，找到持有锁的进程并杀死（优先杀非核心业务）。
  2. 优化根因：
     • 分析 SQL：用explain + 慢查询SQL查看执行计划，若type为ALL（全表扫描），添加合适索引（create index idx_name on 表名(字段);）。
     • 拆分大事务：将长事务拆分为小事务，避免长时间持有锁。
     • 调整配置：增大innodb_buffer_pool_size（建议设为服务器内存的 50%-70%），开启慢查询日志（slow_query_log=1）记录阈值（如超过 1 秒的查询）。
  3. 预防措施：
     • 上线前 SQL 必须通过 “索引检查 + 性能测试”，禁止全表扫描的 SQL 进入生产。
     • 部署慢查询监控（如 Percona Monitoring），超过阈值自动告警，定期分析慢查询日志优化。

四、应用服务故障

1. 应用服务启动失败（如 Java 服务、Nginx）

• 现象：执行systemctl start 服务名后失败，status显示 “failed”，业务端口未监听。
• 可能原因：
  • 配置错误：配置文件语法错误（如 Nginx 的nginx.conf括号不匹配）、依赖服务地址 / 端口错误（如连接的 Redis 地址填错）。
  • 端口被占用：目标端口已被其他进程占用（如 Nginx 默认 80 端口被 Apache 占用）。
  • 权限不足：应用目录 / 日志文件无读写权限（如 Java 服务用普通用户启动，却访问/root目录）。
• 处理步骤：
  1. 查看启动日志：
     • Java 服务：查看应用日志（如logs/error.log），常见 “ClassNotFoundException”（依赖缺失）、“Address already in use”（端口占用）。
     • Nginx：执行nginx -t检查配置文件语法，错误会直接提示（如 “unknown directive”）。
  2. 逐个排查：
     • 端口占用：lsof -i :端口号或netstat -tulnp | grep 端口号，找到占用进程并杀死（kill -9 PID）。
     • 权限问题：ls -ld 应用目录确认所有者是否为启动用户，chown -R 用户名:组 应用目录修复权限。
     • 依赖检查：确认依赖服务（如 MySQL、Redis）是否正常启动，网络是否能连通（telnet 依赖IP 端口）。
  3. 预防措施：
     • 配置文件通过版本控制（如 Git）管理，修改后用脚本自动校验（如 Nginx 配置校验脚本）。
     • 应用启动脚本添加前置检查（如检查端口是否空闲、依赖是否可用），失败时输出明确日志。

2. 应用频繁崩溃（如 Java 服务 OOM、Python 进程退出）

• 现象：应用启动后不久自动退出，日志显示 “OutOfMemoryError”“Segmentation fault”，或被系统 OOM killer 杀死。
• 可能原因：
  • 内存泄漏：Java 对象未释放、Python 循环引用未回收，导致内存持续增长直至溢出。
  • 代码 bug：如空指针异常、数组越界，触发进程崩溃。
  • 资源限制：系统对进程的内存限制过低（如systemd配置MemoryLimit=512M，但应用需要 1G）。
• 处理步骤：
  1. 捕获崩溃信息：
     • Java OOM：启动时添加参数-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/，崩溃后生成堆快照，用jvisualvm分析泄漏对象。
     • 进程退出：查看系统日志/var/log/messages，若有 “Out of memory: Kill process XXX”，说明被 OOM killer 杀死，需调大内存限制。
  2. 临时缓解：
     • 调大内存配置（如 Java 服务-Xms1G -Xmx2G），或临时扩容服务器配置。
     • 若为代码 bug，紧急回滚到上一个稳定版本，同时修复代码。
  3. 预防措施：
     • 上线前做压力测试（如用 JMeter 模拟高并发），监控内存 / CPU 变化，提前发现泄漏。
     • 部署进程守护工具（如 Supervisor、systemd），进程崩溃后自动重启，同时触发告警（如短信 / 钉钉通知）。

五、存储故障

1. 磁盘空间满（No space left on device）

• 现象：应用无法写入日志 / 数据，报 “磁盘空间不足”，df -h显示磁盘使用率 100%。
• 可能原因：
  • 日志文件过大（如应用日志未轮转，单个文件达几十 G）。
  • 临时文件堆积（如/tmp目录未清理的缓存文件）。
  • 误操作（如备份文件写入根目录，未及时转移）。
• 处理步骤：
  1. 定位大文件：
     • 查找占用空间大的目录：du -sh /*（逐层排查，找到最大的目录），再用du -sh 目录/*缩小范围。
     • 常见大文件位置：/var/log（系统日志）、应用日志目录、/tmp、备份目录。
  2. 紧急清理：
     • 清理日志：删除过期日志（rm -f 日志文件），或用echo "" > 大日志文件（避免删除正在写入的日志导致进程异常）。
     • 配置日志轮转：为应用日志配置logrotate（如每天轮转，保留 7 天），避免单个文件过大。
  3. 长期解决：
     • 对核心目录（如/var）进行扩容（如 LVM 扩容、云盘扩容）。
     • 部署磁盘空间监控，使用率 > 85% 时告警，提前清理或扩容。

2. RAID 阵列失效（如 RAID5 一块盘故障）

• 现象：cat /proc/mdstat显示 “degraded”，存储读写变慢，部分文件损坏。
• 可能原因：
  • 物理磁盘故障（如硬盘 SMART 告警、坏道）。
  • RAID 卡电池失效，导致缓存数据丢失，触发阵列保护。
• 处理步骤：
  1. 确认故障盘：
     • 查看 RAID 卡管理工具（如 MegaCli）：MegaCli64 -PDList -aALL | grep "Failed"，找到故障盘的槽位（Slot Number）。
  2. 更换并重建：
     • 热插拔更换故障盘（支持热插拔的情况下），通过工具将新盘加入阵列：MegaCli64 -PDOnline -PhysDrv [Enclosure:Slot] -aALL。
     • 查看重建进度：cat /proc/mdstat（软件 RAID）或MegaCli64 -LDInfo -Lall -aALL（硬件 RAID），期间避免高负载操作（防止二次故障）。
  3. 预防措施：
     • 定期检查 RAID 状态（如通过脚本每天执行mdadm --detail /dev/md0），监控硬盘 SMART 信息（smartctl -a /dev/sda）。
     • 重要业务用 RAID6（允许两块盘故障），RAID 卡电池定期更换（通常 2-3 年）。

总结：故障处理的通用原则

1. 先恢复再排查：核心业务故障优先止损（如重启服务、切换备用节点），避免业务中断扩大。
2. 日志是关键：系统日志（/var/log）、应用日志、监控数据（Prometheus/Grafana）是定位根因的核心依据，必须确保日志完整可查。
3. 事后复盘：每次故障后输出 “故障报告”，记录根因、处理过程、改进措施，避免重复踩坑。
4. 自动化预防：通过监控告警（如 Zabbix）、自动恢复脚本（如进程崩溃自动重启）、定期演练（如故障切换），将被动处理转为主动预防。