打工人上班摸魚小說-第七章机房惊魂、技能联动与“被迫认真”-开发者社区

第七章机房惊魂、技能联动与“被迫认真”

接下来的几天，林舟有意识地调整了自己的“摸鱼策略”。

他依然会进行“带薪冥想”和“创造性学习”，但减少了纯粹为了能量而进行的、过于投机取巧的行为（比如长时间伪装阅读完全无关的资料）。他开始将部分摸鱼时间，真正用于学习一些与工作潜在相关、或自己长久感兴趣的知识，比如更系统地了解公司主营业务的技术栈基础，或者研究一些效率工具背后的设计哲学。

系统对此似乎颇为赞许。当他的“摸鱼”行为带有更明确的“建设性”或“成长性”目的时，能量获取效率往往会有小幅提升，有时还会伴随【心智沉淀】或【知识链接】的额外微效，让学习记忆和理解速度有那么一丝丝不易察觉的增强。

能量缓慢而扎实地增长着，朝着300点的新上限稳步前进。

然而，职场从不会让人真正安逸。经理在周四下午找到了他，脸上带着一种混合着信任与棘手任务特有的无奈表情。

“小林，有个事得麻烦你跑一趟。”经理搓着手，“客服和运营那边反馈，他们用的几个后台系统最近总是间歇性卡顿，特别是每天下午三四点高峰时段，影响挺坏。技术部那边排查了一圈，说服务器和网络层面没发现明显问题，怀疑是咱们这边某个业务接口或者数据查询负载太高，把中间件拖垮了。”

林舟心里一沉。技术问题？他最怕这个。虽然他靠着“言语模糊”糊弄过技术部的会议，但那毕竟是务虚讨论。真要定位具体的技术问题，他那点皮毛都不算的了解和系统赋予的“忽悠”技能，可派不上用场。

“经理，这个……我对具体的技术栈和接口调用不是很熟，怕搞不定。”林舟试图推脱。
“没事，不用你具体修。”经理摆摆手，“主要是去现场跟一下，当个联络人。技术部会派个工程师过去，重点排查我们业务侧可能存在的问题。你去，一是代表我们部门表示重视，二是帮忙协调，需要调什么日志、查哪个时间段的数据、找哪个业务线的同事问话，你居中沟通，省得他们来回扯皮。三是……”经理压低了声音，“也盯着点，别让技术部把问题都推到我们业务逻辑设计不合理上，你懂吧？”

懂了。就是个背锅……不对，是扯皮缓冲区、人肉传声筒、兼部门利益守护者。

这角色可不轻松。技术问题往往黑盒，公说公有理婆说婆有理，最后经常变成扯皮大战。他这个“联络人”夹在中间，两头受气不说，万一问题真出在业务侧，他也难逃干系。

“这个任务比较棘手，但也最能锻炼人。”经理拍了拍他的肩膀，眼神意味深长，“总部交流那边，很看重解决实际问题的能力和跨部门协调经验。”

话说到这份上，林舟知道自己推不掉了。这既是坑，可能也是个机会——在经理和更高层面前展现“解决复杂问题能力”的机会，尽管他对此毫无把握。

“行，经理，我去试试。”林舟硬着头皮答应下来。

“好！下午就跟技术部的人一起去机房那边。保持沟通，随时汇报。”经理松了口气。

下午两点，林舟在办公楼地下二层的机房入口，见到了技术部派来的人。不是上次会议上见过的周工或吴工，而是一个看起来三十出头、戴着黑框眼镜、脸色有些苍白、头发略显凌乱的男工程师，胸前挂着的工牌上写着“郑涛”。

郑工程师话不多，只是冲林舟点了点头，算是打过招呼，眼神里带着技术人员特有的、对非技术背景人员的淡淡疏离和一丝不易察觉的……疲惫？

两人通过门禁，进入机房区域。恒温恒湿的环境让温度骤然降低，巨大的噪音扑面而来——那是无数服务器风扇和空调机组共同演奏的、永不停歇的轰鸣。成排的机柜像钢铁森林，指示灯明明灭灭，闪烁着数字世界冰冷的心跳。

林舟很不喜欢这里。过低的温度，巨大的噪音，还有那种被庞大电子设备包围的压迫感，都让他感到不适。他看了一眼旁边的郑工，对方却似乎早已习惯，眼神专注地扫视着环境监控屏幕。

他们来到标注为“业务支撑区”的几排机柜前。郑工开始操作随身携带的笔记本电脑，接入网络，运行各种林舟看不懂的命令和监控工具。林舟则按照郑工的要求，联系客服和运营的负责人，索要问题发生时段的具体操作日志和用户投诉样本。

最初的沟通还算顺畅。郑工专注于技术排查，时不时让林舟询问一些业务侧的细节，比如“这个查询按钮平均每秒点击量多少”、“那个报表生成一般涉及多大数据量”。林舟尽力协调，将问题翻译成业务同事能听懂的语言，再把对方的反馈提炼给郑工。

