伴隨著互聯(lián)網(wǎng)時(shí)代的真正到來(lái)和云計(jì)算市場(chǎng)的興起，DevOps這個(gè)詞越來(lái)越多的進(jìn)入了我們的視野。我們可以認(rèn)為DevOps是一組方法論的統(tǒng)稱(chēng)，它 擴(kuò)大了開(kāi)發(fā)和運(yùn)維的外延，促進(jìn)開(kāi)發(fā)、運(yùn)維、質(zhì)量保障、運(yùn)營(yíng)等各部門(mén)的協(xié)調(diào)與整合，它定義了簡(jiǎn)明、自動(dòng)化的流程，使我們可以承擔(dān)更快的變更、更小的風(fēng)險(xiǎn)，可 以使開(kāi)發(fā)人員更多的控制生產(chǎn)環(huán)境，讓我們更多的以基礎(chǔ)設(shè)施為中心來(lái)理解應(yīng)用，同時(shí)也讓我們更多的以應(yīng)用為主心來(lái)理解基礎(chǔ)設(shè)施。

可以說(shuō)，DevOps就是不斷優(yōu)化的生產(chǎn)過(guò)程。

可是在微觀(guān)層面，大家對(duì)DevOps的理解又不盡相同，也有人可能會(huì)對(duì)這個(gè)名詞望而生畏，覺(jué)得它有些不可接近。其實(shí)DevOps既不高深也不復(fù)雜， 它只是由一些簡(jiǎn)單的概念和工具鏈構(gòu)成的工作流程，我們可以暫時(shí)忘掉那些教科書(shū)式的理論，開(kāi)始一次務(wù)實(shí)又輕松的DevOps之旅。 從現(xiàn)在開(kāi)始，su root，你就是掌控一切的上帝，讓我們看看你是如何從一點(diǎn)一滴做起，為你的小伙伴們準(zhǔn)備一套DevOps體系的。

-- 開(kāi)始吧！

創(chuàng)世之初，你得建造一個(gè)跳板機(jī)

一個(gè)好的跳板機(jī)可以作為DevOps體系的總?cè)肟?#xff0c;它為每個(gè)人提供運(yùn)維的個(gè)人帳號(hào)，并負(fù)責(zé)精細(xì)化的運(yùn)維權(quán)限管理。它提供DevOps工具鏈的運(yùn)行環(huán)境，還可以記錄、審計(jì)所有人的操作歷史。

跳板機(jī)對(duì)權(quán)限管理的思路是：跳板機(jī)的root帳號(hào)擁有最高的運(yùn)維權(quán)限，它獲得了所有服務(wù)器的各種授權(quán)，包括ssh authorized_keys授權(quán)，管理端口訪(fǎng)問(wèn)授權(quán)，拷貝、部署授權(quán)，命令操作授權(quán)等，每一臺(tái)服務(wù)器都無(wú)條件信任跳板機(jī)的root帳號(hào)。而你的每個(gè)小 伙伴都在跳板機(jī)上擁有一個(gè)屬于他自己的普通帳號(hào)，該帳號(hào)可以運(yùn)行所有的DevOps工具，每個(gè)DevOps工具都是運(yùn)行在root權(quán)限下，它根據(jù)自己具體 的權(quán)限配置來(lái)決定是否允許某人運(yùn)行某個(gè)命令。

舉一個(gè)具體的例子，跳板機(jī)最基本的功能就是登陸其它服務(wù)器，假如這個(gè)登陸的命令叫qssh，它需要提供qssh some_server這樣的功能，我們?nèi)绾螌?shí)現(xiàn)呢？

qssh是一個(gè)C語(yǔ)言編寫(xiě)的可執(zhí)行文件，這個(gè)可執(zhí)行文件用于提權(quán)，它的核心偽代碼是

當(dāng)然，這個(gè)qssh的執(zhí)行文件需要賦予suid權(quán)限：chmod a+s

