有一段时间，我突然发现：
只要我不在，很多事情就会停下来。
一个系统出了问题，要找我。
一个技术方案拿不准，要找我。
一个历史遗留问题没人知道怎么处理，还是找我。
甚至有些事情，已经不是我负责的范围了，最后还是会绕到我这里。
刚开始的时候，我其实挺享受这种感觉。
这意味着：
我很重要。
我有经验。
别人信任我。
很多事情只有我知道怎么解决。
从程序员的角度看，这甚至像是一种“技术壁垒”。
但后来有一次，我真正意识到：
这可能不是壁垒，而是单点故障。
而且，这个故障已经开始爆发了。
一开始，我把“不可替代”当成了能力
程序员很容易形成一种职业幻觉：
一个问题别人解决不了，只有自己能解决。
于是我们很容易把它理解成：
我的价值很高。
但从系统设计的角度看，还有另外一种解释：
系统对你的依赖程度太高。
这两句话，听起来很像。
实际上完全不同。
如果一个系统里只有一个人知道核心逻辑，那么这个人的确很重要。
但与此同时，他也成了系统的风险点。
就像数据库只有一个实例。
平时运行的时候，你可能觉得：
“挺稳定的。”
直到某一天：
数据库挂了。
整个系统跟着挂。
而我以前的职业状态，其实也差不多。
很多工作没有真正沉淀成流程。
很多经验没有形成文档。
很多判断没有形成标准。
很多问题解决以后，也没有留下可以复用的机制。
最后形成了一种很奇怪的状态：
事情一直在往前走，但能力没有真正从“我”迁移到“系统”。
真正的问题，是我离开以后系统怎么办
真正让我警觉的，不是哪一次加班，也不是哪一次紧急故障。
而是某一次我突然发现：
如果我连续几天不处理这些事情，很多工作真的会出现明显的停滞。
那一刻，我第一次认真问自己：
如果我明天离开这个岗位，这些事情怎么办？
这个问题让我有点不舒服。
因为我原来以为：
“我很重要。”
换一个角度看，却变成：
“这个系统太依赖我。”
这不是同一回事。
甚至有可能是完全相反的结果。
真正健康的系统，不应该因为一个人的离开就大面积瘫痪。
而真正成熟的职业能力，也不应该只是：
“我能把事情做完。”
而应该逐渐变成：
“即使我不亲自做，事情依然能够运行。”
这可能才是从执行者走向系统设计者的一个重要分界线。
单点故障真正爆发的时候，并没有什么英雄时刻
后来，类似的问题终于集中爆发。
事情一下子堆了过来。
以前一个问题，我可以自己处理。
两个问题，我也可以扛。
但当问题同时出现的时候，我开始发现：
我的处理能力，本身就是一个瓶颈。
所有事情都排队等我。
我解决一个，下一个继续进来。
我解释一次，下次还要重新解释。
我提醒一个人，下次换个人还得重新提醒。
我 review 一个问题，下一次类似的问题依然会出现。
那段时间最大的感受不是累。
而是：
我发现自己正在成为整个系统的队列。
所有事情最后都进入我的 Inbox。
而我的大脑，就是那个容量有限的消息队列。
消息越来越多。
处理速度却没有明显提高。
于是开始出现：
延迟。
积压。
遗漏。
重复沟通。
情绪消耗。
甚至开始怀疑：
“为什么所有事情最后都变成我的事情了？”
现在回头看，这个问题其实问反了。
真正应该问的是：
为什么这个系统只能靠我处理这些事情？
第一次补救：我没有继续加班，而是开始画依赖关系
以前遇到事情，我第一反应是：
解决它。
后来我开始尝试做另外一件事情：
把问题画出来。
哪些事情必须经过我？
哪些事情只是历史习惯？
哪些事情确实需要我的专业判断？
哪些事情其实别人完全可以做？
哪些事情之所以找我，只是因为没有明确的入口？
哪些事情反复发生，是因为根本没有形成机制？
这一画，我才发现：
真正需要我亲自处理的事情，其实没有想象中那么多。
大量工作之所以不断回到我这里，是因为：
系统没有设计出口。
第二次补救：把“我知道”变成“系统知道”
这是我后来做得最多的一件事情。
以前遇到问题，我知道怎么处理。
后来我开始强迫自己留下东西。
方案为什么这样设计？
某类问题应该怎么判断？
什么情况下需要升级？
哪些问题是常见风险？
Code Review 重点关注什么？
技术方案评审容易出现什么问题？
哪些事情必须提前做？
哪些事情出现以后再处理成本会非常高？
我开始慢慢把这些经验写下来。
一开始觉得很慢。
因为本来五分钟能讲清楚的事情，现在可能需要花半小时整理。
但慢慢我发现：
第一次沉淀很慢，第二次复用就很快。
再后来，有些事情甚至不需要我解释。
别人可以直接查。
可以按照规则判断。
可以按照模板执行。
可以参考历史记录。
我的经验开始从“大脑里的隐性知识”，变成“系统里的显性资产”。
这时候，我才第一次感觉到：
我不是在减少自己的价值。
而是在改变价值存在的方式。
第三次补救：开始培养“第二个我”
这是最难的一步。
因为你会发现：
把事情交出去以后，对方不可能一开始就做到和你一样。
甚至会做错。
以前遇到这种情况，我很容易重新接回来。
“算了，我自己做。”
这句话听起来很高效。
实际上，它会让系统重新回到原来的状态。
于是我开始忍住。
不是完全放手。
而是把任务拆开。
我负责判断。
对方负责执行。
第一次做错，就一起复盘。
第二次再做。
再把经验补进文档。
再把规则补进流程。
慢慢地，原来必须经过我的事情，开始有一部分可以交给别人。
然后又有一部分，可以交给机制。
最后只有真正复杂、关键、需要判断的事情才来到我这里。
这个过程其实很像软件重构。
不是把整个系统停下来重写。
而是在原系统运行的过程中，一点一点替换掉高耦合模块。
我后来才理解，“不可替代”其实有两个版本
第一个版本是：
因为只有我会，所以离不开我。
第二个版本是：
因为我建立了系统，所以这个系统离不开我创造的能力，但不依赖我亲自操作。
这两个状态，表面上都叫“重要”。
但职业风险完全不同。
前一种状态：
你越重要，越累。
你越有经验，越容易被事情绑住。
你越能解决问题，问题越容易继续找你。
后一种状态：
你的价值开始从“亲自做事情”，转向“设计事情怎么被做好”。
这时候，你才真正拥有了可迁移的能力。
当然，我并没有彻底解决这个问题
写到这里，我也不想把这个故事讲成一个漂亮的成功案例。
因为我现在依然会遇到类似的问题。
有些事情还是会找我。
有些知识还是在我的脑子里。
有些流程还是不够完善。
有些工作即使知道应该授权，真正执行的时候还是会忍不住自己上。
所以这个问题并没有被“解决”。
更准确地说：
我开始具备了识别单点故障的能力。
以前遇到问题，我只会问：
怎么把它解决？
现在我会多问一句：
为什么这个问题只能通过我解决？
这句话对我的职业状态产生了很大的影响。
我现在越来越警惕一种“看起来很安全”的职业状态
就是：
每天都有事情做。
每天都有人找。
每天都在解决问题。
每天都很忙。
每天都证明自己很重要。
但一年以后回头看：
自己依然是那个唯一的人。
事情越来越多。
经验越来越多。
责任越来越多。
但是系统并没有变得更强。
这种状态其实非常危险。
因为你会产生一种错觉：
我积累了十年经验。
实际上也可能只是：
我重复维护了十年的同一个单点。
所以现在，我会给自己的职业系统做一个检查
我会问自己几个问题：
如果我突然离开一个月，哪些事情会马上停摆？
哪些事情只有我知道？
哪些工作还停留在“靠经验”？
哪些问题已经重复出现很多次？
哪些事情每次都需要我重新解释？
哪些判断可以沉淀成规则？
哪些工作可以交给别人？
哪些能力可以变成流程？
哪些经验可以变成文档？
哪些事情最终应该变成工具？
这些问题，本质上都在问同一件事情：
我的职业能力，到底有没有从“个人能力”升级成“系统能力”？
单点故障真正可怕的，不是它会坏
而是：
你可能一直不知道自己就是那个故障点。
因为在它没有爆发之前，你甚至会因为“所有人都需要你”而产生一种职业安全感。
但真正的安全感，也许不是：
“没有我不行。”
而是：
“即使没有我，系统依然能够运行；而我可以把时间放到更高价值的问题上。”
这可能也是我40岁以后，开始重新理解“职业竞争力”的一个变化。
年轻的时候，我更关注：
我能解决什么问题？
后来我开始关注：
我能让什么问题以后不再发生？
再后来，我开始关注：
我能不能设计一个系统，让别人也能够解决这些问题？
这三句话，看起来只是工作方式的变化。
但对我来说，它其实代表着职业系统的一次小规模重构。
以前，我是那个不断被调用的函数。
现在，我开始尝试写出：
让系统不必频繁调用我的代码。
也许这才是一个程序员到了40岁以后，真正应该开始练习的一种能力。
不是让自己永远成为那个最忙的人。
而是让自己慢慢成为那个：
能够让系统变得更稳定的人。
我是语霖。/
执笔为语，心落成霖。/
希望用文字和声音，记录一个40岁程序员重新设计人生系统的过程。/
我们下期接着聊。