工作总结
时间：2026-04-052026年IT技术支持年终个人工作总结。
又是一年年终。干我们这行的，说好听的叫“保障业务连续性”，说难听点就是给全公司擦屁股。今年跟去年最大的差别，是我终于不再天天当救火队员了。不是说火少了，而是我开始琢磨怎么让火自己烧不起来。
先交个底：全年处理工单487个，其中紧急故障67起，硬件更换22次，系统重装15台。跟去年比，工单量降了12%，但紧急故障少了将近一半——去年这个时候紧急故障是112起。这组数据是我自己拉的，没领导要求，就是想看看一年忙下来到底有没有进步。
改变从备件管理开始。去年有三次硬盘故障，每次都折腾超过8小时。最操蛋的一次，半夜RAID卡报警，我到机房发现备件抽屉里躺着三块盘，没有一块能直接用——型号对不上，固件版本也不一致。打电话给供应商，人家说“明天下午送到”。第二天业务部门开会，财务总监拍着桌子问“为什么一个硬盘坏了一天都修不好”，我当时真想回一句“你问我我问谁”。但这话不能说，只能咽下去。
今年我把备件全部重新梳理了一遍。不只是按型号分类，而是给每块盘贴了个二维码标签，扫码能跳到一个内网页面，上面写着：适用于哪几台服务器、磁盘阵列级别是什么、热备盘策略怎么做、更换后要不要手动触发重建。还做了个简单的Excel台账，谁拿走了哪块盘、什么时候拿的、用在哪台机器上，必须登记。这个事看起来简单，但真落实下去花了整整两周。不是技术难，是没人愿意配合。运维那帮人嫌麻烦，说“换块盘还要扫码登记，至于吗”。直到三月份那次深夜故障，他们才闭嘴。
那是三月底的一个晚上，财务部的HP DL380报“Predictive Failure”。我看日志是Slot 2的600G SAS盘快挂了。搁去年，我会先翻半天台账，找不到盘再打电话问，问完再等采购。但这次我从机柜侧面的备件抽屉里拿出一块盘，扫二维码确认型号匹配、固件版本一致，然后进iLO看RAID状态——热备盘已经顶上去了。用hpssacli把新盘加入阵列，手动触发重建。整个过程37分钟。说实话，不是因为我多厉害，是因为流程顺了。财务第二天上班完全没感觉，这就对了。故障处理最高境界就是让用户感觉不到发生过故障。
但也不是每次都这么顺。五月份那次就翻车了。一台编译服务器报内存CE错误，我按流程换了内存条，跑MemTest86没问题，就关单了。结果一周后又报同样的错。我再查日志，发现不是内存本身的问题，是CPU内存控制器的一个针脚氧化了，接触不良导致的间歇性CE错误。这玩意儿换CPU才能根治，但生产环境不能随便重启。最后我用了一个土办法：在BIOS里把那个内存通道降速到1066MHz，错误率直接降了90%。这不算标准方案，但管用。我把这个案例写进了知识库，备注了四个字：“备而不用”。意思是，标准流程解决不了的时候，你得有点歪招。
监控系统也是今年的大工程。之前的Zabbix配了三百多个监控项，但有效告警率不到40%。凌晨三点经常被“CPU负载过高”这种垃圾告警吵醒，爬起来一看，是编译服务器在正常干活。我骂了半年，最后实在忍不了了，花了两个周末把所有监控策略重做了一遍。
具体怎么做的？我把服务器分了三类：交易类、批处理类、基础架构类。交易类服务器不看load average，盯着run queue里等待调度的进程数，超过CPU核心数的1.5倍才报警。批处理类看15分钟平均负载的变化率，五分钟内从2.0飙到15.0才报——这种陡升说明有任务异常。基础架构类最简单，就看硬件传感器温度、风扇转速、电源冗余状态。调完之后，告警量从每天200多条降到15条左右。 www.ZY185.COm
但这里头有个坑，我得说实话。第一版调完，有一台批处理服务器还是天天误报。那台机器跑的是夜间数据清洗任务，负载波动特别大，有时候十分钟内从1.0跳到12.0，然后又掉下来。我按“五分钟内变化率”设的阈值根本压不住。后来我想了个办法，把这台机器的监控策略单独拎出来，用了动态基线——取过去七天同时段的负载平均值作为基准，超过3倍标准差才报警。这才算彻底搞定。如果我不说这段，你可能觉得我一次就成功了，其实不是，中间返过一次工。
-
✹范文资源网精选精华:
- IT技术支持工作总结 | 技术支持工作总结 | 基因检测技术支持工作总结 | 技术支持年度工作总结 | it技术支持年终个人工作总结 | it技术支持年终个人工作总结
暴雨那晚的事我就不细说了，机房空调故障，监控只报了一条告警，没有刷屏。运维经理打电话来说“这次监控立功了”，我心里想的是，立功的不是监控，是我那两周周末加班。
团队培训这块，最让我头疼。我组织了三次Linux排障培训，讲strace、perf、systemtap，来的人一次比一次少。有个小伙子直接跟我说：“哥，我用top看够了，学那些有什么用？”我当时挺无奈的，但不能发火。后来我换了个法子：每周随机抽一台服务器，我手动制造一个故障——比如把/var/log写满、改sshd_config后不重载服务、用fork炸弹把进程数打爆——然后谁先定位到问题并修复，当周不用写运维日志。这招真管用。三个月下来，团队平均故障定位时间从25分钟降到了9分钟。但说实话，这个过程让我挺挫败的，因为我发现很多人不是学不会，是不愿意主动学。你得拿鞭子抽着走。
说说明年的打算。我准备把精力放在自动化巡检上。今年很多故障还是被动发现，等用户投诉了才去查。我想做一个基于硬盘SMART数据、内存CE错误率、网卡丢包率的预测性维护脚本，用Prometheus采集数据，再写几条简单的异常检测规则。不搞什么机器学习，那玩意儿我不熟，也没必要。就是阈值加趋势判断，比如“过去7天重分配扇区数持续增长，且日增长率超过5%”，就发预警。这事能不能成不好说，但至少先把数据采起来。
-
想了解更多【工作总结】网的资讯，请访问：工作总结
