代码之外09：团队离不开我，晋升名单却没有我

《代码之外：程序员重启人生》· 第09篇
上一世，他最自豪的一句话是：

“这个系统除了我，没人敢动。”

后来他才发现，真正困住他的，恰恰就是这句话。

周一上午十点。

技术周会刚结束，林川回到工位，赵明就把椅子滑了过来。

“老徐又请假了？”

“嗯。”

“那支付结算那边怎么办？”

林川看了一眼项目群。

群里已经连续@了好几次。

@徐志远 结算任务昨晚为什么没跑？

@徐志远 财务那边等着出账。

@徐志远 这个存储过程是不是只有你知道？

没人回复。

半小时后，部门负责人在群里说：

有谁熟悉结算系统，先帮忙看一下。

群里安静了。

没有一个人接话。

赵明小声说：

“这系统除了老徐，谁敢碰。”

林川没有说话。

因为他太熟悉这句话了。

上一世，他听到这句话时，甚至有一点羡慕。

徐志远是团队里资格最老的后端工程师。

工作八年。

技术强。

熟悉公司的核心交易系统。

数据库、结算、账务、定时任务、历史数据迁移，几乎没有他不知道的东西。

新人遇到问题都会说：

“问徐哥。”

线上出问题，第一反应也是：

“叫老徐。”

领导评价他时经常说：

“徐志远是团队定海神针。”

听起来几乎是技术人员能够得到的最高赞美。

林川以前也想成为这样的人。

最好整个系统都离不开自己。

最好别人一遇到关键问题，就必须来找自己。

那不就是不可替代吗？

可上一世，徐志远最后离职时，只说了一句话：

“我花了八年，把自己焊死在这个工位上。”

当时林川没有完全听懂。

现在，他懂了。

一、所谓“不可替代”，有时候只是“最方便继续用你”

下午一点。

徐志远终于上线。

原来早上孩子发烧，他带去医院了。

人还没回公司，电话已经打了三个。

第一个来自项目经理：

“结算任务失败了，赶紧看一下。”

第二个来自财务：

“今天必须出账。”

第三个来自部门负责人：

“这个事情比较急，你先远程处理。”

徐志远坐在医院走廊里，打开电脑连VPN。

二十分钟后，他找到问题。

上周修改了一张配置表，其中一条历史规则没有同步。

补完配置，重新执行任务。

系统恢复。

群里一片：

徐哥牛。

还得是老徐。

定海神针。

徐志远只回了一个：

已处理。

下午四点，他才到公司。

整个人明显很疲惫。

赵明笑着说：

“徐哥，你不在我们是真不行。”

徐志远也笑。

“所以我才不敢死啊。”

周围的人都笑了。

只有林川没笑。

因为他知道，这不是一句玩笑。

徐志远已经三年没有完整休过一次年假。

只要离开城市超过两天，就必须带电脑。

前年去海南，凌晨处理过结算问题。

去年春节，大年初二远程修过数据库。

老婆生孩子那天，他还接了两个生产电话。

大家都知道：

这个团队离不开他。

问题是——

晋升名单里，依然没有他。

二、最扎心的不是“你不重要”，而是“你太重要了，所以不能动”

半个月后。

年度职级评审结果出来。

赵明升了一级。

一名做平台建设的同事也升了。

徐志远没有。

办公室里没人敢主动提。

下午，徐志远被领导叫进会议室。

一个小时后才出来。

林川看了一眼他的表情。

很平静。

平静得有些反常。

晚上七点，办公室只剩下两个人。

徐志远突然问：

“林川，你觉得我还能升吗？”

林川没有说安慰话。

“领导怎么说？”

徐志远笑了一下。

“他说我的技术能力没有问题。”

林川也笑了。

程序员一听这句话，基本就知道后面是什么。

果然。

徐志远继续：

“但是影响力不够。”

“平台化建设不够。”

“团队培养也不够。”

“长期还是集中在结算和交易这些具体系统里。”

林川问：

