工作总结

[优秀]运维个人工作总结。

这一年下来，翻翻工单系统，我经手的故障处理从去年的47次降到了31次，平均恢复时间从32分钟压缩到19分钟。数字好看，但真正让我心里有底的，不是这些平均数，是那几个差点让我通宵、最后靠提前准备没出事的案例。

一、故障处理的活儿，从“捞鱼”变成了“修网”

往年我是典型的“救火队员”——告警响了，远程连上去，top一看CPU飙红，重启服务，完事。第二天写报告，最后一句永远是“加强监控”。今年我不想再这么混了。

二季度，业务那边投诉说有个查询接口一到下午就卡，客户点个订单要转圈七八秒。我盯了三天，发现不是CPU问题，是Redis里一个库存大key。那个key存的是全站所有商品的库存JSON，串行化后快50MB了。每次查询，业务代码直接get整个key再反序列化，哪怕你只查一个商品。

搁以前，我会丢给开发说“你们改代码”。今年我换了个法子：我先在本地搭了一套一模一样的压测环境，把那个key导出来，写了个脚本模拟并发查询。压测结果甩过去——30个并发就把网关拖到超时。开发老大看了一眼，没吭声，第二天就排期改。他们改成hash结构，field是商品ID，value是单商品库存，查询时用HMGET只取需要的字段。上线后，我又在应用层加了本地缓存，Caffeine配置了5000个热商品，过期时间5分钟。最后那个接口的TP99从2.1秒掉到90毫秒。

说实话，这事儿给我最大的教训不是技术，是沟通。以前总觉得开发不配合，其实人家只是没看到直观证据。你光说“有性能问题”，谁理你？把数据、压测报告、火焰图堆他桌上，比什么都管用。

二、设备维护，我差点栽在一个“正常”的硬盘上

机房那批老存储阵列，用了快六年，厂商早不维护了。我们巡检一直靠手动：每周看一遍硬盘灯，每月跑一次smartctl -a。今年我闲下来的时候，写了几个Python脚本，从监控系统里把每块盘的IO延迟、重分配扇区数、指令超时计数每天拉一次，做了个简易基线——不是固定的阈值，是每块盘跟自己前30天的均值比。超过3倍标准差就发预警。

五月份，脚本报警说某块盘的读延迟从平均值4ms跳到了15ms。按厂商手册，15ms连警告线都没到。但那个盘的曲线是缓慢爬升的，不是突发波动。我跟同事说，这盘一个月内要挂。他不信，说“你太敏感了”。结果第11天，凌晨两点，那块盘正式报UNC读错误，但因为我们提前在热备盘上同步了数据，业务读写自动切过去了，用户零感知。第二天我把那个脚本的判定逻辑公开到团队群里，现在其他人也都在用。

那次之后我加了一条规矩：所有硬盘的“预期剩余寿命”不能光看SMART的百分比，必须看延迟和重分配扇区的变化率。说白了，设备跟人一样，生大病前总有点小征兆，关键是你能不能捕捉到。

三、布线验收那次，我跟施工队吵了一架

公司上边缘节点，二十多个机柜的综合布线外包出去了。验收那天，施工队长指着整整齐齐的扎带说，“你看，多漂亮”。我没搭理，掏出游标卡尺和红光笔。

标准规定光纤弯曲半径不能小于40mm，他有的地方折到35mm。我让他返工，他不服，说“差5mm能怎样”。我说，去年有个节点就是因为一根光纤折角太小，运行半年后衰减从0.2dB涨到0.9dB，导致跨机房同步天天丢包，我排查了两个通宵，最后拿OTDR打出来就是那个弯。他闭嘴了，重新盘了线。

我还测了每根光纤的衰减值。有一根链路OTDR显示0.45dB，比其他的高出一截。我让他换掉，他嫌麻烦。我说合同里写了“符合GR-409标准”，0.45dB虽然没超标准上限，但你看看前后两段的曲线——中间有个明显的小台阶，那是熔接点质量不行。后来他用显微镜一看，那个熔接点果然有气泡。换完再测，降到0.21dB。

这活儿干得累，但那个节点上线到现在快四个月，没出过一次物理层故障。相比之下，另一个没这么较真的节点，已经报修两次光纤中断了。

四、说一个我搞砸的事，长点记性

【每天帮】编辑们主动加班的动力:
• 运维转正个人工作总结 | 运维简短个人工作计划 | 网络运维工作总结 | 运维客服工作总结 | 运维个人工作总结 | 运维个人工作总结

八月份，我自作聪明调了一组内核参数。网上有篇帖子说“高性能网络模板”，我照着改了net.ipv4.tcp_tw_recycle和tcp_tw_reuse，还调低了tcp_keepalive_time。压测环境跑了三小时没问题，我就推到线上。

结果第二天上午，部分连接开始随机超时。抓包一看，TCP连接在TIME_WAIT状态被提前回收，导致新连接复用了旧连接的序列号，触发了对端的RST。业务方打电话来骂，我只能赶紧回滚参数，重启服务，折腾了一个小时才恢复。

复盘的时候我查了官方文档，才发现tcp_tw_recycle在NAT环境下就是颗雷，而且Linux 4.12之后内核已经把它废弃了。我当时看的那篇帖子是2015年的。从那以后，我定了个死规矩：任何内核参数调优，必须先查内核版本的官方文档，然后灰度上线——先上一台边缘节点，观察24小时，再看核心节点。

五、最后唠叨两句

这一年我最大的变化，是开始相信“预防比修复重要一万倍”。以前觉得写自动化脚本、建基线、较真验收标准，这些都是“额外的工作”。现在我想明白了，这些才是本职工作。故障处理得再漂亮，也是补救。

明年我打算把故障自愈的覆盖面再往上提。目前沉淀了23个常见故障的自动处理脚本，覆盖大概六成场景。剩下的四成里，有5个是因为业务代码改动频繁，脚本跟不上；有3个是硬件故障没法自愈；还有2个是我自己没想清楚怎么自动判断根因。这些坑，明年一个一个填。

那天凌晨四点，客户老李打电话来说谢谢的时候，我正蹲在机房冷通道的地板上，笔记本垫着机箱盖，旁边倒了三罐红牛。他说完就挂了，我也没多客气。但挂了电话我坐那儿愣了几秒——干运维的，图的不就是这句“没事了”吗。

推荐阅读: [优秀]运维个人工作总结 [全面]网络运维个人工作总结 运维转正个人工作总结（汇集十三篇） 运维简短个人工作计划（系列十一篇）

我们精彩推荐工作总结专题，静候访问专题：工作总结

热门标签: 运维客服工作总结 维稳个人工作总结 运维部资源工作总结 运维检修部工作总结 通信运维部工作总结 直播运维总结

本文来源：//www.mtb31.com/m/188665.html