运维小回顾：巡检体系、告警调优与自动化实践

每年的这个时候，我都会习惯性打开自己的运维笔记，把过去一年踩过的坑、做过的事、改过的系统翻出来过一遍。这个动作坚持了挺多年了，像给自己的工作做一次全身检查。今年也不例外，借着写这篇“运维小回顾”，我想把那些值得记住的内容沉淀下来——不是流水账式的罗列，而是把思路、命令、配置和背后的判断逻辑一并记录下来。

这篇回顾面向的是正在做运维或者准备转运维的朋友。无论你是负责几台服务器的小团队，还是维护上百节点集群的专职运维，里面提到的巡检体系、监控告警调优、故障排查方法论和自动化思路，都可以直接拿过去对照参考。我尽量把话说得直白，把自己实际用下来的东西写清楚，也把踩过的坑原原本本摊开来讲。

1. 日常巡检体系的沉淀

1.1 巡检清单从手敲命令到固定流程

最早做巡检，其实就是登录服务器敲几条命令：uptime看一眼负载，df -h看一眼磁盘，free -gh看一眼内存，再tail几下日志有没有报错。这套动作在机器少的时候完全够用，但服务器一旦上了两位数，每天挨台执行就开始变得不现实。而且人总会偷懒，状态好的时候可能连着几天不巡检，真出事时又手忙脚乱。

后来我把巡检内容整理成了一份固定清单，分成了主机层面、中间件层面、应用日志层面三类，每类列出必须看的指标和对应的命令。再后来，这些命令被固化成了脚本，放到每台服务器的定时任务里执行，结果统一收集到指定目录。这一步是巡检从“想起来才做”变成“每天都做”的关键转折——人可能会忘，但定时任务不会。

再往后，我把巡检脚本的输出解析出来，推送到监控系统的指标库。现在打开面板就能看到所有节点的巡检状态，有异常自然会亮红。这个演进路径我认为很有参考价值：不要一上来就想着上多复杂的系统，先把手工清单做好，再逐步自动化，最后接入监控平台。

1.2 巡检脚本的核心写法与要点

很多人写巡检脚本容易犯一个毛病：堆命令，不控错误。比如直接写一堆df -h、free -m然后输出，看似全面，实际上一旦某台机器某个指标取值异常，脚本可能中途退出，后面全部没检查。我自己常用的写法是每条检查独立执行，加上超时控制和退出状态捕获。

拿磁盘检查举个例子：

#!/bin/bash # disk_check.sh 输出磁盘使用率超过80%的分区 THRESHOLD=80 LOG_FILE="/var/log/ops_check/disk_check.log" TIMEOUT_SEC=10 HOSTNAME=$(hostname) DATE=$(date '+%Y-%m-%d %H:%M:%S') while read -r line; do usage=$(echo "$line" | awk '{print $5}' | sed 's/%//') mount=$(echo "$line" | awk '{print $6}') if [ -n "$usage" ] && [ "$usage" -ge "$THRESHOLD" ]; then echo "$DATE $HOSTNAME WARN disk_usage=${usage}% mount=${mount}" >> "$LOG_FILE" fi done < <(df -hP | grep -vE '^Filesystem|tmpfs|overlay') # 关键：检查df命令本身是否超时 if [ $? -ne 0 ]; then echo "$DATE $HOSTNAME ERROR df_command_timeout" >> "$LOG_FILE" fi

注意几点：df -hP加P参数是为了不换行，防止挂载点名字太长时输出被截断问题；grep -vE过滤掉虚拟文件系统，避免tmpfs干扰；所有结果只追加写入日志，不覆盖，方便回溯历史；每跑完一步都检查退出码，拿不到结果比拿到坏结果更值得预警，因为拿不到结果往往说明命令本身已经卡死了。

1.3 巡检数据的可视化与周报自动化

