2小时，账单47万！「Milkie Way公司破产未遂事件」复盘分析

2019年11月，Milkie Way公司开始开发一个叫Announce的产品。

2020年3月，这家初创公司就差点儿破产关门。

一个云上的小测试项目，使用了数据库和Serverless服务，几个小时，在1000个实例上进行了1160亿次读取和3300万次写入，他们不小心烧掉了将近72000 美元（折合人民币约47万元）！

EXO ME ？？？？？？？

我们大概讲过一万次（bushi）：用户用云是有一定的学习成本和难度的。在应用和基础架构，加上丰富多样的云产品和服务之间，是存在GAP的。

但一直没有合适的案例。

这次的「Milkie Way公司破产未遂事件」，当事人Sudeep Chauhan的一手复盘分析和经验总结，我们觉得非常有代表性和参考性，值得跟大家分享。

尽管文中的示例是关于GCP（Google Cloud Platform）的，但所有云服务都具有相似的功能，只不过具有不同的名称、价格和使用策略。

事情是怎么发生的？

作为一家初创企业，一开始团队就是简单快速创建了MVP（最小可行性产品），把产品部署在Google App引擎上。工作的重点都放在写产品代码和UI设计上，对云的关心程度仅限于“能用就行”。

这，就为后面发生的事情埋下了导火索。

2020年，随着新冠疫情的爆发，Sudeep Chauhan认为这可能是他们的产品走向世界的好机会。于是，创建了Announce-AI项目。

团队在没有彻底研究清楚Cloud Run（Serverless服务）到底是怎么个玩法的情况下就在上面部署了“测试版”Announce-AI，想看看效果怎么样。

由于这个测试版只是一个非常小的站点，所以团队选择了Firebase的数据库。

他们创建了一个新的GCP项目，设置了7美元的云资源使用预算，选择了Firebase免费计划，想着最坏不过是超过每天的免费额度（该计划免费提供5GB的存储空间，以及每天免费提供5万次读取和2万次写入操作）。

3月26日，一切都很好。

到了第二天晚上，噩梦就开始了。

Sudeep Chauhan在邮箱中发现了几封来自GCP的提醒邮件：

第一封邮件：您的Firebase Project已自动升级为收费账户。

第二封邮件：您在GCP的7美元云资源使用预算已超支。

第三封邮件：由于信用卡支付失败，您的GCP账户已暂停使用。

由于Sudeep Chauhan的信用卡设置了100美元的消费限额，他以为此时此刻的花费最多不过100美元。然而，他登录后台查看账单时却看到一张约5000美元的账单。

就在他还在思考如何付清这笔“巨款”的时候，更可怕的事发生了：账单金额还在不停增长！

5 分钟后，账单显示15000美元。

20分钟后，账单显示25000美元。

…………

他整个人都懵了。

直到两个小时以后（这大概是他人生最漫长的两个小时，期间，他们禁用了计费功能，并关闭了所有服务），账单金额最终停在接近72000美元。

由于在所有GCP项目中都绑定了相同的银行卡，因此他们所有的帐户和项目都已被Google暂停。产品开发工作被迫停止，公司前途未卜。他开始疯狂研究破产法，因为，没钱。

他们到底做错了什么？

他们主要犯了两方面的错：

一、在云上部署了有缺陷的算法；

二、对GCP产品和服务的认知不足，使用默认选项。

有缺陷的算法

团队使用POST请求将URL作为数据发送到某一实例，且并发使用多个实例以替代串行使用单一实例（这是发挥云上弹性优势的常见操作）。由于Cloud Run的处理操作能够精确到毫秒，所以全部页面都将得到并发处理，整体性能得到了高度优化。

但在具体的编码过程中，由于缺少break语句，实例无法中断。而POST请求可以具有相同的URL，如果其中存在指向上一页的反射链接，那么Cloud Run服务就会陷入无限递归中，而且这个递归会呈指数增长。

团队将最大实例数设置为1000，这意味着当测试开始后，这1000个实例会不断进行查询，并且每几毫秒就向Firebase数据库写入一次。高峰时，Firebase每分钟的请求数甚至高达10亿个。

24小时内，Cloud Run进入后台进程，在1000个实例上，一共消耗了16022个小时。

最终，在账户被GCP停用前，该项目共执行了1160亿次读取和3300万次写入。而Firebase上的读取成本是每十万次0.06美元，仅此项花费就接近7万美元。

不了解GCP产品和服务

1、不了解Firebase就直接用了，也没注意账户会自动升级成付费账户

Firebase不是一种可以学习的语言，是Google提供的一种Serverless服务，有特定的规则，而不是由自然法则或特定用户可能会认为的规则来定义。

而且虽然他们使用的是Firebase的免费计划，但他们并没有注意到GCP刚刚更新了和Firebase的深度集成，一旦接受了GCP项目的结算条款，Firebase账户默认可以自动升级为付费账户。

2、不知道GCP账单有延迟

团队过于依赖GCP自带的预算超支通知，由于需要先进行结算，该通知在结算完成后才会发出，当预算超支，触发云功能关闭的时候，大量账单费用已经产生了。

3、没有意识到Firebase仪表盘数据存在延迟可能造成的后果

虽然Firebase控制台文档明确表明仪表板数字和GCP账单数据略有不同。但在发生每分钟10亿次请求时，这个延迟将非常致命。

4、信用卡支付限额并不能阻止巨额账单的生成

GCP的账单结算与支付之间同样存在延迟，因此100美元的信用卡支付限额并不能阻止巨额账单的生成。当GCP发现无法扣款后，用户账号被停用，但此时已经产生了大量的欠费。

完美的故事结局

幸运的是，他们还活着。

在等待、咨询、冗长的电子邮件和查找BUG上花费了无数的时间后，Google最终免掉了他们的账单。

一般来说，故事到了这里就结束了。

就像王子和公主幸福地生活在一起了一样。

但我们更想问一句：后来呢？

后来，Milkie Way公司花了几个月的时间来了解云和自己的产品体系架构，报废了V1版的产品，构建了可扩展的架构来为产品提供动力，在云上建立了一个可以快速迭代、安全的平台，而不仅仅是一个MVP。

7个月后，他们发布了V2版产品。

去年年底，创始人Sudeep Chauhan在公司博客上复盘了这次事件，说：

“云就像一把双刃剑。如果使用得当，它可能会很有用，但是如果使用不当，则可能会导致后果。

如果您算一下GCP文档中的页数，则可能比几本小说中的页数还多。了解定价和用法不仅耗时，而且需要深入了解云服务的工作方式。

怪不得有人专门做这个！（没错，说的就是我们。）

Firebase和Cloud Run确实强大。

在高峰期，Firebase能够处理每分钟约10亿次读取。这是异常强大的。我们已经在Firebase上玩了2-3个月，并且仍在学习它，但是直到现在我仍然完全不知道它有多强大。

Cloud Run也是如此！并发==60，max_containers == 1000，每个请求占用400毫秒，Cloud Run的请求数每分钟可以处理900万个请求！60 * 1000 * 2.5 * 60 = 9,000,000个请求/分钟

相比之下，Google搜索每分钟可获得380万次搜索。“

Sudeep Chauhan的云实践一手经验

1、多花点时间学习
1.1、上云之前请先阅读说明书

几乎所有云产品都有非常完整且不断更新的操作指南，里面包含了一系列需要做或不应该做的事情。

强烈建议阅读即将使用的每项云服务的操作指南，这不仅能够得到帮助，也可以避免不必要的麻烦。

1.2、不要直接挑战多云HARD模式

不同的云厂商有各自不同的优缺点，如果你有专门的开发团队和SRE（就是DevOps），你可以使用多云。但如果你是独立开发人员或小型创业公司，建议你不要一上来就使用多云，除非你确实需要其他云平台的某个独有功能。

因为每个云平台都有丰富的产品类型和大量的工具资料，多花一些时间研究这些东西，可以确保你对整个云平台和即将使用的产品服务有一个清晰的认识。

1.3、了解钱是怎么花出去的

大多数云服务都会提供成本计算器，多花一些时间测试成本，确保你知道钱都花到哪里了，再开始部署。

比较可靠的做法是，先在安全的环境（开发帐户）中测试服务一到两天，等待完整帐单处理完毕，并且你能够正确理解帐单上的每一项之后，再将其集成到产品中。

2、不要做这两件事
2.1、不要下载密钥

保护密钥和令牌的最简单解决方案是永远不要下载它们。

2.2、不要把鸡蛋放在一个篮子里

理想情况下，在任何项目中，你都应该具有dev、test、staging、prod环境。即便项目非常小，你也应该至少拥有相互之间完全分离的dev和prod环境。

3、捂紧你的钱包
3.1、设置云厂商的服务配额

大多数云服务都可以设置配额，也就是支付上限，可以从每天、每分钟、每用户每分钟使用等多个维度来进行该设置。

当你的实际使用情况达到配额上限时，平台就会自动切断服务。

在设置配额时，需要注意两点：

某些默认配额是针对大客户的，在普通用户看来会非常离谱，比如每天一百万美元的云资源预算，必须重新对其进行设置；

并非所有服务都有配额限制，比如在本次事件中起主要因素的Firebase读写操作。

3.2、强烈建议开启云监控功能

当云服务的使用情况超出用户设置的配额时，云监控可以触发包括短信、电子邮件和应用程序通知在内的警报，云监控的大多数指标仅有几分钟的延迟。

GCP把这项服务称为Cloud Monitoring，AWS叫Cloud Watch，Microsoft叫Azure Monitor，国内包括阿里云、华为云、腾讯云在内的主流云厂商均称其为云监控。

这个服务一般是免费的，或者只收取极低的价格，建议时刻开启这项服务。

3.3、设置预算超支通知

几乎所有云平台的文档都会都建议用户设置预算超支通知，但由于整个“结算-账单-通知”流程存在延迟，当你收到预算超支的通知时，你可能已经积累了相当大金额的账单，你应该开启这个功能，但不要过于依赖它。

3.4、使用多种付款方式，并设置支出限额

首先，你必须给开发和生产环境分配不同的付款方式，避免两者混用。

这样当其中一个付款方式出现问题后，它只会影响其绑定的环境，而不会对其他工作产生影响。

其次，对付款方式设置支出限额，支出限额可以设置在你预计费用的120-150％之间。

我们在3.1中设置了服务配额，如果某个服务达到了这个配额，那么云平台会立即扣费，扣款会失败，你的服务会被暂停。

如果你没有对你的付款方式设置支出限额，或者你绑定的压根就是一张无限信用卡，那费用就会被成功扣除，可能会从你的卡里扣除一笔远远超过你预期的费用。

这是最后一道防线了，如果你严格按照本文中的建议操作，应该用不到这一步。

如果这些都做到了，你应该能睡个好觉。

• END -

速石科技（ID：Fastone_tech）

我们致力于构建为应用定义的云，让任何应用程序，始终以自动化、更优化和可扩展的方式，在任何基础架构上运行。希望和你共同建立持续迭代的多云世界观。

说出你的应用，我们就有故事~~

（你要是唠这个我就不困了。）