造了个一触即崩的系统,我却摸到了进阶的契机

大飞码字 2019-05-26 11:09:00
2012年的时候,我参与了一个项目,我觉得那个项目是我职业生涯的一个转折点。经过那个时间节点后,我在能力,视野,心理上都获得了巨大的成长,也为自己后面的发展奠定了基础。

 

当年的那个转折点

 

当时产品刚刚站稳了脚,市场总算攻下来了,后台技术上,面临的问题是稳定性和成本。

 

当时的技术总监找到我和我的leader,说目前的业务发展越来越快,用户增长迅速,业务需求也多,而目前的存储存在三个问题:

 

  • 机器的性能没有充分发挥出来

  • 运维不够自动化

  • 灾备能力不够好

 

希望我们能自己研发一个。性能上要有三倍的提升,而且运维便利性和灾备能力要有质的提升。

 

当时听完,即兴奋又觉得压力山大。

 

兴奋的是可以大干一场,做个分布式存储,还是很牛B的。但对于老大提出的目标,自己心里没底,不知能不能达标。

 

之后团队就开始讨论,开始设计了。我们很快有了方案,来回跟技术总监过了几次,大家觉得方案没问题后,就开始搞了。这里,因为没有充足的时间做业务摸索和方案调研,也给后面留下了巨大的坑!

 

我用了一个月的时间,完成了编码的工作,再用了两个星期进行了各种线下测试。当时以为自己很牛B,上面给的是三个月,自己一个多月就完成了。

 

噩梦之始

 

接下来,才是噩梦的开始。

 

第一天,线上验证的结果就狠狠地打了一把脸。bug数量超出想象,而且有各种奇葩的bug。后面又花了两个星期,加固各种测试,修复bug,总用时两个月后,再次上线。

 

我小心翼翼地采用灰度的方式来进行再次的验证。找了台机器,慢慢放量,经过一个星期的时间,终于在可见范围内没有bug了。

 

后面又灰度了几台机器,在灰度到一台访问量高的机器的时候,又出问题了。机器的磁盘性能顶不住了,晚上高峰期的时候,又发现网卡流量也撑不住了。

 

当然慌得一B呀,感觉完蛋了,时间期限也快到了,性能不但没有达标,还比原来的系统差了。

 

我leader知晓这个事情后,也一起加进来,想解决的方案。我们又折腾了一周,终于搞清楚了性能问题,也想出了应对的方案。

 

后面我leader也加入进来,一起编码,一起review代码和测试。历经一个月后,再次上线。

 

那一个月,是我最难熬的时间。因为已经上线了几台机器,要回退回去,又要折腾好长时间,而且机器还要留着做性能试验。

 

所以我当时白天要写代码、测试,晚上高峰期又要盯着那一触即崩的系统,周六日也要看着。简直就是精神和体力的双重煎熬。

 

我记得有一个周六,我同学从深圳过来,吃完饭后,准备去唱K。结果手机突然收到个报警,我只能杀回公司处理 。那时候感觉这简直就是一份非人的工作,有好几次想辞职不干了。

 

不过当时又想起毕业时,导师说的,离职都不怕了,工作还有什么好怕的。于是就继续干下去了。当然心里就一个念头,要搞定它,都没想什么996了,几乎是7 *24 小时待命。

 

最后,总用时四个多月,终于发布了第一个稳定,性能达标的版本。

 

后面这个存储系统随着业的扩大,不断升级改进,最终整个部门几乎百分之九十五的业务,都使用了这套存储系统。

 

虽然我最后离开了存储团队,但那段经历让我记忆犹新。现在回过头来看,有几点感悟:

 

没有规范的流程,只有先抗住再优化

 

规范的软件开发流程,在高速发展的互联网产品部门似乎并不存在。

 

回想起当时的团队,整体开发团队好像不超过40人,而且有大量的业务需求。

 

在当时要找个专家评审团,评审一番,再做个业务调研,做个详细架构的设计,再来排期,一步一步的实施,按正常流程下来,估计要耗费一年以上的时间,等到那个时候,业务都已经凉凉了。

 

事实证明,在当时的业务快速发展,人力资源受限的情况下,先搞上去顶住,再慢慢地做优化是对的,虽然不符合传统的软件开发流程。

 

业务访问模式和存储模型的匹配

 

这个感悟跟技术强相关。当时接到这个存储系统的任务的时候,对存储模型的理解,只停留在mysql B+树的层面。

 

直到后面,才深刻的理解到,存储模型的设计是跟业务访问模式强相关的。而业务访问模式的理解,来自对业务的深刻理解和对众多子业务的归总和抽象,还有一个是对未来业务发展的预判。

 

第一点需要对已有的业务系统做深入的调研和探讨,第二点对未来的预判,需要敏锐的业务洞察力和技术预判能力。

 

所以,业务跟技术不分家,是相辅相成的。

 

被倒逼出来的技术

 

互联网技术有很多都是倒逼出来的。当时的第一个版本,你可以认为是摆不上台面的东西,只是经过各种的折腾,它终于慢慢跑了起来。

 

一开始的时候,它只用在了一个业务系统上面。但因为当时的性能在我们特定的业务场景下已经超过了mysql的性能,而且灾备能力也优于mysql,系统的口碑在团队内部就慢慢传开了。

 

一方面,我们不断地在内部兜售我们的系统,希望业务接入,另一方面,业务团队也不断的给我们提出新的需求和挑战。

 

虽然整个团队的人员一直都不多,最高峰时候,好像也不到20人,经过几年的发展,经过各种业务不断的锤炼、优化,系统却慢慢牛B了起来。

 

去年的时候,基于这个系统写了一个paper,还被顶级的存储会议 VLDB  收录。

 

虽然我那时候已经离开了存储团队,去了业务部门。不过我也感慨,当年那一坨仅仅可以跑起来的代码,如今竟成长为如此优异的一个系统,我内心也是倍感欣慰。

 

仔细地想想,也因为有了这个伟大的产品,才倒逼出了这个优异的系统和优秀的技术。

 

能力,视野,心理素质
 

 

完成那一次艰难的任务后,我并没有马上被升职,被加薪。我还是一如往常地做着个小兵,写着我的代码。

 

但我明显地感觉到,我的技术深度,技术视野和心理素质有了一个质的变化。

 

  • 在技术深度上

 

我在跟其他业务同事探讨技术方案的时候,我有时候会惊讶,“这个不是很简单吗?”,“这个不是常识吗?”,有一段时候,我有点困惑,怎么他们连这个也不懂。

 

后面我才意识到不是这些东西简单,而是因为自己一直在思考这些问题,权衡各种方案,在自己的脑海里,很多东西已经变成了一种“常识”,一种自然的逻辑。而有些同事,他没有做过基础架构的事情,所以他并不清楚。

 

  • 在技术广度上

 

我看很多其他的系统设计,似乎可以一眼看透了。跟负责人聊聊他的业务痛点,自己脑子里就自然出现了最合适的方案。

 

因为发现无论业务怎么变化,在后台架构领域,业务会遇到的问题基本都是差不多的,虽然表现形态不同,但本质其实一样。你深入理解了本质,很多设计工作,其实就是在权衡成本和收益,剩下的就是体力活了。我相信这点在其他的技术领域也是相同的。

 

  • 在心理层面上

 

我觉得那次的成长非常巨大,好像经历那次之后,自己心理上再也没有遇到更加难熬的时候。后面的工作任务中,其实也有很难的工作,但自己好像有了一种发自内心的自信,会有压力和紧张,但心里有底气,一定可以搞出来,只是时间问题。我觉得这种技术自信,也源自于那一次的历练。

 

结语

 

那是一次职业技能和心理素质双重考验和带来成长的一个经历。那个时期过后,我对技术工作突然有了很大的信心,感觉困难都是可以解决的,而且心理素质,抗压能力都获得了巨大的提升。

 

到现在,我也依然很感激那次的经历给我带来的成长。突然想起了一个兔子拔萝卜的图片,当你觉得最艰难的时候,也可能是收获最大的时候。为处于困难,处于压力中的同学们共勉!

 

 

作者:大飞码字

来源:大飞码字订阅号

dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn

最新评论
访客 2019年09月18日

请问下为什么不用logstash同步呢?

访客 2019年09月16日

写的太好了,我这就开始学

访客 2019年09月16日

Discretized Streams 就要过时了??

访客 2019年09月07日

写的就跟屎一样

访客 2019年09月01日

没看懂啊,PK的时候,没懂,怎就就从 (1,1)变成了…

活动预告