案例1：基于云的運(yùn)維自動(dòng)化

我們是小規(guī)模的公司，搭建在 AWS 上的服務(wù)，主要使用 Ruby on Rails，并實(shí)現(xiàn)了應(yīng)用的水平擴(kuò)容。

在專(zhuān)案一開(kāi)始的時(shí)候只有一臺(tái) EC2 就可以跑了，后來(lái)因?yàn)閷?zhuān)案越做越大，開(kāi)始做平行擴(kuò)充以及 SOA，因此我們導(dǎo)入了 Chef 做自動(dòng)化運(yùn)營(yíng)，主要使用 Chef 做機(jī)器的安裝及部署，使用 Cloud Watch 做機(jī)器與 Application 的效能監(jiān)控，在每次 deploy 的時(shí)候做AMI，當(dāng)資源負(fù)擔(dān)到達(dá)設(shè)定值時(shí)，Chef 會(huì)使用***的 AMI 開(kāi)一臺(tái)新的機(jī)器加入 ELB，這個(gè)過(guò)程大約是 5 分鐘，于此我們做到了 Application 面的平行擴(kuò)展。

數(shù)據(jù)庫(kù)的部分，我們使用 PostgreSQL 做集群，一臺(tái) Master + 多臺(tái) Slave 加上 AWS 本身的 muti-AZ 機(jī)制，可以動(dòng)態(tài)加開(kāi) slave 以及 load balance;Redis 的部分亦同。

現(xiàn)在我們使用 Jenkins 做 CI，每次跑完 CI 會(huì)包一個(gè) Docker 版本來(lái)跑 staging 環(huán)境，staging 環(huán)境現(xiàn)在跑 docker，但現(xiàn)在還不敢放到 production 環(huán)境中。

案例2：關(guān)于自動(dòng)化部署

我從多個(gè)方面來(lái)描述下我們廣告公司運(yùn)維自動(dòng)化的實(shí)施情況。

編譯：

我們這邊RTB是用linux下的C++開(kāi)發(fā)的，部署的過(guò)程中需要依賴一些特定版本的linux的運(yùn)行庫(kù)，而編譯本身需要的庫(kù)和頭文件會(huì)更多，所以我們是將編譯和自動(dòng)部署分開(kāi)的，業(yè)務(wù)需求完成編碼和測(cè)試后，會(huì)將可執(zhí)行文件放在指定的位置，用jenkins來(lái)調(diào)用之前調(diào)試好的自動(dòng)部署腳本來(lái)進(jìn)行推送和啟動(dòng)運(yùn)行，這樣能保證編譯的程序相關(guān)的功能都是測(cè)試通過(guò)，且經(jīng)過(guò)驗(yàn)證的，自動(dòng)化部署之后外圍還有相應(yīng)的監(jiān)控系統(tǒng)會(huì)定時(shí)掃描端口開(kāi)放情況以及程序運(yùn)行情況。

商務(wù)平臺(tái)：

這部分是用java開(kāi)發(fā)的，包管理使用maven，已經(jīng)做好了關(guān)聯(lián)的特定版本的jar包的管理，這部分功能就是開(kāi)發(fā)測(cè)試完畢，將驗(yàn)證沒(méi)有問(wèn)題的特定版本號(hào)的svn地址提交給系統(tǒng)部，通過(guò)jenkins從SVN拉代碼，調(diào)用maven進(jìn)行編譯，部署和啟動(dòng)，相關(guān)功能都是在運(yùn)行服務(wù)器上執(zhí)行。

數(shù)據(jù)：

