工作总结
2026-04-17 工作总结 主管工作总结[精选]主管工作总结。
三季度我们团队负责的三条业务线，系统可用性数字是99.99%。比上季度高了0.02个百分点。你算算这0.02%对应多少时间？季度按2160小时算，大约26分钟。而我们实际故障总时长从原来的43分钟降到了17分钟——发现时长从8分钟压到3分钟，恢复时长从22分钟压到11分钟，加起来正好少了26分钟。数字不是凑的，是每一步抠出来的。
先说那17起三级以上故障。硬件坏了4起：三块SSD报Media Error，一台电源模块闪断。配置变更惹的3起：有人改了下游超时参数忘了同步通知。剩下的10起，全是老系统迭代后冒出来的边界条件——比如一个五年前的接口返回了NULL而不是空数组，新代码没处理。我把每起故障的根因、处置动作、后续改进列了一张表贴在团队wiki置顶。这里讲一个最折腾的。
八月份那次数据库连接池爆满，凌晨两点十一分告警。连接数从200跳到1500，应用开始报“Connection wait timeout”。按老套路先查慢SQL，日志里干干净净。活跃连接全卡在“idle in transaction”。我立刻拉上DBA和中间件同事，分三路：一路查最近发布，一路查锁等待，一路查网络设备。发布记录显示昨天下午有个灰度版本，里面加了一个定时任务。我让同事把那段代码调出来一看，@Transactional注解上没写timeout参数，底层连的又是默认无限等待。这个任务每五分钟跑一次，每次循环里还有远程调用，调用慢了事务就一直挂着。吃了教训。
处理动作很直接：我写了一条脚本，pg_stat_activity里查state为‘idle in transaction’且state_change超过30秒的连接，拼接出pg_terminate_backend(pid)批量执行。释放了800多个连接，系统恢复。整个过程用了四分钟，其中两分钟是等脚本执行。然后紧急回滚那个灰度版本。事后我们干了两件事：第一，把所有带事务注解的代码强制加上timeout=5，并在CI流水线里加了个checkstyle规则，扫描没写timeout的事务注解直接报错。第二，连接池监控从分钟级改成秒级，针对‘idle in transaction’状态单独设告警阈值——一旦超过10个这种连接持续20秒，立刻发钉钉给值班人。你懂的，这种配置遗漏，review时根本看不出来，只能靠工具卡。
再讲一个设备维护的事。机房有批Dell R730xd，硬盘跑了三万七千小时，已经超出厂商建议的更换周期。以前我们等硬盘亮黄灯再做热备重建，重建一次至少六小时，期间还有性能下降风险。今年我改成主动轮换：每季度按批次换掉15%的老盘，提前用MegaRAID的patrol read扫描坏道。换下来的盘做dd全盘擦除和smartctl慢测试。这个动作一季度多花了我们大概八个工时，但提前发现了三块盘有pending sector。你算算，如果不换，这三块盘在未来三个月内坏掉的概率超过七成，到时候至少三次紧急换盘，每次影响业务读性能。划得来。
质量验收方面，以前我们只卡功能测试和压测。今年加了一个“变更影响面验证报告”，必须包含三张图：变更前和变更后核心接口的P99响应时间对比、错误率曲线、上下游依赖的健康检查结果。刚开始运维兄弟嫌烦，说这是形式主义，一个简单配置变更也要写报告。我说行，那你把报告模板简化成五个字段，但必须有数据。后来有一次变更改了一个网关的路由规则，影响面验证报告里显示下游某个非核心服务的熔断器被误触发，错误率从0.01%飙到5%。如果不是这份报告，这个异常要等到业务投诉才会被发现。说实话，有时候笨办法就是最不笨的办法。
施工规范上，我们梳理了二十种常见故障场景，每个场景配了“标准处置流程”和“止血手段”。比如磁盘写满怎么查哪个目录占用大、CPU sys态飙高怎么看软中断分布、网络丢包怎么用dropwatch定位。这些流程不是文档库里的摆设。每个季度抽两个下午做盲演——我随机挑一个场景，值班的人必须在五分钟内给出第一波操作指令，并且要在测试环境里实际跑一遍。搞盲演不是为了表演，是真要出事儿时手不抖。今年九月份一次线上CPU软中断飙高到70%，值班的同事三分钟内就用perf top定位到是网卡驱动的问题，果断切流到备用服务器。事后他说，上个月盲演刚练过这个场景。
没做好的地方也不少。三季度有一次机房单路电源切换，我们提前三天发了通知。结果切换当天，有三台服务器直接掉电。查下来发现，这三台机器是去年扩容时上架的，当时只接了一路PDU。资产台账里记录了双电源，但没人去核对真实接线。这个事赖我。作为主管，我没把电源冗余检查写进季度巡检的必做项。事后我们做了两处改进：一是每台机器的电源状态用dmidecode和ipmitool采集，写进cmdb，每周自动比对；二是所有新上架机器必须拍电源接线照片作为验收依据，否则运维不接收。
团队管理上，我不太讲什么“帮助成长”。我就干三件事：第一，每周五下午雷打不动做“故障回头看”，哪怕这周没故障，也要找一个其他公司的典型案例拆一遍。第二，知识库不许写“按照步骤操作即可”这种废话，必须贴出具体的命令、输出截图、以及踩过的坑。第三，新人前三个月必须独立处理至少五类不同的一线故障，我坐旁边看着，不插手，只最后点评。今年有个新人，从不会看堆栈到能独立定位死锁，用了两个月。
说到跨部门协调，数据库那次故障我印象很深。DBA一开始坚持说锁等待是应用代码问题，不愿意查数据库参数。我直接把innodb锁监控打开，截了张图发群里——显示持有锁的session正是那个灰度版本的应用连接。然后我提议：以后每次变更前，DBA和中间件团队派一个人参与预审，不用全程跟，只看事务超时和连接池配置。这个事推动了两周才落地，中间吵了三回。但现在回头看，跨部门联合预审确实帮我们发现过两次类似的隐患。
- 活动范文吧小编为您推荐工作总结专题，欢迎访问：工作总结
