工作总结
发表时间：2026-04-28转正工作总结[2026借鉴]。
从入职到现在三个多月，岗位是运维工程师，直属我们系统保障组，一共6个人。试用期考核指标有三条：故障首次响应≤5分钟、系统可用性≥99.99%、上线变更零事故。现在回头看，三条都踩线过了，但也捅过篓子。下面把几个真刀真枪的案例拆开讲，重点是团队怎么配合、跨部门怎么协作，以及我踩过的坑。
先说入职第二周那个交易接口超时的事。周五下午三点半，业务群炸了——核心交易接口耗时从200ms飙到3秒多，客户电话已经打到运营总监那。我当时正跟着组长熟悉监控大盘，看到告警直接跳上堡垒机。按我们组的SOP：先看四台应用服务器的CPU和内存，都正常；再看中间件，RocketMQ里积压了一万多条消息；最后追到数据库连接池，有个查询把128个连接吃掉了119个。定位到是某条统计SQL没走索引，关联了七张表。开发那边反馈说“今天上午上线了新报表功能”，DBA在群里回了一句“这SQL谁写的？”
说实话，我当时心跳过百，手没抖但脑子在转。按流程，这种事应该先汇报组长。我当场给组长打电话，他说“你来判断，我信你，但降级操作必须通过我确认”。我先在网关层（Spring Cloud Gateway）写了条路由规则，把/report/**的请求全部转发到一个只返回{“code”:503,“msg”:“报表维护中”}的mock服务，耗时三十秒配置完，然后截屏发给组长，他秒回“执行”。降级生效后三分钟，交易接口耗时回到280ms。接下来DBA在线加了索引，开发改了SQL。事后复盘，我补了三样东西：一是把慢查询告警阈值从1秒改成500ms，二是推动上线前必须过SQL审核，三是写了个《限流降级一键脚本》发给组里。组长说我“动作快但流程差点”，后来每次操作我都先口头知会他再动手，这是学到的第一课。
再讲机房搬迁那个事。那是个周六凌晨，基建部门负责机柜和布线，我们运维负责设备上下架。我提前三天做了三件事：打印设备对应表、每条光纤和网线都缠了颜色标签（红-业务、蓝-管理、黄-存储）、把配置文件备份到两台不同机房的存储。搬过去上电后，两台存储扫不到盘。基建的说是存储HBA卡配置问题，存储工程师说“不可能，上架前刚测过”。我拿光功率计测了收发光，发现两路光纤有一路衰减达到18dB，远超标。我跟基建领班说“弯曲半径可能小了，国标要求不低于30mm”。他有点不耐烦：“我们一直这么布线的。”我没争，直接翻出国标GB/T 50312-2016那一页给他看。他沉默了两秒，说“换跳线试试”。但库房没有同型号的长跳线，最后是在桥架里重新理线，用理线架固定了弯折处，花了四十多分钟才恢复。质量验收一次性通过。这件事让我明白：跨部门协作，光态度软没用，得手里有标准和数据。后来我把《设备上架工艺自查表》整理出来，把光纤弯曲半径、电源冗余、网口自协商关闭等十几个检查项全列上，发给运维和基建共享。组长说这个表可以放到部门Wiki里当规范。
试用期内我总共处理了23起告警事件，独立负责8起，参与上线变更4次，写了6份运维文档，值班累计168小时。数据都来自我们组的工单系统，可以查。但有次自己搞砸了——上个月那个缓存穿透事故。我配置Redis缓存时，把一批热点key的过期时间都设成了整点后5分钟。结果同一秒内几百个key同时失效，所有请求打到数据库，连接池瞬间打满，应用连续报错三分钟。我第一时间发现，临时方案是把这批key的过期时间改成随机偏移（180-300秒），两分钟后恢复。但DB已经被打了一波读压力，峰值QPS冲到平时的15倍。事后我主动在组里做了事故复盘，承认是设计失误，然后花了一个周末写了份《缓存设计避坑手册》，内容包括：设置随机过期、空值缓存、布隆过滤器防穿透，以及要用SETEX而不是EXPIRE+SET保证原子性。组长说“认错态度可以，但要记住疼”。我把手册贴到团队知识库，后来又帮测试组做了两次缓存压测。
对了，还要感谢我师傅老周。有两次凌晨的磁盘告警，我判断不准是硬件故障还是文件系统问题，都是先打他电话。他从来不会直接给答案，而是说“你先看dmesg，再看smartctl，把输出发我”。两次都是他自己爬起来看了日志，再远程指导我处理。事后他把排查步骤整理成《磁盘故障三板斧》贴到群里。这种带法，比我自己啃文档快十倍。
转正之后，我给自己列了三条：一是把自愈脚本再补几个场景，比如缓存击穿自动加布隆过滤器；二是每两周跟开发、测试做一次变更预演，把沟通成本降下来；三是下季度争取把故障平均恢复时间从12分钟压到8分钟以内。不喊口号，就盯监控、写脚本、画拓扑。转正只是换了个工牌，活还是那个活，但责任更实了。
- 为了您方便浏览更多的工作总结网内容，请访问工作总结
