工作总结
发表时间：2026-04-212026年中公转正工作总结。
三个月试用期，说白了就是一场没完没了的“救火演习”。转正那天领导拍了拍我肩膀说“辛苦了”，我心里想的却是：这才哪到哪，系统里还埋着多少雷，我自己都没底。
说几个真刀真枪的事。
日志轮转那个斜杠，坑了整个团队三个月
入职第一周，我被分配去盯一套老旧的数据采集服务。说实话，头几天完全是告警驱动的活法——半夜三点磁盘写满，爬起来扩分区；早上七点CPU sys飙高，查出来是某个内核参数没优化。最让我崩溃的是，有个“/var/log 使用率超过90%”的告警，几乎每隔两天就来一次，每次都得手动删日志、重启服务。来回折腾了三四回，我实在忍不了了。
一个周五下午，我把过去三个月的告警历史全部拉出来，用awk统计了一下触发频率。结果你猜怎么着？光是这个磁盘告警就占了总告警量的40%，而且每次发生的时间点都差不多——凌晨两点到四点之间。这简直令人难以置信，同一个坑，团队每周要踩两回。
我翻进那台机器的/etc/logrotate.d/，看了一眼myservice的配置。问题简单得让人想骂人：轮转路径写的是/var/log/myservice/*.og，少了个“l”，应该是*.log。就这一个字符的差别，导致轮转从来没真正执行过。我当场改了配置，顺手用Python写了个小脚本，每天早上六点检查所有logrotate配置文件的语法，顺便扫描各分区日志目录的增长率，超过阈值就往钉钉群里丢一条警告。脚本很简单，核心就二十行，但跑起来之后，那个告警再也没出现过。
这件事让我明白一个道理：真正的运维不是比谁处理故障快，而是比谁能让故障根本不会发生。
一次504，让我学会了“先看日志再看人”
第二周周三下午两点半，业务方突然在群里炸了——API网关大量返回504。我当时的反应和所有人一样：先看网关自己的健康检查，正常；再看后端服务进程，也在跑；再看数据库连接池——好家伙，活跃连接数飙到了上限的两倍。我赶紧切到慢查询日志，抓到一条SQL，平时30毫秒，当天执行了12秒还没完。后来才知道，是运营部一个同事跑了个不带索引的全表统计，直接堵死了连接池。
从收到告警到定位根因，我用了9分钟。说实话，这9分钟里有6分钟是弯路——我先去查了nginx的连接数、看了网络重传率，甚至怀疑过交换机丢包。后来强迫自己冷静下来，按标准流程走：先看上游响应时间，再看数据库负载。找到那条慢查询后，我直接kill掉会话，临时调大连接池上限，业务在三分钟内恢复。
但真正让我在转正答辩里有底气说的，是后面补的三件事。第一，我给那张表加上了联合索引，把同类查询的执行时间压到50ms以内。第二，我在数据库中间件层配置了慢查询自动熔断——执行超过5秒的SQL直接拒绝，并且往运维群发一条告警。第三，我写了一个crontab，每天凌晨把慢查询日志里Query_time超过1秒的SQL汇总成报告，自动发邮件给开发组长。
这三件事做完后的第二周，同样的场景又出现了一次——有人跑了个不带索引的统计，但这次熔断机制直接在5秒后拒绝了请求，业务完全没受影响。我在复盘文档里专门记了一笔：“熔断阈值设5秒是因为观察过正常业务的P99响应时间是800ms，留了充足的余量。”这段细节后来被团队当成了模板。
换硬盘那次，差点把阵列搞崩
机房有一台存储节点亮黄灯，显示一块硬盘故障。按照标准流程，我应该先确认RAID状态，然后热插拔换盘，最后等重建完成。但我把旧盘拔出来之后，阵列卡突然报警，日志里出现“Unexpected sense”错误码，紧接着阵列卡把另一块健康盘也标记成了“Foreign”。当时我后背一下子就湿了——那台机器上跑着两百多G的日志数据，如果阵列崩了，恢复起来至少半天。
手边没有备用阵列卡，我不敢乱动。犹豫了五分钟，还是决定先别强制上线，老老实实去查厂商的官方文档。翻了半小时，在一个技术论坛的角落里找到一篇帖子，说这个型号的阵列卡固件有bug，热插拔时可能会误判，必须先升级固件再换盘。我按照步骤升级固件，重新插回旧盘，等阵列状态恢复正常，再换上新盘。重建过程花了四个小时，我就在机房里守着，每隔半小时看一次进度条，生怕再出幺蛾子。
这件事之后，我做了一个改变：每次做硬件变更之前，我会先把厂商手册里“异常处理”章节截图存到手机里，同时在工单上写明：“如果出现XX现象，执行YY步骤；如果出现ZZ现象，直接回滚。”看起来很啰嗦，但真正出事的时候，这种预演式的文档能救命。
几点没人教我的体会
这三个月的磕碰，让我对自己有了几个新认识。
第一，别信经验，信数据。以前我排查问题喜欢猜——“可能是网络抖动”、“大概是内存不够”。现在我会说：“从tcpdump抓包看，重传率是0.3%，正常；从vmstat看，si/so都是0，内存够用。”没有数据支撑的推测，在复盘会上就是废话。
第二，把解决问题的过程变成消除问题的流程。每次处理完一个故障，我会问自己三个问题：监控为什么没提前发现？代码或者配置能不能改成防呆的？操作手册里有没有漏掉这个分支？然后去推动对应的改进。三个月下来，我自己那个故障案例库里已经存了23个条目，每个都按“现象-根因-解法-预防”四列整理好。
第三，别怕跟开发扯皮，但要拿证据说话。有一次一个接口频繁超时，开发非说是网络问题。我没跟他吵，直接把网关日志里的upstream_connect_time和upstream_response_time拉出来，画了个折线图，证明是后端处理慢。对方看完没话说了，第二天就优化了代码。
转正了，但说实话我心里更不踏实了——系统越稳定，说明看不见的坑可能越深。不过也有点底气了，至少下次再出504，我有信心说：“给我十分钟，我先看一眼慢查询。”
- 想了解更多工作总结的资讯，请访问：工作总结
