今天，我终于鼓起勇气提了离职。

真正说出口的时候，并没有想象中那么激动，更多的是一种终于可以结束了的感觉。在这里，连年假都很难真正休息好，待遇也算不上好。过去这一年，我一直想着再坚持看看，看看事情会不会变好，看看自己还能不能从这里得到一些新的东西。但到了今天，我觉得，对于国产数据库的这段探索，已经到了应该告别的时候。

最开始，我确实对国产数据库抱有很大的兴趣。真正进入这个行业以后，我才逐渐意识到，国产数据库很大程度上是一种政策红利。在没有外部因素驱动的情况下，中国企业天然更愿意使用免费的 MySQL 和 PostgreSQL。它们成熟、便宜、生态完善，人才储备丰富，也足以解决绝大多数企业的问题。国产数据库真正需要证明的，从来不只是“我们也能做一个数据库”，而是为什么客户应该放弃那些已经足够好、甚至免费的东西，转而为你付费。当外部驱动力消失以后，这个问题就会变得格外现实。

这一年里，我也接触了很多听起来很好的技术概念，比如超融合。超融合当然是一个很好的概念，把更多东西整合起来，减少机器、减少组件、减少维护成本，本质上都是为了降本增效。但后来我越来越意识到，降本从来不是没有代价的。当越来越多的东西集中在一起，复杂度和风险也会随之集中，省掉了一部分成本，却可能增加新的单点风险。所以后来再看一个技术方案，我已经不太在意它听起来有多先进，而更关心几个很朴素的问题：它到底省掉了什么，又增加了什么风险，以及真正出了问题以后，到底谁来兜底？

“谁来兜底”这个问题，后来也贯穿了我在这里工作的很多经历。

我做过无数次售后。做得越多，我越觉得公司的文档做得一坨屎。最开始我会把它理解成一个单纯的文档建设问题，觉得只是文档写得不好、覆盖不全、维护得不够及时。但做久以后，我才慢慢发现，文档做不好很多时候只是表象，因为如果一个产品连自己的错误体系都没有标准化，文档本身就很难真正建设起来。

大量错误没有稳定、标准的错误码，很多东西最终依赖的还是字符串匹配。看到某一串报错，再依靠人的经验判断这是什么问题、可能是什么原因、应该检查什么、最后应该执行什么操作。这在我看来其实是一件很 Low 的事情。如果从一开始就有标准化的错误码，那么错误、日志、文档、知识库、监控、告警、自动诊断，甚至整个售后流程，本来都是可以串起来的。一个错误发生以后，人不应该每一次都重新从一段字符串里理解世界，而应该有一个确定的 ID。沿着这个 ID，可以知道它是什么、为什么发生、应该检查什么、如何解决，甚至进一步把其中一部分诊断和处置自动化。

如果这个基础存在，那么研发、产品、文档、售后之间就可以形成一条完整的链路。售后遇到的问题可以沉淀，研发产生的错误可以被准确描述，文档可以围绕稳定的错误定义组织，监控和知识库也可以直接关联，而不是所有经验最终散落在人的脑子、聊天记录和一篇篇彼此孤立的文档里。错误码只是一个看起来很小的东西，但它背后体现的其实是一个产品有没有真正建立起自己的工程体系。以前的我只是觉得文档不好，后来才发现，文档不好可能只是更深层问题表现出来的一个结果。

而在无数次售后和研发任务之间，我也越来越疲惫。我经常觉得自己像一条 Node.js 的主线程。主线程本来就在不停进行 CPU 计算，这时候突然有一个 Event 进来了，于是马上切换 Context，开始处理这个 Event；处理完以后，再切回去继续刚才的 CPU 计算。还没有处理多久，下一个 Event 又进来了，于是再次切换 Context。

售后、研发、客户、项目、故障、临时需求，就像一个个不断进入 Event Loop 的事件。人几乎没有真正的空闲时间。最可怕的甚至不是单纯的事情多，而是不同场景之间不断发生的 Context Switch。刚刚还在思考代码里的状态机，下一分钟就开始排查客户数据库；刚刚理解完一个研发问题，又有另一个客户现场着火了；好不容易把那个问题处理完，再回过头来，还得努力回忆十几分钟前自己到底写到了哪里、当时脑子里的那套 Context 又是什么。

主线程一直在进行 CPU 计算，Event 一进来就迅速切换 Context，处理完 Event 再继续 CPU 计算。表面上看，线程从来没有闲下来，CPU Utilization 甚至可能非常漂亮，但人终究不是 CPU。对于人来说，每一次 Context Switch 都有成本，而当这样的切换持续发生，人实际上很难再进行真正长时间、完整而深入的思考。更重要的是，人需要 Idle。一个人不应该因为队列里永远还有 Event，就永远不能停下来。

这种疲惫之外，还有一种一直伴随着我的感觉，就是没有安全感，因为很多时候我知道身后并没有人兜底。

公司让我承接一个原有的项目，因为带我的 Tech Leader 离职了。那时候其实我就已经产生了跑路的念头。一个刚刚开始承接项目的人，突然失去了本来应该带着自己往前走的人，很难不去想接下来出了问题怎么办。但当时我还是想着再坚持看看，也许项目能够做起来，也许事情会慢慢变好，也许自己真的可以把它扛下来。

后来事实证明，我确实扛下来了很多东西。但也是在这个过程中，我逐渐意识到，“我能够扛下来”和“这件事情应该让我来扛”，其实是完全不同的两件事。一个人有能力兜底，不代表组织就应该默认这个人永远可以兜底；一个人曾经成功救过一次火，也不意味着以后所有的火都应该继续让这个人去救。

