工作总结
（标准）2026年主持工作总结。
干了一年多主持，说白了就是台前台后两头跑。白天盯工艺标准执行，晚上趴机柜跟前听风扇转速，哪块板子温度异常耳朵都能听出来。今天不在纸上谈兵，聊三件实打实的事——有凌晨被电话炸醒的，有被产线班长拍桌子的，还有给开发擦屁股擦了三天最后差点自己背锅的。
第一件：凌晨两点，磁盘说满就满
那天我当值，2:13分告警短信像鞭炮一样炸。核心交易库的归档日志把根分区啃得只剩0字节。远程SSH敲进去，df -h 直接飘红，/u01 使用率100%。alert.log 疯狂刷 ORA-00257，说白了就是归档撑爆了。脑子里第一反应：先保业务别停，再找凶手。
常规思路是删归档、扩分区，但这库的归档路径跟 $ORACLE_HOME 挤在同一个卷组，剩余空间已经是负数。更操蛋的是，rman 备份脚本前几天被运维组一个小年轻改过参数，把 delete input 给注释掉了，说是“怕误删”，结果归档从没被清理过。 36gH.COM
值班员在旁边催：“要不要切备库？”我算了算切库要改应用连接串，至少影响五分钟后端的批处理任务。我说等等，先试试 lsof | grep deleted。果然，有个监控进程还锁着一个巨大的归档文件——文件已经被 rm 了，但进程没释放，空间还占着。找到PID，kill -9 干掉。再跑 df -h，刷地一下放出12G。接着手动 rman 跑 crosscheck archivelog all; delete expired archivelog all;，干掉三百多个过期日志。总共折腾四十分钟，库恢复。当时后背全是汗，万一那进程杀错了，整个监控链路得断。
事后复盘，我直接在机房白板上写三条：第一，任何SQL脚本改动必须拉群通知加双人复核，签字截图存工单；第二，核心库根分区监控阈值从95%压到80%，轮询周期从两分钟改成每分钟；第三，给全体值班员加一堂课——专门讲 lsof 查deleted文件的用法，每人现场操作一遍才算过。
说实话，这事最让我窝火的是那个改脚本的没走变更流程。找他谈话，他说“我以为只是临时注释一下”。我当场没骂人，但后面专门补了一条硬规矩：所有生产环境脚本修改，哪怕改一个空格，都得走工单系统，违规一次当月绩效扣分。
第二件：产线班长拍桌子，就为0.5毫米
去年三季度，老化房连续报了三台设备电源模块过热停机。产线上的人咬定是散热风扇来料有问题。我拿热电偶一测，温度最高点不在风扇附近，在电源管理芯片的导热垫位置。拆开一看，装配工艺卡写着“导热垫厚度1.5±0.2mm”，实际贴的却是2.0mm的老款垫片。差这0.5毫米，贴合不紧密，芯片温度比散热片足足高了15度。
产线班长姓刘，老员工，拍着桌子跟我说：“标准是死的，人是活的，换了个垫片型号至于上纲上线？”我把热成像照片直接甩他桌上，芯片表面一块亮红色的热点，旁边散热片是绿的。他看了一眼不吭声了。
问题根源在哪？库房老库存用完了，采购直接买了替代型号，没通知工艺组更新BOM里的厚度参数。产线领料时看到编码不一样，但形状差不多，就按老习惯往上装。
救火措施分三步走：第一，所有库存的2.0mm垫片当场封存退库，紧急调拨1.5mm规格，加急物流第二天早上到；第二，已经装配好的120台设备，每一台都得拆盖换垫片，每台要拧12颗螺丝，两个人干了整整8个小时，手都磨出水泡；第三，在MES系统里加一道防错——扫码枪扫导热垫条码时，系统自动比对当前工位允许的厚度范围，不对应直接锁枪。
事后我写了一份内部通告，标题就叫“0.5毫米的代价”，抄送采购、工艺、生产三个部门。同时改了物料替换流程：任何非功能参数的替换，必须先拿三台样机做热成像对比测试，测试报告签字后才能批量上产线。
你懂的，有时候标准文件写得再清楚，到了执行层只要一个环节信息断了，前面全白搭。那之后我每个月随机抽一天蹲在产线边上，看他们实际操作，发现有偏差当场纠正，不攒着等问题爆发。
第三件：给开发擦屁股，差点自己背上锅
有个边缘采集服务，每两周左右准点重启一次。日志里只有一行 Killed process，没有OOM堆栈。开发同事在群里说“偶尔抖动，先观察”。我直接回了一句：“观察了两周了，我要root cause。”
架了 perf 和 bcc 的 memleak 脚本，跑了三天。发现进程的RSS以每小时50MB的速度稳定增长，但堆上活跃对象没多。晚上十一点，我蹲在机房查 /proc/pid/maps，突然看到有个共享内存段在不停追加写入——是一个日志库，每次连接断开后忘了调用 shm_unlink。这个连接来自第三方老设备的上传通道，正常设备每24小时重连一次，但现场有一批旧固件的设备每20分钟就断线重连一次。断开时不释放共享内存句柄，积累几百个就把进程干掉了。
我找到开发的组长，把证据丢给他。他看了半天说“那让设备升级固件呗”。我说设备是客户资产，升级要审批，周期至少两个月。能不能先在应用层把日志库打上补丁，加上 atexit 清理函数？他不情不愿地答应了，拖了一周才给包。
我这边催着现场运维把老设备分批升级固件，不能升的就加协议转换网关，把重连间隔限制到一小时以上。部署完之后，那个采集服务连续跑了76天没重启——76天后因为计划内停机才重启的。
这事最让我憋屈的是：故障排查的这几天，领导在会上问“为什么这么慢”，开发组长轻飘飘来一句“现场环境复杂，我们配合排查”。言下之意是我拖着他们。我当时没吭声，会后把三天所有的日志、命令输出、分析过程截图整理成一个文档，发到技术群，顺便抄送给领导。什么话都没多说，但所有人都看明白了。
从那以后，我在每周的稳定性例会上固定加一个环节：翻出所有“自动重启过但无根因”的进程列表，一个一个过。谁再说“习惯了就这样”，我就把那次的内存泄漏文档甩过去。
被漏掉的那个背锅位
其实还有一件事，没写在上面，但挺值得提。上个月帮一个业务部门查接口超时，查了三天，各种抓包、看线程堆栈、压测，最后发现是他们代码里把时区写死成UTC，导致凌晨的任务跟数据库时间对不上，批量卡死。汇报的时候，领导第一句话是“你们运维怎么不早点定位到应用层？”我当场愣住——三天里我提供了六份分析报告，每种可能性都列了，最后排查出是他们代码问题，反而成了我的不是？
后来我想明白了，干这行，有时候你查出来的问题越底层、越偏向别人，你背的锅就越重。所以我现在的原则是：所有跨部门的排查过程，每天发一次进度邮件，把当前结论、下一步计划、需要的协作都写清楚，抄送双方领导。不是为了甩锅，是为了让信息透明，谁也别装傻。
这三件事之后，我在白板上又加了一行字：应急演练改成盲演——只通知时间窗口，不告诉故障类型。第一次盲演，值班员用了二十分钟才定位到是DNS故障，当场就骂娘，但第二次就只用了八分钟。手头的十几份SOP我都用“默写测试法”验证过一遍——让值班员不看文档逐步操作，哪里卡住就改哪里。最老的一份磁盘扩容SOP被改了七个版本，现在连新来的实习生照着做都不会出错。
没什么高大上的理论，全是机柜前边蹲出来的汗和教训。就这么干，比写再漂亮的总结都管用。
- 想了解更多【工作总结】网的资讯，请访问：工作总结
