工作总结
发布时间：2026-04-222026年试用期工作总结。
报账三个月，光故障单我就签了四十六张。系统稳定运行时长从刚接手时的98.5%拉到了99.9%以上，看着还行，但每涨零点一个点，背后都是一宿没睡的折腾。
说个最让我后怕的事。入职第二周，生产环境Redis连接池泄漏，用户登录大面积超时。我冲上去第一反应是看网络，ping了一圈网关，丢包率正常。再看CPU、内存，都没冒尖。折腾了快一个小时，最后是在慢查询日志里逮到一条接口调用次数异常高，单机每秒请求两千多次，每个请求都新建一个Redis连接，但就是不释放。代码是离职同事写的，接手时文档就一句“使用连接池”，具体实现是黑盒。
当时业务方已经在群里炸了，运营总监直接@我老板：“还能不能用了？”我手都在抖，但脑子清楚——必须先恢复。我手动kill掉应用进程，重启，把连接池上限从20临时调到80，再给那个接口加了一层限流。三分钟后，登录恢复了。事后我看日志，那一小时里共有四千七百多个用户登录失败。
但真正的麻烦在第二天。开发负责人跑过来跟我说，这代码之前review过没问题，是我运维配置不对。我直接把代码反编译出来的截图甩他桌上——finally块里根本没有jedis.close()。他脸色变了，又嘴硬说测试环境跑得好好的。我怼回去：“测试环境并发才几十，当然跑得起来。你要不要看看生产环境的监控数据？”后来我们俩吵到技术总监那儿，总监拍板：所有涉及连接池的代码必须走静态扫描，CI里挂了SpotBugs规则，不通过不让合并。
这事之后我自己也反思：如果我入职第一天就把所有外部资源调用过一遍，也许能提前发现。但我没做到。所以我给自己定了个死规矩——每个新接手系统，先把它的连接池、线程池、文件句柄这三样东西的监控配好，设好阈值，不等出问题再查。
还有一次，不是大故障，但特别丢人。表结构变更，开发给了个SQL脚本，加三个字段重建一个索引。我在测试环境跑了一遍，十几秒完事。凌晨两点上生产，直接复制粘贴执行，结果生产那张表有一千两百万行数据，是测试环境的二百倍。重建索引跑了四十分钟，期间表锁死，关联业务全等着。我蹲在机房里，手机震个不停，但不敢接。最后总算跑完了，业务恢复，但我整个人虚脱了一样。
第二天写事故报告，我把自己骂了一通——为什么不在执行前先查一下表大小？为什么不做并行度评估？后来我写了个小脚本，每次变更前自动拉取表的行数和数据量，估算执行时间，超过三分钟的直接标红，必须申请变更窗口延长。同时强制要求所有索引重建必须加上ALGORITHM=INSTANT或者LOCK=NONE，测试环境还得用真实数据量（脱敏后）跑一遍。打那以后，表变更再没出过长时间锁表。
说个差点失败的例子。上个月某天凌晨，日志服务器磁盘写满，导致整个日志链路堵死。我到现场一看，一个服务的错误堆栈每秒打印两百多条，一小时写了16GB日志。我当时的处理是：先删日志，重启服务，加频率限制。但删的时候手快了，没先备份。结果事后复盘时发现，那个错误堆栈里藏着一个关键的空指针异常信息，被我删了，查了三天才从别的节点上拼凑出来。这事让我记住一条：不管多急，先tar一份现场日志到备份目录，再动手删。现在我的运维工具包里多了一条命令，叫“emergency_backup.sh”，每次遇到磁盘告警自动跑。
这三个月的报账，说白了就是把坑一个个踩过去，然后填上，再立个牌子告诉后来人“这儿有坑”。我整理了六份事故简报，每份不超过一页，包含现象、根因、处理步骤、防止复现。最近新来的同事说看了这些简报，省了他不少瞎摸索的时间。
试用期过了，但运维这行没有“毕业”一说。接下来我想把那些还得靠人盯着的东西——比如连接数突增、日志速率异常、慢SQL堆积——全部用自动化检查替代。不是为了偷懒，是人真盯不住那么多东西。下次再写总结，希望能少几个“当时手抖”的瞬间，多几个“早就防住了”的底气。
-
欲了解工作总结网的更多内容，可以访问：工作总结
