几年前,我还在互联网大厂加班到秃头的时候,身边有个女同事突然宣布要结婚了。那天她发朋友圈九宫格,笑得像bug被fix了一样开心。可没过一年,她又发了一条状态,只有两个字:离婚。配图是一杯孤零零的咖啡。
我当时的第一反应不是同情,而是想:这系统也太不稳定了吧。因为在我看来,现代婚姻就像一个典型的分布式系统问题,每个参与者都是一个node,有自己的state和logic。你在恋爱阶段像是在dev环境,一切都mock得很好,数据漂亮,interaction顺滑。可一到production环境,也就是结婚后,真实流量打进来,各种hidden bug就全爆了。
什么婆媳关系就是跨域调用,沟通成本高到离谱;经济压力就是资源竞争,两个service抢同一个CPU时间片,最后都timeout。我自己也差点踩坑,三十五岁那年相亲认识一个姑娘,聊得挺投机。她喜欢旅行,我说那就像microservice的scaling,水平扩展人生体验嘛。结果深入一聊,发现她的expectation和我完全不在一个consistency level。
她想要daily emotional sync,我却习惯batch processing,周末集中输出关心。几次sync失败后,我就决定不deploy这个feature了。现在想想,当时的我可能就是个bad actor in the consensus algorithm,拖累了整个group。当然,我不是说婚姻没救,系统设计里再烂的架构也能通过重构救回来。
但前提是你得承认,问题不是出在某个function,而是整个design philosophy。社会这个orchestrator,现在给婚姻这个application分配的resource越来越少,却要求它support更多features:经济独立、情感满足、个人成长、父母养老。这不就是典型的feature creep吗?最后产品经理也就是我们自己累死,user experience还差。
躺平之后我看了不少书,其中《系统之美》让我感触最深。作者德内拉·梅多斯讲的那些杠杆点,在婚姻里也适用。比如改变系统的目标,比修补具体bug有效多了。现在很多人目标是找到灵魂伴侣,这就像要求系统百分百uptime一样不现实。
换成共同维护一个还算可用的家庭集群,也许bug tolerance就高多了。不过有时候我也会推翻自己,去年有个大学同学结婚十年,孩子都上小学了,突然说要离婚,理由是没感觉了。我本来想用我的理论劝他,说这是normal degradation,定期reboot一下就好。
结果他告诉我,他老婆在外面有了新node,正在migrate state。我当时竟然有点羡慕,因为至少他系统里还有data flow,而不是我这种idle状态。毒舌一点说,那些在网上高呼爱情至上的人,大多是还没经历过production crash的。等你半夜debug孩子发烧、双方父母同时住院、自己绩效还被pua的时候,你就会明白浪漫主义就是个beautiful lie,写在README里好看,实际跑起来全是exception。
我现在的生活像一个精简过的单体应用,代码少,dependency少,维护成本低。虽然偶尔会想,如果当年多做点load test,是不是能避免一些pitfall。但谁知道呢,人生又不能AB test。你要是还在纠结要不要结婚,我给不了确定答案,因为每个人的runtime environment都不一样。
也许你适合高可用架构,我适合eventually consistent的躺平模式。总之别让别人定义你的API,先把自己的core logic写清楚再说。写着写着,说不定就找到那个能完美integrate的service了,或者发现solo mode其实也没那么坏。