2026年了，凌晨三点被报警电话叫醒，登录服务器一看磁盘使用率100%、MySQL连接数打满、老板在群里连发三个问号——这种场面我经历过不下十次。后来我把监控、日志、性能、数据库、备份这五件事做成了标准动作，P0故障从每月3次降到0.3次。下面全是实操步骤，没有一句废话。

1. 监控告警别只配CPU和内存，漏了这三个指标等于白装

很多团队装个Prometheus就觉得自己有监控了，但只看CPU、内存、磁盘使用率，问题爆发前根本无感。我建议至少补三个指标：磁盘inode使用率、TCP重传率、OOM kill计数。我遇到过一个案例：一台Nginx服务器内存才用了60%，但TCP重传率飙到15%，用户反馈页面卡顿，查了三天才定位是网卡驱动bug，换驱动后重传率降到0.1%。这几个指标在Prometheus里加这几条规则：

node_filesystem_files_free / node_filesystem_files_size * 100 < 20
rate(node_netstat_Tcp_RetransSegs[5m]) > 10
node_vmstat_oom_kill > 0

告警推送到Alertmanager，分组规则设成凌晨只电话通知，白天推送钉钉或飞书，避免“狼来了”效应。

2. 日志排查别只会tail -f，用Loki+Promtail把定位时间从30分钟压到1分钟

我以前查问题也是tail -f | grep，遇到分布式调用链直接抓瞎。后来上了Loki+Promtail，成本比ELK低一个量级，查询速度够用。实操：Promtail采集nginx和业务日志，打上service标签，JSON结构化输出。某次订单服务偶发超时，用Loki查status=500且耗时>3s的请求，通过trace_id关联上下游，1分钟定位到Redis连接池耗尽。查询语句长这样：

{service="order-api"} |= "status=500" | json | latency > 3s | line_format "{{.trace_id}} {{.latency}}"

建议日志别再用纯文本正则硬解析，输出JSON能省掉一半排障时间。

3. CPU飙高不要只会top，perf+火焰图定位到具体函数才算入门

top只能告诉你哪个进程在烧CPU，具体哪行代码在烧，得靠火焰图。实操：先用top -Hp拿到线程ID，再用async-profiler（对生产影响<1%）生成火焰图。有一台Java服务CPU常年90%，top看是GC线程，其实代码里频繁创建大对象。用./profiler.sh -d 60 -f /tmp/flamegraph.svg PID生成火焰图，发现某个JSON序列化库的反射调用占掉70% CPU，换成fastjson2后CPU降到35%。这个工具我强烈推荐，比perf record安全，输出是SVG可以直接丢给开发看。

4. 数据库连接池不是越大越好，用这个公式能避免70%的雪崩

很多同学把HikariCP的maximumPoolSize设成200，觉得越大越抗并发，结果数据库先挂了。连接池大小有个经验公式：connections = ((core_count * 2) + effective_spindle_count)。一台8核SSD服务器，把连接池从200调到18，响应时间反而下降40%，因为200个连接导致数据库CPU上下文切换和锁竞争，吞吐量不升反降。实操：打开HikariCP的metrics监控连接等待时间，如果等待时间稳定超过10ms，先别急着扩池，先看是不是慢SQL拖住了连接。

5. 备份不做恢复测试等于零，用restic做增量备份+每月一次演练

备份文件躺在那里和没有备份区别不大。我见过一个团队用mysqldump每天全备，结果事故恢复时发现最后一次能用的备份是7天前，因为备份脚本连续一周报错没人看，最后丢失一周数据。实操：用restic备份到S3兼容存储，每天凌晨自动增量；MySQL用xtrabackup+binlog，RPO从24小时降到15分钟。恢复命令：

restic -r s3:xxx restore latest --target /tmp/restore

然后每月手动删一次测试库，用备份恢复，记录耗时。把恢复时间写进SLA，否则平时没人重视备份质量。

运维的核心不是背锅，是把不确定性变成可重复的流程。上面五步照着做，至少能少挨一半骂。如果你连监控告警都没配全，今晚先别熬夜，把第一条搞定。

📌 延伸阅读：百度蜘蛛IP段详细分类，优质蜘蛛和垃圾蜘蛛 | HTTPS改造避坑手册：从证书申请到混合内容清零，别让“不安全”吃掉你的转化

以上就是本文的全部内容，希望对你有所帮助。如果有任何疑问，欢迎联系站长。