中小企業基于雲的自動化運維實踐二則

案例1：基于雲的運維自動化

我們是小規模的公司，搭建在 aws 上的服務，主要使用 ruby on rails，并實作了應用的水準擴容。

在專案一開始的時候隻有一台 ec2 就可以跑了，後來因為專案越做越大，開始做平行擴充以及 soa，是以我們導入了 chef 做自動化營運，主要使用 chef 做機器的安裝及部署，使用 cloud watch 做機器與 application 的效能監控，在每次 deploy 的時候做ami，當資源負擔到達設定值時，chef 會使用最新的 ami 開一台新的機器加入 elb，這個過程大約是 5 分鐘，于此我們做到了 application 面的平行擴充。

資料庫的部分，我們使用 postgresql 做叢集，一台 master + 多台 slave 加上 aws 本身的 muti-az 機制，可以動态加開 slave 以及 load balance;redis 的部分亦同。

現在我們使用 jenkins 做 ci，每次跑完 ci 會包一個 docker 版本來跑 staging 環境，staging 環境現在跑 docker，但現在還不敢放到 production 環境中。

案例2：關于自動化部署

我從多個方面來描述下我們廣告公司運維自動化的實施情況。

編譯：

我們這邊rtb是用linux下的c++開發的，部署的過程中需要依賴一些特定版本的linux的運作庫，而編譯本身需要的庫和頭檔案會更多，是以我們是将編譯和自動部署分開的，業務需求完成編碼和測試後，會将可執行檔案放在指定的位置，用jenkins來調用之前調試好的自動部署腳本來進行推送和啟動運作，這樣能保證編譯的程式相關的功能都是測試通過，且經過驗證的，自動化部署之後外圍還有相應的監控系統會定時掃描端口開放情況以及程式運作情況。

商務平台：

這部分是用java開發的，包管理使用maven，已經做好了關聯的特定版本的jar包的管理，這部分功能就是開發測試完畢，将驗證沒有問題的特定版本号的svn位址送出給系統部，通過jenkins從svn拉代碼，調用maven進行編譯，部署和啟動，相關功能都是在運作伺服器上執行。

資料：

資料部分采用了redis和tair叢集，用于存儲人群屬性和cookie映射資料，redis和tair是通過jenkins進行部署的，資料導入是每天定時跑完畫像資料後自動導入的，而資料的遷移是通過人工觸發的，當部分節點資料存在問題時，外部有系統監控，發現問題，人工觸發資料遷移。人工觸發資料遷移是一般是在發現資料分布不均衡，特定節點負載非常高的情況下，會在後半夜觸發遷移操作。

流程規劃：

業務相關的程式開發之後，預設是手動部署的，手動部署時會梳理相關的流程，形成腳本，後續jenkins的自動化腳本也是來源于手動部署的腳本。

auto scale：

叢集是auto scale的，平時會有一個最基本的機器數量配置，部署相應的程式，部署完成後不存在減機器的情況，如果有流量突發高峰和廣告投放高峰，有一部分備用的機器可以快速部署，然後把流量指到新部署的機器上

規模：

目前大概用于rtb的機器有40多台高配的伺服器，每台伺服器上會有20個左右的程序，商務平台和展現點選收集以及計費系統，伺服器有20多台機器，而後端的日志存儲和人群畫像部分用到的hadoop有50多台機器。

精彩觀點摘錄

自動化運維的本質，個人愚見就是把人解放出來，人騰出來做更有價值的事，事不會少，但産生價值的事要越來越多，其實從某種程度上面來講，對運維人員是一個悲劇，如果運維人員不提升自己的核心競争力，那就面臨着下崗，在老闆心目中，機器能更快更好的做好，為什麼需要人來做(慢，不能量化)。當然反過來說，運維人員就要在老闆面前找到自己的價值。

自動化運維，我更關注人。

基于公司實際情況，制定完善的流程，把重複的工作工具化，有挑戰的工作簡單化，相應的流程及工具文檔化。總之盡可能不需要人為幹預，即便需要人操作，懂點技術的員工按流程和文檔即可完成操作。

q & a

q1：資料叢集采用jenkins部署是否存在不妥，是否違背了編譯和部署分開的原則?

其實資料叢集用jenkins部署主要是編譯的基礎環境是一定的，可以在使用jenkins部署之前完成機器系統安裝之後會将相關的編譯環境也批量安裝好，是以用jenkins部署是沒有問題的。

q2：jenkins在裡面用得太重了，不知道會不會導緻ci慢或其它問題?

其實不會，因為子系統劃分是将對比較輕的，不會有非常複雜和耗時的編譯。

本文作者：董偉/付海軍

來源：51cto