我在 Serverless 方面的惨痛教训

我在写了一篇介绍无服务器架构使用初体验的文章后，对于总结的心得和取得的成绩还沾沾自喜。然而，次日早晨的遭遇却让我苦不堪言。

度了两周的假期后我在这天早上起来，准备工作。我查了一下邮件和短信，冲了个澡，吃过了早餐――你也知道这是每天的惯例。然后在7点43分，我收到了亚马逊发来的预算通知。这时候，想必诸位已猜到发生了什么。

AWS预算通知邮件

乍一看，费用似乎并不多。预测费用83.28美元，我预料实际总费用大概少5美元。我马上登录到亚马逊控制台，径直进入到计费部分，发现预测费用居然高达800美元，实际费用180美元。我脑袋一时空白，这笔费用对我来说太高了，诸位也许可以从邮件中的预算值中看出来。

我赶紧马上分析日志，找到了自己犯的错误。这是昨天我在撰写博文时发现的一个bug，忘了更改代码就直接部署上去……

我的S3存储桶（S3 bucket）采用了这种设置方式：只要添加新文件，就会触发一个Lambda函数，该函数根据文件类型来确定缓存持续时间，并存储在元数据中。由于对象已被覆盖，它再次触发该事件，因为它被视作一个新的对象――这进而再次触发Lambda函数。是有处理该行为的检查机制，我检查了元数据是否已经在那里；如果在，就会用一个简单的返回语句终结脚本。问题就出在这里；由于重构（refactor），我忘了返回语句，它完全继续再次覆盖。因而形成了无限循环。

我觉得脚本一直在运行，因为在我发表我那篇博文前夕，日志全是关于它的内容。

我觉得这天再糟糕不过了，几小时过后，确实如此。我猜费用定期更新，因为它更新后，费用再次上涨。

AWS费用

实际费用现在是206美元，预测费用超过1000美元，这让我重新考虑将来要不要使用按使用付费的服务。犯了个小小的错误，却花费大笔钱，预算通知来得太晚了，我对此无能为力。

眼下，我不断刷新亚马逊上的计费页面，希望费用不会变得更高――晚上估计是睡不踏实了。

我倒不是说无服务器很坏，而是说你在使用无服务器时要格外小心。你要留意日志，再三测试各个部分。设置预算警报，尽管我最后的费用仍有206美元，但要是没有预算警报，费用会高得多。

为有兴趣的读者提供一些统计数字，你可以清楚地发现S3和Lambda一直非常活跃。