數(shù)據(jù)部分采用了redis和tair集群，用于存儲(chǔ)人群屬性和cookie映射數(shù)據(jù)，redis和tair是通過(guò)jenkins進(jìn)行部署的，數(shù)據(jù)導(dǎo)入是每天定時(shí)跑完畫(huà)像數(shù)據(jù)后自動(dòng)導(dǎo)入的，而數(shù)據(jù)的遷移是通過(guò)人工觸發(fā)的，當(dāng)部分節(jié)點(diǎn)數(shù)據(jù)存在問(wèn)題時(shí)，外部有系統(tǒng)監(jiān)控，發(fā)現(xiàn)問(wèn)題，人工觸發(fā)數(shù)據(jù)遷移。人工觸發(fā)數(shù)據(jù)遷移是一般是在發(fā)現(xiàn)數(shù)據(jù)分布不均衡，特定節(jié)點(diǎn)負(fù)載非常高的情況下，會(huì)在后半夜觸發(fā)遷移操作。

流程規(guī)劃：

業(yè)務(wù)相關(guān)的程序開(kāi)發(fā)之后，默認(rèn)是手動(dòng)部署的，手動(dòng)部署時(shí)會(huì)梳理相關(guān)的流程，形成腳本，后續(xù)jenkins的自動(dòng)化腳本也是來(lái)源于手動(dòng)部署的腳本。

Auto Scale：

集群是auto scale的，平時(shí)會(huì)有一個(gè)最基本的機(jī)器數(shù)量配置，部署相應(yīng)的程序，部署完成后不存在減機(jī)器的情況，如果有流量突發(fā)高峰和廣告投放高峰，有一部分備用的機(jī)器可以快速部署，然后把流量指到新部署的機(jī)器上

規(guī)模：

目前大概用于RTB的機(jī)器有40多臺(tái)高配的服務(wù)器，每臺(tái)服務(wù)器上會(huì)有20個(gè)左右的進(jìn)程，商務(wù)平臺(tái)和展現(xiàn)點(diǎn)擊收集以及計(jì)費(fèi)系統(tǒng)，服務(wù)器有20多臺(tái)機(jī)器，而后端的日志存儲(chǔ)和人群畫(huà)像部分用到的hadoop有50多臺(tái)機(jī)器。

精彩觀點(diǎn)摘錄

自動(dòng)化運(yùn)維的本質(zhì)，個(gè)人愚見(jiàn)就是把人解放出來(lái)，人騰出來(lái)做更有價(jià)值的事，事不會(huì)少，但產(chǎn)生價(jià)值的事要越來(lái)越多，其實(shí)從某種程度上面來(lái)講，對(duì)運(yùn)維人員是一個(gè)悲劇，如果運(yùn)維人員不提升自己的核心競(jìng)爭(zhēng)力，那就面臨著下崗，在老板心目中，機(jī)器能更快更好的做好，為什么需要人來(lái)做(慢，不能量化)。當(dāng)然反過(guò)來(lái)說(shuō)，運(yùn)維人員就要在老板面前找到自己的價(jià)值。

自動(dòng)化運(yùn)維，我更關(guān)注人。

基于公司實(shí)際情況，制定完善的流程，把重復(fù)的工作工具化，有挑戰(zhàn)的工作簡(jiǎn)單化，相應(yīng)的流程及工具文檔化?？傊M可能不需要人為干預(yù)，即便需要人操作，懂點(diǎn)技術(shù)的員工按流程和文檔即可完成操作。

Q & A

Q1：數(shù)據(jù)集群采用Jenkins部署是否存在不妥，是否違背了編譯和部署分開(kāi)的原則?

其實(shí)數(shù)據(jù)集群用jenkins部署主要是編譯的基礎(chǔ)環(huán)境是一定的，可以在使用jenkins部署之前完成機(jī)器系統(tǒng)安裝之后會(huì)將相關(guān)的編譯環(huán)境也批量安裝好，所以用jenkins部署是沒(méi)有問(wèn)題的。

Q2：Jenkins在里面用得太重了，不知道會(huì)不會(huì)導(dǎo)致CI慢或其它問(wèn)題?

其實(shí)不會(huì)，因?yàn)樽酉到y(tǒng)劃分是將對(duì)比較輕的，不會(huì)有非常復(fù)雜和耗時(shí)的編譯。