“那这些系统为什么一直由你负责？”

徐志远沉默了几秒。

“因为别人接不住。”

“为什么别人接不住？”

“不熟。”

“为什么一直不熟？”

徐志远不说话了。

答案其实很简单。

因为过去几年，每次有人准备接手，都会遇到这种情况：

新人看代码太慢。

徐志远说：

“算了，我来吧。”

别人排查线上问题两小时没找到。

徐志远过去十分钟解决。

别人准备重构一段历史代码。

他一看：

“风险太大，你先别动。”

最后，所有最难的部分仍然在他手里。

团队确实越来越依赖他。

可他也越来越无法离开这些具体工作。

徐志远苦笑着说：

“最搞笑的是，领导今天还跟我说了一句话。”

“什么？”

“现在结算系统也确实离不开你，你要是转其他岗位，短期没人能接。”

两个人同时沉默。

这句话终于把整个逻辑闭环了。

不能晋升，因为影响力不足。

无法扩大影响力，因为必须继续负责原系统。

无法离开原系统，因为没人接手。

没人能接手，因为所有复杂问题最后还是他自己解决。

系统离不开他。

于是，他永远只能留在系统旁边。

三、程序员为什么会主动把自己变成单点

很多程序员并不是被强迫成为“单点”的。

最开始，甚至是主动的。

因为这种感觉很好。

别人搞不定的问题你能搞定。

领导只信任你。

关键系统只有你敢操作。

凌晨两点，所有人都在等你上线。

你会产生一种非常强烈的价值感：

我很重要。

尤其对技术人员来说。

我们不擅长复杂的人际表达。

代码和故障却会直接给反馈。

一个系统别人修不好，你修好了。

成就感非常真实。

时间久了，你开始享受这种依赖。

文档懒得写。

因为解释还不如自己改。

代码没有人评审。

因为没人比你熟。

新人问问题。

你直接告诉他答案。

别人准备处理。

你嫌他太慢：

“我来吧。”

所有事情短期效率都提高了。

但你在不断向团队写入一个隐藏规则：

遇到复杂问题，不需要学会解决，找我就行。

于是你越来越忙。

其他人越来越不懂。

最终形成一个完美闭环：

别人不会 ↓ 你自己做 ↓ 别人没有机会学 ↓ 别人更加不会 ↓ 更多事情只能你做

程序员把这种状态叫：

不可替代。

从系统设计角度看，它其实还有另一个名字：

单点故障。

任何架构师都知道，一个系统里存在单点，是重大风险。

可很多技术骨干，却亲手把自己设计成了整个团队最大的单点。

四、上一世的林川，也走过一模一样的路

林川重新活过一次后，最警惕的并不是别人甩锅。

而是自己重新变成徐志远。

因为他上一世也经历过同样的阶段。

负责会员系统以后，所有复杂需求开始找他。

最初，他很享受。

某个接口性能有问题。

他处理。

规则引擎出Bug。

他处理。

新人不知道怎么设计数据表。

他直接给方案。

线上有异常。

他第一时间上线。

慢慢地，大家产生了一个习惯：

有问题找林川。

甚至出现过这样的对话。

产品：

这个需求技术上怎么做？

开发：

先问一下林川。

测试：

这个算Bug吗？

开发：

问林川。

项目经理：

这个版本能不能上？

所有人：

看林川怎么说。

林川曾经很满足。

直到有一天，他发现自己一天参加七个会议。

没有时间写代码。

没有时间学习。

没有时间做真正重要的架构升级。

晚上八点，才能开始处理自己的任务。

他想培养新人。

可新人刚开始做得慢。

业务又催。

最后他总会忍不住说：

“我先来处理，这个后面再教你。”

那个“后面”，永远没有到来。

他也一点点把自己焊死在了系统里。

五、这一世，他第一次故意不去解决一个自己明明会的问题

周三下午。

会员系统出现一个数据同步Bug。

一名新同事小陈负责处理。

半小时后，他来到林川工位。