脚本产生的日志单纯堆在服务器里，时间久了就没人看。我发现最有效的办法是把结果转成可视化面板，每天瞄一眼趋势，哪里不对劲一眼就能看出来。我用的是Prometheus加Grafana的组合：写了一个小exporter，把巡检脚本解析出的磁盘使用率、内存余量、关键服务状态这些字段暴露成指标，Grafana上拉几条折线，业务方问起来也直观。

以前每周要花一个早上手工汇总巡检数据写周报，后来我用Python写了个小脚本，直接读数据库里的指标记录，自动生成带趋势对比的Markdown周报，再转成邮件发出去。这个脚本其实逻辑不复杂，就是把数据从库里拉出来，按周聚合算平均值和最大值，再填到模板里。难点在于指标的命名规范要统一，这点越早定越好。我后来把所有自定义指标都按module_name_metric_name的格式命名，导出、查询、告警规则写起来都省事很多。

2. 监控告警体系的搭建与调优

2.1 监控指标到底该选哪些

很多人搭建监控系统时最容易犯的选择困难症：什么指标都想要，什么数据都先采了再说。结果就是告警条目几百条，每天信息轰炸，真正有价值的信息被淹没在噪音里。

我的选型原则是分层面看待：硬件层看健康和容量，系统层看资源争抢，应用层看用户体验。硬件层核心指标是磁盘坏道、内存错误、电源状态这些，容量类看磁盘剩余、内存剩余；系统层主要看CPU使用率、CPU iowait、内存使用率、文件句柄数、TCP连接数；应用层则要按业务实际定义，比如接口响应时间、错误率、QPS（每秒请求数）、队列积压数。

把指标分成必选和可选：必选指标数量控制在20个以内，全部纳入告警配置；可选指标只采集展示，不配置告警。这样可以避免告警规则泛滥。真正重要的不是指标数量，而是你能不能通过这几个指标快速判断出一个节点的健康状态。我的习惯是任何一个告警触发，必须做到在五分钟内能定位到大概的问题方向，否则这条告警设置的意义就大打折扣。

2.2 告警阈值的坑与调优思路

阈值设置是最能体现运维经验的地方，也是新人最容易翻车的环节。一个常见的反面例子就是把磁盘使用率告警阈值定在90%，结果某天早上业务方反馈服务不可用，一查磁盘已经100%占满，根本支撑不到触发告警就被写满了。后来我把阈值改成85%告警，75%提示，同时增加了磁盘增长速率预测——连续两个周期增长率超过某个值就提前预警，而不是死等达到阈值。

另一个典型问题是把CPU使用率阈值设得太过敏感。很多批处理任务的机器CPU就是会周期性跑满，这是正常现象，结果告警在每天晚上定点轰炸，值班同事直接免疫。解决办法是引入基线告警：通过历史数据建立每天的CPU使用率基线，实际值偏离基线超过设定幅度才告警。虽然配置起来工作量增加不少，但实际效果远比固定阈值可靠。

在告警分级上我目前采用三层结构：P0级故障直接电话加即时通讯机器人同时推送，要求立刻响应；P1级通过机器人推送，工作时间15分钟内响应；P2级只在工作时段推送日报汇总。关键点是告警不只是“出了问题才发”，还要设置恢复通知——问题解决了要自动触发一条恢复消息，这样值班人员才知道闭环了。

2.3 告警收敛：从信息轰炸到精准通知

刚搭建监控系统的头一个月，我所在的运维群一晚上能刷几百条告警。磁盘检查脚本每台机器每5分钟采一个数据点，阈值一突破就发告警，同一个磁盘持续性告警能刷屏一整晚。后来我做了三件事，效果立竿见影：

第一，告警聚合。同一个对象在一个时间窗口内反复触发同一条规则时，自动合并成一条，后面只更新触发次数和持续时长。第二，告警依赖抑制。主机已经处于宕机告警状态时，它上面的进程、端口、应用类告警全部自动屏蔽，因为这时候报一堆下游故障没有任何排障价值，还掩盖了根因。第三，告警标签标准化。每条告警必须包含环境、集群、模块、故障类型四个标签，比如env=prod、cluster=app-a、module=mysql、type=slow_query，这样方便做规则匹配，也方便快速过滤。

