上云上的差点破产是什么体验？
前言
2020年，很多小的初创公司因为疫情的原因，纷纷倒闭关门，哪怕是勉强支撑的也大多是一蹶不振濒临破产。
有一家名为Milkie Way的美国小公司，没有因为疫情受到影响，本该是大展宏图之际，却差点被自己坑的申请破产，这到底是怎么一回事呢？我们一起来看下吧。
这家Milkie Way是一个仅仅拥有8人团队的初创公司，创始人Sudeep Chauhan曾在谷歌工作，他们公司的作品https://announce.today 服务是一款类似于自动发布各种警告信息，包括地震、海啸、各类事件、各类新闻的安全通知平台，随着疫情的发展，线上发布各种公告也让他们看到了大展拳脚的最佳时机。但是没想到的是因为内部测试期间的一些小疏忽，他们收到的是一纸 72000 美元（约 47 万人民币）的天价账单！
为了能更好的服务于疫情期间，Milkie Way原本准备开发一个 Announce-AI 项目，旨在自动发布由 AI 创建的上述各类安全内容。为了开发 Announce-AI，他们决定使用 Cloud Functions（谷歌发布的无服务器平台），但是很快他们遇到一个问题，Cloud Functions 的超时时间长达 9 分钟，无法满足他们的使用需要，于是他们转而开始研究Cloud Run（谷歌发布的另一款无服务器服务）。
虽然当时团队中的成员都对Cloud Run不太了解，但是码农的特质就是在探索中不断学习，所以他们也没觉得有什么不妥。同时因为 Cloud Run 不提供任何存储功能，他们使用了 Firebase 作为数据库。（因为站点规模很小，完全用不上 SQL Server 或者任何其他成熟的商业数据库）
Sudeep Chauhan还非常小心的对这个GCP项目设置了 7 美元的云资源使用预算，很多小伙伴看到这里肯定会想，那这个项目最多也就是用光这7美元的预算咯，Sudeep Chauhan当时肯定也是这样想的。
部署完成之后他们就开始了一些常规的测试，并保持程序运行，到了第二天，噩梦开启！
首先，Sudeep Chauhan收到了一封关于Firebase自动升级的邮件，然后马上又收到了7美元预算超支的邮件，当时他倒是没有怎么紧张，因为他的信用卡设置了100美元的消费限额。但是当他登录Google Cloud Billing之后，看到了一张价值5k美元的账单，瞬间脑海中一片空白。
不难想象，如果我在起床刷牙的时候看到我500额度的信用卡刷了一个几万的账单出来，我也会当场晕倒。当时的Sudeep Chauhan一脸懵逼，真就像电影里拍摄的一样，一方面他是完全不知道哪里在产生费用，一方面这个费用还在不停的增长，5 分钟之后，账单数额增长到了 15000 美元；20 分钟后，数额增长至 25000 美元；2 个小时后，数额最终定格在 72000 美元。 是不是很夸张？
最后一筹莫展的Sudeep Chauhan和他的小伙伴只能关闭所有的服务用来停止账单的增长。
第二天Sudeep Chauhan还联系了许多律师事务所，甚至没有一家事务所肯受理他的预约，不过也难怪，连他自己都没搞明白这件事的来龙去脉。
最后经过他们彻夜不眠的调查，终于发现事件的因果：
首先，Firebase 在提示条款中没有提及会自动升级的情况下自动升了级
然后，谷歌的账单结算有着一天的延迟，导致他们一天后才发现账单已经欠下巨款
再者，谷歌无视信用卡100美元的设置，导致天价账单的产生
最后，关键的关键，就是为了解决Cloud Run 中的超时问题，使用了 POST 请求（将 URL 作为数据）将作业发送至某一实例，且并发使用多个实例以替代串行使用单一实例。这样 Cloud Run 中的每个实例只会抓取一个页面，所以永远不会超时。这样做的隐患就是：
1、不中断的指数递归：由于没有 break 语句，因此实例不知道该何时中断。
2、POST 请求可以具有相同的 URL。Cloud Run 服务将陷入无限递归当中；而最糟糕的是，这个递归将呈指数增长
从最后的数据来看，这套部署在 Cloud Run 的“Hello World”版本一共执行了 1160 亿次读取与 3300 万次写入！
1160 亿次！
所以按照Firebase 上的读取操作成本：
(0.06 美元 / 100,000) * 116,000,000,000 = 69,600 美元！无怪乎那么贵了
从这个事情我们可以看到，云服务上部署了一个错误的算法，在完全不了解的情况下使用了Firebase，最终导致了天价账单的产生，所以一般常识里面的一边学习一边开发，其实是很危险的一个行为。
尤其是在云平台上进行一些不确定的开发测试，云平台像是一把双刃剑。如果使用得当，它确实威力巨大；但如果使用不当，后果也将极为严重。Firebase 也不像是能够直接学习的编程语言，它是谷歌提供的一项容器化平台服务，其中使用的是大量预定义规则。
也千万不要因为设置了某些消费上限而掉以轻心，无论什么时候，一定要严谨的对待自己的每一段代码每一个程序，清楚自己的程序做了什么产生了什么，尤其是那些容易在后台持续运行的进程。
后记
不幸中的万幸，谷歌在收到Milkie Way的完整事件反馈后，还是免除了这笔天价账单，Milkie Way也避免了公司破产的厄运，当然凡事也不会每次都那么幸运，Milkie Way的成员深知这个道理，在那之后花了几个月时间学习云架构和他们自己的业务体系，避免类似问题再次出现。
所以，无论什么时候，没有投机取巧，没有捷径，只有不断刻苦钻研避免问题发生才是王道。
题外话，如果你觉得谷歌换成了国内的那些巨头，会免了这个账单吗？
往期推荐