时间一分一秒过去。机房的低温让林舟手脚有些发凉，持续的噪音也开始让他有些心烦意躁。郑工的眉头越皱越紧，在尝试了几个常规优化方案（调整某个中间件连接池参数、重启两个疑似有内存泄漏的服务实例）后，问题依然没有明显改善。

“奇怪……”郑工盯着屏幕上的性能监控曲线，喃喃自语，“峰值时段CPU和IO都没有爆，网络也通畅，但应用响应时间就是飙高。像是……有什么东西在排队，或者锁竞争？”

他要求林舟协调，从业务侧模拟几个高峰时段的典型操作流程，同时他这边进行全链路跟踪。

这个过程更加繁琐。需要多个业务部门的同事配合，在测试环境进行操作，中间还涉及到权限申请、测试数据准备等一系列麻烦事。林舟像个救火队员，在各个钉钉群和电话之间穿梭，解释、恳请、催促。机房的寒冷和噪音消耗着他的体力，扯皮和等待消耗着他的耐心。

他开始感到熟悉的疲惫和轻微头痛——不是系统技能能立刻缓解的那种，而是长时间处于不适环境和高压协调状态下的身心俱疲。

能量槽里的数字缓慢跳动着，但杯水车薪。他瞥了一眼系统界面，【精力充沛（被动）】在默默生效，但似乎也只能让他勉强支撑，不至于立刻垮掉。

“找到了！”下午四点半左右，郑工忽然低呼一声，声音在机房噪音中显得有些突兀。

林舟精神一振，凑过去看。郑工的屏幕上显示着复杂的调用链跟踪图谱，其中一条红色的链路异常显眼，耗时占据了整个请求的百分之七十以上。

“是数据层的问题。”郑工指着那条红链路，“这个查询，每次执行都要全表扫描一个巨大的历史日志表，而且没有有效索引。平时数据量小还好，高峰时段并发一上来，磁盘IO就顶不住了，拖慢了整个链路上的所有后续操作。”

问题找到了！林舟心中一喜。但紧接着，郑工的话让他心又沉了下去。

“这表结构设计有问题，至少缺两个关键索引。但这表是你们业务侧设计维护的吧？数据模型也是你们定的。”郑工推了推眼镜，看向林舟，语气平静但带着技术人员的笃定，“优化需要加索引，可能还得考虑历史数据归档。这涉及数据模型变更，需要评估对现有业务逻辑的影响，不是我们能直接动的。”

皮球，又踢回来了。而且踢得有理有据。

林舟看着屏幕上那条刺眼的红链路，仿佛看到了后续无尽的扯皮：业务侧说当初设计是经过技术评审的，技术部说评审时没考虑到这么高的并发场景，然后互相指责，开会，扯皮，问题迟迟无法解决……

头疼得更厉害了。机房的冷气好像钻进了骨头缝里。

难道又要陷入那种无休止的、消耗精力的循环？他仿佛看到了王睿U盘里那些记录——被各种突发问题、跨部门扯皮打乱的“完美”工作计划，不断累积的焦虑。

不。他不想这样。

就在这时，也许是长时间处于噪音和低温环境让精神有些涣散，也许是“精力充沛”被动效果与疲惫感产生了某种奇异的对抗，又或者只是灵光一现——林舟看着那条红链路，看着它关联的那个数据表名，脑子里忽然闪过一个模糊的印象。

好像……上周“伪装学习”时，在某篇关于数据库性能优化的技术博客里，瞥到过一个类似的案例？关于如何在不改变表结构、不影响在线业务的情况下，通过查询重写和应用层缓存，临时规避全表扫描带来的性能问题？

印象非常模糊，细节全无。但那个“类似案例”的感觉很强烈。

是“深度发呆”描述里提到的、极低几率的“灵感闪烁”？

林舟来不及细想。他揉了揉刺痛的太阳穴，对郑工说：“郑工，技术上的事情您最专业。不过，我好像记得……有没有可能，在应用层代码里，对这个查询条件做个优化？比如，利用现有的一些业务时间戳字段进行粗筛，先减少扫描范围？或者，如果这个查询结果实时性要求不是那么高，能不能加一层短期缓存？哪怕缓存几分钟，也能极大缓解高峰压力。”

他说得很犹豫，用词也非常不专业，纯粹是基于那点模糊的印象和业务侧对“实时性要求”的了解进行的猜测。

郑工闻言，却没有立刻反驳，而是愣了一下，手指在触摸板上滑动，重新审视那个查询语句和调用它的业务代码片段。片刻后，他眼睛微微一亮：“咦？你这么说……这个查询的‘状态’过滤条件，确实可以结合‘最后更新时间’来大幅缩小范围。业务上能接受数据有几分钟延迟吗？还有，这个查询结果的变化频率……”

他快速敲击键盘，调出更多的代码和配置查看，嘴里嘀咕着一些技术术语。

