十年前 我在抓虾(5)

导语：在去抓虾以前，我的关注点主要集中在开发上。写好代码，能跑起来，工作就算完成了。但是去了抓虾之后我才发现，工业级的程序不是这么玩的。首先所有的服务程序都有专门的启动程序，保证真正的程序不死，死了也能迅

在去抓虾以前，我的关注点主要集中在开发上。写好代码，能跑起来，工作就算完成了。但是去了抓虾之后我才发现，工业级的程序不是这么玩的。首先所有的服务程序都有专门的启动程序，保证真正的程序不死，死了也能迅速重启。同时，所有的程序运行的状态，也必须一目了然，不但要有实时查看，还要有日报、周报等等各种报表。

这相当于一边写程序一边问自己：我的程序里应当提供哪些关键信息，通过它们就可以鉴别程序的状态，这些信息通过什么途径可以访问——这是一个“元设计”的过程，促使我们更深层次地思考我们的工作。我也深刻领会到了“输出给程序处理的信息应该是什么样”，它和给人看的信息有哪些差别。

可惜到如今，我发现还有大量的程序员从来不思考这样的问题，自己的程序在跑着，既看不到实时的状态，也不提供每天的统计。出现问题只能通过肉眼排错，不但意识不到效率的低下，反而乐于扮演“救世主”的角色。这些，其实都是缺乏严格训练的表现。回想我们都离职之后，服务器“裸奔”了大半年竟然没有出问题，靠的都是之前在工程上做的各种努力。

值得一提的还有“负责任的精神”。当时有一些基础的模块是振宇早期写的，当时抓虾有着名的十大谎言，第一大谎言就是“振宇的程序没有bug”，每次说起这个振宇都是笑笑，“这不是谎言嘛”。结果有天中午吃饭时聊到程序，似乎振宇的程序逻辑真的有个bug，只见他神色凝重，立刻放下筷子回去了，把这个bug修好了才算解脱。其实那个bug并没有立刻引起重大的影响，而且振宇已经很忙了，但是他仍然保持着对质量和技术的执着追求，让我汗颜，也让我佩服。

这种汗颜和佩服是有理由的。有一次线上出现了bug，我两三天也没有解决，每次被问起来就说“正在解决”。直到有一天振宇问我，我才承认“我调不出来”，敷衍等到明天再说。我记得他当时神情一变，凛然正色道：“不可能，我不相信有调不出来的bug。”然后拉着我一起调试。

多机器、多线程的系统，本来调试就很复杂，但他就靠着GDB，蹬着转椅在几台电脑前晃悠，从吃过晚饭一直调到深夜，我们终于定位、解决了问题，出公司回家已经是星斗漫天，一看表已经三点了。我总觉得IT行业虽然年轻，还是可以从传统的师徒制借鉴很多的。起码，后来我自己带领技术团队时，我也有好几次说“不可能，我不相信有调不出来的bug”，然后拉椅子现场坐下来证明我说的对。

抓虾在技术上要求很严格，但不死板。很多时候都是“任务式管理”，你领到的是个抽象的任务，并没有限制解决的办法，但要求实现最终的效果。这样看起来很自由，真正解决起来很痛苦，但也锻炼人。

在我入职后不久，就有博客作者反馈抓虾的抓取比较慢，他们自己新发表一篇博客，其它在线阅读器可能半小时就抓到了，我们却要一个小时。当时在我看来这是小概率事件（几十万种子里有个案抓取慢而已），意义不大。但是，连着几次开周会的时候易容都在强调这件事情，我不得不顶着巨大的压力去解决“怎样能在抓取速度上全面超过竞争对手”，绞尽脑汁想了各种办法，终于算是解决了问题。在那之后，我开始领悟到什么是“解决复杂问题”了。

还有一次，因为抓取程序的频率调整机制失控，新浪微博把我们的抓取服务器IP给屏蔽了。我还记得当时振宇给我发了条短信“今天必须把新浪的事情搞定”，没有任何关于方法的指示。我找到之前在新浪工作过的朋友，辗转打了二十多个电话，终于联系到执行屏蔽的技术人员。在我确认承诺修正程序，以后不超负荷抓取之后，封锁的问题终于得到了解决。

这件事也给了我很多启发：当时有一种建议是找大批代理服务器来抓，但我没有采取这种办法。技术产生的问题当然可以用技术解决，但是这不是唯一的途径，我们也可以靠沟通来解决，而且也应当靠沟通来解决。明白了这个道理，我在后来的工作中受益很多，甚至在求职中也受益很多。从抓虾离职后，有次面试中HR让我举例说明自己的专业素质，我举的就是这个例子。从最终的结果来看，这个答案应该是不错的。

我本来以为十年前的故事应当很容易写完，但今天真正坐下来动笔，才发现根本不能一一记录。虽然已经过了十年，那些记忆还那么真切。十年前的每一个傍晚，我在保福寺高高的写字楼上看到四下居民区的灯渐次亮起，入夜再渐次熄灭，然后自己才下班，那画面仿佛就在昨天。无论今天的人如何评说，那段经历已经和自己融铸为一体，无可剥离，也无法冷冰冰地“客观”看待。

年轻的时候，我们往往会被成功的故事所激励，被“出类拔萃”、“与众不同”、“卓尔不群”这样的词所感动，最终却发现，自己很可能只不过是“类”、“众”、“群”的一份子而已。但是谁又能说，这一定不是好事呢？