当年的那个转折点

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

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

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

• 运维不够自动化

• 灾备能力不够好

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

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

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

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

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

噩梦之始

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

被倒逼出来的技术

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

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

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

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

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

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

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

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

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

• 在技术深度上

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

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

• 在技术广度上

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

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

• 在心理层面上

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

结语

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

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