工作总结
发表时间：2026-04-10月工作总结。
这月主要跟三个故障较劲。写总结不为别的，把坑标出来，下回绕着走。直接上干货。
头一个事：凌晨磁盘满，差点把交易系统搞瘫
那天凌晨两点，值班电话跟催命似的响——核心交易系统日志分区写满了，应用直接卡死。说实话，这种告警每周都蹦几次，但清理脚本平时能兜住，这回彻底哑火。
我第一时间ssh上去，df -h一看，/var/log 使用率100%。先别急着重启，用lsof | grep deleted扫了一圈，好家伙，有个Java进程把日志文件删了，句柄还死死攥着，空间一直占着不放。找到PID，kill -9 重启进程，句柄一释放，分区腾出12G。但问题没完——脚本为啥没跑？
翻cron日志，发现清理脚本报“权限不足”。上周调整了日志目录属主，从root:root改成app:app，但脚本里的sudo规则没跟着改。这破事，偷偷跑了七天了。更坑的是，这七天里有三次磁盘使用率冲到85%，我们设了提前告警阈值，但因为脚本一直失败，告警被人为忽略了——值班同事看每天半夜都发，以为误报。
临时措施：修复sudo规则，手动跑通脚本。但我知道这治标不治本。顺手干了三件事：第一，写了个每分钟跑的systemd timer，执行lsof | grep deleted，发现句柄未释放就发钉钉告警，附上PID和进程名；第二，把关键分区的提前告警阈值从85%降到75%，并且强制要求每次告警必须确认根因，不能直接忽略；第三，翻历史数据，过去两周同类告警有11次，其中3次差点触发满盘。我把这些数据贴在复盘文档里，让团队看到严重性。
事后我才琢磨明白，还有个隐藏坑——那个Java进程为啥会留下僵尸句柄？查代码发现，日志轮转用的是Logback的TimeBasedRollingPolicy，但没配maxHistory，导致旧文件被删除后进程没收到信号。顺手改了配置，加了maxHistory=30和cleanHistoryOnStart=true。
第二个事：机房电源线，看着小事差点酿大祸
上个月新上一批服务器，验收时我顺手拽了一下电源插头——居然能晃动。拆开线槽一看，施工队只在两头扎了扎带，中间全悬空。你懂的，这地方旁边是台存储阵列，风扇转速8000转，震动起来电源线脱扣，整台机器直接掉电，数据都来不及刷。
我没急着发火。拿手机拍了视频，用测振仪APP测了下，震动幅度3mm。然后翻出机房施工规范第4.2.3条，拍在施工负责人桌上：“每20厘米固定一次，拉力测试10N。你们这中间跨度快一米了。”对方还想扯皮，说“一直这么干没出过事”。我直接把视频慢放给他看，电源线随着风扇震动一抖一抖的。
整改要求：三天内全部返工，每根线用拉力计测，我随机抽20%复查。同时，我把这个检查项加进机房验收清单，写明“手拽验证，晃动幅度超过1mm即为不合格”。更狠的是，我把这个案例做成了一页纸的警示，贴在机房入口——上面就一句话：“别让你的服务器死在电源线上。”
后来我巡检另外两个在建机柜，发现同样问题，提前按住了。说实话，这事让我意识到，做运维不能只盯着屏幕，物理层那点破事儿一样要命。
第三个事：一条慢SQL，把接口拖成龟速
某天下午三点，业务高峰，订单查询接口从50ms飙升到3秒。看监控，数据库CPU才30%，连接数正常，但应用线程池全在等数据库。抓个慢查询日志，发现一条新上线的统计SQL，explain一看，全表扫描，预估rows=20，实际扫了200万行。
问题在哪儿？开发用了status字段做条件，联合索引是(create_time, status)。优化器认为create_time过滤性更好，直接忽略status。说白了，索引顺序没按等值查询放前面。
我当场没敢直接加索引——怕锁表。先在线用ALTER TABLE ... ALGORITHM=INPLACE, LOCK=NONE加了个idx_status_ctime (status, create_time)，然后ANALYZE TABLE更新统计信息，再强制使用新索引。接口响应立马降到60ms。峰值期扛住了。
但这事还没完。我翻了开发上线记录，这条SQL没经过任何审核。于是我拉着团队搭了一套SQL审核流程——用SOAR做自动分析，配合Archery平台，强制要求explain的rows必须小于1000，否则不让上线。上线后头两周，拦住了3条类似的低效SQL。
后来跟开发复盘，对方说“我本地测试就20条数据啊”。我直接回他：“生产环境200万，你拿测试环境说事？”从此立了条规矩：开发环境必须灌入生产数据量的1%做压测。
顺便说个失败的
上个月还有一次，磁盘满我着急重启进程，结果那是核心服务的注册中心，重启导致所有会话断连，被投诉了半小时。后来我学精了，凡是重启前先pstree -p看依赖关系，再用curl调一下健康检查接口，确认影响范围。现在这个动作写进了故障处理SOP，谁违反谁请喝奶茶。
回头捋这三件事：磁盘满、电源线松、慢SQL，根因都一样——变更管理失控。改个属主忘了同步脚本，图省事少扎两道扎带，索引顺序拍脑袋。所以我这个月还干了一件事：把每个故障的根因抽象成一条可执行的检查规则，塞进发布前自检表和机房巡检清单。比如“重启前先看句柄”“扎完线用手拽”“上线前explain一遍”。别跟我扯什么流程优化，落到实处就这几条。
干这行快五年了，最大的体会就是：别信“我以为”。你以为脚本天天跑，结果权限炸了；你以为施工队按标准干，结果中间悬空；你以为开发测过了，结果全表扫描。现在我就一个笨办法——但凡经手的东西，自己亲手验一遍。不是不信任别人，是故障这玩意儿，从来不讲情面。
- 想了解更多【工作总结】网的资讯，请访问：工作总结
