线上故障排查与应急响应实战：从零开始建立你的SRE体系

线上故障排查与应急响应实战从零开始建立你的SRE体系大家好我是迪哥。2024 年我们的线上故障平均恢复时间MTTR是 45 分钟2025 年降到了 10 分钟怎么做到的靠的是完善的应急响应机制和故障排查手册。今天就把压箱底的经验分享给大家。故障分级优先级明确级别定义响应时间负责人P0全站不可用/核心交易链路不可用立即5分钟内响应技术负责人 各模块负责人P1重要功能不可用/用户大面积受影响15分钟内响应对应模块负责人P2小范围功能异常/不影响核心流程1小时内响应开发工程师P3提示性问题/UI 小瑕疵1天内响应前端/产品应急响应流程P0 级1. 接警与确认0-5 分钟告警来源Prometheus 告警系统级SkyWalking 告警链路级监控大盘业务级用户反馈确认动作# 1. 检查服务状态 kubectl get pods -n prod # 2. 查看日志最近 500 行 kubectl logs --tail500 -n prod deploy/order-service # 3. 检查错误率 curl http://prometheus/api/v1/query?queryerror_rate2. 止血5-15 分钟优先用这三招回滚新版本上线后出问题立即回滚上一版本kubectl rollout undo deployment/order-service -n prod限流熔断流量过大导致雪崩立即限流Sentinel 控制台调整限流规则网关层面限流降级非核心功能直接关掉GetMapping(/api/feature-not-important) public Result feature() { if (isDegrade()) { return Result.success(功能维护中暂不可用); } // 正常逻辑 }3. 排查15-30 分钟黄金 5 条命令# 1. 看 CPU/内存 top htop # 2. 看日志 tail -f /var/log/app/error.log grep Exception /var/log/app/error.log # 3. 看网络 netstat -anp ss -s # 4. 看 GC jstat -gcutil pid 1000 10 # 5. 看线程堆栈 jstack pid thread.dump jmap -dump:formatb,fileheap.hprof pid排查思路看监控从大盘找到异常指标看日志找到错误堆栈看链路用 SkyWalking 找到慢/错误 Trace想变更最近上线了什么查依赖数据库/MQ/Redis 挂了吗4. 恢复与复盘30 分钟问题解决验证业务正常复盘会24 小时内完成5 Whys 分析法写出详细故障报告制定改进计划常见故障排查手册故障 1OOM内存溢出现象Pod 反复 Crash状态是 OOMKilledJVM 日志有OutOfMemoryError排查# 1. 导出堆 kubectl cp pod:/app/dump.hprof ./dump.hprof # 2. MAT 分析 # 重点看大对象、内存泄漏解决短期调大-Xmx长期修复内存泄漏故障 2数据库慢查询导致雪崩现象数据库 CPU 100%应用请求超时错误率飙升排查-- 1. 查慢日志 SHOW VARIABLES LIKE slow_query%; -- 2. 查正在执行的 SQL SELECT * FROM information_schema.processlist WHERE command ! Sleep ORDER BY time DESC; -- 3. EXPLAIN 分析 EXPLAIN SELECT * FROM orders WHERE status 0;解决加索引优化 SQL限流或降级该功能故障 3微服务雪崩现象A 服务挂了导致 B、C 都跟着挂连接池耗尽排查SkyWalking 看拓扑图看哪个服务错误率最高解决熔断降级快速扩容优先恢复核心服务演练定期做 Chaos Monkey// Chaos Monkey 测试随机杀 Pod public class ChaosMonkey { public static void main(String[] args) { // 每 10 分钟随机杀一个 Pod仅在测试环境 while (true) { killRandomPod(); Thread.sleep(TimeUnit.MINUTES.toMillis(10)); } } }应急响应 CheckList序号检查项状态1核心服务是否正常⬜2最近是否有变更⬜3数据库/Redis/MQ 是否正常⬜4错误率/延迟是否有异常⬜5日志中是否有明显报错⬜6是否已尝试回滚/限流/降级⬜7是否已通知相关人员⬜经验总结止血优先不要死磕根因先恢复服务回滚是第一选择大部分故障由变更导致平时要演练不要到故障时才发现命令不会敲文档要完善尤其是应急手册复盘要落地只说不做下次还会出同样问题说到故障排查我家那只叫 Docker 的哈士奇最近拆家越来越有经验先咬沙发腿核心服务再咬靠垫非核心我现在练出 5 分钟内就能制止它的应急响应能力 我是迪哥我们下期再见往期推荐《系统容量规划与压测实战》《Spring Cloud Alibaba 微服务全家桶》