“川哥，能不能帮我看一下？”

“什么现象？”

“用户等级更新以后，权益没有同步。”

林川其实一听就大概知道问题。

大概率是事件消息里的旧版本号导致消费者忽略了更新。

如果他自己处理。

十分钟。

最多十五分钟。

但他没有接过键盘。

他问：

“查到哪了？”

“数据库等级已经变了。”

“权益库呢？”

“没变。”

“那中间经过哪些组件？”

“等级服务发消息，权益服务消费。”

“消息发了吗？”

“还没看。”

“那继续查。”

小陈愣了一下。

“你不帮我看看？”

“我正在帮你。”

“我是说……你直接看代码可能比较快。”

林川点头。

“我知道。”

“但今天快十分钟，下次还会继续找我。”

“你自己查可能要一个小时，但下次你就知道怎么排。”

小陈有点尴尬。

林川没有把他赶走。

而是给了一个排查框架：

第一，确认数据在哪一层开始不一致。

第二，确认事件有没有产生。

第三，确认消息有没有发送。

第四，确认消费者有没有收到。

第五，再看业务为什么没有执行。

“你按这个顺序查。”

“卡超过二十分钟，再来找我。”

小陈回去了。

四十分钟后，他突然在群里发：

找到了。生产消息里version还是旧值，消费者判断为重复事件直接忽略了。

林川回复：

把原因和排查过程整理进Wiki。

小陈问：

要写这么详细吗？

林川回答：

要。

下一个人遇到类似问题，不应该再从头问一次。

半小时后，Wiki增加了一篇：

《会员等级与权益不同步问题排查指南》

这件事看起来比林川自己处理慢了半小时。

但从团队角度，系统第一次多了第二个知道怎么排查这类问题的人。

真正的效率，从来不是今天最快解决一个问题。

而是下一次这个问题不用再找你。

六、很多技术骨干最大的错觉：我不亲自做，质量就会下降

两周后。

小陈负责一个新的会员批量升级功能。

方案评审时，林川发现设计并不完美。

小陈准备：

先查询符合条件的用户。

一次性写入升级任务。

再批量更新会员等级。

林川第一眼就看出了几个问题：

• 大数据量可能内存过高
• 批量失败后恢复困难
• 重复执行缺少幂等
• 无法精确知道每一批处理状态

上一世的林川会直接说：

“别这么做，我给你重新设计。”

然后打开白板。

十分钟后，方案变成自己的。

小陈负责照着实现。

最终项目成功。

所有人又一次证明：

还是林川技术强。

这一世，他没有直接给答案。

他问：

“如果处理到第八万条时服务挂了，怎么办？”

小陈愣住。

“重新跑？”

“那前八万会不会再执行？”

“要做幂等。”

“怎么做？”

小陈开始思考。

“给每次升级加任务号？”

“继续。”

“每个用户记录处理结果……”

“如果一次处理一百万用户呢？”

两个人讨论了四十分钟。

最后，小陈自己把方案改成：

• 主任务拆分批次
• 批次独立记录进度
• 用户维度增加幂等
• 失败批次支持重试
• 全过程可监控

方案和林川心里想的非常接近。

但有一个本质区别。

这一次不是林川设计的。

是小陈设计的。

会议结束后，小陈明显很兴奋。

“川哥，我感觉这种方式比你直接告诉我印象深多了。”

林川笑。

“因为这是你自己想出来的。”

技术负责人最难的一次升级，往往就是接受：

别人做出来的80分方案，可能比自己亲手做的95分方案更有长期价值。

如果什么都追求自己做到最好。

你永远只能放大自己的产能。

如果允许别人学习、犯小错、逐步做到80分。

你开始放大整个团队的产能。

七、徐志远第一次休了一个完整的周末

林川开始推动一件事情。

核心系统轮值。

结算系统不能再只有徐志远一个人负责。

他找到徐志远。

“把结算系统拆一下。”

“怎么拆？”

