第二十七章 陈锐的转变
一
陈锐来找王志远帮忙，是在一个周四的下午。
这件事本身就很不寻常——陈锐从来不找人帮忙。他宁可自己加班到凌晨，也不愿意开口说"我不会"。
但这次，他实在没办法了。
二
陈锐负责的一个模块——支付对账系统——出了一个棘手的问题。
系统每天凌晨会自动跑一个对账任务，把公司的交易记录和第三方支付平台的记录进行比对，找出差异。这个任务之前一直运行正常，但最近一周开始频繁超时——对账任务从原来的 10 分钟变成了 2 小时，有时候甚至跑不完。
陈锐排查了三天，没有找到原因。
他试过优化 SQL、加索引、调整 JVM 参数，都没有明显效果。他甚至怀疑是数据库的问题，让 DBA 小刘查了一遍，也没发现异常。
周旋经理开始催了："对账系统是财务的命脉，不能出问题。陈锐，你到底什么时候能修好？"
陈锐的脸涨得通红："我在查……"
"查了三天了。"周旋的语气不太好。"需要帮忙就说。"
陈锐张了张嘴，最终没有说出"需要"两个字。
三
那天下午，王志远在茶水间倒水的时候，看到陈锐一个人坐在角落里，盯着笔记本电脑，眉头拧成了一个结。
他犹豫了一下，端着水杯走了过去。
"陈锐，对账系统的问题，需要帮忙吗？"
陈锐抬起头，看了他一眼。他的眼神很复杂——有犹豫，有不甘，还有一点……感激。
"你懂对账系统吗？"
"不太懂。但我可以帮你一起排查。两个人看问题，比一个人看得全。"
陈锐沉默了几秒钟，然后点了点头。
"好。"
这是陈锐第一次对王志远说"好"。不是敷衍的"好好好"，是真正的、接受帮助的"好"。
四
两个人在会议室里坐了一下午。
王志远先让陈锐把对账系统的架构和流程讲了一遍。他一边听一边画图——这是他的习惯，听任何复杂的东西都要画图。
对账流程大致是这样的：
1. 从数据库查询当天的所有交易记录（约 10 万条）
2. 从第三方支付平台拉取当天的所有支付记录
3. 按交易号匹配，找出差异
4. 生成对账报告
"你说超时是最近一周才开始的？"王志远问。
"对。之前一直是 10 分钟左右。"
"最近一周有什么变化？数据量增加了？代码改了？配置改了？"
陈锐想了想："数据量没有明显增加。代码没改。配置……"
他突然停住了。
"等等。上周运维做了一次数据库迁移，从单机 MySQL 迁到了主从架构。"
王志远的眼睛亮了："主从架构？对账任务读的是主库还是从库？"
陈锐查了一下配置："从库。迁移之后，读请求默认走从库。"
"从库的数据有延迟吗？"
"有。主从延迟大概 1-2 秒。"
王志远在白板上画了一条时间线：
凌晨 00:00 对账任务开始
↓
从数据库（从库）查询当天交易记录
↓
问题：如果有些交易记录还没同步到从库呢？
↓
对账任务查到的记录数 < 实际记录数
↓
匹配时发现大量"差异"
↓
差异处理逻辑触发重试和补偿
↓
重试和补偿消耗大量时间
↓
超时！
"找到了。"王志远说。"问题不是查询慢，而是主从延迟导致对账任务读到了不完整的数据。不完整的数据产生了大量'假差异'，差异处理的重试和补偿逻辑消耗了大量时间。"
陈锐盯着白板上的时间线，愣了几秒钟，然后一拍大腿："对！我一直在优化查询性能，但问题根本不在查询上！"
五
修复方案很简单：把对账任务的数据源从从库改回主库。
对账任务每天只跑一次，数据量不大，对主库的压力可以忽略不计。
陈锐改了配置，跑了一次对账任务——10 分钟，恢复正常。
他坐在椅子上，长长地出了一口气。
"谢谢。"他说。
这是陈锐第一次对王志远说"谢谢"。不是客套的"谢谢"，是真心的、如释重负的"谢谢"。
王志远笑了笑："不客气。其实你自己也快找到了，只是被'优化查询性能'这个方向带偏了。"
"是。"陈锐苦笑了一下。"我一直在想'怎么让查询更快'，没有想过'查询的数据对不对'。"
"这就是为什么排查问题要先画时间线。"王志远说。"时间线能帮你看到事件之间的因果关系，而不是只盯着一个点。"
陈锐看了他一眼："你这招是赵哥教你的？"
"对。线上故障那次学的。"
陈锐沉默了一会儿，然后说了一句让王志远意外的话：
"小胖，你比我强。"
六
这是陈锐第一次承认王志远比他强。
不是在技术细节上——陈锐的 Java 基础比王志远扎实，算法能力也更强。而是在解决问题的方式上——王志远有一种"结构化思维"的能力，能把复杂的问题拆解成清晰的步骤，用画图和时间线来理清因果关系。
这种能力不是天赋，是训练出来的。是赵北辰一次又一次地教他"先画图、再分析"训练出来的。
陈锐以前看不起这种"笨方法"。他觉得自己脑子够快，不需要画图，直接在脑子里分析就行。但这次的经历让他意识到——脑子再快，也有盲点。画图的目的不是因为脑子不够用，而是为了让思维可视化，发现脑子里看不到的盲点。
七
那天之后，陈锐对王志远的态度明显变了。
他不再阴阳怪气，不再冷嘲热讽。在站会上，他开始主动跟王志远讨论技术问题。在 Code Review 里，他的评论变得建设性了——不再是"这里不对"，而是"这里可以考虑用 XX 方式，原因是 YY"。
有一次，王志远在 Review 陈锐的代码时，发现了一个潜在的并发问题。他在评论里写了详细的分析和建议。
陈锐回复了一条："分析得很到位，我改。"
没有争辩，没有不服气。
苏薇看到了这条回复，在旁边加了一条评论："今天的陈锐让我刮目相看。"
陈锐回复了一个苦笑的表情。
八
又过了几周，陈锐做了一件让所有人都意外的事——他在组内做了一次技术分享。
题目是：《我踩过的坑——对账系统排查记》。
他在分享里详细讲了对账系统超时的排查过程，包括他走过的弯路（一直在优化查询性能）和最终的解决方案（主从延迟导致数据不完整）。
他还特别提到了王志远的帮助："小胖教我的一招——画时间线。这招看起来很简单，但在排查复杂问题的时候特别有用。"
分享结束后，王志远带头鼓掌。
陈锐站在投影幕前，表情有点不自然——他不习惯被鼓掌。但王志远看到了他嘴角微微上扬的弧度。
九
那天晚上，王志远在笔记本上写下：
Day 400
陈锐说了一句"你比我强"。这句话从他嘴里说出来，比从任何人嘴里说出来都重。
一年前他说"他过不了试用期"。一年后他说"你比我强"。不是我变了，是他变了。也许两个人都变了。
每个人都有自己的骄傲。陈锐不愿意求助，不是因为他不需要帮助，而是因为他害怕承认自己不行。今天他做了技术分享，讲了自己踩的坑——能公开承认自己的错误，需要比技术更大的勇气。
人和人之间的关系，有时候只需要一次真诚的帮助就能改变。
:::{admonition} 小胖的笔记 :class: tip
本章知识卡片：团队协作与问题排查
1. 主从数据库架构
写请求 → 主库（Master）
│
│ 同步（有延迟）
▼
读请求 → 从库（Slave）
主从延迟的影响： - 写入主库后，从库可能还没同步 - 如果业务逻辑依赖"写后读"，可能读到旧数据 - 解决方案：关键读请求走主库，或等待同步完成
2. 排查问题的思维框架
1. 确认现象（什么异常？）
2. 画时间线（什么时候开始？同期有什么变化？）
3. 提出假设（可能的原因是什么？）
4. 验证假设（用数据验证，不要凭感觉）
5. 修复 + 复盘
常见陷阱： - ❌ 一头扎进细节，忽略全局 - ❌ 被第一个假设带偏，不考虑其他可能 - ❌ 只看代码，不看环境变化（配置、部署、数据量）
3. 团队协作原则
- 主动帮助，不等别人开口
- 对事不对人，不翻旧账
- 承认错误需要勇气，要尊重这种勇气
- 竞争和合作不矛盾——在竞争中合作，在合作中成长
:::