这篇会详细阐述我从毕业到现在，是如何从一名业务开发，慢慢走向基础架构方向的。以及在这期间我面临的选择和思考，希望对你也有所启发。

我从 2013 年毕业来到北京，入职了一家移动互联网公司，公司体量虽然不算太大，但在业界还算小有名气（至少听过名字）。

我在学校期间的主流语言是 Java，面试也是以 Java 招进来的，但进来后发现公司大部分后端都在转向 Python，于是边学边干，我的技术栈也慢慢切换到 Python 上来。

为什么公司后端用 Python，当时得到的信息是，Python 语法简单、写代码非常快，很适合当下公司业务快速发展的节奏（当年知乎、豆瓣都是 Python 起家的）。

第 1 年的工作内容，主要是重写老旧的内部系统，这个内部系统属于工作流中的一环，用户主要是内部员工，体量也很小。

这段时间就是产品经理给需求，我来编码实现。因为刚毕业没多久，写代码也比较菜，连最基本的 SQL 调优都不会，有一次 SQL 写的有问题，还把数据库查挂了，还好内部系统影响不大。

就这样大概做了差不多一年，后来因为业务需要，需要采集一些网站的数据，我开始转向做「爬虫」，主要是抓取各种网站的数据。

Python 是写爬虫的利器，有大量开源框架和库可以用，随着数据采集需求越来越多，我主导设计出了一个通用的垂直爬虫平台（基于开源框架二次开发），通过简单配置，就可以采集到想要的数据。

因为自己算是团队里来得算比较早的一波人，慢慢负责的业务模块越来越多，逐渐成为团队的核心骨干。

在实现业务需求的同时，我的技术能力也在提高，在这期间还多次参加了公司举办的代码评审大赛（评审架构设计、代码实现），我作为团队内多次征战的选手，可谓是经历多次锤炼和毒打，这也让我的编码水平不断提升。

就这样干了 2 年多，在这期间遇到两件事，对我职业生涯的早期带来了一些变化。

第一件事是公司准备筹划「上市」。为了稳定业务和技术团队军心，公司筹划给每个研发团队的核心骨干授予「股票期权」。

给员工授予股票这件事，对于现在的互联网大厂来说已经稀松平常了，但对于当年我这种中等互联网公司，给股票的公司少之又少（现在回看公司很良心）。

那时候对公司上市、股票这些概念一窍不通，后来了解了一下才知道，公司准备在国内的 A 股上市。

玩过股票都知道，国家对于在 A 股上市公司的要求很「苛刻」，必须要求连续 3 年盈利（互联网企业都是亏损经营，能在 A 股上市大多数都是实体企业），这也是很多互联网公司只能选择在美股、港股上市的原因。

由此可见，当时公司已经有了自我造血能力，不用靠拿投资人钱活着。

在国内上市除了盈利要求，财务审核流程也非常繁琐（还要排队），所以对于准备上市的企业，一般至少要提前 2 年开始筹备。

作为团队内的核心，我也自然被授予了一些股票，当然，对于未来能变现多少一无所知，当时更多还是关注当下做的事情和短期收益。

第二件事是我的 Leader 因为业绩突出升职了。被老板任命到一个新的业务线，不再带我们团队。

这件事对我当时影响还是有的，一块共事 2 年多，加班做项目、技术攻坚、团建喝酒，我也是他一手提拔上来的（加薪、给股票），当时相处得非常愉快，突然得知他要离开，虽有遗憾但也只能祝福。

后来虽然不在一个团队，但工作中遇到一些问题，时不时也会找他请教。

就这样大概过了几个月，期间除了带了 2 个实习生之外，我负责的业务一直也没有什么变化，慢慢地工作进入倦怠期。

这时我去找了之前的 Leader 聊了聊，想让他帮我指点一些职场上的困惑，这一聊是我职场第一次变化的开始。

他表示如果对当下的工作内容不满意，只要我愿意，可以去他的团队，他那边正好也缺人。