“至少培养两个人可以独立处理常见问题。”

徐志远第一反应是摇头。

“他们搞不定。”

“现在当然搞不定。”

“那线上出问题怎么办？”

“你做二线。”

“新人一线排查。”

“半小时解决不了再找你。”

徐志远苦笑。

“最后还不是我。”

“开始会。”

“但三个月以后不一定。”

徐志远没有马上同意。

他说：

“以前也培养过人。”

“后来呢？”

“业务一催，我还是自己做了。”

林川看着他。

“那问题不是他们学不会。”

“是你等不起。”

徐志远沉默。

这句话扎得很准。

很多技术骨干嘴上说：

新人带不出来。

实际上是自己无法忍受：

别人比自己慢。

别人第一次做得不够漂亮。

别人需要试错。

于是每次到了关键时刻，都重新抢回控制权。

短期看，是救火。

长期看，是不断中断培养过程。

最终结论变成：

看吧，还是没人能替我。

徐志远最后同意。

结算系统安排两名后端轮值。

第一个月。

徐志远依然被叫了十几次。

第二个月。

降到五次。

第三个月。

有一周，没人找他。

那个周五下午，他站在林川工位旁，表情有些复杂。

“这周结算一次问题都没找我。”

“挺好。”

“感觉有点失落。”

林川笑了。

他懂这种失落。

当一个人长期通过“别人需要我”确认价值，突然没人找，会产生一种奇怪的不安全感。

好像自己没那么重要了。

徐志远也笑。

“但我明天终于不用带电脑出门了。”

那周末，他带孩子去了趟郊外。

手机一直有信号。

电脑留在了家里。

这是他三年来，第一个真正意义上完整的周末。

八、真正高级的技术影响力，是你不在时系统依然能运行

三个月后。

部门负责人重新评估技术岗位职责。

这次，徐志远负责的不再只是结算系统。

他的职责变成：

交易与结算技术域负责人。

具体包括：

• 交易领域技术规划
• 核心系统治理
• 结算规范建设
• 技术人员培养
• 稳定性体系建设

原来由他一个人维护的结算系统，现在有三个人可以独立值守。

历史上只有他知道的十几个特殊逻辑，也全部进入文档和测试用例。

关键操作开始工具化。

常见故障形成Runbook。

上线流程增加自动检查。

他个人处理的事故数量下降了。

影响范围反而变大了。

年度评审前，负责人对他说：

“你这半年最大的变化，不是做了多少技术工作。”

“而是结算系统终于不依赖你一个人了。”

徐志远笑：

“以前不是说系统离不开我，说明我重要吗？”

负责人也笑了。

“重要和可晋升不是一回事。”

“一个系统只能你维护，说明你对这个系统重要。”

“一个领域因为你变得更稳定，团队能力整体提高，才说明你能承担更大的范围。”

这一次，徐志远晋升了。

没有人因为他“不再不可替代”而觉得价值下降。

恰恰相反。

他第一次从一个具体系统里走了出来。

九、程序员真正应该追求的，不是“谁都替不了我”

很多程序员都有一个很深的职业焦虑：

如果别人也会做我的事情，我是不是就不重要了？

于是本能地保护自己的技术壁垒。

关键代码只有自己懂。

部署脚本不写文档。

特殊流程放在脑子里。

所有核心任务都自己完成。

确实，这样很安全。

只要系统仍然存在，公司短期就很难失去你。

但这种安全感有一个代价：

你永远不能离开。

公司不会轻易让你去负责更大的事情。

因为你一走，原来的系统怎么办？

你的不可替代性，最后会变成一条链子。

把你和那个工位锁在一起。

真正健康的职业发展，不应该是：

只有我能做。

而应该经历三个阶段。

第一阶段：我能解决问题

这是个人能力。

别人搞不定的，我能搞定。

第二阶段：我能让别人解决问题

这是团队能力。

我可以教、带、评审、建立方法。

第三阶段：我让这类问题不再依赖具体的人

这是系统能力。