告警治理是一场持久战，不可能一次到位。我现在的做法是每个月花半天时间拉一次告警统计，把近一个月告警数量前十的规则过一遍，逐条问三个问题：这个告警是否曾经命中过真实故障？如果没命中，是阈值不合理还是指标本身没有监控价值？命中过的话，是否已经做了根因处理，告警规则可不可以调得更精准？这套流程坚持下来，告警数量平均每月都能降一些，值班体验也好了不少。

3. 故障排查实录：三起印象深刻的线上事故

3.1 磁盘写满引发的连锁反应

某天下午大概三点多，有业务方反馈上传文件失败。我第一反应是磁盘满了，登录服务器一查，根分区果然100%占用。再细查，发现应用日志把空间吃光了，而且日志文件明明设置了按天切割，但切割之后没有触发压缩清理。进一步看原因，是日志轮转模块的配置文件里，daily参数因为在版本升级过程被动到了，被注释掉了，等于日志轮转事实上处于失效状态。

处理思路其实分两步：先止血再治根。止血就是快速删掉过期日志文件释放空间，我优先清理了三天前的压缩日志和临时文件；随后恢复了轮转配置，手动执行了一次轮转验证，确认旧的日志被切割、压缩、清理，整个流程恢复正常。这里的经验是：遇到磁盘告警，第一件事不是急着买磁盘扩容，而是先找出空间被什么吃掉。用du -sh /* 2>/dev/null | sort -rh | head -10逐层往下定位大目录，确认占用来源，才好决定是扩容还是清理。

这次故障让我把磁盘检查脚本增加了两个维度的输出：一是历史增长速率的估算，二是日志目录总大小的专项统计。日志异常膨胀往往有前置特征，早点发现能避免后面被动。

3.2 慢SQL拖垮数据库连接池

这起事故发生在晚高峰时间段，最开始是几个核心接口陆续超时。从监控面板看，数据库实例的CPU使用率接近100%，活跃会话数激增，很多查询在排队等待。当时我第一反应是数据库慢查询把连接占满了，于是登录数据库查看SHOW PROCESSLIST，发现大量同一张表相关会话处于Sending data状态，怀疑是全表扫描导致的阻塞。

确认方向后，我先从慢查询日志里把执行时间最长的几条SQL捞出来，结果找到了一个分页查询，排序字段没有索引，数据量一大就全表排序，在晚高峰流量放大下直接把CPU打满。处理分两步：第一步给排序字段加上联合索引，这一步操作影响面可控；第二步在应用层对这个接口做限流和超时熔断，防止再次被突发流量打死。上线后数据库CPU从接近100%降到了30%左右。

后来我在复盘时意识到一个问题：这条慢SQL已经在慢查询日志里出现好多天了，为什么之前没有处理？原因是慢查询日志是当前数据库部署系统自带的，但它收集上来之后只是躺在日志目录里，没有人去主动分析。这暴露了监控链路的不完整——采集到了数据，却没有形成处理闭环。现在的做法是慢查询日志接入定时分析任务，超过阈值的SQL自动推送明细给开发和运维共同跟进。

3.3 磁盘IO异常波动排查

某天监控面板显示一批节点的磁盘IO延迟出现周期性尖峰，每次持续20分钟左右，然后恢复，隔几个小时又来一次。从业务上看整体影响不大，但高峰时段接口响应时间明显变长。我登录服务器用iostat -x 1观察，确认%util经常冲到90%以上，await也比平时高好几倍。

顺着IO等待高的进程往下查，用pidstat -d 1按进程维度看I/O读写，发现是一个备份进程在跑全量数据备份。再对照时间线，备份任务每天定点启动，但由于业务增长，备份数据量越来越大，备份耗时长到与晚高峰业务重叠，叠加之下就把磁盘IO打满了。解决思路很直接：把备份任务错峰到凌晨低峰期，同时把备份拆分成多个分片，降低单次IO冲击。改了之后IO尖峰基本消失。

这次排查给我一个教训：所有的计划任务调度也需要做统一管理和审查。备份、日志切割、数据同步这些后台任务看起来各自不相关，但它们在共享同一套系统资源，集中调度能避免任务“撞车”。

3.4 排查方法论：从现象到根因的路径

经历多次故障后，我把自己的排查思路总结成一条固定的路径。第一步明确时间线，故障是什么时候开始的、持续多久、是否周期性出现，时间线能帮你快速排除大量无关因素。第二步看变更，最近24小时中有没有配置变更、发布、扩容、开关切换，大量故障的根因其实就是一次不起眼的变更。第三步看指标，CPU、内存、IO、网络、应用层错误率逐项排除，把范围从整个集群缩小到单台主机或单个模块。第四步看日志，应用日志和系统日志交叉定位，找到第一个异常发生点。

这套方法论看起来朴素，但实战中非常管用。很多时候排查不顺利，是因为上手就扎到细节里，忘了先画整体时间线。我在排查重大故障时一定会拉一个简单的排查记录文件，把什么时间检查了什么指标、得出了什么结论、下一步计划是什么，一条条记录下来。这既能避免排查过程反复横跳，也是事后复盘最重要的素材。

4. 自动化与工具链的演进

4.1 脚本库建设：从命令史到标准化沉淀

做运维头几年，我的服务器上散落着大量命名混乱的脚本，比如1.sh、backup2.sh、final_new.sh，有的脚本连注释都没有，过了三个月再看根本想不起来它当时解决的是什么问题。后来我下决心整理了一遍，建立了一个统一的脚本仓库，核心做了三件事：统一目录结构、统一输出格式、统一日志策略。

目录结构按功能模块划分，比如system_check/放巡检，deploy/放发布，log_cleanup/放日志清理。每个脚本头部必须写清楚用途、参数、依赖的环境变量、维护人。输出格式统一成时间 主机名 级别 事件的格式，方便后期解析。日志全部写到独立的日志目录，并统一按天切割。当时整理这批脚本花了不少时间，但收益非常明显，后续维护成本大幅下降，新同事接手也更快。

4.2 批量操作工具的选型与落地

服务器数量多了之后，手动登录每台机器执行命令的方式逐渐变得不可接受。我最早尝试的是自己写循环SSH脚本，比如用for循环加ssh user@host "command"批量执行，简单场景确实够用，但一旦要区分不同机器执行不同命令、失败重试、结果回传，脚本就越来越复杂，而且容易出错。

后来我引入了配置管理工具来统一做批量操作。用配置管理工具的好处是可以把目标状态写成声明式配置，反复执行结果都一样（幂等性），不会因为执行两次就把系统搞乱。比如需要批量修改所有机器的DNS配置，以前要写循环脚本挨台执行，现在只要写好配置模板和变量，一条命令就能完成。

这里分享一个我踩过的坑：刚开始用配置管理工具时，我试图把所有服务器配置都塞进一个仓库管理，结果拉取执行时间越来越长，而且有些机器的系统版本不统一，配置很容易冲突。后来按照业务模块拆分成多个项目，不同项目用不同的变量文件，清晰很多。不是所有东西都适合一把梭，按场景拆分才是正解。

4.3 发布流程的简化之路

早年上线发布是我最紧张的环节之一。手工登录服务器、拉代码、切版本、清缓存、重启服务，每一步都要靠人盯，出错概率高，出了错还要靠经验回滚。后来我基于持续集成流水线做了一套自动化发布，把发布操作固化成流程：代码合并到发布分支后触发编译打包，产物推到制品库，然后流水线自动分发到目标服务器的指定目录，执行前自动备份当前版本，执行后自动做健康检查。

最关键的改进是回滚变得比较简单。发布前自动备份上一个版本的目录，健康检查失败后可以选择一键回滚到备份版本。以前手工发布时，回滚经常因为“没留备份”或者“备份不全”而措手不及，现在这个环节被工具保证住了。

自动化发布上线后，我自己的发布操作失误率下降了很大幅度。但也必须说明，自动化不等于无脑执行，流水线里还是需要加一些需要人工确认的门禁节点，比如重大版本发布时，可以设置一个审批步骤，由负责同事点击确认后才继续往下走。

4.4 定时任务统一调度

分散在各台服务器上的crontab管理起来非常头疼。某次排查环境问题时发现某台机器上的一个定时脚本从未执行成功过，查了半天才发现脚本路径在部署时写错了，而当时部署的人也早忘了这事。这类问题靠人力检查效率太低。

我现在的做法是把定时任务尽可能收口到少数几台专门的管理节点上，通过统一命令下发到目标机器执行，而不是每台机器各写各的crontab。规划是让所有定时脚本统一存放在固定目录，统一日志输出，统一异常通知，这样即使脚本执行失败，也会通过消息机器人把错误信息推送到群里。

5. 踩坑记录与实用避坑清单

5.1 那些看似简单却反复踩的坑

第一个坑是计划任务重启后失效。排查了很久，最后发现是某次升级过程将crond服务禁用了，重启后定时任务没有自动启起来。现在我自己有个习惯，任何机器重启之后必查一遍定时任务状态和后端服务状态，而不是只看进程在不在。第二个坑是防火墙规则的顺序问题，一条宽泛的拒绝规则放在了允许规则前面，结果导致本该放行的端口全部不通。排查这类问题最快捷的办法是先看规则列表，再看命中计数，而不是自己在那里反复测试。

第三个坑是文件句柄数限制。应用本身没有问题，但高并发场景下不断打开文件不释放，最终把进程的文件描述符耗尽，表现为“too many open files”。这类问题通常比较隐蔽，因为平时低流量下根本不会触发。解决方法是一方面把系统的ulimit调大，另一方面更要排查应用本身的资源释放逻辑，只调操作系统限制是治标不治本。第四个坑是时区问题。不同服务器时区不一致，导致日志时间线错乱，排查问题的时候对不上号。现在所有服务器统一使用同一个时区，日志里全部记录带时区的时间信息。

5.2 常见问题速查表

这张表我经常翻看，每次故障处理完也要顺手把新案例补进去，慢慢形成自己的问题库。

5.3 运维工作的一点个人体会

做了这么久的运维，我最深的感受是这行核心追求就两个字：稳定。但稳定不等于一成不变，反而需要持续迭代优化。监控告警要调，巡检脚本要改，自动化流程要完善，每一样都是慢功夫。

我记得有人说过，运维做的很多事都是“默默无闻”的，系统稳定的时候没人注意到你，一旦出故障所有人都会来找你。这话确实道出了这行的处境。但换个角度看，运维又是最有成就感的岗位之一——你搭建的监控系统在深夜0点发出告警，你爬起来处理掉隐患，第二天业务照常运转，这种在幕后守住防线带来的踏实感，是其他岗位很难体会到的。

5.4 接下来的改进方向

复盘过去一年的工作，我也给自己列了几个下一步想重点改进的方向。一个是完善容量管理，不只是被动地等磁盘满了再告警，而是主动做容量趋势预测。另一个是推进业务可观测性建设，在现有系统层监控基础上，逐步打通链路追踪和日志关联分析，让故障定位从分钟级缩短到秒级。还有一个方向是完善故障应急手册，针对历史出现过的故障类型编写细化的处理SOP，同时定期组织模拟演练，确保团队里每个人遇到同类问题时都能照着手册快速响应，而不是依赖个别资深同事临时发挥。

做运维这份工作，最不缺的就是新鲜问题和意外状况。每次解决完一个问题，我会花一点时间想想这个问题是怎么来的、以后怎么预防、能不能通过工具自动化兜底。正是这些碎片化的思考积累起来，让运维工作从被动救火逐步转向主动治理。这篇小回顾既是给自己的一份梳理，也希望里面沉淀的教训和思路能对同行有一点参考价值。