有一次，我去客户现场，本来的任务很简单，就是把眼前这个客户的问题处理好，但处理着处理着，其他地方又开始着火。于是出现了一个现在回想起来都有些荒谬的场景：我坐在一个客户的现场，当着这个客户的面，开始处理另一个客户的问题。

我当然知道正常情况下应该怎么做。应该把另一个客户的问题扔给其他人，让其他人先接手，我继续专注于眼前的客户。但问题是，没有人。或者更准确地说，当时没有任何人能够腾出手来处理这些事情，所以最后还是只能由我来。

最终的结果其实很好。现场客户的问题搞定了，另一边的火也救完了。从结果导向来看，这甚至可以算一次很成功的处理：所有事情都解决了，我似乎又一次证明了自己能够解决问题，也能够在混乱的时候把事情兜住。出差结束的时候，我并不开心。

因为我开始意识到，“最后所有事情都解决了”并不能证明这种工作方式是正确的。它可能仅仅证明，这一次还有一个人没有被压垮。

还有一次是在晚上。那天我已经工作完了，刚刚 Commit 了一下代码，洗完澡，准备睡觉。这个时候合作伙伴的东西突然出了问题，客户 On-call 找到了我。于是已经合上的电脑又重新打开，我开始陪着合作伙伴排查故障、处理问题，还要一起面对客户，处置客户舆情。本来已经结束的一天，就这样重新开始运行。

那一刻其实没有什么特别复杂的情绪，也没有愤怒到想立刻做些什么。我只是坐在那里，很明确地感觉到：我已经累了。

以前的我可能会觉得，能解决问题是一种能力，能在客户现场把事情兜住是一种价值，别人解决不了的问题最后找到我，也说明我足够重要。这些当然都是真的，我也并不否认这些经历给我带来的成长。但后来我逐渐意识到，另一件事情同样是真的：一个系统不能永远依赖某几个组件超负荷运行来维持所谓的高可用。

如果一个系统没有冗余，没有隔离，没有限流，没有清晰的责任边界，只是不断告诉其中某一个节点“你再坚持一下”，那不叫高可用，只是故障还没有发生而已。

组织其实也是一样的。

一个人能够扛，不意味着应该一直让他扛；一个人能够救火，也不能成为组织不建设消防系统的理由；一个人能够兜底，更不能意味着所有没有明确 Owner、没有人处理、临时出现的问题都可以理所当然地堆到他的身上。如果一个组织的稳定运行依赖某几个人永远在线、永远能够响应、永远不会疲惫，那么这个组织本身就和一个没有冗余的系统没有什么区别。

所以今天提离职，并不是因为某一个瞬间突然受不了了。更像是过去这一年里，一个又一个 Event 不断进入队列，一次又一次 Context Switch，一次又一次 On-call，一次又一次客户现场，一次又一次救火，一次又一次“现在没人了，只能你上”，最终全部累积到了这里。

也是到了这个时候，我越来越相信一件非常简单的事情：允许人休息，才是一个公司最基本的人文价值。

而这种价值不应该是一种特许。

休息不应该是一种奖励，也不应该只有当“事情全部做完了”“客户不再找你了”“线上没有故障了”“终于有人能够替你兜底了”以后，一个人才终于获得休息的资格。因为事情永远做不完，Event 永远还会进来，客户永远可能有新的问题，代码永远还有下一行。如果休息的前提是队列必须清空，那么人就永远不可能真正休息。

所以允许人休息，不应该是某个管理者心情好时给予的恩赐，也不应该是只有少数人才能获得的特许。它应该是一种普世的价值。人不应该因为自己能扛，就理所当然地一直扛下去；也不应该因为自己重要，就失去下班、休假，以及晚上洗完澡以后能够安心睡觉的权利。

一个真正健康的组织，不应该以某个人永远在线为前提运行。就像一个真正高可用的系统，也不会把自己的可靠性建立在“这个节点绝对不会宕机”这样的假设之上。机器需要冗余，人也需要；系统需要限流，人也需要；系统需要故障隔离，人同样需要自己的边界。

回过头来看，我并不后悔来到这里，也不觉得这一段时间被浪费了。

我真正接触了数据库，接触了 Greenplum，做过研发，也做过售后；写过代码，做过产品，也去过客户现场；处理过线上故障，面对过真实的客户，也真正见过一个商业数据库产品是怎么研发、怎么交付、怎么运转，又是怎么被客户真正使用的。我见过一个问题从研发内部一路传递到客户现场是什么样子，也亲自经历过一个看起来很小的工程问题，最后如何变成售后的巨大成本。

那些无数次救火，也让我开始从另一个角度理解工程。技术从来不只是把代码写出来，高可用也从来不只是机器的高可用。一个好的系统需要错误码，需要可观测性，需要文档，需要明确的责任边界，需要冗余，需要故障隔离，也需要一个节点失效以后，另一个节点能够自然地接替它，而不是祈祷原来的节点永远不要倒下。

组织其实也是一个系统，而人是这个系统里最不应该被当成机器使用的部分。

这一程，我见过国产数据库的理想，也见过它真正落到客户现场之后的样子；见过技术上的可能性，也见过商业、产品、工程和组织现实留下来的限制。我认真地做过，也真的解决过很多问题，所以到了离开的时候，我并没有觉得有什么遗憾。

只是到了今天，我觉得已经够了。

对于国产数据库，认真地来过，认真地做过，也从这里带走了属于自己的东西，然后在应该告别的时候，认真地告别。

接下来，我想去看看别的东西，也想重新找回一点属于自己的生活。

至少下一份工作，我希望自己不再是一条永远不能阻塞、不能崩溃、不能下线，甚至不能休息的主线程。

允许自己停下来，并不是因为我扛不住了。

只是因为我终于明白，人本来就不应该被当成一台永远运行的机器。