技术主管工作总结
（实荐）技术主管工作总结。
这一年带着六个运维和三个开发（我们叫SRE小组）扛着公司的核心交易系统，说实话，主管这个位置最难的不是技术本身，而是你得在“冲上去修故障”和“退回来定规矩”之间来回切换。下面讲两件事，一件差点让我背处分，另一件让我重新认识了什么叫“缓存穿透”。顺便也聊聊我带人踩坑的那些零碎事。
第一件：连接池炸了，凌晨三点我差点摔手机
今年三月份的一个凌晨，正睡着呢，值班手机震得像触电。钉钉群里订单服务开始飘红，响应时间从几十毫秒蹦到三秒，紧接着超时告警像机关枪一样往外冒。我光着脚跳下床，连上VPN，看了一眼数据库监控——连接数直接怼到上限，曲线几乎是九十度往上蹿。当时的直觉是慢查询或者死锁，但show processlist一看，大量连接处于Sleep状态，超过三十秒还没释放。这不对，我们用的HikariCP按理说空闲连接很快会回收。
赶紧翻应用的连接池配置。maxLifetime配了10分钟，idleTimeout配了30秒。懂HikariCP的都知道，idleTimeout必须小于maxLifetime，但这里不是大小的问题——关键在于，idleTimeout只对空闲连接生效，而连接一旦被用过就进入“存活”倒计时，maxLifetime没到之前它不会主动关闭。结果呢，那个凌晨跑的批量补单任务，每次打开会话后有个异常分支忘了调用close()，连接就这么一直挂着。压测没覆盖到那个分支，因为出异常的概率只有千分之几，但架不住订单量大，一个晚上积累下来就把池子堵死了。
我当时临时把数据库的max_connections从500拉到800，先确认了DB内存还够（32G，innodb_buffer_pool占了20G，余量撑得住），然后让值班同事重启订单服务。业务恢复用了十五分钟，但那根弦一直没松——因为根因没挖干净，第二天凌晨还会再爆。
第二天一早，我把提交那段代码的同事叫到会议室，没点名骂人，但让他把HikariCP的参数设计文档手抄了一遍关键部分。然后定了三条硬规矩：第一，连接池参数模板锁进自动化部署脚本里，maxLifetime必须比idleTimeout大至少3分钟，任何改动要走评审工单；第二，所有JDBC操作强制用try-with-resources，并且引入SpotBugs静态扫描，发现未关闭连接直接让CI流水线失败；第三，我们之前没有监控连接泄漏，加了个HikariCP的泄露检测阈值设成30秒，一旦超时就打堆栈日志。
这件事后来我让当事同事自己写复盘，写完在会上讲，讲不清楚就重写。他讲了三遍才过。有人问我是不是太严了，我说，这种漏子下次可能是别人踩，规矩立住了，谁都能照着抄。
第二件：缓存穿透，MySQL差点被临时ID锤死
另一个案例跟风控系统的黑白名单有关。设计上先查Redis，查不到再去MySQL。某天下午，MySQL的CPU突然冲到95%，慢查询队列堵了一长串。奇怪的是Redis的命中率没怎么降，但整体请求量翻了三倍——从每秒2000涨到6000多。我抓了几条请求日志，发现查询的key里有大量以“temp_”开头的字符串，长度还不固定。往上追，是某个前端客户端在重试失败请求时，把中间状态的临时会话ID也塞进了查询参数。那种临时ID永远不在缓存里，等于每个请求都直接穿透到MySQL。
当时我真是又气又急。气得是，我们居然没对查询参数做任何格式校验；急的是，再拖下去MySQL集群可能被拖垮。我的处理分两步。第一步，在API网关层用OpenResty写了个Lua脚本，对黑白名单查询接口做过滤：如果key以“temp_”开头或者长度超过32位，直接返回默认放行（风控允许这种降级策略）。十五分钟内热部署上去，MySQL的压力肉眼可见地降下来了。第二步，更彻底的方案——加布隆过滤器。我们把所有合法的客户ID（大约1200万条）预加载到布隆过滤器里，放在RedisBloom模块里。查询前先过一遍布隆，如果判定不存在就直接返回，不去查Redis和MySQL。布隆有误判率，我设成1%，算下来2000万容量大概占200MB内存，可以接受。增量重建怎么做？布隆过滤器不支持删除，所以我们每天凌晨用双Buffer切换：新建一个布隆，加载全量合法ID，然后原子切换指针，旧的等查询排空后删除。这套逻辑用Lua脚本包在Redis事务里，保证切换期间不丢查询。
上线后，这类穿透请求的拦截率在99.8%以上，MySQL的负载回到正常。教训有两层：第一，缓存穿透不能只靠加缓存，要对key空间做准入控制；第二，网关防护要前置——很多问题在业务逻辑里处理已经晚了，能挡在入口就别放进来。
再说点带人和设备上的事
除了软件故障，硬件也出过妖蛾子。去年机房一台存储阵列的SSD磨损度超过90%，变成了慢盘，IO延迟从正常的2毫秒抖到200毫秒，导致好几个依赖磁盘的定时任务超时。当时监控只报了磁盘使用率，没报磨损度。我翻了三天的日志才定位到那块盘。从那以后，我们规范了NVMe SSD的磨损监控，阈值80%就预警，90%直接换盘，不等告警。设备维护这事儿，说起来简单，但你不定规矩，它就永远漏在监控死角。
带人方面，我每周五下午固定做一件事：从当周的事故或变更里挑一个案例，让负责的人用十分钟讲清楚“发生了什么-怎么查的-怎么修的-怎么防”。不讲大道理，就讲操作。讲完之后其他人可以拍砖。一开始有人抵触，觉得像批斗会，后来发现确实能学到东西，慢慢就主动报了。我觉得技术主管的活儿，有一半是修系统，另一半是修人——把人修到能独立处理大部分故障，你才能睡个安稳觉。
写这么多，其实就想说一句话：定规矩比救火难，但规矩定好了，火会少很多。
- 想了解更多技术主管工作总结的资讯，请访问：技术主管工作总结