經(jīng)過(guò)了qssh的提權(quán)動(dòng)作，_ssh就是運(yùn)行在root下的了，_ssh比較靈活，可以用任何語(yǔ)言編寫(xiě)，比如bash，值得注意的是_ssh程序需要做用戶(hù)的授權(quán)控制，通常它會(huì)有一個(gè)如下形式的配置文件：

上面可以看到，_ssh被fork的時(shí)候，第一個(gè)參數(shù)便是用戶(hù)名，_ssh內(nèi)部使用傳入的用戶(hù)名查詢(xún)權(quán)限配置表，以決定是否繼續(xù)執(zhí)行。

_ssh中還需要做一件重要的工作，就是以root身份記下所有人的操作歷史，這份記錄要保證是普通用戶(hù)無(wú)法修改的。記錄的形式大概為：

我們后面會(huì)看到，DevOps體系會(huì)提供很多命令，它們都運(yùn)行在跳板機(jī)上。我們以qssh為例說(shuō)明跳板機(jī)上程序的工作原理，這個(gè)原理對(duì)其它的命令基本是一樣的。

有了跳板機(jī)為基礎(chǔ)，我們有了工具運(yùn)行的環(huán)境，有了精細(xì)化權(quán)限管理的能力，下面就可以放開(kāi)手腳大干一場(chǎng)，補(bǔ)充各種DevOps的工具，讓大家的工作更方便了。

部署，讓所有人頭疼？

部署，是DevOps中最重要的一個(gè)環(huán)節(jié)，弄好了跳板機(jī)，我們開(kāi)始去構(gòu)建一個(gè)安全、方便的部署系統(tǒng)吧。好消息是你同樣不需要做太多的開(kāi)發(fā)工作，我們的部署系統(tǒng)是基于puppet的。

首先，我們需要把部署的信息用版本控制工具管理起來(lái)，這里推薦git。來(lái)看看我們的deploy.git是什么樣子的
?

上面的例子展示了deploy.git大致的目錄結(jié)構(gòu)，nodes下是代表每臺(tái)服務(wù)器的子目錄，每臺(tái)服務(wù)器的目錄下有兩個(gè)最核心的目錄，分別是puppet和root，puppet下放置puppet的配置文件，root目錄下的所有子目錄與服務(wù)器上的/一樣，root目錄下放置需要部署到服務(wù)器上的所有文件。對(duì)于上面的例子，我們?cè)趙eb_server1上部署了一套memcached服務(wù)，現(xiàn)在看看memcached.p是什么樣子的：
?

在這個(gè)文件中，qbin和qfile是我們寫(xiě)的puppet擴(kuò)展類(lèi)，他們的實(shí)現(xiàn)方式很簡(jiǎn)單，這里就不贅述了。我們用qbin部署memcached的二進(jìn)制文件，部署系統(tǒng)將memcached-1.4.15-linux-x86_64.tar.gz解壓縮到服務(wù)器上的/home/app/memcached目錄。我們用qfile放 置memcached的配置文件，部署系統(tǒng)將deploy.git/nodes/web_server1/root/home/app /memcached/memcached.conf這個(gè)文件部署到服務(wù)器上的對(duì)應(yīng)位置：/home/app/memcached /memcached.conf。

準(zhǔn)備好的部署的配置，我們可以開(kāi)始部署了，方式很簡(jiǎn)單，在跳板機(jī)上運(yùn)行下面的命令便可： deploy web_server1

這個(gè)命令會(huì)做以下幾件事件：

deploy命令支持如下的參數(shù)：

了解了工具，我們看看流程，基于上述部署工具鏈的流程大致是：

由于有了pull request和code review流程，所以deploy的權(quán)限可以很開(kāi)放，基本每個(gè)運(yùn)維和開(kāi)發(fā)人員都可以有。設(shè)想一下，一個(gè)第一天入職的運(yùn)維或開(kāi)發(fā)就可以放心地在線(xiàn)上升級(jí)服 務(wù)，或部署新服務(wù)，是多么美妙的事情！通過(guò)使用一些簡(jiǎn)單的工具鏈，并建立適當(dāng)?shù)牧鞒?#xff0c;部署再也不是一件讓人頭疼的事情了。

