要在短时间内定位问题,先做“三步初筛”:
检查监控平台(如Prometheus/Grafana、Datadog)上的延迟、丢包率、CPU、内存、磁盘IO、网络带宽使用等指标,判断是网络层、系统资源还是应用层问题。
从多地(最好从国内与美国多个节点)执行 ping、traceroute/mtr,观察是否存在高延迟或路径抖动;使用 curl -I 或 wget 测试 HTTP 响应头与时间戳,确认是否为后端响应慢。
登录服务器执行 top、htop、iostat、sar、vmstat 查看系统负载;用 ss/netstat 检查 TCP 连接数、TIME_WAIT 或大量重传;用 iftop/nethogs 看实时网卡流量,初步判断是资源瓶颈还是网络故障。
紧急缓解以“快速恢复可用性、最小化用户影响”为目标,优先执行可回滚、低风险的操作。
通过负载均衡器(如ELB/NGINX/HAProxy)将故障实例下线,或把流量切回健康的备用机房/Region;如使用DNS负载,立即切换到低TTL的备用记录或使用GeoDNS。
触发水平扩容(增加实例、启动备机),或启用服务降级(关闭非核心功能、图片压缩、关闭推荐算法)。必要时展示维护页以保护后端。
清空/刷新关键缓存(Redis/Memcached)或临时延长边缘CDN缓存时长,减少对后端的请求压力;若CDN配置异常,可切换到备用CDN或直接回源策略调整。
网络问题排查需要端到端、多点对比与抓包分析。
从多个地域节点做 traceroute/mtr,观察丢包与跃点延迟是否集中在同一ASN或运营商边界;结合BGP监控(如RIPE/BGPView)查看是否有路由波动或黑洞。
在服务器上用 tcpdump 捕获异常时间段的流量,分析重传、零窗口、RST等异常;从客户端复现并抓包对比,确认是上行丢包、下行拥塞还是中间链路问题。
用 iftop、vnstat、sar -n DEV 监控网卡流量;若链路饱和,排查是否被某IP/服务突发拉满(可能是爬虫或攻击),临时可通过黑名单、限速或流量清洗策略缓解。
应用与数据库问题常表现为响应慢或错误率升高,定位需结合日志、性能分析与回滚策略。
查看应用日志(tail -f)、错误堆栈和APM追踪(如Jaeger、New Relic)定位慢接口;对数据库使用慢查询日志(MySQL slow_query_log)和 EXPLAIN 分析慢语句。
若是新版本发布引入的问题,优先回滚最近的部署;对单点服务可先重启进程或重启连接池,释放被耗尽的资源。注意在高并发下重启要做滚动,避免雪崩。
对数据库可暂时开启只读模式、提升缓存命中(增加Redis缓存层或扩大缓存容量)、限流写入或将写操作队列化,减轻数据库压力。
恢复只是第一步,根因分析(RCA)与改进措施能提升下次响应效率与可靠性。
把监控指标、抓包记录、日志、部署记录、运维操作时间线整理,重现问题场景并标注每个环节的异常点,形成时间序列证据链。
根据RCA输出改进项:如优化数据库索引、增加自动扩容策略、降低单机依赖、引入多Region主备、优化CDN与缓存策略、调整报警阈值和运行手册。
把关键应急流程写入Runbook并进行演练(包括切换流量、回滚、扩容、清理缓存),逐步把手工步骤自动化(脚本化切换、自动恢复脚本、健康探针与自愈策略),同时完善SLA与备用链路采购。