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.2、不要直接挑戰多云HARD模式

不同的云廠商有各自不同的優缺點，如果你有專門的開發團隊和SRE（就是DevOps），你可以使用多云。但如果你是獨立開發人員或小型創業公司，建議你不要一上來就使用多云，除非你確實需要其他云平臺的某個獨有功能。

因為每個云平臺都有豐富的產品類型和大量的工具資料，多花一些時間研究這些東西，可以確保你對整個云平臺和即將使用的產品服務有一個清晰的認識。

我們的fastone多云平臺，5分鐘快速上手的可視化界面免去了大量學習成本，
掃碼免費試用現在還送200元體驗金，了解一下？入股不虧。

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

大多數云服務都會提供成本計算器，多花一些時間測試成本，確保你知道錢都花到哪里了，再開始部署。

比較可靠的做法是，先在安全的環境（開發帳戶）中測試服務一到兩天，等待完整帳單處理完畢，并且你能夠正確理解帳單上的每一項之后，再將其集成到產品中。

我們有一份六大云廠商服務器資源價格多維度對比報告，對云上資源的靈活計費模式做了深度科普，掃碼添加小F微信號（ID：imfastone）即可免費獲取。

(二). 不要做這兩件事

2.1、不要下載密鑰

保護密鑰和令牌的最簡單解決方案是永遠不要下載它們。

2.2、不要把雞蛋放在一個籃子里

理想情況下，在任何項目中，你都應該具有dev、test、staging、prod環境。即便項目非常小，你也應該至少擁有相互之間完全分離的dev和prod環境。

(三). 捂緊你的錢包

3.1、設置云廠商的服務配額

大多數云服務都可以設置配額，也就是支付上限，可以從每天、每分鐘、每用戶每分鐘使用等多個維度來進行該設置。
當你的實際使用情況達到配額上限時，平臺就會自動切斷服務。

在設置配額時，需要注意兩點：

某些默認配額是針對大客戶的，在普通用戶看來會非常離譜，比如每天一百萬美元的云資源預算，必須重新對其進行設置；

并非所有服務都有配額限制，比如在本次事件中起主要因素的Firebase讀寫操作。

3.2、強烈建議開啟云監控功能

當云服務的使用情況超出用戶設置的配額時，云監控可以觸發包括短信、電子郵件和應用程序通知在內的警報，云監控的大多數指標僅有幾分鐘的延遲。

GCP把這項服務稱為Cloud Monitoring，AWS叫Cloud Watch，Microsoft叫Azure Monitor，國內包括阿里云、華為云、騰訊云在內的主流云廠商均稱其為云監控。

這個服務一般是免費的，或者只收取極低的價格，建議時刻開啟這項服務。

3.3、設置預算超支通知

幾乎所有云平臺的文檔都會都建議用戶設置預算超支通知，但由于整個“結算-賬單-通知”流程存在延遲，當你收到預算超支的通知時，你可能已經積累了相當大金額的賬單，你應該開啟這個功能，但不要過于依賴它。

云在提供海量資源的同時也在考驗著用戶的技術能力，不管是普通的云上部署/數據傳輸，還是高階的彈性動態使用資源，再進一步根據用戶策略的智能自動化調度，很多事情手動做和自動化做的差別很大，甚至手動根本無法完成，比如——

集群自動化部署：從4天到1.75小時，如何讓Bladed仿真效率提升55倍？
基于用戶策略智能調度：提速2920倍！用AutoDock Vina對接2800萬個分子
GPU/CPU異構資源：155個GPU！多云場景下的Amber自由能計算

3.4、使用多種付款方式，并設置支出限額

首先，你必須給開發和生產環境分配不同的付款方式，避免兩者混用。

這樣當其中一個付款方式出現問題后，它只會影響其綁定的環境，而不會對其他工作產生影響。

其次，對付款方式設置支出限額，支出限額可以設置在你預計費用的120-150％之間。

我們在3.1中設置了服務配額，如果某個服務達到了這個配額，那么云平臺會立即扣費，扣款會失敗，你的服務會被暫停。

如果你沒有對付款方式設置支出限額，或者你綁定的壓根就是一張無限信用卡，那費用就會被成功扣除，可能會從你的卡里扣除一筆遠遠超過你預期的費用。

這是最后一道防線了，如果你嚴格按照本文中的建議操作，應該用不到這一步。

如果這些都做到了，你應該能睡個好覺。

- END -

更多電子書
歡迎掃碼關注小F（ID：imfastone）獲取

你也許想了解具體的落地場景：

155個GPU！多云場景下的Amber自由能計算
怎么把需要45天的突發性Fluent仿真計算縮短到4天之內？
5000核大規模OPC上云，效率提升53倍
提速2920倍！用AutoDock Vina對接2800萬個分子
從4天到1.75小時，如何讓Bladed仿真效率提升55倍？
從30天到17小時，如何讓HSPICE仿真效率提升42倍？

關于為應用定義的云平臺：

【2021】全球44家頂尖藥企AI輔助藥物研發行動白皮書
EDA云平臺49問
國內超算發展近40年，終于遇到了一個像樣的對手
幫助CXO解惑上云成本的迷思，看這篇就夠了
靈魂畫師，在線科普多云平臺/CMP云管平臺/中間件/虛擬化/容器是個啥
花費4小時5500美元，速石科技躋身全球超算TOP500