工作总结

发表时间：2026-04-14

（精选）两年工作总结。

这两年，手机24小时不敢静音，半夜被叫醒是常态。说句实在话，干运维这行，最怕的不是故障本身，而是同一个故障穿上马甲再来一遍。下面几个场景，是我踩过最深、爬得最狼狈的坑，以及填坑之后留下的几条死规矩。

第一个坑：数据库连接池被“慢性毒药”拖死

去年双十一前一周，核心交易系统开始间歇性超时。监控上看，CPU、内存都正常，但数据库活跃连接数死死顶着上限。我心里第一反应是“又有人写烂SQL了”，可查了一圈慢查询日志，没什么异常流量。

这简直让人抓狂——代码没变，配置没变，压测也没问题，问题从哪冒出来的？

凌晨两点，我一个人蹲在工位，把应用日志翻到第3000行才发现：有个新上线的查询接口，在某个特定参数组合下会触发全表扫描。单次执行从50ms暴到8秒，更要命的是连接池的“超时回收”配成了-1（无限等待）。慢查询不释放连接，后续请求疯狂新建连接，把数据库的max_connections吃干榨净。

那会儿我一边在群里安抚业务说“十分钟恢复”，一边手抖着敲命令：
sql
SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE state = 'idle in transaction';

杀了200多个连接后，系统喘了口气。但第一次批量kill写错了条件，差点把主库事务也杀了——当时后背瞬间湿透。

紧急回滚接口，把连接池的maxWait从-1改成3000ms，系统才算稳住。事后我干了三件事：
1. 在MyBatis拦截器里加了慢查询熔断：执行超过1秒直接抛异常，并打印报警到钉钉。
2. 连接池参数重新算：统计了峰值QPS和平均事务耗时，用公式maxTotal = (峰值QPS * 平均耗时秒数) * 2 + 10，留足余量。
3. 每周日凌晨自动跑一次全量慢查询分析，按执行次数和平均耗时排序，直接发邮件给开发组。

这套机制上线后，又拦过7次类似问题。最长一次阻塞不到2秒，业务方根本没感觉到。

第二个坑：机柜维护时的“手滑”事故

有一次机柜扩容，要把一台老旧交换机的上行链路切到新设备。按规范，操作前要备份配置、标记线缆、申请变更窗口。但那天赶进度，我偷了个懒——没做线缆标记，直接拔线。更蠢的是，新交换机的VLAN配置漏掉了管理网段。

重启后，整个机柜26台服务器全部失联。那会儿真想抽自己一嘴巴——备用管理口的IP文档早就过期了，上面写的还是三年前的规划。

我蹲在机柜后面，一根根线缆去试，用笔记本直连串口。串口参数设成9600、8N1，连上之后发现波特率不对，又改成115200才进去。光找回配置就花了30分钟，恢复总用时40分钟。领导在群里问“怎么回事”，我只能回一句“物理操作失误，已恢复”。

那次之后，我给自己定了三条死规矩：
1. 拔线前必须拍照、贴临时标签（用标签机打印“上联-核心交换机G1/0/1”这种）。
2. 插线后必须ping测试，并在机架图数据库里更新。
3. 写了一份《现场操作防呆清单》，打印塑封挂在每个机柜门上。清单第4项是“备份配置到两台独立设备（U盘和笔记本本地）”，第7项是“拔线前用手机拍下端口指示灯状态”。上个月新同事按清单操作，果然发现一根光纤的TX灯不亮，提前换了模块，避免了一次事故。

这办法虽然笨，但过去一年零手滑事故。

第三个坑：幽灵故障——多线程竞态条件

有个批处理任务每周日凌晨2点跑，连续三周都出现“部分数据丢失”。日志显示处理到第100万条记录时抛出空指针，但重跑又能成功。

我花了两个晚上才找到根因：代码里用了一个共享的HashMap做临时缓存，多线程下没加锁。但奇怪的是测试环境从没复现过——后来才发现测试机是2核，生产是16核，并发度一高，哈希冲突导致竞态条件暴露。

迷你日记网知识盛宴精选:

两年学习工作思想总结 | 中职两年思想总结 | 个人近两年思想总结 | 近两年的工作和思想总结 | 两年工作总结 | 两年工作总结

更让人后背发凉的是，这个批处理已经跑了两年，之前没出问题是因为数据量一直没到100万。当第100万条记录恰好触发哈希冲突时，问题才炸出来。

我把代码改成了ConcurrentHashMap，并加了一层层日志。但这件事让我意识到：功能测试根本不够，必须主动搞破坏。

我推动建立了故障注入演练机制。第一次演练时，用ChaosBlade给一个核心服务注入CPU满载，阈值设到90%。结果熔断没触发——因为熔断判断的是“5分钟内平均负载”，而注入是瞬时冲击。那次演练直接导致三个真实业务的接口超时，我被leader骂了一顿。

后来改成了滑动窗口+瞬时峰值双条件判断。现在每月低峰期做一次演练，模拟网络延迟、磁盘写满、进程被kill等场景。第一次演练系统挂了3次，现在MTTR从原来的25分钟降到了6分钟。这个数据是真实故障的统计，不是演练数据——我们每次生产故障都记录恢复时间，取最近三个月的平均值。

两点实在的感悟

第一，文档别写“大而全”，要写“小而狠”。我把自己经手的32次故障都整理成了“病历卡”，每张卡分四栏：现象、根因、止血命令、根治方案。新同事来了，我直接扔给他这份文档，要求必须用虚拟机复现其中至少5个故障的处理过程。现在他处理同类问题的时间从平均2小时缩短到20分钟。

第二，别信经验。有段时间我自认为对TCP调优很在行，结果一次丢包排查，我调了两个小时的tcp_rmem、tcp_wmem，最后发现是光纤模块功率衰减。现在我的原则是：任何故障，先用ethtool看光模块参数、用mtr看路由、用ping看丢包率，物理层没毛病再动协议栈。顺序错了，就是浪费时间。

这两年，我最大的变化是从“救火队员”变成“防火员”。说白了，就是同一个坑别摔两次，摔了也得把坑填上，最好再立个牌子提醒别人。下一步想写个巡检脚本，每天凌晨自动跑“连接池使用率、慢查询数量、僵尸进程、磁盘预分配”四项，结果直接发钉钉。目前已经写了200行shell，卡在怎么处理浮动IP的场景——这事估计还得折腾两周。

推荐阅读:

想了解更多工作总结的资讯，请访问：工作总结

热门标签:

总工会两年个人工作总结

写两年的作文

两年监外执行思想总结