本来是想找他聊一聊职业困惑，听他这么一说，倒是想做一些「改变」，毕竟现在已经进入舒适区挺久了。

随即表达了同意的意愿，之后他抽空找到我的 Leader 聊了下，我的 Leader 同意放人，双方达成一致，转岗在即，一切看似很顺利。

因为是跨部门转岗，需要大部门总监的同意，需要和总监聊一聊，本以为就是走个过场，结果这一聊不要紧，直接影响了我的决策。

总监提出一个建议，如果确实想动一动，除了去前 Leader 的团队，咱们大部门的其它团队也可以供你选择，你自己可以挑一个想去的团队（其实就是在大部门内调岗，而不是转到别的业务线）。

总监帮我分析了利弊，去前 Leader 的部门，因为业务刚刚起步，用户规模比较小，更多是基础业务的建设，去他那边后面可能慢慢会转向管理，技术提升可能不大。

而如果去本部门内的其它团队，可以做面向「外部」用户的后端服务，用户规模大，系统并发高，业务成熟，挑战也更大，对于技术成长更快，看你想要什么。

摆在面前的选项突然一下子多了起来，这让我又开始重新审视自己的决策，到底哪个更利于自己的发展。

一边是前 Leader 抛开的橄榄枝，一边是后端程序员都渴望的高并发系统。

挣扎了许久，我选择了在本部门调岗，选择去到公司内最为「核心」的一个研发团队。

当时我的想法是：之前一直都是做内部系统，规模和体量都比较小，内心还是比较渴望做高并发业务，想看看面对海量并发，一个后端服务究竟如何处理的，掌握这项技能，以后无论去到哪家公司，都是优势。

带着歉意给前 Leader 表达了我的想法和决定，他很遗憾也表示理解，到现在我也非常感激他，直到现在我们还是非常好的朋友，时不时约饭聊天，聊一聊近况。

就这样，在工作 3 年这个阶段，我没有选择跳槽，而是选择了内部转岗，来到了公司的核心团队，迎接新的挑战。

到了新团队，从小需求开始做起，当时 App 的日活是千万级，不算太大也不算小，后端服务的一个变动，可能影响几千万用户。

慢慢地开始接手更多的业务模块，例如营销活动、抢红包、商品分销、站内信、Feed 流等等这些需求我都做过。

在完成业务开发的同时，也看到了一个用户需求，从需求评审，到开发实现，是如何一步步呈现到用户面前的。

技术方面，从刚开始连分布式锁都不知道怎么用，到慢慢接触到重度使用 MySQL、Redis、MongoDB、RabbitMQ、Docker。

经过 2 年多业务需求的历练，这些中间件也都用得游刃有余，渐渐理解了如何设计一个支持高并发的后端系统。

应对读并发，一般就是利用缓存来抗，应对写并发，一般就是 MQ 削峰填谷，在使用这些中间件的同时，还要根据业务巧妙设计你的存储模型（兼顾低成本、高性能），来满足产品需求。

系统除了支持高并发，还要考虑高可用和稳定性，监控告警、慢日志、排障工具链等等，这些东西都在这个阶段慢慢掌握。

当然，在这期间出故障也是少不了的，从故障中学会了发布的代码必须经过严格 Review、遇到故障如何快速救火止损，明白了团队 Backup 是多么重要，以及时刻要对线上系统保持敬畏之心。

与此同时，公司的技术基础设施也在发展，公司成立了基础架构团队，配置中心、容器化平台、DevOps、流量调度、链路追踪平台也在逐渐发展和完善。

这个阶段 CTO 还发起了「异地多活」项目，由基础架构团队牵头，各业务研发团队配合，这个项目在公司内，无论是对基础架构团队还是业务研发团队，都是很大的挑战。

另一方面，经历很长时间的筹备和财务审核，公司顺利在 A 股「上市」，这意味着我的股票期权不再是一团「废纸」，上市后的第二年开始，我的股票也开始逐年变现（行业规则，一般会分 3 年分批兑现）。