通过：

• 文档
• 工具
• 标准
• 自动化
• 监控
• 流程
• 培养机制

让任何合格的人都能够接手。

真正高级的技术人员，不是在所有地方留下自己的名字。

而是把自己的经验写进系统里。

十、林川删掉了通讯录里的“7×24小时”

周五下午。

会员系统准备做一次大版本升级。

项目经理问：

“晚上上线，你要不要留下来盯？”

林川问：

“值班是谁？”

“小陈和赵明。”

“那我不留下。”

周凯有些意外。

“这是核心版本。”

“上线手册写了吗？”

“写了。”

“回滚方案验证了吗？”

“验证了。”

“监控和告警呢？”

“全部配置好了。”

“值班人员会处理吗？”

“做过两次演练。”

林川点头。

“那我二线待命。”

“真有解决不了的问题再叫我。”

周凯笑着说：

“你现在心挺大。”

林川也笑。

上一世，他每次核心上线都必须亲自守到最后。

不是因为团队真的需要。

而是因为他不敢相信：

没有自己，事情也能做好。

那其实也是一种控制欲。

晚上十一点。

版本上线成功。

小陈在群里发：

核心指标正常，观察30分钟无异常，版本发布完成。

没人@林川。

也没有人打电话。

林川已经睡了。

第二天早上醒来，他看到群消息。

没有失落。

反而有一种从未有过的轻松。

他突然想起上一世别人最喜欢夸他的一句话：

“林川在就放心了。”

过去他觉得这是赞美。

现在他更希望有一天，大家说的是：

“这套系统本身就让人放心。”

因为如果一个团队必须依靠某个英雄才能稳定运行。

那不是英雄很强。

是系统太脆弱。

十一、不要把“被需要”误认为“被认可”

这是很多技术骨干最容易混淆的两个概念。

别人天天找你。

不代表你的职业价值正在上升。

可能只是因为：

找你最快。

你不会拒绝。

你掌握最多历史信息。

你习惯兜底。

真正能够带来职业成长的，不只是“被需要”。

而是你创造的能力能够脱离你本人持续存在。

比如：

你解决一次线上事故。

这是贡献。

你建立一套事故响应机制，让团队以后都能快速处理。

这是影响力。

你优化一个慢查询。

这是贡献。

你建立SQL审核和性能监控，让类似问题提前发现。

这是影响力。

你带一个新人完成任务。

这是贡献。

你建立培养方法，让团队可以持续产生合格开发。

这是影响力。

职位越高，组织越关注后者。

因为高级岗位最大的价值，本来就不是：

一个人干更多事情。

而是让更多事情不再必须依赖自己。

写在最后

程序员年轻的时候，很容易追求“不可替代”。

觉得公司越离不开自己，职业就越安全。

工作时间越久，才会发现：

真正舒服的状态恰恰相反。

你休假，系统正常运行。

你不在群里，团队也能解决问题。

新人不需要每天问你。

核心经验不只存在你的脑子里。

你可以离开一个项目，去负责更大的事情。

这并不意味着你变得不重要。

恰恰意味着：

你的价值已经从“一个人的能力”，升级成了“一个团队的能力”。

如果一个程序员离开三天，整个项目就停摆。

他确实很重要。

但他也很危险。

对公司危险。

对自己更危险。

因为所有人都会想：

这个人不能动。

而职业发展最需要的，恰恰是：

你能够不断离开旧位置，进入更大的位置。

林川的重启仍在继续。

下一次，他会重新遇到很多程序员都害怕的一幕。

绩效面谈时，领导拿出一张表：

“你今年做得不错，但团队必须有人拿C。”

上一世，他以为绩效只和工作表现有关。

后来才发现，有些评价从会议开始之前，就已经有了答案。

这一世，他决定不再等到结果公布之后，才开始证明自己。

本篇留一句话

真正的不可替代，不是所有事情都必须由你来做，而是你离开以后，团队仍然在使用你留下的方法继续向前。