创业公司线上服务频繁崩溃，十年老板总结全链路排查方案

凌晨三点手机震得床头柜嗡嗡响不用接都知道线上又崩了。创业第七年这种场面早就麻了。最开始团队拢共五个人连专职运维都没有前端后端打包兼运维出了事故所有人光着脚往电脑前冲查半小时发现是某台云主机磁盘满了业务日志生生打满了 100G 的系统盘MySQL 直接挂死写不进去。这种低级坑踩多了慢慢攒出来一套野路子排查流程不是大厂那种标准 SOP也没什么高大上的方法论胜在快适合人手不足、监控体系半残的中小团队。别信那些什么从上到下按链路一步步排查的狗屁教程真到了线上着火用户炸群的时候谁还按顺序来哪可疑先扎哪先止损再查根因这是创业公司保命的第一准则。先说说最容易被忽略的连接池那点事。上个月刚踩过新上的一个报表服务白天低峰期好好的一到晚上批量跑任务就卡成狗接口 RT 直接飙到十几秒最后直接挂死。一开始新人上来就查 SQLexplain 了半天说索引都命中了没慢查询。我让他去看一眼连接池状态show processlist一拉好家伙一百多个 Sleep 连接占着不放连接池直接打满新请求根本拿不到连接。查了半天才发现新写的导出接口里开了事务中间调了个第三方接口超时事务一直没提交连接就占着不放。高峰期一冲连接池直接耗尽。很多人写代码根本不关注连接池配置maxActive 拍脑袋写个 200也不管数据库扛不扛得住要么就是事务边界乱开一个接口里套着远程调用还开着事务不出事才怪。排查的时候别光盯着代码先敲一行命令看看连接数正不正常比你瞎改半小时代码管用。bash运行netstat -anp | grep 3306 | wc -l说起来上次更离谱网关服务每隔两天准点 OOM 一次堆内存拉满之后直接重启告警消息天天凌晨发。堆 dump 拉下来用 MAT 分析大对象全是字节数组查了半天才定位到是有人把请求体全打进日志里了文件上传接口连整个文件流都往 logback 里塞几 M 的文件一个请求打一次日志高峰期分分钟把堆内存撑爆。很多人排查问题总喜欢加日志加的时候一时爽线上火葬场。日志打多了不仅占磁盘拖 IO严重的时候直接能把服务搞崩。真要排查 OOM别上来就瞎调 JVM 参数先拉 dump拉下来慢慢分析比你猜来猜去靠谱。Xmx 设再大架不住代码里写 bug 造大对象。bash运行jmap -dump:formatb,fileheap.hprof pid别总盯着应用层网络抽风的时候比代码 bug 还恶心。去年有阵子服务间调用超时率突然飙到 30%所有接口都慢查了一圈代码没发版数据库 CPU 内存都正常缓存也没问题折腾了俩小时最后 mtr 测了一下跨可用区的路由中间节点丢包率快 20%云厂商的交换机出故障了。新人最容易犯的错就是一上来就改代码觉得肯定是自己写的逻辑有问题。真遇到全链路普遍超时先 ping 一下依赖的服务telnet 测端口tcpdump 抓个包看看先把网络、DNS 这些基础设施的问题排除了再往代码层面查。省得忙活半天最后发现是机房光缆被挖断了。缓存这东西救得了你也能坑死你。前年做一次大促提前压测了好几轮觉得稳了结果活动刚开始十分钟数据库直接被打挂。查下来是热点商品的缓存集体过期流量直接击穿打到库上MySQL 瞬间连接数打满直接雪崩。当时哪有空查根因先临时在网关层给热点接口加了本地缓存扛过高峰期再说。事后复盘缓存过期时间全设的统一值一到点集体失效不雪崩才怪。后来所有缓存过期时间都加了随机偏移热点数据提前预热再加上本地缓存兜底才算稳住。还有 Redis 的内存淘汰策略很多人默认用 volatile-lru结果热点数据没设置过期时间内存一满先把热点数据清了越忙越乱。说起来监控这东西创业公司最容易走两个极端要么啥都没有服务挂了用户反馈了才知道要么整一堆花里胡哨的Prometheus、Grafana、SkyWalking 全装上最后连告警阈值都没配出了事还是靠人喊。我们最开始就装了个 Zabbix只看 CPU 内存磁盘服务挂了半天都发现不了。后来慢慢加了业务指标QPS、RT、错误率核心接口的成功率才算能在用户炸群之前先收到告警。但也踩过坑SkyWalking 刚搭的时候采样率设了 100%ES 磁盘三天就满了差点把日志服务搞挂。后来改成正常流量 10% 采样异常请求全采样既能留足排查线索也不至于把存储打爆。真要排查问题监控面板扫一眼错误率有没有突增RT 有没有飙高QPS 有没有异常流量基本能先定个大概方向。别上来就登服务器翻日志先看大盘缩小范围。真要翻日志也别瞎翻先过滤异常栈比你逐行看快得多。bash运行tail -f error.log | grep -A 20 Exception很多人一遇到线上崩溃就慌上来就想找根因用户都炸锅了还在那逐行 debug。创业公司没那么多容错空间第一优先级永远是止损。能重启先重启能切流量先切流量能降级先降级把服务先拉起来用户能用了再慢慢查原因。当然不是让你瞎重启重启之前先留现场。线程栈打一下堆 dump 拉一下错误日志备份一下数据库当前的连接、慢查询快照存一下。不然重启完啥证据都没了下次该崩还得崩永远查不出来根因。我见过太多开发出事先重启重启完好了就完事了结果过两天同样的问题再出现还是一脸懵。线上问题不怕偶发怕的是重复踩同一个坑。还有个容易被忽略的点主从延迟。之前有个业务写操作走主库读完马上写结果读从库的时候数据还没同步过来导致业务逻辑异常反复重试最后把接口打挂了。很多人觉得主从延迟就几百毫秒无所谓真到了高峰期主从延迟几秒都有可能尤其是大事务、DDL 操作之后。排查的时候别光看主库状态也看看从库的 Seconds_Behind_Master业务逻辑里别写完马上读从库核心场景强制走主库比你事后排查半天管用。零零散散写了这么多其实线上崩溃的原因翻来覆去就那几类但每次出问题的姿势都千奇百怪。可能是运维改 Nginx 少写了个分号可能是前端写了个死循环疯狂调用接口可能是第三方服务挂了导致连锁反应也可能就是云主机突然抽风。没有什么万能的排查方案说白了就是踩的坑多了扫一眼监控大概就知道是哪层的问题。创业公司没人没资源不可能像大厂那样搞全套稳定性体系先把最基础的监控、日志、应急流程搭起来能覆盖 80% 的问题。就先写到这想起来啥再补。线上的坑永远踩不完共勉。