工作总结

发表时间：2026-04-14

2026年程序员试用期员工工作总结。

三个月，47个工单，12次系统变更，3次故障复盘。这些数字背后，有7个凌晨两点被叫醒的夜晚，也有2次因为自己手贱差点搞出二次故障的教训。

先看KPI。故障响应时长从入职第一周的12分钟降到了现在的4分钟以内，系统可用性维持在99.97%。但说实话，这个“4分钟”有水分——我压的不是处理问题的速度，而是告警配置的精准度。第一个月我经常被无效告警轰炸，半夜爬起来发现只是某台备机的CPU毛刺。后来花了两个周末，把所有阈值重新过了一遍，该合并的合并，该删的删。告警量从日均150条降到40条，真正需要人工介入的不到10条。这才是响应时长下降的真实原因，不是因为我手变快了。

入职第二周那个凌晨故障，到现在想起来还觉得后背发凉。核心订单系统接口响应从50ms飙到3秒，支付回调积压。我账号权限都没捂热，值班师兄在忙另一个库的死锁，我只能自己上。第一步切流量，把异常节点的nginx摘掉——这是入职培训教的，不管什么故障，先止血。系统回到200ms，但我知道只是躲过去了。登录那台机器，top看CPU正常，ss -s显示TIME_WAIT接近5万。顺藤摸瓜查代码，发现调用下游会员服务的HTTP连接池没开keepalive，每次请求都新建连接。流量一上来，端口耗尽，线程全卡住。临时方案是在nginx侧开upstream keepalive，但这个改动得走变更审批。凌晨三点，我打电话叫醒了负责nginx配置的DBA，两个人对了一遍回滚方案，才敢在灰度节点上先试。观察了20分钟，确认积压下降，才全量。那天早上七点下班，我在工位上坐了很久——如果当时切流后直接去查日志而不是看连接数，可能要多花半小时。后来我把“查看TIME_WAIT和CLOSE_WAIT”写进了故障处理第一步的checklist。

日常巡检里有个事让我印象特别深。某天扫Zabbix，发现一台缓存服务的内存使用率每天早上八点准时出现锯齿状波动，幅度20%。这不是正常业务曲线的样子。查了最近一周的变更记录，有人提了一个单子，写着“优化缓存命中率”，没具体说改了什么。我找开发要了配置备份，对比发现他把淘汰策略从LRU换成了LFU。早高峰新数据涌入，LFU要维护频率计数器，内存申请和释放频率变高。改回LRU后锯齿消失。我跟组长提议，变更单里必须附上修改前后的参数对比和预期影响，不写清楚就不给合入。这个规矩现在已经执行了。

还有一次磁盘告警，/var/log分区使用率85%。常规操作是删旧日志，但我多看了一眼，发现error.log从凌晨开始每分钟写300行“Failed to obtain lock”。查下去，是某个定时任务在分布式环境下没做好锁竞争的重试机制。如果只删日志，下周还回来。我联系开发改了调度逻辑，加了随机退避重试，又写了个logrotate预处理脚本，专门压缩超过500MB的日志文件。分区使用率从85%降到了32%，之后一个月没再告警。

试用期里干过一件蠢事。有次做变更，批量重启一批缓存节点，我脚本里写的rm -rf /var/cache/app/*，但变量拼接时因为某个环境变量没传进去，变成了rm -rf /var/cache/app/（注意最后的空格和斜杠）。幸好我有个习惯——所有rm操作之前先跑ls确认路径。那一瞬间看到ls /var/cache/app/列出的目录不对劲，赶紧ctrl+c。如果晚半秒，删的就是整个/var/cache。从那以后，我所有删除脚本都强制要求用绝对路径，并且第一行先set -u防止空变量。

跟开发扯皮是家常便饭。上个月一个数据库连接池泄漏的故障，开发说是运维的监控没提前发现。我没跟他吵，直接把最近一周的连接池使用率曲线拉出来，每天都有三次接近95%的尖刺，但我们的告警阈值设的是100%。这个阈值是我前任留下的，我接手后一直没改。那天下午我改了监控模板，连接池使用率到80%就预警，并且把泄漏点的代码片段（没关resultset）贴到了故障报告里。开发没话说了，第二天就发了修复版本。

【检讨书大全】年终大盘点特刊: