Rafter的DevOps

引導階段

在過去的6年裡，我有著獨一無二的機會觀察我們公司是如何由幾個只想著出 租教科書的應屆畢業生髮展成一個大而成熟的公司。當我回頭看時，我會將我們 的成長分成兩個不同階段：A輪融資之前和A輪融資之後，與你聽到或讀到的大部 分創業公司不同，我們經曆了相當長一段時間的A輪融資（大概有3年）。

在這一發展階段，我們並沒有花費大量的資源或人力在DevOps上，相反我們主 要關注產品的構建。在剛開始幾年的大部分時間裡，我把自己定位為一軟體工程 師，每月只需幾天時間花費在系統管理上。

我們經常開玩笑說，我是那個抽到下籤，被“困於”伺服器管理的 那個人。但是，實際上，我自己特別享受。儘管如此，我也從來沒想過我對軟體 開發的熱情居然會用在伺服器管理上。

盡量簡單（在你能控制的範圍）

我們初期之所以能不在DevOps上花費力氣是有幾個原因的。首先，很大程度上 是因為我們是小公司，變化也比較少。我們選擇了一個簡單的架構，應用程式數 量也比較少。所以儘管我們的產品不斷髮展，但是需要對底層的基礎架構進行修 改的地方卻比較少。

過度投資

第二，早期我們在伺服器硬體上投資過度了。我們可能只需要兩台伺服器就可 以運行我們整個網站，而我們卻買了10台。但這允許我們之後花很少的時間去擔 心那些效能或基礎架構發展等問題，而我們也是在幾年之後才耗盡初期購買的服 務器的效能。當然，配置這些伺服器是有前期成本的，但是一旦設定好了，就不 需要大的改動。

選擇好的工具

最後，我們採用Ruby on Rails作為應用程式架構，及其關聯的工具，比如： Git、Capistrano和Teamcity，允許我們在早期就採用那些良好的發布和部署實踐 。與此同時，我們也構建於那些行之有效且穩定的開源解決方案之上，比如： nginx、MySQL和memcached。

也正因為對這些工具和架構的採用，從而讓我們避免了採用不必要的複雜且專 有的解決方案。很多時候我覺得這些方案會隨著公司的成長，降低其開發速度。

成長

隨著我們公司進入第二個成長階段，我們的工程師和產品團隊也穩步增長。只 有兩個開發人員的日子已經一去不複返了，一眨眼間，我們就有10個，甚至20個 人為現有的以及新產品工作。可想而知，我們需要引進的變化數量也會穩步增加 。我們的硬體上需要承載的應用絕對數量也直線上升，先是以前的兩倍，然後三 倍。同時開發人員也想使用新的應用程式框架、程式設計語言、資料庫、排隊系統及緩衝 伺服器等。

隨著這些複雜性的增加，錯誤和停機的成本也增加了。很快我們發現舊的手動 配置基礎架構已不再適用，而我們基礎架構層對成熟性和靈活性的缺乏也將給我 們帶來以下問題：減緩新產品和功能的發布，危害我們的穩定性。認識到這一點 ，我停止了在產品上的工作，並將重點全部放在研究開發自動化、監控和發布流 程上。

引進Chef

幸運的是，我們認識到我們需要實行DevOps實踐。而當時，我們遇到了 OpsCode Chef，以及它所倡導的“基礎架構即代碼”原則。最初，我 們花費了幾個月時間為現有基礎架構的每一部分編寫自動化指令碼。一旦完成，我 們就可以利用這些自動化指令碼重構所有伺服器，這將大大減輕我們肩上的負擔。 現在我們所有伺服器都已設定一致，而我們最終也有一個地方能讓團隊所有人都 可以看到每塊基礎架構到底是如何建立和設定的。同樣重要的是，它允許我們快 速地將額外資源添加進來。

DevOps團隊的成立

DevOps開始在公司內擔負起獨特的責任，為我們的產品線提供關鍵支援，並保 證我們的基礎架構可以持續拓展。除了這些重點之外，我們也在不斷開發工具和 產品，用於管理這些需要持續支援和改進的基礎架構。尤其在前期，通常來說如 果往基礎架構中引進新的應用，就要求對底層自動化指令碼進行修改。由于越來越 多人開始依賴我們的工作，內部使用者（開發人員和營運人員）也隨之提出了更多 與DevOps相關的需求。

由於我們的Team Dev已經分為不同的產品團隊，且每個團隊都關注不同的業務 ，我們決定設定一個單獨的DevOps團隊。這樣我們就有一個專門的團隊全職解決 基礎架構問題。另外，應用平台的可用性和穩定性對我們的業務來說也是及其重 要的，宕機或別的問題對我們的服務都會有很大的影響。我們需要隨時保證有專 門的、訓練有素的工程師來協助和調查問題，尤其當問題的歸屬可能跨越多個團 隊或無法當時就明了時。

自動化果實

按需配置

在採用Chef和自動化我們產品的基礎架構之後，我們立馬著手做的事情就是改 善我們的測試和staging系統，給它們配上同等程度的自動化。我們經常聽到的抱 怨之一就是開發人員無法簡單快速地給業務人員展示他們當前所做的工作。為此 ，我們開發了一個100%自助服務的門戶，這樣公司裡的任何人都可以啟動一個預 設定管理員在EC2上運行完整的程式。