Dropbox 早期宣布了用户总量突破1亿7千万大关，并且“大言不惭”地表示有一天他们会取代硬盘，真是艺高胆大啊…不过作为最成功的云端“盒子”服务之一，Dropbox 背后故事想必是所有创业者乐于耳闻的。

　　在布达佩斯举行的RAMp大会上，曾经以服务器部门总工程师身份任职于 Dropbox 的 Rajiv Eranki 就给一屋子工程师回顾了一些 Dropbox 创立早期的故事。Eranki 在 2008 年加入 Dropbox，工作了三年多后由于“想要接受更新更难的挑战”，于 2011 退出。其中一个挑战就是跑到纽约开了家鸡尾酒酒吧。

　　如果不是被当时还只有 2000 个用户的 Dropbox 从学校挖走，Eranki 现在可能会是个非常优秀的学者。初加入公司时，他和另一个同事组成了两人后台维护小组，那时的 Dropbox 只有一台数据库主机和一个前台服务器。

　　在回想早期团队的工作时，Eranki 这么说：“好多事情都是在磕磕绊绊中完成的，但还是发展了好几千用户。”比如说 Dropbox 的第一代分享功能就充满了 bug，跨数据库之间无法做到串联，同时也存在大量的‘denormalisation’。

　　他们“并有打算要做任何改变”，而早期 Dropbox 这种充满干劲又略带随意的工作方式反而为之后的工作带来了一些好处。他们可以在不加任何特殊代码的情况下观测用户行为、在各数据库之间进行访问。这种结构也允许他们进行大量的 bug 修复，因为他们可以在 MySQL 中轻松找到这些 bug。拥有多个共享文件夹的用户也只需对数据库发出一次请求。而只有一个前端也意味只用检测一份 log。

　　以上这些“(为 Dropbox)提供了巨大的灵活性和拓展性”，Eranki 说。

　　另一个极其重要的心得就是用 python 语言：他们用 python 写所有东西，甚至连客户端也是。收效还相当不错。也就是说在当初达到 100 万用户时，整个平台仍然只有几百行代码，而不是应有的几千行。使用 python，“我们不用为了服务 4000 万用户而写上几千行 C 语言。”他们在过程中还发现“图表都是没用的”，取而代之的是仪表盘式的显示方式。他们发现 Dropbox 的第一大“用户群”其实是在十分不合理地使用服务(比如当做 CDN 使用)，而第二大用户群其实才是最终为 Dropbox 的商业进化做出巨大贡献的核心用户。

　　在创业方面，Eranki 也分享了几个体会。他认为自作聪明地去做一些预测会导致最终的失败。事实上还不如静观事态发展然后从中总结出经验。为了防止墨菲定律之类的事情发生，他们还会主动地去模拟一些潜在的危机，比如硬重启服务器。保存 log 数据也被他们看做是比删除就代码更好的方式 – 总有一些时候你会需要看看这些记录的。Eranki 说，“避免一切删除行为除非万不得已”。如果为这些做一个粗略总结的话，那就是对所有新事物保持警戒心态。