客户端工程师创业踩坑：冷启动与基建实战复盘

　　去年国庆节那会儿，老张他们组搞的那个客户端创业项目，不是崩了么？我原以为冷启动最多就是没人用，结果他们连接口都扛不住——用户量刚到三位数，注册接口就开始超时，监控大盘上那条绿色的线抖得跟帕金森似的，日志刷得比咖啡机漏水还快，根本看不清堆栈。

　　老张当时在工位上拍桌子，说“这破接口怎么连灰度都扛不住？”我凑过去看，发现他连限流都没加——客户端工程师写后端，总觉得“用户量小不用搞这些”，结果被现实教做人。他后来跟我吐槽：“我原以为冷启动就是慢慢拉新，结果第一天就被羊毛党薅了三百次注册接口，缓存击穿得跟筛子似的。”

　　运维小王在旁边插嘴：“你们表结构也没设计好，用户表里连个‘是否羊毛党’字段都没有，回滚的时候脏数据混着正常数据，查了半天才理清楚。”老张气得直挠头：“我哪知道冷启动会来这么多机器注册？我以为最多几十个真人！”

　　这时候咖啡机突然“嗡”地响了一声——坏了。全组人盯着那台老古董，外卖筷子掉在地上的声音都显得格外刺耳。老张叹了口气：“算了，先回滚到昨天的版本吧，反正今天也没几个真实用户。”

　　可回滚完更糟——定时任务没做幂等，重复发了三百条欢迎短信，产品经理在群里狂@老张：“用户投诉说被骚扰了！”老张一边改代码一边骂：“这破项目，连个基本的限流和幂等都没有，活该被淘汰。”

　　我原以为客户端工程师搞后端，最多就是代码风格野点，结果发现他们连最基本的基建意识都没有——比如监控，他们只接了接口耗时，没接错误率；比如日志，他们只打 INFO 级，连 DEBUG 都不留；比如缓存，他们用 Redis 连键名都不统一，有的用下划线，有的用驼峰，查问题的时候得猜半天。

　　最搞笑的是，他们为了“快速迭代”，连数据库连接池都没调，默认值 10 个连接，用户量一上来就挤爆，MySQL 慢查询堆得比工位隔断上的便签还高——那些便签还是老张去年贴的，现在早卷了边，没人记得上面写了什么。

　　老张后来跟我复盘，说“冷启动不是光拉新，得先把基建扛住”。我补刀：“你们连最基本的接口超时处理都没做，用户量一上来，不是崩就是慢，谁愿意用？”他点头：“是啊，我原以为客户端和后端差不多，结果发现差得远——客户端只要自己跑通就行，后端得扛住所有人的请求，连羊毛党都得防。”

　　这时候产品经理路过，听见我们聊天，插嘴：“其实最坑的是需求变来变去——昨天说要加分享功能，今天说要加排行榜，明天说要加社交，表结构改了八遍，最后连主键都变了，老张你们后端不得疯？”

　　老张苦笑：“何止疯？我们连灰度发布都没做，改个需求就得全量上线，出问题只能回滚，回滚完脏数据又得清理，清理完监控又得重新配——这哪是创业？这是填坑。”

　　运维小王在旁边翻白眼：“你们还算好的，至少代码在自己手里。我上次接手一个老系统，表结构连文档都没有，字段含义全靠猜，有个‘status’字段，取值是 0/1/2/3，问原开发说‘0 是未处理，1 是处理中，2 是处理完，3 是…’他想了半天，说‘3 是备用状态，暂时没用’——结果后来发现，3 是‘处理失败但不想让用户知道’。”

文章配图，仅供参考

　　我补了一句：“而且客户端工程师搞后端，容易犯两个错：一是觉得‘用户量小不用搞基建’，二是觉得‘后端和客户端差不多’。其实差远了——后端得扛住所有人的请求，连羊毛党都得防，连产品经理的变态需求都得接，连运维的奇葩配置都得适配，连历史代码的祖传逻辑都得理清楚——这哪是写代码？这是打仗。”

　　老张点头：“是啊，我原以为创业是写代码，结果发现是填坑——冷启动的坑、基建的坑、需求的坑、运维的坑，填完一个还有一个，填不完就得死。”

　　这时候咖啡机突然“嗡”地又响了一声——还是坏的。全组人盯着那台机器，外卖筷子掉在地上的声音又响了一次。老张叹了口气：“算了，先点外卖吧，填坑也得吃饭。”

　　我后来想，老张他们项目死得不算冤——优胜劣汰，基建太烂的项目，活该被淘汰。但我也有点后怕——如果是我去创业，会不会也犯同样的错？比如觉得“用户量小不用搞限流”，比如觉得“后端和客户端差不多”，比如觉得“监控日志随便配就行”？

　　可能吧。所以我现在写接口，哪怕用户量小，也会加限流、幂等、监控、日志——不是为了应付用户量大的情况，是为了应付自己懒的情况。毕竟，填坑的滋味，谁填谁知道。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!