林舟心跳有些加速。难道蒙对了？

他赶紧补充（继续忽悠）：“客服那边反馈的主要是操作卡顿，对数据绝对实时性要求应该没那么苛刻，特别是历史日志的查询。缓存的话，哪怕一两分钟，也能分担掉大部分重复查询的压力吧？” 这些话半是基于常识推测，半是希望如此。

郑工思考了十几秒，点了点头：“有道理。这是一个临时缓解的思路，比直接动表结构风险小得多。我改一下这个查询的SQL，让它强制使用时间范围索引，再在应用层加一个针对高频查询参数的短期本地缓存试试。需要跟你们业务确认一下这个时间范围划定的合理性，以及缓存时长和失效策略。”

“这个我来协调！”林舟立刻应道。只要不涉及底层数据模型变更，只是在现有逻辑上做优化和缓存，业务侧接受起来会容易得多，协调难度也小。

接下来的一个多小时，效率奇高。林舟迅速联系相关业务负责人，简要说明情况（避重就轻，强调是“优化查询”和“增加缓存提升体验”，而非“数据结构有缺陷”），很快拿到了确认。郑工那边手指翻飞，修改配置，部署到测试环境，进行验证。

晚上七点，在模拟的高峰压力测试下，修改后的方案表现良好。那条刺眼的红链路消失了，整体响应时间恢复到正常水平。

郑工长舒一口气，关闭电脑，揉了揉发酸的眼睛，看向林舟的眼神少了许多疏离，多了点意外的认可：“没想到你对技术优化点还挺敏感。这个思路虽然治标不治本，但确实能快速解决问题，给彻底优化争取时间。”

林舟心里一块大石头落地，同时也有些汗颜。他哪里是敏感，不过是瞎猫碰上死耗子，外加系统可能给予的一点点飘渺的“灵感”提示。

“是郑工您技术厉害，这么快就找到了根因和优化办法。”他连忙把功劳推回去。

两人走出机房，回到相对温暖和安静的办公区。林舟感觉自己的耳朵还在嗡嗡作响，但精神却因为问题解决而振奋了一些。

【检测到宿主在高压、复杂环境下，运用非直接技能（模糊知识印象、沟通协调）参与解决实际技术难题，并取得有效成果。】
【行为判定：跨界问题解决与危机化解。】
【获得额外奖励：摸鱼能量+40！‘言语模糊（初级）’熟练度小幅提升。‘精力充沛（被动）’效果微弱巩固。】
【特殊提示：技能与场景的非常规结合，有时能触发意外成效。请宿主继续探索自身能力与系统辅助的更多可能性。】
【当前摸鱼能量：167/300。】

一次性40点！还有技能熟练度提升！林舟精神大振。这次“被迫认真”参与解决问题，虽然过程煎熬，但收获远超平时常规摸鱼！而且，系统提示似乎也在鼓励他将摸鱼获得的能力，应用于解决实际问题？

这感觉……好像比纯粹为了摸鱼而摸鱼，更踏实一点？

和郑工道别后，林舟回到自己部门所在的楼层。办公室里人已经不多。经理竟然还在，看到林舟回来，立刻迎了上来：“怎么样小林？听说问题定位了，还找到了临时解决方案？”

消息传得真快。林舟简单汇报了情况，当然，重点放在技术部郑工的专业排查和自己的“协调”与“提出业务侧优化建议”上。

经理听得连连点头，脸上笑容掩饰不住：“好！干得漂亮！我就知道你能行！既能跟技术深入沟通找到关键，又能从业务实际出发提出可行建议，这协调解决问题的能力，非常出色！总部交流那边，你这又是加分项！”

林舟再次被夸得有些心虚，只能谦虚应对。

晚上回到家，虽然身体依旧疲惫（机房环境消耗太大），但精神上却有种奇异的满足感，不再是之前那种纯粹摸鱼得逞后的暗爽，而是一种……似乎真的做了点有用之事的轻微成就感。

他洗了个热水澡，驱散机房的寒气。躺在床上时，他又想起了那个U盘，想起了王睿那些试图自我优化却最终失败的记录。

今天，他也在解决问题，也在协调，也承受着压力。但和王睿不同的是，他有系统托底，有“精力充沛”让他不至于立刻被压垮，有“言语模糊”帮助他在沟通中周旋，甚至，还有那一点点不知是否真实存在的“灵感闪烁”提示。

更重要的是，他似乎开始摸索到一条不同的路：不是王睿那种自我压榨式的“硬扛”，也并非完全躺平式的“摸鱼”，而是利用系统赋予的“余地”和特殊视角，以一种更灵活、有时甚至有点取巧的方式，去应对和化解问题。

这条路依然模糊，且肯定不轻松。但至少，他感觉自己不是在原地打转，或者滑向某个已知的悲剧深渊。

他看了一眼系统界面，167点能量。距离下一次强化还有一段距离。