关于技术探索与实践的一些经验
本文作者：快手6年老架构师，从0到1搭过消息中台、推荐引擎和直播推流系统。目前在快手某核心组搬砖快2年，日常Mac开发 + 偶尔Windows测试，代码洁癖晚期患者。
上个月刷脉脉，看到一条热帖：“35岁还在写业务代码，是不是该焦虑了？”
我默默点了个赞，然后关掉页面继续改PR——因为产品刚在群里@我说“这个需求双11前必须上线”。
其实我也焦虑。但不是因为年龄，而是每次面试候选人，问起“最近在探索什么新技术”，回答要么是“没时间学”，要么是“公司不让用”。
技术人最怕的不是不会，而是不敢试。
今天这篇不讲大道理，就说说我这两年在快手折腾的一些事，以及为什么我觉得“技术探索”不该只是简历上的装饰品。
一不小心，成了“技术债回收专员”
去年年初，我们组接手了一个三年前的老直播后台。那代码……怎么说呢，像是产品经理拿Excel画完流程图后直接扔给实习生写的。
- 模块耦合度高得离谱，改一个功能要动五个服务
- 日志格式五花八门，ELK里查个错误像玩扫雷
- 最骚的是，居然用Redis当消息队列，还美其名曰“轻量级方案”
当时CTO来review，看了一眼监控面板就摇头：“这系统再跑半年，双11怕是要上热搜。”
于是，我和两个兄弟接下了重构任务。Deadline？一个月后。理由？“业务不能停，但也不能死。”
技术选型：不是越新越好，而是“刚好能活”
我们没盲目上Service Mesh或FaaS，而是做了三件事：
- 拆单体为微服务：用Go重写了核心推流逻辑（Java太重，Node.js扛不住高并发）
- 引入Kafka替代Redis队列：虽然运维大哥一开始说“又要学新东西”，但看到Redis内存飙升到80%后立马真香
- 统一日志规范：强制所有服务输出JSON格式，字段对齐，TraceID贯穿全链路
# log.yaml 示例
level: info
format: json
fields:
- trace_id
- service_name
- request_id
- timestamp
说实话，过程中踩了不少坑。比如Kafka consumer group rebalance 导致重复消费，差点把用户打赏记录发两遍——还好测试同学眼尖，在预发环境拦住了。
但最大的收获不是系统稳定了，而是团队开始相信“重构不是浪费时间”。以前PM一听“重构”就摆手：“别整虚的，先做需求。”现在他们会主动问：“这块能不能顺便优化下？”
被逼出来的“全栈视野”
很多人以为架构师就是画PPT、定规范。其实不然。在快手，架构师往往得自己撸代码、自己压测、自己半夜被PagerDuty叫醒。
去年双11前夕，我们压测发现新推荐服务TPS卡在5k上不去。查了一整天，最后发现瓶颈在数据库连接池——配置还是默认的20。
// 错误示范（别学我）
db, _ := sql.Open("mysql", dsn)
db.SetMaxOpenConns(20) // 默认值，生产环境等于自杀
改成500后，TPS直接飙到3w+。那一刻我深刻体会到：架构设计不能只停留在画框框连线，必须深入到每一行配置、每一个参数。
这也让我意识到，综合能力比单一技术栈更重要。你会K8s但不懂网络调优？上线照样被打脸。你精通算法但不会看GC日志？性能问题永远在表面打转。
所以这两年，我逼自己：
- 学了点eBPF，用来抓内核级网络延迟
- 看了Linux性能之巅，搞懂了cgroup和OOM Killer
- 甚至去学了点前端，至少能看懂React组件怎么和后端API对接
不是为了转岗，而是避免成为“纸上谈兵”的架构师。毕竟，代码人生不是写PPT，是写能跑、能扛、能救火的代码。
求职时，别只秀“我会什么”
上周帮HR筛简历，看到一份特别亮眼的：
“精通Spring Cloud、Kafka、Redis、Elasticsearch、Prometheus、Istio……”
我反手就问了个问题：“如果Kafka消费者突然积压100万条，你怎么排查？”
对方回：“重启消费者？”
……好吧。
技术探索的价值，不在于你用了多少新框架，而在于你能否用它们解决真实问题。
我在快手面试时，更看重候选人是否具备“问题驱动”的思维。比如：
- 遇到慢查询，会不会主动看执行计划？
- 服务超时，会不会查链路追踪+线程堆栈？
- 甚至，会不会在本地用wrk压个测？
有一次招人，一个候选人说自己用Rust重写了公司内部的一个ETL工具，性能提升8倍。我让他现场讲设计思路，他掏出笔记本（Mac，好评），打开tmux分屏，一边敲perf top一边解释缓存局部性优化——当场offer。
求职不是罗列技术栈，而是展示你如何用技术创造价值。
代码人生：写代码，也写自己的成长路径
有人说，程序员35岁就该转管理。我不这么认为。
我在快手认识不少40+的同事，依然活跃在一线：有人专注数据库内核优化，有人深耕音视频编解码，还有人天天和K8s operator死磕。
他们的共同点是什么？持续探索，且乐在其中。
我自己也有过迷茫期。2021年那会儿，觉得“架构”就是搭架子，结果线上出了次P0事故——因为没考虑到NTP时间同步偏差导致分布式锁失效。那天凌晨三点，我和运维蹲在机房看日志，他幽幽来一句：“你这架构，缺了点地气啊。”
从那以后，我给自己定了个规矩：每个季度，必须亲手做一个小工具或实验项目。不为上线，只为保持手感。
比如上个月，我用Go写了个简易的APM agent，自动采集goroutine阻塞、GC pause等指标。虽然没进生产，但帮我理解了pprof底层原理。这种“无用之用”，反而成了面试时最能打动人的故事。
写在最后：技术探索不是奢侈，而是生存必需
回到开头那个问题：35岁还在写代码，焦虑吗？
我的答案是：只要还在解决问题，就值得骄傲。
在快手这两年，我见过太多“稳妥派”——用着三年前的技术栈，拒绝任何变更，美其名曰“稳定”。结果业务一增长，系统直接崩盘，还得返工重做。
而那些愿意尝试新方案、哪怕失败几次的人，反而成了团队的中坚力量。
所以，别等公司给你“学习时间”。每天抽半小时看一篇RFC，周末跑个demo，甚至在GitHub上给开源项目提个PR。技术人的护城河，从来不是年龄，而是持续进化的能力。
至于求职？当你能清晰说出“我用XX技术解决了XX问题，带来XX收益”，简历自然发光。
毕竟，代码人生，不是复制粘贴的人生，而是不断debug、不断commit、不断merge的成长史。
P.S. 上周五晚上又加班到十点，产品说“这个需求很简单，就加个开关”。
我微笑着打开VS Code，心里默念：
“简单的需求，往往藏着最深的坑。”
—— 一个还在写代码的快手架构师
评论 0