聊聊技术探索与实践：一个准备考公的在职程序员的深夜复盘
上周五晚上十一点半，我瘫在浦东张江某小区出租屋的旧沙发上，盯着屏幕上一行报错日志发呆。女朋友小林从厨房探出头：“又卡住了？要不要吃点宵夜？”我苦笑：“不是卡住，是快崩了——明天就要交方案，结果新引入的那个分布式任务调度框架死活跑不通。”
这场景太熟悉了。自从去年十月下定决心一边上班一边备考公务员，我的生活就变成了“白天写业务代码、晚上刷行测题”的双线程模式。房租3500，两个人合租在地铁6号线沿线，省吃俭用只为多攒点上岸后的缓冲资金。而技术，这个曾经让我热血沸腾的东西，现在却常常成了压垮骆驼的最后一根稻草。
但说实话，正是这些“卡住”的时刻，逼着我去真正做技术探索，而不是停留在API调用的舒适区。
一次被逼出来的技术深潜
事情得从三个月前说起。公司接了个政府数据中台项目，领导点名让我牵头重构任务调度模块。原系统用的是老旧的 Quartz + 手动轮询，高峰期经常丢任务。我提议引入 XXL-JOB —— 毕竟是开源项目，文档齐全，社区活跃，看起来“稳”。
结果刚上线预发环境就翻车了。任务偶尔会重复执行，日志里全是“JobHandler already running”。我第一反应是：是不是并发配置错了？查了一晚上配置文件，改了线程池大小、重试策略、分片参数……问题依旧。
那晚凌晨两点，小林已经睡了，我还在 Stack Overflow 和 GitHub Issues 里打转。突然看到一条三年前的 issue：“当注册中心网络抖动时，executor 心跳丢失会导致 master 误判节点下线，从而触发 failover 并重新分配任务。” 我心头一紧——我们测试环境正好部署在一台网络不太稳定的云主机上！
那一刻我才意识到：光会“用”框架远远不够，你得知道它怎么“坏”。
于是周末两天没碰行测题，我把 XXL-JOB 的源码 clone 下来，重点啃了 executor 注册逻辑和 master 的 failover 机制。画了两张架构图贴在墙上，还用 JMeter 模拟网络延迟。最终定位到：我们的 executor 心跳间隔设得太长（默认30秒），而 master 判定超时是90秒。一旦网络波动超过30秒，master 就认为节点挂了，立刻把任务分给其他节点；等原节点恢复心跳，它还以为自己该继续跑，于是重复执行。
解决方案很简单：把心跳间隔调成10秒，超时阈值调到40秒。但这个“简单”背后，是整整48小时的深度调试和验证。
技术分享，不是为了装X，而是为了活下去
这件事之后，我在团队内部做了个半小时的技术分享，标题就叫《XXL-JOB 踩坑实录：别让 failover 变成 double-run》。没想到反响出奇地好。隔壁组的老王拍我肩膀：“兄弟，你这实战经验太及时了！我们下周也要上调度系统，差点踩同一个坑。”
其实我做技术分享从来不是为了表现自己。在上海这种卷到骨子里的城市，一个普通程序员想靠“熟练工”混日子越来越难。去年我面试另一家公司，HR直接问我：“除了 CRUD，你对系统稳定性有什么思考？” 当时我支支吾吾，只说了些监控告警的套话。最后 offer 没拿到，月薪卡在18k，离我期望的22k差了一大截。
从那以后我就明白：技术深度，是你在职场谈判桌上唯一的筹码。
所以哪怕现在全力备考，我也没完全放下技术。每天早上六点起床，先刷30分钟 LeetCode 或看一篇系统设计文章；通勤路上听技术播客；周末抽半天复现一个开源项目的核心模块。不是为了跳槽涨薪（毕竟目标是体制内），而是因为——技术探索本身，就是一种对抗不确定性的能力训练。
公务员考试何尝不是？行测的逻辑推理、申论的材料分析，本质上和 debug 一个复杂系统没太大区别：都是在有限信息下，快速定位核心矛盾，提出可行解。
真正的实战经验，来自“不得不解决”的压力
很多人觉得“实战经验”就是参与过多少个项目。但我觉得，真正的实战，是你在 deadline 前夜、在老板催问、在用户投诉的压力下，依然能冷静拆解问题、找到根因的能力。
记得有一次线上支付回调失败，用户投诉激增。当时我刚做完一套真题模考，脑子还沉浸在数量关系里。接到告警电话时手都在抖。但强迫自己深呼吸三次后，我按老习惯做了三件事：
- 先止损：临时关闭非核心支付通道，减少影响面；
- 再定位：用链路追踪工具锁定是第三方证书过期导致 HTTPS 握手失败；
- 最后复盘：推动建立证书生命周期监控，避免再犯。
整个过程不到两小时。事后运维同事说：“你心态真稳。” 其实哪有什么稳，只是经历过太多次“凌晨三点重启服务”的崩溃，慢慢练出来了。
这种在高压下保持逻辑清晰的能力，恰恰是考公最需要的素质。申论大作文要结构清晰，面试要条理分明——这些不都是我们在 daily standup 上汇报阻塞问题时练出来的吗？
给同样在“夹缝中求生”的朋友几点建议
如果你也像我一样，既不想放弃技术积累，又在为人生新方向努力，这里有些血泪总结：
别追求“学全”，要追求“学透”。与其泛泛了解十个框架，不如吃透一个系统的完整链路。考公复习也一样，资料不在多，在精。
把每次故障当成案例库。我有个 Notion 页面专门记录“生产事故复盘”，包括现象、排查路径、根本原因、预防措施。这不仅是技术资产，更是思维训练。
技术分享是最好的学习。讲给别人听，逼你把模糊的认知变成清晰的逻辑。我现在甚至会对着小林讲“今天 Redis 缓存穿透怎么解决的”，她虽然听不懂，但点头的样子让我觉得自己没白忙。
允许自己阶段性偏科。备考冲刺期可以适当减少新技术尝试，但别彻底断联。保持手感很重要，就像跑步不能停太久，否则再起步特别痛苦。
写在最后：技术人，永远在解决问题的路上
昨天收到笔试成绩，行测72，申论68，勉强进面。小林比我激动，当晚煮了顿火锅庆祝。我边涮毛肚边想：其实无论是写代码还是写申论，底层逻辑都是相通的——面对问题，不逃避，一步步拆解，直到找到出口。
技术探索不是为了成为架构师，实践也不是为了吹牛简历。它是一种生存方式，一种在混沌中建立秩序的能力。
明年如果真的上岸，我可能不再天天和 Kafka、Redis 打交道。但那些深夜 debug 的焦灼、解决问题后的狂喜、分享经验时的踏实感，早已刻进骨子里。
毕竟，真正的技术人，从不局限于工具，而在于思维方式。
而这条路，无论通往体制内还是硅谷，都不会白走。
——
写于2024年6月，浦东出租屋，窗外梅雨淅沥。
评论 0