在这个团队待了 2 年多，前后大大小小的业务需求做的越来越多，常见的「业务模型」基本该做的也都做过了，新的需求也都能快速搞定，这时，我又进入了舒适区和倦怠期。

不知是机缘巧合还是命中注定，老天又给了我一次选择的机会。

前面提到，公司要搞异地多活，这块涉及到很多基础设施的建设，如自研中间件、开源框架二次的开发等等，这些工作都是基础架构团队的事情。

当时基础架构团队压力大，短期招不上来人，多活项目进度推进缓慢。

有一个在基础架构团队和我关系还不错的同事（曾经在一个组，经常一起下班），有一次下班路上他跟我说：你要是觉得现在工作没啥意思了，要不考虑来我们团队？我们这事多人少急需人，来了和我一起搞中间件。

当时我的一个反应：你开玩笑吧，你们搞的那些中间件都很底层，难度大，恐怕我也玩不转呀。

同事表示其实也没啥难的，刚开始都觉得难，谁不是边学边做过来的。但我当时我只当他随意说说，没往心里去。

同样的场景，又发生了两三次，他一度邀请我是和他一块搞事情，这时，我才开始慎重考虑这件事。

又到了做选择的时刻，进入舒适区许久，成长缓慢，面前有一个可以让我成长的地方，当然，困难也是史无前例的，到底要不要去？

如果不去，可能一直就这样平淡下去，如果去，压力是显而易见的，不过反过来想，再差也能学到点东西吧，更何况有熟悉的人带你。

和这个同事详细沟通了那边需要做的事情和挑战，考虑了许久，虽然觉得压力会很大，最终还是下定决心去试一试。

同事拿到到我决定后，找他的 Leader 推荐我，他的 Leader 评估了我之前的工作表现感觉还可以，另外有同事的背书，表示没啥意见后，我跟我的 Leader 提出了调岗申请。

Leader 表示很惊讶，感觉业务开发做得好好的，为什么要转岗，挽留的同时，也对我的选择表示「质疑」，他也觉得我去搞中间件难度太大，可能扛不住。

真的会扛不住吗？我也不清楚（还是有点怀疑自己），既然决定了，那就硬着头皮试试看吧。最终 Leader 只能放人，双方谈妥，没多久做了交接。

在工作 5 年之际，我从舒适区又踏入了「挑战区」，从一名业务研发，转向基础架构方向。

来到新团队，我的技术栈从 Python 转向了 Go，从写一些运维工具开始做起，平时还负责一些线上 Redis 的问题定位，以及协助运维团队处理问题。

中间件我挑了 Redis 这个方向来做，众所周知缓存是高并发的利器，在高并发场景下业务非常依赖 Redis，选择这个方向突破，也是考虑到未来无论走到哪里，都有需求和市场。

虽然之前写业务代码使用 Redis 已经比较熟了，但到了这个团队，要求更高更深入，最好从底层原理甚至「源码」层面全面了解 Redis 才行。

果然，硬着头皮上是有代价的，在刚开始的前 3 个月，非常痛苦，碰到线上问题一脸懵逼，不知道如何下手，而且多数都是很紧急的问题，每次都要请教同事，多数情况下，我连分析问题的思路都没有。

记得那段时期，每天上班心情如上坟，压力非常大，有点后悔当初做的这个决定，时不时怀疑自己究竟适不适合做这个方向，还不如老老实实回去写业务代码。

压力虽然大，但摆在面前的问题还是要想办法解决，静下心来想一想，说到底还是自己的底层知识储备不够。

问题搞不定怎么办？没办法，只能恶补底层知识。

数据结构、网络协议、操作系统、分布式系统，之前这些东西觉得写业务代码够用就行，也没有太深挖原理，现在可没法再糊弄自己的了，只能老老实实一步步再深入啃一遍，之前会的这次继续深挖（不能局限在八股文层面），不会的就重新开始学。

