工作总结

发表时间：2026-04-19

2026年建设银行个人工作总结。

干一线运维这些年，我有个很深的体会：系统不出事的时候，没人觉得你重要；一出事，第一个找的就是你。所以我的工作逻辑很简单——把问题摁死在冒头之前，万一真冒了头，也得最快速度按下去。下面是我这一年的干活笔记，全是真碰过的钉子，没有漂亮话。

1. 那次ATM“吞卡”的破事，让我重新认识了温度

年初，一个离行式自助点的存取款一体机频繁报“现金模块通讯超时”。第一次去，断电重启，好了。两小时后电话又响。第二次去，换数据线，刷固件，管了半天。第三次，我差点把主板换了。

说实话，那几天我走路都在想这破机器到底什么毛病。第四次去，我没急着动手，搬了把椅子坐旁边，盯着它的自检流程。突然发现一个细节：设备启动后，内部温度读数从32度飙升到58度只用了几分钟。拿测温枪一扫机芯仓，好家伙，散热风扇转速只有标称的一半。风道堵了厚厚一层灰，热量散不出去，控制芯片热得不干活了。

我没只换风扇。按施工规范，拆了整块主板，用压缩空气把每个散热鳍片吹透，还在机柜侧面加了一个辅助排风扇，专门调了风道方向。同时改了巡检项——以后每次巡检必须用红外测温枪打一下机柜内温度，记在台账上。这套搞完，那台机器再也没犯过老毛病。后来我把这个案例写进了《常见故障排除手册》，加了一条：“凡是通讯类偶发故障，先看温度，再看信号，最后才动主板。”这顺序能省你半天时间。

2. 那次磁盘写满，差点酿成生产事故

二季度，核心业务系统的一个日志分区突然100%写满。交易响应从毫秒级掉到秒级，柜员那边已经开始骂了。我紧急扩了空间、清旧日志，15分钟后恢复。但这事不能就这么过去。

复盘时我发现，日志轮转策略还是五年前的配置——每天凌晨轮转，保留7天。现在业务量是五年的四倍，7天的日志就有200多G。更蠢的是，监控只告警磁盘使用率超过90%，但告警发出来的时候，往往已经来不及了。

我干了两件事。第一，改成每小时轮转一次，保留3天热数据，压缩后转储到备份服务器保留90天。第二，写了一个自动清理脚本，每15分钟跑一次，检查使用率超过85%就自动删除最老的归档日志，同时发一条预警到运维群。脚本部署后，磁盘告警从每周平均4次降到了0次，连续跑了三个月没出问题。这让我意识到，很多所谓的“突发故障”，其实是慢性病拖出来的。你只要肯花半天时间把历史数据翻一遍，总能找到规律。

3. 那次和业务部门“扯皮”，我学会了用数据说话

有一次，业务部门投诉某报表系统“慢得没法用”，说我们运维没搞好网络。我ping了一下，延迟正常。查服务器负载，CPU、内存都低。最后翻应用日志，发现一个查询语句每次要扫描300万行数据。

我把这条SQL拖出来，放到测试库上一跑，果然是全表扫描。截图、执行计划、耗时统计，三样东西打包发邮件给业务部门，附了一句：“这个查询建议加个索引，或者改一下查询条件。现在这写法，换什么网络都快不起来。”业务那边刚开始还不认，说以前都能用。我直接把去年同期的日志拉出来对比——那时候数据量才80万行，现在300万行，当然慢。数据摆在那，他们没话说了，老老实实找开发加索引。

这事之后，我养成了一个习惯：凡是接到性能投诉，第一件事不是解释，是拿数据。数据比嘴巴管用一万倍。

4. 那次误操作，让我永远改了操作规范

说起来丢人。去年有一次，我要在测试环境重启一个服务，结果ssh窗口开多了，一顿操作猛如虎，重启的是生产环境的日志采集器。十几秒后，监控大屏上那个网点断联了。我当时后背一下就湿了。

✹读书笔记吧精品索引: