我是团队主管，同时也负责核心模块的开发。干了快七年，越来越觉得管理这事不能只靠开会和定制度，得实打实地带着兄弟们解决问题。下面说两个今年碰上的真事儿，有技术有管理，都是自己踩过的坑。
第一件，支付网关的响应时间半夜突然飙升。监控显示从120毫秒跳到将近4秒，成功率掉到82%。说实话，我半夜爬起来看到这个数字，第一反应是数据库被打满了。结果查了一圈，CPU、内存、磁盘IO全正常，网络也稳。这就有意思了——所有基础指标都正常，但业务就是不行。我拉上值班的小王和小李，分了两路：小王去看最近的发布记录，小李去拉线程堆栈。
小王翻出三天的发布清单，有个改动引起我注意：为了给产品加一个回调日志，我们在支付回调的异步处理里塞了一个日志写入，用的是共享的线程池。当时代码评审我也在场，觉得异步嘛，不会阻塞主链路，就过了。小李用Arthas一追，果然，那个日志写入任务把线程池的4个核心线程全占了，真正的支付回调任务全在队列里排着。说白了，一个辅助功能把主干道给堵死了。
解决不复杂：单独开一个日志专用线程池，核心线程数设成2，队列改成有界1000，满了直接丢弃日志。改完压测，响应时间回到150毫秒以内，成功率99.97%。但这里有个细节你们可能注意到——150和120还有差距。后来我们深挖了一下，发现是因为日志从同步改成异步后，原来的释放连接逻辑多了一次上下文切换。我们又调整了回调处理器的线程模型，最终压到125毫秒。
这事之后，我做了两件事。第一，把这次故障复盘写成了《线程池隔离操作规范》，要求所有异步任务必须单独声明线程池，并且压测报告里必须包含队列积压的监控截图。第二，我在周会上把责任担了——当初评审是我签的字，我没坚持让开发做压测。然后我罚自己请团队喝了顿奶茶，顺便说了句：以后谁再觉得“小改动没问题”，就自己请全组喝奶茶。你别说，这招比扣绩效管用。
第二件，测试环境一套数据库服务器老出慢查询，甚至直接宕机过两次。每次重启就恢复，硬件诊断全过，让人深感无奈。运维老张说是偶发，我不信。我拉着组里负责性能优化的小赵，在服务器上部署了一个持续IO延迟监控脚本，每10秒采样一次。跑了四十八小时，终于抓到一次延迟从平均2毫秒突跳到380毫秒。
我们把同时段其他三台同型号服务器的日志拉出来对比，发现只有这台机器的RAID卡固件版本是2.0.3，其他都是2.1.6。我去厂商官网查固件发布说明，2.1.3版本的更新日志里赫然写着“修复特定负载下IO命令超时导致中断的问题”。那一刻我真有点上头——一个固件版本，让我们查了三周，中间还重装过一次操作系统，折腾了六个人。
升级固件很简单，但问题是为什么三周才查到？我坐下来复盘团队的知识盲区：我们所有人都默认硬件诊断通过就等于硬件没问题，从来没想过固件也算硬件的一部分。后来我拉了一份清单，把所有服务器的RAID卡、BIOS、BMC固件版本全部登记，定了个规矩：每季度巡检一次，版本低于基线的一律走变更升级。另外，我在新人入职的培训里加了一节“设备维护不是只有除尘”，专门讲固件管理的重要性。
这两个案子之后，我把重心往团队管理上移了移。说个具体的事。团队有个小伙子小陈，代码能力不错，但总爱自己闷头干。有一次线上排查故障，他发现了问题线索，没同步给其他人，自己试了三个方案都没成，最后把时间耽误了。我当时没当场批评他，但事后找他单独聊了半小时。我问他：“你觉得你一个人搞三个小时，和三个人一起搞半个小时，哪个风险小？”他想明白了。后来我把他安排给小李带，专门负责故障响应时的信息同步。现在小陈已经是故障响应的副班长了，遇到问题第一件事不是动手，是先拉个群把现象贴出来。
说句实在的，当主管最怕的不是技术难，是人和人之间不咬合。我以前觉得自己能搞定一切，现在越来越意识到，把规则固化下来，把经验和误区分给所有人看，比我自己多写几行代码管用得多。
明年我准备做这么几件事：把线程池隔离规范推进到所有核心模块，每个模块的压测报告必须过我的审核；把固件巡检做成自动化脚本，每个月跑一次并自动报警；另外，我想在团队里搞一个“故障复盘会”，不追责只讲坑，每两周一次，每个人轮流讲自己遇到的真实问题。说白了，把经验变成共识，才是团队能长久跑下去的根本。hN373.CoM
-
需要更多的工作总结网内容，请访问至：工作总结