工作总结
发表时间：2026-04-18总部三定工作总结。
三定方案下来的那天，我就知道接下来半年别想睡整觉。果然，文件还没捂热，业务系统的认证服务先炸了。
先说几个硬数字：这半年我们处理的告警事件总共47起，其中人为误操作11起，硬件故障8起，剩下全是配置或代码问题。故障响应时效从之前的平均23分钟压到了8分钟以内——这里解释一下“响应时效”的口径：从告警系统发出第一条通知，到有人在中控群里回一句“我来跟”，算作响应。8分钟听着还行，但说实话，有几次是我半夜被电话吵醒，闭着眼睛点的确认。
跨部门工单流转耗时降了42%，绝对值是从平均4.5小时压到2.6小时。为什么是这个数？因为三定期间团队职责切得碎，原来一张工单在A组签收完转B组，现在可能要在C组和D组之间再绕一圈。我后来干了一件事：把所有工单的流转节点画出来，哪个节点停留超过30分钟就标红，每天晨会只过这些红点。两周转下来，最慢的那个节点从90分钟砍到了15分钟。
客户满意度从62涨到78。这个分我是有疑问的——业务部门自己也在三定里折腾，他们对我们运维的预期可能本来就降低了。但不管怎么说，至少没人再骂“你们修个故障要半小时”了。
下面说一个具体的故障，你们感受一下三定期间的真实处境。
那天凌晨两点，告警刷屏：认证服务超时，大量用户登不上去。当时原负责认证的团队已经调走了大半，新团队的人连运维手册的目录都没背全。我第一反应不是打电话问谁负责，而是直接登录跳板机。查了Redis的连接池状态——info stats 一看，connected_clients 飙到了3800，而默认上限是4000。再查 client list ，发现大量连接来自同一个业务模块的IP，而且session的TTL全是-1。
代码里被人写死了 setMaxAge(-1) ，永不过期。加上三定期间临时给测试团队开了不少账号，连接池被活活吃死。
我当时干了几件事：第一，CONFIG SET maxclients 8000 临时扩容，然后重启认证服务，三分钟内登录恢复。第二，写了个Python脚本，逻辑很简单——每隔十分钟扫描Redis里所有以 session: 开头的key，检查TTL，如果是-1就删掉。扔到cron里跑。第三，截图那个业务模块的配置，发给开发负责人，要求当天重新走发布流程，把永不过期改成24小时。
第二天复盘，我把原团队、新团队、开发三方拉到一个群里，发了一张时间轴——每一分钟谁做了什么、系统指标长什么样。我问了一个问题：为什么永不过期的配置能通过测试环境？后来发现，测试环境的压测脚本只跑功能，从来不跑连接池耗尽。我们在混沌测试用例里补了一条：模拟一万个并发session，观察连接池回收机制。另外在运维规范里加了一条死规矩——所有涉及状态存储的配置变更，必须附带一张连接池容量评估表，写清楚预期连接数、峰值、回收策略，否则不准上线。
三定期间最大的坑不是技术，是责任真空。后来我定了一个临时规矩：谁第一个看见告警，谁就是临时负责人，不需要等任何人授权，直接动手恢复。等故障处理完了，再坐下来慢慢厘清归属。这套“先斩后奏”让三定期间的MTTR反而比平常低了15%。但也出过事——有个新同事太积极，把别人的正常变更当故障给回滚了。后来我们加了一步：动手前先在群里发一条“我准备操作X，有人反对吗？”等两分钟，没人吭声再动。
说完故障，说说设备维护和施工规范。
三定后机房里的物理设备重新划了归属，但标签还没换。有一次新同事去换硬盘，拔错了机器——幸好那是台备用的，上面没跑业务。我在周例会上没骂人，但当场定了一个检查清单：换任何硬件之前，必须做三步——1）拿手机扫设备上的二维码，系统自动读出设备名和槽位；2）人工核对机柜标签和面板贴纸；3）在监控系统里查一下该设备最近一次心跳时间，确认它确实是你要换的那台。三步做完，才允许拔线。
布线调整也是。我要求每个机柜提前画一张“物理连接拓扑图”，不是Visio那种好看的，而是手机拍一张机柜背面照片，用红笔在上面标出每根线的起点和终点，还要写上线的颜色和长度。验收的时候，拿着这张照片去机柜后面一根根对。有一回发现两根光纤交叉走线，虽然没影响业务，但按规矩就是不合格——重走。因为我知道，下次半夜查故障时，这种交叉线会让你多花两个小时捋线。
质量验收我坚持做破坏性测试。每次系统变更完，除了常规的功能验证，我会随机挑一台缓存节点，让人手动拔掉网线。三定期间有一次验收，新接手的同事拍胸脯说“全测过了”，我让他现场拔线——结果业务直接报错。后来发现负载均衡的健康检查配错了端口，一直在检查80端口，而实际业务端口是8080。那次之后，我们写进验收标准第一条：必须包含至少一种故障注入，不拔网线不算完。
设备维护这块，我搞了一个“健康度评分卡”。每台服务器每天根据十几个指标自动打分：磁盘的SMART属性、内存的CE计数、网卡的丢包率、系统日志里的link down次数等等。低于80分的进观察名单，低于60分的强制安排维护窗口。三定期间靠这个提前发现了三块SSD的坏块数在快速上升，抢在彻底报废之前换了，避免了两次可能的数据丢失。
再说说三定期间那些没法写在PPT里的事。
交接班。原来团队交接，口头说一句“没啥事”就走人了。三定期间我规定：所有未完结的工单，必须在交接记录里用红字标出——故障ID、当前状态、下一步动作、卡住的原因。接班的人如果发现红字记录不全，有权拒绝交接。第一个月有个人被拒了三次，后来老实了。
和开发团队吵架。有一次，业务方非要周日上线一个新功能，我一看变更内容，涉及到三个核心库的表结构变更，回滚方案只写了一行“不行就改回去”。我说不行，等周一有完整值班人手再说。对方组长在群里说“你们运维就是怕担责任”。我回了一句“对，我怕。我怕周日凌晨三点你接不到电话”。后来折中了一下：周日下午四点，我给他开一个预发环境，先灰度跑两小时，观察完没问题，周一早上八点再上生产。那天下午五点半，预发环境挂了——新功能里有个死循环，把连接池又吃满了。对方组长没再说话。
那0.01%的可用性丢失，我也得交代清楚。一次计划内的负载均衡切换，按标准流程应该先切10%流量，观察十分钟。那天是凌晨，我心想“都老手了，快一点吧”，直接切了50%。结果新实例的JVM参数没调好，新生代太小，Full GC频繁，导致部分请求超时。五分钟之内我回滚了，但超时已经发生了。这事后来复盘，根本原因不是参数问题——而是我跳过了流程。我在变更单上自己给自己记了一笔违规，然后加了一道硬约束：所有灰度操作，必须在系统里勾选“已执行10%验证”，系统才会开放50%的按钮。一个人说了不算，系统说了算。
三定结束了，我工位抽屉里多了三盒润喉糖——跟新团队吼的。但说实话，这半年也让我想明白一件事：运维的稳定不是靠个人英雄主义，是靠每一道流程里都有人较真，而且那个较真的人不一定是老员工，可能是刚入职两周的新人——只要他手里有一份能照着做的检查清单，有一张没人敢跳过的验收标准。
-
想了解更多工作总结的资讯，请访问：工作总结
