工作总结

发表时间：2026-04-22

运维试用期工作总结。

转正那天，我把工位抽屉里的速溶咖啡收拾了一下——三个月的量，正好一罐。说实话，试用期能留下来，靠的不是那几份复盘报告，而是凌晨三点对着告警屏幕没摔键盘的那股劲。下面这几件事，算是我给自己交的底。

先说磁盘满那个晚上。

值班手机响的时候我正窝在沙发上看书，一看是数据库服务器告警，97%，再过俩小时就得写故障报告了。远程连上去，du -sh /var/log，发现一个叫app.log的文件32G。第一反应是直接rm掉，手都快敲下去了——但突然多看了一眼tail的输出，发现里面全是同一个异常：Connection pool exhausted。这不对劲，正常日志不会这么高频刷同一个错。

我没删，先mv到/tmp，然后kill -HUP 应用进程让它重新打开日志文件。磁盘占用降到72%，告警消了。但我知道根儿没除。查应用连接池配置，maxActive=20，看着正常。再查数据库的连接数，show processlist一看，同一个IP（就是那个网关服务）挂了85个Sleep连接，Time列全是28000多秒。我脑子里“嗡”了一下——连接没释放。查网关配置，connectionTimeout和idleTimeout都是0，等于永不超时。上周网关刚升过级，研发说“优化了连接池”，没给我发变更单，我自己也没复测这个参数。

后半夜我干了三件事：先把数据库的wait_timeout从28800改成600，这样就算网关赖着不放手，数据库也能把睡死的连接掐掉。然后给研发值班打电话，对方迷迷糊糊说“不可能，我测过”，我把show processlist截图甩过去，他沉默了半分钟，改口说“哦，那个配置文件我忘了提交”。最后我们俩在线上把网关配置改完、重启、观察半小时，Sleep连接降到5个。挂电话前我跟他说：“下次改配置，走工单，我测完再上线。”

这事儿我后来复盘，最蠢的不是技术，是我自己也差点犯懒——如果那天直接rm了日志，告警消了就睡，那这个隐患至少还得藏一个月。所以我在排障手册里加了一条：任何清理操作之前，先看一眼日志内容，确认是“量的问题”还是“质的问题”。

再说第二个事，雨季那台网关。

客户运维老张，我跟他通话记录里最多的一句话就是“又掉了”。那段时间每隔两三天，某个采集点就离线，重启就好，但原因死活找不着。监控看了无数遍，CPU、内存、带宽都正常。直到有一天早上，我坐公交上班，老张电话来了：“第三台，今早六点半又掉了，你们能不能给个准话？”语气不重，但我听得出来，他们夜班的人已经烦透了。

我调出那台网关断连前一小时的监控，重传率从0.1%一路飙到23%，然后连接就断了。这是典型的网络质量劣化。为什么只有这一台？查上联交换机，是一台老思科2960，放在弱电间里，没空调。那几天连续下雨，湿度大。我让现场同事看端口状态，发现有大量CRC错误和Runts。拔下来一看，水晶头触点发黑。重做水晶头，CRC清零，但问题没完——为什么其他网关接另一台华为交换机就没事？查了资料才知道，华为端口默认开了auto-mdix和信号整形，抗干扰能力强，思科这台老机器默认配置扛不住。跟领导说了情况，申请把这台交换机换了。批下来之前，我先给网关加了个脚本：每分钟ping对端，丢包率超过5%就重启网卡，算是临时保命。

老张后来在微信群里说了一句“这周没掉”，没打电话，也没感谢。我觉得这才正常——运维干好了就是隐形人。

试用期里我还干了一件笨事：把之前散落在各个聊天记录里的排障经验整理成了一份“故障排查树”。比如磁盘满，第一级分支是：是日志文件、数据文件还是临时文件？日志文件走清理流程，数据文件要查分区规划是不是出了问题，临时文件就要查哪个进程在疯狂创建。每个节点都写了具体命令和预期输出。新来的同事上周遇到CPU飙高，照着文档跑了三分钟就定位到是一个死循环的脚本。他跟我说“这玩意儿有用”，比领导说一百句都强。

当然也有搞砸的时候。有一次处理一个内存泄漏，我怀疑是tomcat的问题，直接重启了服务，结果忘了先看堆栈dump。重启完确实好了，但第二天又复现，研发问我要内存快照，我拿不出来。对方当时没说什么，但那个眼神（隔着屏幕我都能感觉到）让我记住了：紧急操作之前，先留现场。后来我写了一个脚本叫“before_i_touch.sh”，里面是ps aux、netstat -an、dmesg、free -m、df -h，运行完自动打包到/backup/crash/目录下，带时间戳。每次动手前先跑一遍，哪怕事后用不上也比后悔强。

迷你日记网-W286.cOM出圈必读: