工作总结
运维个人年终工作总结及明年工作计划。
又到年底。今年是我干运维的第七年，说实在的，这行干久了，最怕的不是出故障，而是出了故障找不到根儿。今年碰上的几件事，有的让我后怕，有的让我憋屈，有的让我半夜坐起来想“当时要是……就好了”。挑三个最典型的说说，算给自己交个底。
一、三月的那个“午后卡死”——连接池泄漏，我差点冤枉了数据库
3月15日，周三，下午两点刚过。业务方在群里甩了张截图：系统响应时间从80ms飙到12秒，接着就是一片“超时”“请稍后重试”。这套系统跑了一年多，最近三个月业务量涨了40%，但监控一直正常。开发老张私聊我：“是不是数据库扛不住了？我看慢查询日志里有几条扫描了20万行。”我没接话，先去看了数据库的活跃连接数——50个上限，全满。但慢查询日志里那些SQL执行都在20ms以内，CPU也只用了15%。这不合理。
我决定现场抓。连续两天下午两点半蹲在服务器前，用jstack打线程堆栈，发现大量http-nio线程卡在prepareStatement上。jmap dump堆内存，用MAT一分析，HikariProxyConnection对象数量超过2000，但活跃连接只有35。这意味着连接借出去了没还。当时心里骂了一句：又是代码没关连接。
定位到批量导入Excel那个模块。开发用了try-with-resources包了Statement，但循环里查了ResultSet没关，更隐蔽的是——如果业务校验抛异常，catch块只记了个日志，根本没调connection.close()。HikariCP默认泄漏检测是关的，连接只借不还，池子就不断新建，直到把上限撑爆。
那天晚上我改了三处配置：开启leakDetectionThreshold=10000，临时把最大连接数从50提到80保证业务不崩；然后写了段压测脚本，模拟并发导入，把异常路径也覆盖进去。最后跟开发定了条死规矩：所有涉及数据库操作的PR，必须显式关闭ResultSet和Connection，finally块里不能只有log。
修复后上线那个凌晨，我盯着监控面板看了四十分钟，连接数从78慢慢降到43，最后稳定在28。第二天业务方在群里说“下午没卡”，我回了个“收到”。其实心里松了口气——这个故障让财务对账晚了三天，业务负责人差点在周会上拍桌子。要是再拖一周，我估计得写检讨。
二、七月的那个周六下午——机房42℃，干冰和风扇救了场
7月17日，下午两点半，我刚带孩子上完兴趣班，手机连续震了五下——机房温度告警，42℃。当时脑子嗡了一下：核心交换机和数据库服务器的上限是40℃，再升就要过热关机。我一边往单位跑一边打电话给值班同事。他说空调压缩机烧了，备用空调去年报废后一直没买新的。
我到现场时温度已经45℃。两台存储节点开始报警降速，机柜后面热得像桑拿房。常规方案是等维修或运新空调，但至少要两个小时。我等不了。突然想起库房有两台工业风扇和几块干冰——之前冷链设备留下的。我让同事把所有机柜前门打开，风扇对着进风口猛吹，同时把干冰砸碎放在金属托盘里推进机柜间的通道。干冰升华吸热，十分钟内温度降到38℃。
但干冰只能撑四十分钟。我一边盯着温度曲线一边算时间，同时联系行政从食堂搬来三台移动式蒸发冷风扇，加冰晶接力降温。干冰化完的那十几分钟，我蹲在机柜后面，手里攥着湿毛巾给电源模块物理降温，每隔三十秒看一眼温度，心里默念“千万别跳闸”。下午四点零三分，维修人员换好压缩机，空调恢复。全程零宕机，只是业务抖了几下。
事后我写了份《高温应急操作手册》，把风扇怎么摆、干冰用多少、冰块替代方案全写进去。同时推动采购部门年底前装好备用空调，还加了三级温度告警：45℃红色紧急、40℃橙色预警、35℃黄色注意。有人问我“干冰哪来的”，我说是冷链废料，但建议明年正式配气溶胶降温装置——提案已经过了。
三、九月的那笔“差8小时”的账——环境差异让我吃了大亏
9月22日，财务月底结账，发现部分跨天交易的时间戳差了8小时。开发在测试环境死活复现不出来，怀疑数据库时区。我查了：数据库UTC+8，应用服务器Asia/Shanghai，没问题。折腾了两天，我把生产环境和测试环境的JDK版本号对了一下——生产是1.8.0_202，测试是1.8.0_291。查了Oracle release notes，发现_291修复了一个TimeZone缓存bug。
- ★好读后hdH765.CoM内容组内部传阅清单:
- 后勤个人年终工作计划 | 个人年终工作计划部队 | 酒店个人年终工作总结 | 记者个人年终工作总结 | 运维个人年终工作总结 | 运维个人年终工作总结
复现条件极其苛刻：只有某个旧版客户端App（v2.3.1）会用new Date()直接存MySQL，而驱动版本5.1.40的连接串里少了serverTimezone=Asia/Shanghai。服务端在解析时误用了JVM默认时区（UTC）转成字符串再存，一来一回差了8小时。我花了两个晚上写单元测试，强制TimeZone.setDefault(TimeZone.getTimeZone("UTC"))才模拟出来。
那周我建了个“环境差异台账”，把所有依赖组件的版本——JDK、驱动、中间件——在生产、测试、开发三套环境里对齐，写了个脚本每天自动对比。以后再有人跟我说“测试环境没问题”，我就先跑脚本。
解决方案：升级MySQL驱动到8.0.16，连接串强制指定时区；接口层统一用LocalDateTime代替Date，所有时间存之前先转UTC。这活干了三天，改了四十几个文件，回归测试差点出岔子——有个报表依赖旧时区逻辑，临时加了适配。教训是：别信“没问题”，信日志、信版本号、信复现步骤。
明年要干的几件事
不说虚的，就五件：
- 故障演练每季度一次：春节前先搞一次模拟空调全停，实测风扇加冰块能撑多久，顺便把干冰供应商的联系方式存到应急通讯录里。
- 全链路监控补全：3月前接入SkyWalking，确保每个请求从网关到数据库都能用TraceId串起来。开发那边已经答应配合改日志格式。
- 两台核心交换机替换：Q2完成。预算批了，如果供货延迟，备选方案是拿一台旧设备做冷备，手动切流。
- 环境差异台账自动化：脚本每天跑，差异项自动发邮件给开发和运维群。目标是不再出现“复现不了”这种话。
- 个人考证：把CKS（Kubernetes安全专家）拿下。今年容器化两次权限配置问题，不能再靠临时查文档了。
做运维第七年，最大的体会是：系统不出事的时候没人记得你，一出事全盯着你。但说实话，最踏实的瞬间不是解决了一个大故障，而是凌晨两点手机没响。明年继续盯连接数、盯温度、盯时区，把“可能出事”变成“有预案、能兜底”。
- 推荐阅读: 运维个人年终工作总结及明年工作计划 护士个人年终工作总结及明年工作计划（热门十二篇） 客服个人年终工作总结及明年工作计划（经典10篇） 酒店个人年终工作总结及明年工作计划(精选12篇) 2025部门个人年终工作总结及明年工作计划(系列十四篇)
- 需要更多的工作总结网内容，请访问至：工作总结
