工作总结
发表时间：2026-04-292026年技术总监年终工作总结。
接手这个位置两年，今年才算把屁股坐稳。说句不好听的，以前觉得技术总监最大的挑战是管人，现在才明白，最难的是亲手把自己写的那些“差不多”的代码揪出来，当众扇自己耳光。
开年第一记耳光，是3月份的一个凌晨。我们核心交易网关在压测中直接雪崩。监控大屏上的红线像心电图骤停，值班同事重启、切流，来回折腾了三次，每次恢复不到十分钟又跌回去。我远程连进去，随手点开一段三个月前我亲自review过的熔断配置——阈值设的是2000，而实际正常请求的峰值才300。当时怎么想的？就是觉得“应该不会那么满”，随手填了个整倍数。说白了，懒了一下，后面就忘了。
真正让我脸上发烫的不是这个数值，而是第二天拉日志发现，那条触发熔断的慢查询SQL，是我去年底为了配合一个新业务字段加的组合索引。索引顺序写反了——等值查询的字段放在第二列，范围查询的放第一列，等于白建。开发在测试环境跑过，数据量小，没暴露。上生产三个月，某个低频场景突然被批量调用，把连接池拖成死锁。
那天复盘会开到凌晨四点。运维同事翻出一份半年前的巡检报告，里面清清楚楚标着那个连接池的活跃线程数峰值已经到阈值上限的60%。我竟然没认真看过那份报告。会议室里安静了两秒，我说了句：“我的问题，报告我读了前三页，后面附件没点开。”没人接话，但我知道有几个老同事在拿笔在本子上写了什么。
处理本身不复杂。临时把那批调用切到备库，手动把熔断阈值压到450，再用事件探查器抓到那条SQL的真实执行计划，按实际查询条件把索引顺序重建。全程四十分钟，业务损失三笔超时。但真正的硬仗在后面——我逼着所有核心服务的配置项必须附上“触发证据”。熔断阈值不再凭感觉，而是取过去六个月P99真实值的1.5倍，再往上取整。性能优化的基础数据必须来自生产日志抽样，不准只拿压测工具跑出来的理想值说话。
这个规则刚推的时候，有个小组长跟我顶：“那如果上个月P99被一次异常尖刺拉高了，阈值跟着涨不是废了吗？”我愣了下，他说得对。后来我们改成用滑动窗口中位数，去掉最高5%的毛刺，这个坑又花了两周才填平。你懂的，技术管理最怕的就是你定了个规则，被一线直接找出漏洞。
9月份的数据库分库扩容是另一块硬骨头。单表数据破了八千万，写性能开始肉眼可见地变慢。我们选的分片方案是按用户ID哈希，同时把热数据塞Redis做读写分离。方案评审时差点翻车——跨库事务怎么处理？团队里吵了两天，有人主张上分布式事务中间件，我坚持改业务逻辑，拆成本地事务加最终一致性。不是中间件不好，是我们的并发量没到那个级别，多引入一个组件就多一个故障点。
吵到最凶的时候，有个开发拍着桌子说：“本地消息表那套我们没玩过，上线出问题谁兜？”我说我兜。那周我们几个人关在会议室，对着时序图一行行抠细节。最后定的是：订单创建先写本地事务，成功后发MQ，异步更新辅助表。测试时发现，如果MQ发送失败，辅助表数据会缺失。我们加了个本地消息表，把消息落库后由独立守护进程轮询重试。多了一次数据库写入，但换来的是可对账、可追溯。上线那天晚上，数据迁移脚本写漏了where条件，导致一个分片的用户订单被重复迁移了两次，回滚折腾了三个小时。凌晨两点，我带着两个同事手工刷数据，一边刷一边骂自己为什么不在预发环境多跑一次全量比对。
那次之后，我定了个死规矩：所有数据迁移脚本必须先在生产备库上跑一遍全量，再截取10%的抽样做手工比对。谁跳过这个步骤，代码直接打回。
还有件小事让我印象深刻。今年我们把部署规范也纳入了代码review。之前每次发布总有新服务忘记配健康检查，导致被负载均衡误踢。我们写了个门禁脚本，在流水线里强制检查每个服务的三个文件：启动自检脚本、优雅停机时长配置、依赖健康检查的超时与重试策略。缺一个就阻断发布。第一次跑这个门禁时，有个老员工在群里发了个大哭的表情，说“以前上线十分钟，现在配置要改半小时”。我回他：“半小时总比半夜爬起来好。”他没再吭声，但后来他主动把自家服务的配置模板整理了一份共享出来。
说实话，这些流程加多了，团队里不是没怨言。我自己带了一个模块——把交易网关的限流算法从令牌桶换成滑动窗口，加上自适应拒绝。一边写代码一边拉了两个年轻同事跟我结对。改完之后我们压测：同一套并发场景，CPU使用率降了12%，尾延迟从800毫秒压到200毫秒以内。我没开会宣布这个结果，只是在周会上把压测报告挂出来，加了句“谁想看看代码怎么写的，下午我在这”。那天来了六个人。
下半年我调整了团队的工作节奏。每个迭代必须留20%时间做故障演练。第一次练的时候，我们把一个服务节点的网络随机丢包30%，结果服务发现组件花了整整两分钟才把它踢出集群。因为心跳间隔设的太长了，默认15秒一次，丢包后要连丢五次才判定失效。改成一秒一次后，恢复时间缩到十五秒。但副作用是心跳包的网络开销涨了三倍。最后折中：动态心跳——正常时五秒，连续两次失败后切到一秒。这些坑不亲手去踩，光看文档永远想不到。
设备维护上也吃过亏。我们的对象存储网关用的老款SSD，写入寿命掉了60%。监控一直报IO延迟抖动，我带着两个运维查了两周网卡、交换机、驱动，最后才想起来看SMART信息——固件有个已知bug，在写入寿命低于50%后会触发垃圾回收异常。升级固件后问题消失。后来我们写了个脚本，每天凌晨把每块盘的SMART关键指标和业务IO延迟做相关性打分，超过阈值自动发短信。这活儿不高级，但管用。
- ✹中学范文网刷屏专题:
- 技术总监工作总结 | 人事总监年终工作总结 | 技术总监年度总结 | 技术年终工作总结 | 技术总监年终工作总结 | 技术总监年终工作总结
质量验收这块，今年我全部要求“优化前后对比+边界条件测试报告”。不准再说“性能提升了30%”，必须讲清楚在多少条数据、多少并发、哪几个指标、怎么测的。有个同事交上来的报告里写着“经测试，系统稳定”，被我打回去三次。第四次他把压测脚本、数据集、监控截图、GC日志全附上了，我请全组喝了奶茶。
最后说个事。今年有两次我亲自上手改核心代码。一次是限流算法重构，另一次是修一个内存泄漏。那个泄漏藏了八个月，不同人打过三四个补丁，一直没根治。我用MAT花了整整两天，把引用链一层层剥开，最后发现是一个静态缓存持有了请求上下文里的线程栈变量。改完那晚我在工位坐到半夜，不是因为感动，是因为我想明白了一个道理：如果你自己都不敢跳到最脏的代码里去刨根问底，那你定的那些规范、流程、门禁，在团队眼里就是个笑话。
有个新来的毕业生在我旁边看我改完那个泄漏后，小声问了句：“总监，你还天天写代码啊？”我头也没抬：“我不写，怎么知道你们偷没偷懒？”他说了句让我记到现在的话：“那我觉得你不像个总监。”我说对，我就是个写代码的，只不过顺便管点事。
明年没什么漂亮话。就三件具体的事：把混沌演练的故障注入做成自动化随机触发，一周至少一次；把性能基线和业务监控打通，自动巡检每天出一页报告；把每次故障处置的录屏剪成十分钟以内的短片，当新人教材。每件事我亲自盯闭环。
做具体的事，解决具体的问题，比什么都强。
- 欲了解工作总结网的更多内容，可以访问：工作总结
