【獵雲網（微信號：ilieyun
）】10月15日報導 （編譯：堆堆）
當1992年Avi Freedman準備從Temple University畢業時，費城幾乎沒有地方可以購買網際網路服務。即便你想付錢來換取一個上網撥號帳戶，你也沒處送錢。而Freedman卻早就開始運營一個Unix機器供他認識的人登錄來使用。之後，他決定把他對於網際網路現狀的不滿轉化為去創建一家公司，供區域內的所有人來撥號上網。
他是這麼想的：「這也沒什麼難的吧。我只需要買一個可以全天使用的商用聯網連結，然後增添一些數據機就可以了。」不久之後，Freedman創建了費城第一家網際網路服務提供商。早期的經驗讓他受益匪淺。提供商業性網際網路服務的Netaxs以及其他類似的服務供應商衍生出了一群經營大企業、提供網頁和雲服務供應商基礎設施的人。這些基礎設施遍布全球。
Freedman自此之後開始進軍網際網路世界。他負責全球網絡骨幹供應商AboveNet的工程業務（如今AboveNet已被Zayo收購）。他還在Akamai待了十年時間，負責運營網際網路團隊並且圍繞基礎設施開發服務，之後他擔任公司的首席技術官一職，負責技術工作以及雲服務公司ServerCentral。兩年半後，他創建了Kentik，為企業提供完全可視化的網際網路流量、表現以及安全情況。Freedman已經看到100多家初創企業升級了自己的基礎設施，而他則可以為技術基礎設施提供最佳建議。
在本篇文章中，Freedman將會跟我們分享初創企業在設置系統時常常會犯的三大錯誤。
• 它們進入了雲監獄。
• 它們捲入了流行工具。
• 它們在設計時沒有考慮可監測性。
如果你發現了自己公司存在上述問題的症狀，不用擔心。在你創建公司的過程中，你是可以避免這些陷阱的。
歡迎來到雲監獄
「這是一個反覆發生的故事：一家初創企業貸款了25萬美元來設置雲端的基礎設置。這很不錯。剛開始時，每個月的花費僅為2萬美元。但隨著公司的發展，雲端基礎設施的花費變成了每月5萬美元，之後增加到了每月10萬美元。突然之間，貸款額度已經用完了。而雲端基礎設施的成本也在繼續增加。這時候董事會突然問道：『等下，發生了什麼？員工才應該是你最大的資金支出來源，你卻將所有資金都投入了雲端！』於是乎這家初創企業開始『縮衣節食』——即優化資料庫服務的使用、購買及時型實例或是預留實例、調整實例類型、追蹤並且刪除無用的對象存儲或塊存儲。最終，公司將雲端成本減少到了每月8萬美元。一段時間之後，他們盡力壓縮的成本仍在增加，這就使得之後進行優化的資金大大減少。」Freedman這樣說道。
如果他們還想按照董事會的期待，繼續快速發展公司，那麼他們就要立即越過之前的高水位線，這一點實行起來並不容易。初創企業將很難支付得起繼續使用基礎設施的費用——尤其是在2016年，大家都愈加關注盈餘以及單位經濟效益。
每個人都希望自己能夠回到過去，告訴當時的自己去利用雲服務來發展公司，但不受限於任何一家供應商。
「雲監獄指的是：你會發現自己在基礎設施上花費了過多的資金並且完全受限於你的雲服務供應商。」Freedman這樣說道，「但此事發生時，換一個雲服務供應商卻沒那麼簡單。你使用的是它們特定的服務和環境。你已經和它們提供的服務緊緊相連了，遷至另一個雲端非常困難。」
就拿行業領導者亞馬遜來舉例吧，亞馬遜擁有一系列吸引人的屬性。它可以輕易識別用戶身份。身份驗證、消息列隊、郵件、通知以及無縫資料庫，這些都是可以為你節省很多時間的輕量級服務，但前提是你得使用AWS（亞馬遜公司旗下雲計算服務平臺）。亞馬遜的魅力在於儘管存儲以及寬帶成本日益增加，但它們仍可以保證用戶不會遷至另一個雲平臺。亞馬遜的客戶根本無法想像自己缺乏AWS提供的服務之後會是什麼後果......
「醒醒！董事會正在打電話詢問你為什麼毛利潤永遠無法超過40%？為什麼你在基礎設施上花的資金比在開發者身上要多？」他說，「你解釋說事情本應當是按照對數級增長的。公司在發展的過程中，成本本應該會減少——但是事實情況不是如此。尤其是在如今的風投市場上，這類的藉口是無用的。」
那麼你應該怎麼做呢？
「你親自去調查基礎設施，然後發現雲服務並非一直都是那麼便宜或是高性能。」 Freedman這樣說道，「這就像是你有一個災難恢復計劃或是安全應急方案一樣——當你出於成本或是性能原因無法在雲端運營一些內容時，你應該清楚知道自己要做什麼。至少有一部分基礎設施你得知道自己該如何使用，你還需要僱傭一些對此有經驗的早期團隊成員。」
Freedman表示你可以租用其他人運營的現有設施，然後購買或租用伺服器或是路由器。這種做法要更為高效。
你越早能想到這一點越好。如果你可以擺脫雲監獄，那麼你就應該開始採用多個雲平臺模式並且給出最初的牽引力、設置小型的基礎設置，將其與你的雲服務供應商連接在一起。
員工也能起到很大作用。只需要早期僱傭的3到5個員工，他們就可以運營雲端以及專用的基礎設施。和剛開始相比，該團隊通常可以運營十倍大的系統。
最後一條關於雲平臺遷移的建議：「對於隨時在線或是有很大存儲量要求的工作任務來說，你可以考慮裸機雲平臺以及像SoftLayer、LeaseWeb、OVH、Packet這樣的專用伺服器供應商。」Freeman說。
輕信流行工具
「人們都愛嘗試新工具。當他們聽聞有一家牛逼的網頁公司開發出了一個技術型基礎設施工具來解決某問題時，他們就想去嘗試一下，因為這聽上去又方便又節省時間。」Freedman說，「我們之前在Kentik也輕信過這些流行工具。我們當時發現了一個可以解決特定分布式系統問題的工具，然後覺得『這看上去不錯——我們一直想擁有這樣一種工具』。幸運的是，我們只不過是在內部投入了大量時間，並未引起用戶的憤怒。」其他的公司就沒有這麼幸運了。
即便是世界上最聰明的人也會對一遍又一遍使用同樣的工具感到無聊。他們總是想要嘗試可以解決問題的新工具。
Freedman關於此事的建議是：當涉及到基礎設施組件時，儘可能保證組件的簡單。也要持有一定的懷疑態度。當涉及到基礎設施中的核心組件——存儲量、負載均衡以及服務發現時——你必須要確保使用的組件不會帶來任何問題。也許，你剩餘的應用或是組件已經給你帶來很多麻煩了。
那麼你應該怎麼做呢？
作為總裁，如果你發現團隊被流行工具吸引住了，你需要在短時間內暫停工作然後詢問他們：「究竟我們試圖要解決的問題有多嚴重？」你可以用以下這些問題來判斷你對此問題的感覺：
• 你願意為此做出多大妥協？
• 你願意為此冒多大風險？你可以為此犧牲資金、時間或是消費者嗎？
• 你是否必須要定期為這項工具/組件的開發投入資金？
• 你可以負擔得起僱傭一個或是多個兼職員工來將此工具/組件開發成不同級別可應用的工具嗎？
• 這項組件技術有多成熟？它在你運營的應用類型中是否起到積極作用？
• 你有什麼證據來證明這項工具在不同情況下是穩定的？
• 如果運行順利，那麼這項工具可以節省我們多少時間和精力？
• 這項工具/組件（由於其他工具/組件的使用效果不好）是公司最終也需要自己進行開發的嗎？
• 你可以找到人證明它不適用的模式嗎？尤其是當你找不到這樣的人時，你能投入足夠的時間去自己找出答案嗎？你還需要去尋找它的弱點以及恢復途徑。
設計時要考慮可監測性
「測試優先開發」好像變成了業界奉行的準則之一。當然，其間有很多原因。如果你無法理解某一行代碼，那就進行測試好了。但是Freedman卻持有不同的觀點。
「首先要關注的不僅僅只是測試，你還要從批判性的角度去思考監測的能力。」他這樣說道，「如果你不知道組件是如何同其他基礎設施配合運行的或是說你不知道該如何將組件放置在你需要的儀器裡面，那麼放置這個組件就變成了一個很危險的事情。」
測試往往指的是單元測試，這類測試重視的是組件本身。但每當組件運行出現問題時，往往是組件參與的動態系統出現了出人意料的結果——這並非是事物本身的問題。
你需要去思考所有可能的交互作用以及在開發之前就去思考好最終的儀器會是什麼樣子。尤其是在分布式系統中，問題顯示的位置和產生連鎖反應的根源往往相距甚遠。
總結
Freedman強調的三種錯誤絕非是他職業生涯中遇到的唯一幾個陷阱。這只不過是最常發生且最耗資金的陷阱。幸運的是，他的建議可以幫助你避免與基礎設施相關的問題。
• 早點思考這些問題。早到你自己都認為思考這個問題太早了。
• 與此同時，谷歌所做的一切不一定就適合你。
• 建立一個三權分立的制度。爭取獲得專家的幫助。
• 預測你盡最大努力會讓公司走到哪裡，在發展過程中不斷重申這一點。
• 無損用戶為先。不惜一切代價保護好用戶體驗。尊重他們的信任。
有了這些建議，你就可以在很大程度上控制自己公司的命運。當你能更好地掌控這些問題時，你的注意力就可以集中放在那些你要真正解決的問題上。