面对压力，我斗志也被激发出来了，记得有很长一段时间里，工作日的晚上和周末，基本都在充电学习。

慢慢地，遇到问题不再慌了，从手足无措到有沉着冷静的分析问题，给出解决方案，在这个阶段深深感受到，理论与实战的结合非常重要。

在排查问题过程中，也让我学会了遇到问题一定要追溯根因，不能模棱两可糊弄过去，要把整个问题链条都搞清楚，否则下次还会掉到这个坑里去。

例如，业务反馈读写 Redis 延迟高，你得能从业务侧到网络层，再到 Redis 侧，甚至内核层都要清楚，数据是怎么流转的，可能受到什么因素影响，再结合 Redis 自身的特性，来分析定位潜在的问题。

记得有很多个夜晚，和同事定位问题到深夜。

定位根因虽然很难，但每搞定一次就能把整个链路都打通（业务端、网络层、中间件、操作系统），对自己提升非常大。

这里也非常感激我的这个同事带我，他算是我职业道路上的第 2 个贵人，第 1 个贵人是前面提到的前 Leader。

补齐技术短板之后，我慢慢开始接手 Redis 中间件的二次开发、异地多活组件建设、Codis（开源的 Redis 集群方案）异地多活二次开发等等。

因为要围绕 Redis 做中间件，以及 Codis 的二次开发，这段时间上班经常看 Redis 和 Codis 源码，开发中碰到问题，本能的反应是先去翻源码，这个阶段看中间件源码成了家常便饭（当时还发现很多 Redis 低版本的 Bug）。

就这样搞了近 2 年，我们团队把整个异地多活基础设施搭建起来了，取得了阶段性成果。

虽然不是很完美，但基于当时的业务场景，当一个机房故障时，另一个机房可以随时接管全部流量，完成容灾切换。另外，平时还可以根据业务粒度，把流量在不同机房之间做分配和切换，达到容灾演练的目的。

另一方面，在基础架构团队的这 2 年时间里，我的股票也「全部」套现完成。

我所从事的第一家公司，从内部系统开发，到高并发后端系统，再到基础架构，经历 3 个技术团队，一共待了 7 年之久，这 7 年时间里，我的技术一直在成长。

算了一下，在这家公司里，我基本上把公司核心后端技术团队待了个遍（除大数据团队外）。

这时，感觉自己的成长在这个公司基本已经到了「天花板」，7 年没有跳槽，想着也该换一换新的环境了，然后，我选择了裸辞。

是的，我没有找到下家再离开，而是直接选择了裸辞。

当时股票全部套现完成，资金上暂时也没什么压力。另外因为这么多年多没换过公司，这次想给自己先「放个假」休息一下。

本来想着休息 2 个月就开始找工作，结果拖延症犯了，一下子休息了半年之久。

当然，这半年我也没完全闲着，这个公众号前期的那些硬核文章，基本都是在这个阶段写的，那段时间沉浸在写文章的「乐趣」当中，花 2 周甚至更久写一篇硬核技术文，是常有的事。

这个阶段我的公众号读者也迎来爆发性增长，关注的人越来越多，我对自己的写作要求也越来越高，写作水平也在提升。写公众号的同时，还会学一些运营、商务上的知识，也挺有意思。

这段期间，我还被邀请参与了一场技术分享的录制、一次技术直播，也逐渐有了些技术影响力。

为什么坚持写文章？工作这么久，我觉得我的每个阶段都会有一些收获，我想通过文章把自己的这些技术和经验梳理出来，也算是对我程序人生道路上的阶段性沉淀和总结。

例如，做 Redis 中间件这么久，踩了很多坑，也积累不少的实战经验，所以才有了那么多篇硬核的《Redis 实战文章》。

做过了异地多活系统，我看业界基本没有讲异地多活的入门文章，我就想从头到尾梳理了一下做多活的技术难点，以及业界常见的解决方案，尽力做到阅读门槛低，深入浅出。然后才有了那篇爆款文章《搞懂异地多活，看这篇就够了》。