指令編排，解放大家的手指

部署系統(tǒng)本質(zhì)上是對(duì)服務(wù)器狀態(tài)的維持，除此之外，我們還需要對(duì)服務(wù)器進(jìn)行一些操作，比如重啟某個(gè)服務(wù)、重新加載某個(gè)配置、查看服務(wù)器的狀態(tài)等，這就 需要指令編排系統(tǒng)。指令編排系統(tǒng)提供了一系列預(yù)設(shè)好的指令，和與之配套的權(quán)限控制，這些指令可以由操作員來(lái)調(diào)用，并作用于服務(wù)器。我們基于salt來(lái)構(gòu)建指令系統(tǒng)，先看看指令系統(tǒng)是如何使用的吧：

它的權(quán)限控制大致是如下形式：

do命令只需要很少的編碼工作，它基本上是直接轉(zhuǎn)調(diào)salt命令，salt維護(hù)了所有服務(wù)器到跳板機(jī)之間的長(zhǎng)連接，所以指令的執(zhí)行是非常快的。

如果你需要的命令系統(tǒng)沒(méi)有提供怎么辦？其實(shí)所有預(yù)設(shè)的指令都是在一個(gè)代碼庫(kù)里，你隨時(shí)可以提交自己的命令，salt會(huì)自動(dòng)把腳本部署到每臺(tái)服務(wù)器，非常方便。
?

善待你的日志

日志的處理是DevOps中另一個(gè)比較大的話(huà)題，好的日志處理方式可以讓大家方便的查看、分析日志，可以支持各種分析系統(tǒng)以準(zhǔn)實(shí)時(shí)的方式分析日志，并輸出我們想要的任何結(jié)果。讓我們來(lái)看看如何使用開(kāi)源的工具鏈構(gòu)建一套強(qiáng)大的日志處理系統(tǒng)。

一個(gè)系統(tǒng)的日志通常有多個(gè)部分組成，比如程序的日志，用于審計(jì)的事務(wù)日志，第三方程序（比如nginx、mongodb、memcached等）的 日志，甚至還可能包括第三方合作伙伴（比如支付寶、CDN等）的日志，這些日志分散在很多的地理位置、很多的服務(wù)器、很多的磁盤(pán)目錄或其它介質(zhì)中，我們第 一個(gè)需求是把這些日志收集、匯總，并按照合理的形式存放，方便大家隨時(shí)查看，也方便后續(xù)的程序進(jìn)行分析。我們使用logstash來(lái)實(shí)現(xiàn)這個(gè)需求。

logstash是一個(gè)日志管理工具，它可以用來(lái)收集，分析，存儲(chǔ)日志。logstash采用插件機(jī)制，它的所有功能都以插件的形式提供，它的插件 分為三種：輸入、過(guò)濾、輸出。輸入插件常用的有file、tcp、log4j、redis等，過(guò)慮插件常用的有g(shù)rep、json、ruby等，輸出插件 常用的有file、tcp、redis、stdout等，更多的插件可以到它的官網(wǎng)上?http://logstash.net/?查詢(xún)，我們也可以使用ruby語(yǔ)言方便的擴(kuò)展它的插件。

假設(shè)我們有兩臺(tái)服務(wù)器產(chǎn)生日志，我們使用logstash的input:file插件在服務(wù)器本地收集日志，并通過(guò)output:tcp發(fā)往日志匯集服務(wù)器，在日志匯集服務(wù)器上，使用input:tcp來(lái)收集網(wǎng)絡(luò)上發(fā)過(guò)來(lái)的日志，并用output:file將日志存放在本地。這樣，我們就實(shí)現(xiàn)了多處日志的傳輸、匯總。

