上一篇
服务器宕机怎么处理
排查故障源，重启服务；启用备用机转移负载，同步
立即评估现状与影响范围
确认故障现象：检查监控工具（如Zabbix/Prometheus）、日志文件及用户反馈，明确是否为全面宕机或局部服务异常，HTTP错误码503、数据库连接超时等。
影响分析：通过拓扑图定位受影响的业务模块、关联系统和用户群体，优先恢复核心功能（如支付网关＞普通查询）。
️ 临时措施：若有必要，切换至备用节点/负载均衡器分流请求，避免雪崩效应扩大化。
标准化应急响应流程
| 阶段 | 操作步骤 | 工具示例 |
|---|---|---|
| 隔离故障源 | 断开可疑硬件/进程；禁用自动重启防止反复冲击 | systemctl stop <service> |
| 保存现场证据 | 截取完整日志快照；创建磁盘镜像备份 | tar -zcvf /var/log/.tar.gz |
| 尝试基础修复 | 重启依赖组件→清空缓存→重载配置文件三部曲 | docker restart container_id |
| 回滚变更点 | 若近期有过更新部署，立即撤销最近一次代码提交或配置修改 | Git revert commit_hash |
| 扩容资源池 | 横向扩展实例数量；纵向提升单节点CPU/内存配额 | Kubernetes HPA自动扩缩容 |
深度排查根因（Root Cause Analysis）
常见诱因分类排查表
| 类型 | 典型特征 | 诊断命令/方法 |
|---|---|---|
| OOM Killer触发 | dmesg含”Out of memory”告警 | dmesg | grep -i kill |
| 死锁进程阻塞调度器 | top显示某进程CPU占用率持续100%且状态为D | ps auxfw查看调用栈 |
| I/O等待积压 | iostat显示await值>5ms | iotop定位高负载磁盘操作 |
| 网络闪断 | netstat出现大量RETRANSMITTED包重传记录 | tcpdump抓包分析链路质量 |
| 慢SQL拖垮数据库 | slow_query_log记录执行超时的复杂事务 | EXPLAIN解析未命中索引的查询语句 |
进阶技巧
️ 使用strace -p <PID>追踪系统调用级异常行为
️ 对比健康节点与故障节点的配置差异（尤其关注内核参数sysctl设置）
️ 对分布式架构执行混沌工程测试复现问题场景
系统性恢复策略
渐进式验证方案：按“单组件→子系统→全链路”顺序逐步上线服务，每阶段设置观察期（建议≥5分钟），先恢复API网关→激活微服务实例→最后加载数据库读写分离集群。
️ 防御性加固：在重启过程中启用读只模式(readonly mode)，阻止新写入导致数据不一致；采用蓝绿发布策略降低风险。
压力测试复盘：用JMeter模拟峰值流量冲击修复后的集群，确保TPS、响应延迟等指标回归基线水平。
事后归因与长效预防机制建设
编制RCA报告模板参考项
| 维度 | 内容要点 |
|————–|————————————————————————–|
| What | 确切描述故障表现及时点 |
| Why | 根本原因链推导（直接原因→间接原因→体系缺陷） |
| How Fix | 已实施的技术改进措施 |
| Prevention | 新增监控指标、自动化巡检脚本、灾备演练频率调整等 |
️ 基础设施优化方向
→ 引入Service Mesh实现东西向流量治理
→ 部署eBPF探针实现无侵扰可观测性增强
→ 建立SLO/SLI体系量化服务质量标准
相关问题与解答
Q1: 如果所有备份都损坏了怎么办？
A: 立即启动灾难恢复预案：①联系云厂商提取冷存储归档数据；②协调上下游系统进行补偿交易；③启用异地机房的热备环境承接流量，日常应遵循“3-2-1原则”（至少3份副本放在2种不同介质上，其中1份存于异地）。
Q2: 频繁出现短暂性卡顿如何根治？
A: 这种现象多由连接池泄漏引起，解决方案包括：①配置合理的超时时间（如MySQL wait_timeout=30s）；②使用中间件代理层统一管理长连接；③定期审计线程池使用情况