边写文章边休息了半年，然后开始找工作，经过 2 个月刷题、面试，最终拿到腾讯 Offer，来到了现在的鹅厂。

选择腾讯的原因其实也比较简单，一是因为是大厂背景，在中等体量公司干了这么久，还是挺想来大厂看看，另一面我的学历比较差，来大厂也能在职业履历上给自己做一些弥补。

二是做的方向还是中间件，但这次是结合云原生。云原生、云计算是近几年一直很火的方向，也是大趋势所在。中间件可以持续发挥自己的优势，中间件 + 云原生这两个加在一起，想看看能碰撞出什么火花。

然后就是你看到我上篇总结的来腾讯 1 年多的感受了，关于在鹅厂更多的工作细节，我也正在学习和经历中，等后面有些阶段性成果后，再给你分享。

以上，就是我近 10 年的程序人生阶段性总结和回顾。

当然，这些年除了提升技术外，我还涉猎学习了其它领域，例如经济、金融、商业、投资、自媒体。

曾经有段时间系统学习了「投资」方面的知识，自己也一直在按照自己总结出来的投资框架持续实践。

自媒体写作也算是一种新的尝试，一方面可以让我深度思考，另一方面探寻程序人生的更多可能性。

如果让我给近 10 年的工作经历做个总结，有以下几点心得分享给你。

1、第一份工作经历还是比较幸运的，遇到了不错的团队和 Leader，如果非要我评价，我只能说运气好，毕业就赶上了移动互联网的红利，赶上了公司高速发展的阶段，在机会来临时，能紧紧抓住这些机会，技术 + 金钱都在持续收获。

2、回顾工作这近 10 年，我时刻牢记一个主题，就是要让自己持续「成长」，进入舒适区太久，要保持警惕，敢于迈出舒适区，迎接新挑战，只要痛苦和挫折才会让自己更加强大。

3、在让自己成长面前，不要太在意薪资和别人的眼光，分清楚孰轻孰重。自己能力持续提升，市场自然会补足你匹配能力的薪资，别人的看法也自然会有转变，一切只是时间问题。

4、努力上一艘大船，互联网是大船，核心团队是大船，稀缺的技术也是大船，大厂是大船，对中国经济有信心也是大船，我本身并不是特别拼的那种人，知道自己做不到某个方向顶尖，那就选择抓住这些机遇，做不到单个领域 90 分，那就努力做到「多领域」80 分，这个难度应该不怎么高。

5、不要给自己「设限」，机会总是伴随着风险和挑战，人的成长来源于一个个舒适区到挑战区的磨练，还没开始就说自己不行，机会来了你也抓不住。这个世界是符合二八定律的，80% 的人甘于平庸，稍微努力点就能成为那 20% 的人。

6、要保持「耐心」，不要太急于求成。我每次换到一个新团队，都会有半年到一年多的适应期，不适应、有抵触情绪，这个再正常不过，想在一个新领域做出些成绩，至少要以半年到 1 年为时间周期来看，所以我也不建议「高频率」的跳槽，可能你还没到开始积累的时候，就把自己的机会放弃掉了。

7、除了提升技术外，还要学会提高自己的「认知」，面对选择如何做出有利自己的决策，首先你要有足够多的高质量信息，然后才是分析和判断。高质量信息哪里来？读书、专栏、牛人的经验（付费也就成了顺理成章的事情），这些东西虽然不能帮你快速变现，但在你做选择时，都会潜移默化地给你分析问题的依据。

8、这也是我最近写公众号的新思路，不再是只输出技术文，我觉得技术人到一定阶段，如果技术还只是他的全部，我认为是比较失败的。自己的经验、思考、观点、认知，我觉得更重要，所以我后面还会分享更多自己的思考，例如读了什么书、有什么新的想法。

希望我的这些经历和思考，对你也有所启发，共勉。