一个 Python Bug 干倒了估值 1.6 亿美元的公司

Posted 2022-09-07 AI科技大本营

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了一个 Python Bug 干倒了估值 1.6 亿美元的公司相关的知识，希望对你有一定的参考价值。

整理 | 苏宓

出品 | CSDN（ID：CSDNnews）

2011 年，风险投资家、原 Netscape 创始人 Marc Andreesen 的一句「软件正在吞噬世界」，警醒众人。自此一切可编程的大门逐渐开启。然而在百花齐放软件驱动产品的背后，往往一个 Bug，极有可能瓦解所有。

近日，一位科技博主分享了一则早年间真实发生的一个 Bug 事件，因为一个“灾难性”的软件版本发布间接地导致了曾可以与 Reddit 匹敌的科技网站 Digg 分崩离析，最终让这家曾经估值高达 1.6 亿美元的公司被以 50 万美元价格收购。

作为亲身经历者，软件工程师 Will Larson 在 2018 年以《Digg's v4 launch: an optimism born of necessity.》一文，回顾了当初 Digg 公司的发展情况与个人参与的整个遭遇。万万没想到的是，经历了两年改版重写，再到耗时一个月的寻找 Bug，最终的问题竟是与 Python 的一个函数有关，然而彼时再想修复，似乎一切已为时已晚。借此，通过这篇文章也想给奋战在一线的开发者避一避坑。

背景

这家名为 Digg 的公司，成立于 2004 年，是一个以科技为主的新闻站点。与当时其他新闻网站有所不同的是，Digg 允许用户把自己搜集的新闻和其他互联网内容汇聚在一起进行提交，然后 Digg 通过内部算法机制将新闻抓取到网站的首页，用于展示。

来自维基百科

这样做有一个好处就是，Digg 将文章的筛选权利交给了用户，可以让他们自己筛选出最受关注和有价值的文章，然后通过订阅方式，订阅数量高的就会自动被推荐上首页，由此让更多的人看到。在时下这种新颖的做法，也让很多用户有了参与感，Digg 的规模也逐渐扩大。

当然，所有事情也有两面性，也所谓「树大招风」。

Will Larson 在 2018 年发布的博文里提到：“过去一年里，Digg 过得异常艰难。我们的 CEO 在我加入的前一天离开了；高级工程师们鬼使神差地离开了公司，并拉走了他们剩在公司的朋友们，降低了公司的生产力；具有欺诈性的团伙规避了我们的算法，利用投票与订阅的方式，出售我们网站头版的访问权，并威胁我们要及时修改算法以防止他们的滥用；我们的开发者环境配置工具坏了，没有人知道如何修复它们，所以我们给新员工重新分配了近期离职同事的僵尸虚拟机。”

要说一家发展前景良好的公司，为何会沦落如此，一方面，必然有其内部的战略问题，另一方面，也与外部的竞争环境有关。Will Larson 称，受到外部的影响因素之一便是与 2011 年 Google 推出了 Panda “反垃圾网站”算法有关。

那时，Google Panda 的主要目的是将质量低、含有垃圾内容的网页或网站排名降低，使得高质量的内容得到应有的合理排名。

虽然 Google Panda 算法本身是利好质量高的网站，但是 Will Larson 表示，“当时 Digg 已经被 Google Panda 算法更新破坏了。由于该搜索更新花了一个月的时间才慢慢生效，Digg 的命运就此也发生了巨大逆转：我们从第一个也是唯一一个盈利的月份开始下跌，一直跌到网站月流量被砍掉一半。前一个月，公司在五年的盈利道路上达到了顶峰，下一个月，公司处于自由落体状态，即将从弱势地位进行融资。”

为了重振旗鼓，也为了改变现状。Digg 决定对网站的 v3.5 进行重写，将发布 Digg v4 版本。

不过时间转瞬过去了两年，Digg 因重重变故，导致新版本一拖再拖。然而，Digg v4 版本是该公司回归互联网巨头竞争的战场中唯一的机会，如果错失，可能也就错过了整个时代。后来，经过公司内部的商议，他们决定将没有完全准备好的 Digg v4 紧急上线。

‍

‍重写 Digg v4 的办公现场，来源 Will Larson 博客

殊不知，这一仓促的决定也注定了其仓促的收场结局。

Python 函数的默认参数的一次失败案例

慢慢地问题开始显现。

彼时的上午 10 点左右，有人问研发团队什么时候开始切换新版本，工程师回答称："我们已经开始重新配置 V3 服务器了。" 不过，由于容量太小了，该团队决定重新映像所有现有的服务器，然后在新的软件栈中重新配置。

切换工作正式开启，不过一些奇怪的事情发生了。切换过程中，新的网站并没有真正地出现。运营团队匆匆忙忙地发布了一个维护页面，整个团队陷入了沉思。因为，他们并没有一个回滚计划。然后有一个工程师给出了或许是唯一可能的选择：继续向前切换。

他们也的确这么做了，一个小时后，当全部量切换完成，旧网站页面取而代之的是 Digg v4 版本，所有人员也长舒一口气。

不过刚高兴没多久，大家发现多数的页面呈现无法加载的状态。初期，该研发团队将问题定位为 Cassandra 集群，因此他们扩大了对 memcache 的使用，作为保护 Cassandra 的一个写通缓存。

几个小时之后，访客页面没有问题，但是已经登录的用户却仍然看到报错的页面，如 MyNews，该页面类似于“个人中心”，会呈现用户与每篇文章互动的记录以及个性化的新闻页面。无奈之下，研发团队将登录用户的默认页面改为 TopNews，这样使得用户登录之后可以使用网站。

次日，MyNews 已经彻底无法访问，网站每隔四个小时之后就会出现故障。除此之外，还有几十个小问题也在不断出现。

于是，他们再次做了一个大胆的决定——从头开始写 MyNews 页面。起初，该团队以为 Cassandra 的缓存击穿了 memcache，破坏了相关功能。后来他们用 Redis 重写了，并实施了一个分片的 Redis 集群，并成功将原来的迁移到新开发上。

遗憾的是，研发团队还是需要每隔四个小时就手动启动每个进程。

简单来看，相当于问题的根源还是没有找到，只是用了一种麻烦的替代方案来短暂支持。没想到的是，这个 Bug 耗费了该团队一个月的时间来追踪。

好在最终还是发现了问题的所在。Digg 的 API 服务器是一个 Python Tornado 服务，它将 API 调用到 Python 后端层，即 Bobtail（前端是 Bobcat），其中一个最经常被访问的端点是用来通过用户的名字或 ID 来检索用户。因为它支持按名字或 ID 检索，所以它把两个参数的默认值都设置为空列表。

def get_user_by_ids(ids=[])

然而，Python 只在函数第一次被评估时初始化默认参数，这意味着每次调用函数时都会使用同一个列表。

在这种情况下，每次调用时，用户的 ID 和名字都被附加到默认列表中。几个小时后，这些列表开始在每次请求中检索数以万计的用户，甚至压垮了 memcache 集群，导致了页面崩掉。

通过一个简单的例子可以直接看出：

def f(l=[]):
  l.append(1)
  print(l)


f()
f()
f()
输出
[1]
[1, 1]
[1, 1, 1]

最后

事情最后的结局是，Digg 团队修复了该漏洞，Digg v4 完全正常启动。而距离此事过去了一周后，Digg 迎来了最后一任 CEO；一个月后，Digg 开启第三轮裁员；一年后，Digg 公司被 Chartbeat 的母公司 Beatworks 以 50 万美金的价格收购。

谁曾想，Digg 也是互联网的宠儿，估值曾达到过 1.6 亿美元，登上过《商业周刊》的封面，Google 也曾计划以 2 亿美元将它收入囊中。殊不知，正是这一次的失败改版让 Digg 迅速损失了人气，以及内部一些管理问题，让竞品迅速超越。自此，一家创业明星公司就此陨落。

Will Larson 在文末写道，「Digg V4 有时会被作为灾难性发布的例子，隐含的教训是我们不应该发布它。我曾经一度同意这个观点，但现在我认为我们推出的决定是正确的。因为，我们的流量明显下降，每个月都在损失一大笔钱。如果我们能在推出伟大的东西和糟糕的东西之间做出选择，肯定会更倾向于推出伟大的东西，但我们却选择了最后一次挥棒。」

另外，他还表示，“即使是现在，我也不确定当初那样一个有才干的团队是如何进行这种愚蠢的展示的。”

归根结底，这是程序员一次技术失败导致的惨痛教训。也有不少网友评论道，「动态类型一时爽，代码重构火葬场」。

参考链接：

https://lethain.com/digg-v4/?continueFlag=0a23bc7c424c6abc75f97cbaaa2d55ff

https://weibo.com/u/1642628345