通過(guò)上面的例子看到，用logstash實(shí)現(xiàn)最簡(jiǎn)單的日志匯集的需求是非常容易的。除了日志匯集，還有日志全文搜索有需求，這里我們使用redis 、elasticsearch、kibana三個(gè)工具配合來(lái)實(shí)現(xiàn)。上面提到在日志匯集服務(wù)器上我們使用input:tcp來(lái)收集日志，使用output:file將日志組織在本地磁盤(pán)上，現(xiàn)在我們?cè)倥渲胠ogstash把日志存儲(chǔ)在本地之外，再使用output:redis插件將日志發(fā)送到redis中一份，然后啟動(dòng)一個(gè)新的logstash實(shí)例，使用input:redis插件從上面的redis中讀取，使用output:elasticsearch輸出到elasticsearch中建立索引，最后，我們使用kibana運(yùn)行一個(gè)圖形化的搜索界面，供大家使用。整個(gè)架構(gòu)不需要寫(xiě)一行代碼。

?

提到日志的處理，就必須要提opentsdb。opentsdb是一個(gè)時(shí)間序列的分布式數(shù)據(jù)庫(kù)，是日志分析的神器。我們用它存放分析日志后得到的數(shù) 據(jù)點(diǎn)。從上面描述的架構(gòu)中，我們看到最終收集到的日志輸出了兩份，一份是本地磁盤(pán)，一份是redis，進(jìn)而輸入到索引系統(tǒng)。現(xiàn)在我們?cè)僖胍粋€(gè) redis，作為日志分析系統(tǒng)的待處理隊(duì)列，將日志導(dǎo)入這個(gè)隊(duì)列中，再由opentsdb的處理程序從這個(gè)隊(duì)列中讀取。日志灌入redis的過(guò)程與上面一 樣，不再贅述。在將日志輸入到redis后，我們啟動(dòng)一個(gè)新的logstash實(shí)例，這個(gè)實(shí)例的input是從redis讀取，并用output:exec插 件來(lái)執(zhí)行自己的分析腳本，分析腳本的輸入是標(biāo)準(zhǔn)輸入中的一行一行的原始日志，腳本對(duì)日志分析后，將結(jié)果存入opentsdb。logstash支持多個(gè) output并聯(lián)，所以我們可以配置很多分析腳本，用于分析各種我們關(guān)心的數(shù)值，比如性能、可用率、命中率、流量等。數(shù)據(jù)導(dǎo)入opentsdb后，我們可 以用它來(lái)繪圖、告警等。

?

保證質(zhì)量！

質(zhì)量永遠(yuǎn)是我們的終極訴求。

沒(méi)有對(duì)質(zhì)量的保證，一切都是空談，DveOps也只是浮華的空中樓閣。幸運(yùn)的是，DevOps實(shí)踐并不是質(zhì)量的敵人，相反，我們可以把一些簡(jiǎn)單有效的保證質(zhì)量的手段融入DevOps實(shí)踐中。

首先，我們需要持續(xù)集成和單元測(cè)試，這是質(zhì)量保障最基本的手段。jenkins是非常好用的持續(xù)集成工具，也很容易配置，我們用jenkins配置 一個(gè)定時(shí)的編譯任務(wù)，每10分鐘pull最新的master代碼，編譯、運(yùn)行單元測(cè)試、分析單元測(cè)試覆蓋率，如果有某項(xiàng)沒(méi)有通過(guò)或不滿(mǎn)足要求，則立刻發(fā)郵 件通知到大家，并要求相關(guān)的責(zé)任人及時(shí)處理。

OK，現(xiàn)在對(duì)質(zhì)量有了最基本的保障，可這還遠(yuǎn)遠(yuǎn)不夠。下面我們來(lái)構(gòu)建集成測(cè)試系統(tǒng)。主要使用的工具有travis-ci和docker.io，travis-ci是一個(gè)云端的持續(xù)集成服務(wù)，通常與github.com配合使用，docker.io是一套lxc工具鏈，可以方便得實(shí)現(xiàn)系統(tǒng)級(jí)資源的隔離，比如內(nèi)存、文件系統(tǒng)、網(wǎng)絡(luò)、CPU等，它類(lèi)似于虛擬機(jī)技術(shù)，但比虛擬機(jī)更輕量級(jí)，對(duì)資源的消耗也更少。

集成測(cè)試的流程大概是：當(dāng)github.com上有新的pull request提交，可以觸發(fā)travis-ci啟動(dòng)構(gòu)建，travis-ci構(gòu)建成功后，使用腳本將構(gòu)建出的程序發(fā)往集成測(cè)試服務(wù)器，集成測(cè)試服務(wù)器使 用docker.io啟動(dòng)一個(gè)獨(dú)立的沙箱，按預(yù)設(shè)的配置將所有服務(wù)運(yùn)行起來(lái)。服務(wù)運(yùn)行正常后，集成測(cè)試服務(wù)器取得testing.git中的所有集成測(cè)試腳本并逐個(gè)運(yùn)行，最后將成功或失敗的消息返回給travis-ci，travis-ci會(huì)根據(jù)集成測(cè)試的結(jié)果，在pull request上標(biāo)記'travis-ci passed'或'travis-ci failied'。

有了集成測(cè)試流程，當(dāng)我們看到一個(gè)pull request時(shí)，就可以很方便的知道這個(gè)功能或bugfix的集成測(cè)試有沒(méi)有通過(guò)，大大降低了code review的壓力，既加快研發(fā)速度，又提升產(chǎn)品質(zhì)量。

?

你真的了解你的系統(tǒng)嗎？

走完了上面的流程，我們的服務(wù)已經(jīng)順利上線(xiàn)運(yùn)行啦！現(xiàn)在還有最后一個(gè)問(wèn)題，你真的了解你系統(tǒng)的運(yùn)行狀態(tài)嗎？---- 系統(tǒng)有沒(méi)有出故障？網(wǎng)站的速度如何？可用性怎么樣？哪些地區(qū)的訪(fǎng)問(wèn)還需要優(yōu)化？某個(gè)業(yè)務(wù)的轉(zhuǎn)化率是高是低？用戶(hù)流失最多的是哪個(gè)功能或頁(yè)面？是什么原因？

在一個(gè)公司中，需要有人回答上面的問(wèn)題，我們認(rèn)為這是DevOps的職責(zé)所在。那么，去了解一個(gè)線(xiàn)上的系統(tǒng)，有哪些手段呢？

在線(xiàn)監(jiān)控

在線(xiàn)監(jiān)控是監(jiān)控系統(tǒng)中最重要的一環(huán)，它提供最實(shí)時(shí)的系統(tǒng)運(yùn)行狀態(tài)的信息，通常信息反饋的速度是按秒來(lái)計(jì)算。在線(xiàn)監(jiān)控最重要的功能是告警，當(dāng)系統(tǒng)的某 些指標(biāo)不符合預(yù)期，或基礎(chǔ)設(shè)施出現(xiàn)故障，在線(xiàn)監(jiān)控系統(tǒng)都應(yīng)該立刻告警，告警的方式通常是郵件和短信。構(gòu)建在線(xiàn)監(jiān)控系統(tǒng)，我推薦使用zabbix，原是是：

使用zabbix來(lái)構(gòu)建基本的在線(xiàn)監(jiān)控系統(tǒng)十分方便和簡(jiǎn)單，這里不再展開(kāi)討論，官方文檔 zabbix.com 可以解答幾乎所有疑問(wèn)。

第三方在線(xiàn)監(jiān)控

從事故的預(yù)警來(lái)看，在線(xiàn)監(jiān)控可以覆蓋大部分的故障，但有一些IDC一級(jí)的網(wǎng)絡(luò)問(wèn)題內(nèi)部監(jiān)控是無(wú)法察覺(jué)的，這時(shí)我們需要使用一些外部監(jiān)控來(lái)更全面的覆 蓋可能發(fā)生的故障。第三方的監(jiān)控我推薦使用監(jiān)控寶一類(lèi)的監(jiān)控服務(wù)，這類(lèi)監(jiān)控服務(wù)可以在全國(guó)多個(gè)地區(qū)發(fā)起監(jiān)控請(qǐng)求，我們只需要將自己的業(yè)務(wù)邏輯，比如打開(kāi)頁(yè) 面，登陸，上傳，下載等的http請(qǐng)求方式配置好，這類(lèi)服務(wù)就可以模擬真實(shí)的用戶(hù)發(fā)起請(qǐng)求，如果出現(xiàn)機(jī)房網(wǎng)絡(luò)故障或區(qū)域性的網(wǎng)絡(luò)故障，或者請(qǐng)求的返回不符 合預(yù)期，這類(lèi)監(jiān)控服務(wù)就會(huì)立刻通過(guò)郵件和短信告警。適當(dāng)使用第三方的監(jiān)控服務(wù)，成本不高，但可以有效得彌補(bǔ)內(nèi)部監(jiān)控的缺陷，值得一試。

第三方測(cè)量

除了告警外，監(jiān)控系統(tǒng)還應(yīng)該關(guān)注最終的用戶(hù)體驗(yàn)，這也是監(jiān)控系統(tǒng)中最難測(cè)量的一塊。幸運(yùn)的是現(xiàn)在出現(xiàn)了一些第三方的測(cè)量服務(wù)，比如基調(diào)、博銳等，這 類(lèi)測(cè)量服務(wù)在全國(guó)擁有大量的真實(shí)客戶(hù)端，可以支持從這些客戶(hù)端發(fā)起預(yù)設(shè)的請(qǐng)求，使用最真實(shí)的方式還原終端用戶(hù)的訪(fǎng)問(wèn)，收集性能、可能性等指標(biāo)。我推薦大家 使用這類(lèi)服務(wù)，把自己最核心的業(yè)務(wù)流程監(jiān)控起來(lái)，通常這類(lèi)服務(wù)都有自己的數(shù)據(jù)展示和報(bào)表頁(yè)面，也支持發(fā)送日?qǐng)?bào)、周報(bào)和月報(bào)。當(dāng)時(shí)，如果你對(duì)它的報(bào)表不滿(mǎn) 意，或者有自己特殊的報(bào)表需求，也可以通過(guò)api將最原始的監(jiān)測(cè)數(shù)據(jù)導(dǎo)出，自己進(jìn)行分析和展示。

嗯，差不多了，還有什么？

我們花了一點(diǎn)時(shí)間，聊了幾個(gè)DevOps的話(huà)題，這幾個(gè)話(huà)題串起來(lái)，基本構(gòu)成了DevOps的流程。我們也看到了DevOps并不復(fù)雜，使用一些常 見(jiàn)的工具就可以方便地構(gòu)建自己的DevOps架構(gòu)，我鼓勵(lì)大家從現(xiàn)在開(kāi)始就動(dòng)手嘗試，邊完善邊推動(dòng)，邊推邊使用，邊使用邊完善，在生產(chǎn)中摸索適用于自己公 司的DevOps實(shí)踐。

運(yùn)維二字承載了太多的內(nèi)容，DevOps極大的豐富了運(yùn)維的外延，但我認(rèn)為運(yùn)維的內(nèi)涵始終沒(méi)有變過(guò)，流程固然重要，但也不能忘記本質(zhì)。所以說(shuō) DevOps并不是運(yùn)維的全部?jī)?nèi)容，我也想請(qǐng)各位從事運(yùn)維工作的朋友時(shí)刻謹(jǐn)記這點(diǎn)，抓住運(yùn)維工作的內(nèi)核，輔以不斷優(yōu)化的生產(chǎn)過(guò)程，定是如虎添翼，成為業(yè)務(wù) 和產(chǎn)品的強(qiáng)有力的守護(hù)神。