工作总结

2026-03-28 工作总结转正工作总结

员工转正工作总结（借鉴版）。

试用期最后一个月，我基本上把凌晨三点的告警短信当闹钟用了。不是因为系统烂，是我自己把阈值调得太敏感，第一周被误报折腾了三回。这事说起来有点蠢，但要不是这几回折腾，我可能到现在还跟以前一样，等到用户骂上门了才开始翻日志。

说回正事。这三个月我主要负责的是订单核心链路那块，说白了就是确保从用户点下“提交订单”到数据库落地的整个过程别出岔子。我刚接手的时候，这块业务的状态可以用八个字形容：被动响应，疲于奔命。告警配置是前任留下的，阈值宽得离谱，CPU飙到90%才报，磁盘满了才响。结果就是每次出问题，都是业务方先发现，我们后知后觉。

第一次让我觉得必须改的，是上个月那次库存校验的慢查询。那天上午十点多，运营群里突然炸了，说用户下单卡在“确认订单”那一步。我登上数据库一看，连接数爆了，将近两百个线程卡在同一个SQL上。按以前的习惯，我肯定先重启连接池，把业务续上再说。但那天不知道哪根筋搭错了，我忍住了，先看了一眼慢查询日志。

那条SQL长什么样我还记得：select stock from inventory where sku_id in (...) and warehouse_code like '%'，like前面带百分号，等于强制全表扫描。我当时的反应是，这谁写的，脑子呢。但骂归骂，活儿得干。我临时加了个联合索引，把warehouse_code的查询条件改成精确匹配，再重启连接池。前后折腾了将近四十分钟，那四十分钟里运营催了三次，领导在群里@了我两回。等负载降下来之后，我看了一眼监控，数据库CPU从82%掉到了11%出头。

这事之后我做了两件事。第一是把所有类似的慢查询扫了一遍，跟开发那边开了一次会，把那些明显不合理的地方列了个清单。第二是我把告警分级重新做了。以前磁盘85%告警、90%也告警、95%还告警，一个晚上能收二十多条，到最后人都麻木了。我现在改成：85%是P2，工作日处理；95%是P1，任何时候都得爬起来。改完那个星期，凌晨被吵醒的次数从四次降到了一次。那一次还是真的有问题，行锁升级导致的阻塞。

再讲一个，上周的Nginx超时。这个故障很恶心，不是一直有，是每隔三个小时左右出现一次，每次持续五到八分钟。最烦这种间歇性的，你盯着它的时候它好好的，你一转身它就犯病。我蹲了两天，第一天用strace抓了进程的系统调用，没抓到有用的。第二天换了思路，在服务器上开了tcpdump持续抓包，同时把Nginx的access log和error log按分钟切割。熬到凌晨两点多，终于抓到了一次。

当时我看到日志里有个规律：每次超时发生前五秒，都有同一个后端服务的响应时间突然飙到十几秒。我顺着这个线索追过去，发现那个服务在特定时间点会触发一个数据清理的定时任务，清理逻辑写得有问题，一次性删的数据量太大，导致数据库的行锁升级成了表锁。找到根因之后就好办了，跟开发那边商量，把清理改成分批提交，每次删五百条，sleep一秒。改完上线，观察了三天，那个超时再没出现过。

这两个案例让我想明白了一件事。以前我总觉得运维就是“保证系统别挂”，现在我觉得不光是这个。保证系统不挂是底线，但真正的价值在于你处理完一个问题之后，同样的问题不会再来第二回。我那个慢查询的案例，如果当时只重启不修索引，可能过两天又得折腾一回。同样，Nginx那个问题，如果只是加个超时时间，那数据清理的定时任务迟早还会惹别的麻烦。

当然，这三个月也不是一帆风顺。有一回我改负载均衡的转发规则，图省事，没走变更流程，直接在线上改了。第二天同事排查另一个问题的时候，绕了三个小时才发现是配置冲突。那之后我立了个规矩，不管多小的变动，哪怕只是改个参数，也必须在wiki上记一笔。后来有一次凌晨处理故障，我翻到之前记的变更记录，五分钟就定位了问题。那会儿心里想的是，幸亏当时没偷懒。

▲小学范文网编辑力荐: