当前位置：首页 > news >正文

第四章：暗礁

news 2026/6/1 9:16:03

第四章：暗礁

一

入职第二个月的周三下午，部门组织了一次技术分享会。

分享会在B座十二层的大会议室里举行，参加的人不少——不仅有技术研发部的，还有产品部、测试部的一些同事。林晚到的时候会议室已经坐了大半，他找了一个靠后的位置坐下。

张磊站在讲台旁边，拿着话筒说了几句开场白："今天是咱们部门的月度技术分享，有三位同事会做分享。第一位——"

他看了一眼手里的名单。

"林昊。入职两个月，分享主题是'基于规则引擎的动态审批流设计'。"

林晚对"林昊"这个名字有印象——入职培训的时候在走廊里见过几次，一个长得很高、很精神的男生，穿着干净的白衬衫，说话声音不大但很清楚。他们没有正式说过话，只是在走廊里点过几次头。

林昊走上讲台。

他没有用PPT——直接打开了笔记本电脑上的一个项目demo。代码编辑器、终端、浏览器三个窗口并排，实时演示。

"各位好，我今天分享的是一个我课余做的小工具。"

他开始讲。声音不大，语速适中，没有废话。他先用一分钟介绍了背景——"公司的审批流是用硬编码实现的，每加一种审批类型就要改代码。我想做一个规则引擎，让非技术人员也能配置审批流"。然后他开始演示——在界面上拖拽几个节点，设置条件，点击"生成"，系统自动生成了一段审批流程代码。

会议室里安静了几秒钟。然后有人开始鼓掌。

林晚也鼓了掌。

他看着林昊在讲台上操作——代码很精炼，架构清晰，前端界面虽然简陋但功能完整。这不是一个"课程设计"级别的东西，是一个真正可用的工具。

林晚心里有一种复杂的感觉。不是嫉妒——他能分辨嫉妒和欣赏的区别。他真心觉得林昊做的东西很好。但同时，他也有一种非常具体的无力感——他入职两个月了，做的最有技术含量的事是改了一个分页查询的默认值。而林昊在同样的时间里，做出了一个让整个部门鼓掌的工具。

差距不是一个量级的。

张磊在林昊讲完之后说了一句话："这才是校招生该有的水平。"

这句话在会议室里回荡了几秒钟。林晚坐在后排，听得很清楚。

他没有不舒服。或者说——他以为自己没有不舒服。但那天晚上回到出租屋之后，他打开备忘录，在"踩坑记录"里加了一条：

第八条："差距是真实的。看到差距不丢人，假装看不见差距才丢人。"

他没有写更多。但那天晚上他躺在床上想了很久——想林昊的代码、张磊的话、自己的分页查询。他第一次清晰地意识到：在这个公司里，"做得好"和"做得被看到"是两件事。而林昊两件事都做到了。

二

入职第二个月的后半段，林晚第一次遇到了"被甩锅"。

事情是这样的。

一个周五的下午，线上监控系统发了一条告警——客户管理模块的某个接口响应时间异常，从平时的200毫秒飙升到了2秒。影响不大——只影响了部分客户的页面加载速度——但告警级别是P2，需要当天排查。

张磊在群里分配了排查任务："老周带林晚一起查一下这个告警，今天内给结论。"

老周接了任务，转头对林晚说："你先查一下是不是数据库慢查询的问题。看看最近有没有新上线的SQL。"

林晚点头，打开了数据库监控面板。他花了大约两个小时，把最近三天的慢查询日志全部拉出来看了一遍。结论是：没有异常的慢查询。数据库层面没有问题。

他把这个结论告诉了老周。老周嗯了一声，说："那查一下是不是缓存的问题。看看Redis的命中率有没有变化。"

林晚又花了两个小时查Redis——缓存命中率正常，没有异常波动。

他又告诉了老周。老周说："那查一下是不是网络的问题。看看最近有没有网络设备的变更。"

林晚去查了网络监控——没有变更记录。网络正常。

三个方向都排除了。但问题还在。

林晚有点着急——从周五下午开始查，现在已经是周六上午了。他查了快八个小时，什么都没查到。

他去找老周。老周正在工位上看什么东西，看到林晚过来，说了一句："还没找到？"

"三个方向都查了，没有异常。"

老周想了想："那你查一下是不是最近上线的那个新接口引起的。上周不是有个新的客户批量导入功能上线吗？"

林晚回去查了那个新接口。发现那个接口在处理大文件时会并发调用客户管理模块的某个方法，导致线程池被占满，间接影响了客户管理模块的整体响应时间。

问题找到了。

林晚松了一口气，把排查结果发到了群里。张磊回复了一句"好，处理一下"。

排查完之后，林晚坐在工位上，忽然觉得有什么不对。

他回头想了一下整个排查过程——老周让他查的三个方向（数据库、缓存、网络），都不是问题的真正原因。问题的真正原因在"新上线的接口"上——而这个方向，老周是最后才让他去查的。

但老周第一天就知道这个新接口上线了。

林晚翻了一下代码仓库的提交记录——那个批量导入功能是老周上周review的。老周一定知道这个接口和客户管理模块之间有关联。

也就是说——老周一开始就知道问题可能出在新接口上，但他没有让林晚直接查这个方向。他让林晚先去查数据库、缓存、网络——三个"不太可能出问题"的方向。

为什么？

林晚想了两个小时，想明白了。

这不是恶意，是效率优先。

对老周来说，让一个新人去排查核心问题风险太大——如果林晚查错了方向，或者在排查过程中误操作了什么，反而会添乱。不如给他三个"安全"的方向去查——查了不会出事，查不出来也不会有损失。而老周自己在同时处理更核心的工作——他需要集中精力在真正的问题上。

等林晚把三个方向都排除了，老周再给出第四个方向——这个方向是真正需要认真查的。

"给新人一个不重要的任务让他不添乱，就是最优解。"

这是林晚事后总结的。当时他没有想到这一层。当时他只觉得——"老周让我查了八个小时，最后问题不在那三个方向。我浪费了时间。"

但等他冷静下来之后，他意识到：老周没有做错。从老周的角度来看，这是最合理的安排。新人的任务是"消耗时间"而不是"解决问题"。解决问题是老周的事。

林晚在备忘录里写下了第九条踩坑记录：

"不是所有'安排'都是信任，有些是'安置'。老周让我查了八个小时的数据库和缓存，不是因为他觉得我能查出来，是因为他需要我'不在他旁边'。这不是恶意，是效率。但你得明白——在职场里，'被安排'和'被信任'是两件事。"

写完之后他又加了一行：

"下次遇到这种情况，不要闷头查。先问一句：'除了这个方向，还有哪些可能的原因？'——给自己留一个全局视角。"

三

入职第三个月，林晚做了一件他觉得很"对"的事——然后他发现"对"和"被看到"不是一回事。

事情是这样的。

张磊在一次组内讨论中提到，客户管理模块的查询性能有优化空间，但一直没有时间做。林晚主动请缨，花了一周时间做了一份详细的调研报告——分析了现有查询的性能瓶颈、对比了三种优化方案的优劣、给出了推荐方案和实施计划。

报告写得很用心——不仅有数据支撑，还有图表、对比分析和风险评估。他自认为这是他入职以来做得最好的一份东西。

他把报告发给了张磊。张磊看了之后说了一句："写得不错。"然后就没有然后了。

两周后，部门月度会上，张磊做了一个技术分享，主题是"客户管理模块性能优化方案"。

林晚坐在台下，听张磊讲了四十分钟。

PPT的核心内容——三种方案的对比、推荐方案的理由、风险评估——和林晚的报告几乎一模一样。数据是林晚的数据，图表是林晚的图表（稍作修改），结论是林晚的结论。

张磊在分享的最后说了一句："这个方案是我们组最近做的调研成果。"

没有点林晚的名字。

会议室里响起了掌声。有几个同事点头表示认可，有人在笔记本上记了几笔。总监在后排听着，微微点头。

林晚坐在台下，鼓了掌。

他没有不舒服。至少他以为自己没有。

但回到工位之后，他盯着屏幕看了很久。他想的不是"张磊抢了我的功劳"——他知道功劳的流转规则。他是张磊的下属，他的工作成果默认归张磊所有。这不是"抢"，是"规则"。

他想的是另一个问题：张磊知道这份报告是我写的吗？

答案是：知道。张磊亲口说了"写得不错"。

那张磊为什么不提他的名字？

答案也很简单——在部门会上，张磊需要展示的是"我的团队在做什么"，而不是"林晚在做什么"。团队的成果归leader，leader的成果归总监。这是组织的运转逻辑。

如果张磊在会上说"这是林晚做的调研"，大家会怎么想？"一个刚入职三个月的新人做的方案？靠不靠谱？"——反而会降低方案的可信度。

张磊不说林晚的名字，不是因为不认可他，是因为说了反而不利。

林晚想通了这一点之后，在备忘录里写下了第十条：

"功劳的流转路径：从下往上流，但在每一层都会被'过滤'。你做的工作，经过你的leader变成'团队成果'，经过leader的leader变成'部门成果'。这不是贪污，是组织的运转方式。你能做的不是抗议，是让自己变得不可替代——当你的贡献大到无法被忽略时，功劳自然会流回来。"

写完之后他想了想，又加了一行：

"但如果你的leader把你的成果说成是他一个人做的，而且从头到尾都不提你——那不是规则问题，是人品问题。要分清。"

张磊是前者还是后者？林晚不确定。但他决定先观察，不急着下结论。

四

入职第三个月的最后一天，林晚犯了一个线上错误。

事情很小——他在修改一个接口的时候，没有注意到这个接口被一个老版本的客户端调用。老版本的客户端传入的参数格式和新版本不同，他的修改导致老版本客户端在调用这个接口时返回了500错误。

影响范围很小——只有还在用老版本客户端的用户会受影响，而且只有特定操作才会触发。线上监控在十分钟内就检测到了异常，发了告警。

张磊在群里发了一条排查通知："客户管理模块接口有异常，相关同学排查一下。"

没有人回复。过了五分钟，张磊又发了一条："林晚，你看一下是不是你最近提交的那个改动引起的。"

林晚看了一眼告警日志，心里咯噔了一下——错误日志里的堆栈信息指向的就是他修改的那个接口。

他立刻开始排查。十分钟后确认了原因——他改了接口的参数校验逻辑，但没有考虑到老版本客户端的兼容性。

他把排查结果发到了群里："原因确认：我修改了接口的参数校验逻辑，未考虑老版本客户端的兼容性。正在修复。"

张磊回复："尽快修复。"

林晚花了二十分钟写了一个兼容性补丁——对老版本客户端的请求格式做了特殊处理。补丁提交、测试、上线，总共用了不到一个小时。

从告警到修复，一个半小时。影响不大，修复及时。

但事情没有结束。

下午三点，张磊在群里发了一条消息："关于今天上午的线上问题，相关同学开个简短的复盘会。下午四点，305会议室。"

林晚看到这条消息的时候，心跳加速了一点。

四点整，他走进305会议室。里面已经坐了四个人——张磊、老周、刘洋，还有测试部的一个同事。

张磊坐在桌子的一头，面前放着笔记本电脑。他看到林晚进来，说了一句："坐。"

林晚坐了下来。

"林晚，你先说一下问题的原因和修复方案。"

林晚用两分钟说清楚了——原因、影响范围、修复方案、验证结果。他说得简洁，没有废话。

张磊听完之后没有评价，转头问测试部的同事："这个场景有没有自动化测试覆盖？"

测试同事说："没有。这个老版本客户端的兼容性不在测试用例里。"

"以后加一下。"张磊说。然后他看了看刘洋："刘洋，你 review 一下林晚的修复补丁，确认没有遗漏。"

刘洋点头。

复盘会开了不到二十分钟就结束了。没有批评，没有追责，就是把问题说清楚、把后续改进措施定下来。

但散会之后，张磊叫住了林晚。

"林晚，你留一下。"

其他人陆续走出了会议室。门关上了。

会议室里只剩下张磊和林晚。

张磊看着他，沉默了几秒钟。然后开口了。

"你怎么不先确认兼容性？"

语气不重，但很直接。

林晚没有辩解。他说了一句实话："我以为只影响新版本的客户端。没有去查调用方的历史版本。"

"你以为？"张磊的语气稍微重了一点。"在线上环境，'以为'是最危险的词。你的代码不是在一个真空里运行——它在一个有几十个调用方的系统里运行。你改了一个接口，你得去查所有调用方，确认你的改动不会影响他们。这是基本功。"

林晚低着头，没有说话。

张磊看了他几秒钟，语气稍微缓下来了一些。

"我刚入行的时候也犯过类似的错。有一次改了一个配置文件的默认值，结果影响了三个下游系统。当时我的leader骂了我半小时。"

林晚抬头看了他一眼。

"但关键是——同样的错不要犯第二次。"张磊说。"你可以犯第一次错，因为你在学习。但如果你第二次犯同样的错，那就不是学习的问题了，是态度的问题。"

林晚点了点头。

"回去之后，把你改过的所有接口的调用方都梳理一遍。不只是现在在用的，也包括历史版本。写一个兼容性检查清单，以后每次改接口之前先过一遍。"

"好。"

"行，去吧。"

林晚站起来，走到门口。

"林晚。"张磊在身后叫了他一声。

他转过头。

张磊靠在椅背上，看着他，说了一句："这次的事不大。但你要记住——在公司里，线上问题不是一个人的事。你出了问题，整个组都要帮你擦屁股。所以你改代码的时候，多想一步。不是为了你自己，是为了不给别人添麻烦。"

林晚点了点头，走出了会议室。

走出B座大楼的时候，天已经黑了。他站在大楼门口，深吸了一口气。

他没有觉得被骂了。张磊的批评是就事论事——没有上升到人格，没有威胁，没有阴阳怪气。就是"你做错了，原因是什么，下次怎么避免"。

但他心里有一种更深的东西——不是愧疚，是责任感。

他第一次真正理解了"线上"这两个字的重量。在学校里，代码写错了改了就行，顶多扣几分。但在公司里，代码写错了会影响真实的人——虽然这次影响很小，但它确实发生了。他改的那一行代码，在某一个瞬间，让某个用户看到了一个500错误页面。那个用户可能什么都没说，可能默默关掉了页面，但他确实经历了一次不好的体验。

代码不是抽象的。每一行代码的背后都是一个真实的人在使用。

他在备忘录里写下了第十一条：

"线上问题的重量。改代码之前，多想一步：这个改动会影响谁？不只是现在的调用方，还有历史版本。不只是直接的影响，还有间接的影响。'多想一步'不是谨慎，是责任。"

写完之后他又加了一行：

"张磊的处理方式值得学习：先严厉批评（让你知道问题的严重性），再缓和语气（让你知道这不是世界末日），最后给方向（让你知道下次怎么做）。这不是PUA，这是有效的反馈。"

五

那天晚上回到出租屋，林晚坐在电脑前发了很久的呆。

屏幕上开着好几个窗口——代码编辑器、Git提交记录、备忘录。他没有在做任何事，就是在发呆。

脑子里回放着这个月发生的事——林昊的技术分享、老周的"安置"、张磊的"拿报告"、今天的线上错误。

四件事。每一件都让他学到了一些东西。

林昊让他看到了差距——"做得好"和"做得被看到"是两件事。

老周让他看到了效率——"被安排"和"被信任"是两件事。