伴隨著互聯網時代的真正到來和云計算市場的興起，DevOps這個詞越來越多的進入了我們的視野。我們可以認為DevOps是一組方法論的統稱，它 擴大了開發和運維的外延，促進開發、運維、質量保障、運營等各部門的協調與整合，它定義了簡明、自動化的流程，使我們可以承擔更快的變更、更小的風險，可 以使開發人員更多的控制生產環境，讓我們更多的以基礎設施為中心來理解應用，同時也讓我們更多的以應用為主心來理解基礎設施。

可以說，DevOps就是不斷優化的生產過程。

可是在微觀層面，大家對DevOps的理解又不盡相同，也有人可能會對這個名詞望而生畏，覺得它有些不可接近。其實DevOps既不高深也不復雜， 它只是由一些簡單的概念和工具鏈構成的工作流程，我們可以暫時忘掉那些教科書式的理論，開始一次務實又輕松的DevOps之旅。 從現在開始，su root，你就是掌控一切的上帝，讓我們看看你是如何從一點一滴做起，為你的小伙伴們準備一套DevOps體系的。

-- 開始吧！

創世之初，你得建造一個跳板機

一個好的跳板機可以作為DevOps體系的總入口，它為每個人提供運維的個人帳號，并負責精細化的運維權限管理。它提供DevOps工具鏈的運行環境，還可以記錄、審計所有人的操作歷史。

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

舉一個具體的例子，跳板機最基本的功能就是登陸其它服務器，假如這個登陸的命令叫qssh，它需要提供qssh some_server這樣的功能，我們如何實現呢？

qssh是一個C語言編寫的可執行文件，這個可執行文件用于提權，它的核心偽代碼是

當然，這個qssh的執行文件需要賦予suid權限：chmod a+s

經過了qssh的提權動作，_ssh就是運行在root下的了，_ssh比較靈活，可以用任何語言編寫，比如bash，值得注意的是_ssh程序需要做用戶的授權控制，通常它會有一個如下形式的配置文件：

上面可以看到，_ssh被fork的時候，第一個參數便是用戶名，_ssh內部使用傳入的用戶名查詢權限配置表，以決定是否繼續執行。

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

我們后面會看到，DevOps體系會提供很多命令，它們都運行在跳板機上。我們以qssh為例說明跳板機上程序的工作原理，這個原理對其它的命令基本是一樣的。

有了跳板機為基礎，我們有了工具運行的環境，有了精細化權限管理的能力，下面就可以放開手腳大干一場，補充各種DevOps的工具，讓大家的工作更方便了。

部署，讓所有人頭疼？

部署，是DevOps中最重要的一個環節，弄好了跳板機，我們開始去構建一個安全、方便的部署系統吧。好消息是你同樣不需要做太多的開發工作，我們的部署系統是基于puppet的。

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

上面的例子展示了deploy.git大致的目錄結構，nodes下是代表每臺服務器的子目錄，每臺服務器的目錄下有兩個最核心的目錄，分別是puppet和root，puppet下放置puppet的配置文件，root目錄下的所有子目錄與服務器上的/一樣，root目錄下放置需要部署到服務器上的所有文件。對于上面的例子，我們在web_server1上部署了一套memcached服務，現在看看memcached.p是什么樣子的：
?

在這個文件中，qbin和qfile是我們寫的puppet擴展類，他們的實現方式很簡單，這里就不贅述了。我們用qbin部署memcached的二進制文件，部署系統將memcached-1.4.15-linux-x86_64.tar.gz解壓縮到服務器上的/home/app/memcached目錄。我們用qfile放 置memcached的配置文件，部署系統將deploy.git/nodes/web_server1/root/home/app /memcached/memcached.conf這個文件部署到服務器上的對應位置：/home/app/memcached /memcached.conf。

準備好的部署的配置，我們可以開始部署了，方式很簡單，在跳板機上運行下面的命令便可： deploy web_server1

這個命令會做以下幾件事件：

deploy命令支持如下的參數：

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

由于有了pull request和code review流程，所以deploy的權限可以很開放，基本每個運維和開發人員都可以有。設想一下，一個第一天入職的運維或開發就可以放心地在線上升級服 務，或部署新服務，是多么美妙的事情！通過使用一些簡單的工具鏈，并建立適當的流程，部署再也不是一件讓人頭疼的事情了。

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

部署系統本質上是對服務器狀態的維持，除此之外，我們還需要對服務器進行一些操作，比如重啟某個服務、重新加載某個配置、查看服務器的狀態等，這就 需要指令編排系統。指令編排系統提供了一系列預設好的指令，和與之配套的權限控制，這些指令可以由操作員來調用，并作用于服務器。我們基于salt來構建指令系統，先看看指令系統是如何使用的吧：

它的權限控制大致是如下形式：

do命令只需要很少的編碼工作，它基本上是直接轉調salt命令，salt維護了所有服務器到跳板機之間的長連接，所以指令的執行是非常快的。

如果你需要的命令系統沒有提供怎么辦？其實所有預設的指令都是在一個代碼庫里，你隨時可以提交自己的命令，salt會自動把腳本部署到每臺服務器，非常方便。
?

善待你的日志

日志的處理是DevOps中另一個比較大的話題，好的日志處理方式可以讓大家方便的查看、分析日志，可以支持各種分析系統以準實時的方式分析日志，并輸出我們想要的任何結果。讓我們來看看如何使用開源的工具鏈構建一套強大的日志處理系統。

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

logstash是一個日志管理工具，它可以用來收集，分析，存儲日志。logstash采用插件機制，它的所有功能都以插件的形式提供，它的插件 分為三種：輸入、過濾、輸出。輸入插件常用的有file、tcp、log4j、redis等，過慮插件常用的有grep、json、ruby等，輸出插件 常用的有file、tcp、redis、stdout等，更多的插件可以到它的官網上?http://logstash.net/?查詢，我們也可以使用ruby語言方便的擴展它的插件。

假設我們有兩臺服務器產生日志，我們使用logstash的input:file插件在服務器本地收集日志，并通過output:tcp發往日志匯集服務器，在日志匯集服務器上，使用input:tcp來收集網絡上發過來的日志，并用output:file將日志存放在本地。這樣，我們就實現了多處日志的傳輸、匯總。

通過上面的例子看到，用logstash實現最簡單的日志匯集的需求是非常容易的。除了日志匯集，還有日志全文搜索有需求，這里我們使用redis 、elasticsearch、kibana三個工具配合來實現。上面提到在日志匯集服務器上我們使用input:tcp來收集日志，使用output:file將日志組織在本地磁盤上，現在我們再配置logstash把日志存儲在本地之外，再使用output:redis插件將日志發送到redis中一份，然后啟動一個新的logstash實例，使用input:redis插件從上面的redis中讀取，使用output:elasticsearch輸出到elasticsearch中建立索引，最后，我們使用kibana運行一個圖形化的搜索界面，供大家使用。整個架構不需要寫一行代碼。

?

提到日志的處理，就必須要提opentsdb。opentsdb是一個時間序列的分布式數據庫，是日志分析的神器。我們用它存放分析日志后得到的數 據點。從上面描述的架構中，我們看到最終收集到的日志輸出了兩份，一份是本地磁盤，一份是redis，進而輸入到索引系統。現在我們再引入一個 redis，作為日志分析系統的待處理隊列，將日志導入這個隊列中，再由opentsdb的處理程序從這個隊列中讀取。日志灌入redis的過程與上面一 樣，不再贅述。在將日志輸入到redis后，我們啟動一個新的logstash實例，這個實例的input是從redis讀取，并用output:exec插 件來執行自己的分析腳本，分析腳本的輸入是標準輸入中的一行一行的原始日志，腳本對日志分析后，將結果存入opentsdb。logstash支持多個 output并聯，所以我們可以配置很多分析腳本，用于分析各種我們關心的數值，比如性能、可用率、命中率、流量等。數據導入opentsdb后，我們可 以用它來繪圖、告警等。

?

保證質量！

質量永遠是我們的終極訴求。

沒有對質量的保證，一切都是空談，DveOps也只是浮華的空中樓閣。幸運的是，DevOps實踐并不是質量的敵人，相反，我們可以把一些簡單有效的保證質量的手段融入DevOps實踐中。

首先，我們需要持續集成和單元測試，這是質量保障最基本的手段。jenkins是非常好用的持續集成工具，也很容易配置，我們用jenkins配置 一個定時的編譯任務，每10分鐘pull最新的master代碼，編譯、運行單元測試、分析單元測試覆蓋率，如果有某項沒有通過或不滿足要求，則立刻發郵 件通知到大家，并要求相關的責任人及時處理。

OK，現在對質量有了最基本的保障，可這還遠遠不夠。下面我們來構建集成測試系統。主要使用的工具有travis-ci和docker.io，travis-ci是一個云端的持續集成服務，通常與github.com配合使用，docker.io是一套lxc工具鏈，可以方便得實現系統級資源的隔離，比如內存、文件系統、網絡、CPU等，它類似于虛擬機技術，但比虛擬機更輕量級，對資源的消耗也更少。

集成測試的流程大概是：當github.com上有新的pull request提交，可以觸發travis-ci啟動構建，travis-ci構建成功后，使用腳本將構建出的程序發往集成測試服務器，集成測試服務器使 用docker.io啟動一個獨立的沙箱，按預設的配置將所有服務運行起來。服務運行正常后，集成測試服務器取得testing.git中的所有集成測試腳本并逐個運行，最后將成功或失敗的消息返回給travis-ci，travis-ci會根據集成測試的結果，在pull request上標記'travis-ci passed'或'travis-ci failied'。

有了集成測試流程，當我們看到一個pull request時，就可以很方便的知道這個功能或bugfix的集成測試有沒有通過，大大降低了code review的壓力，既加快研發速度，又提升產品質量。

?

你真的了解你的系統嗎？

走完了上面的流程，我們的服務已經順利上線運行啦！現在還有最后一個問題，你真的了解你系統的運行狀態嗎？---- 系統有沒有出故障？網站的速度如何？可用性怎么樣？哪些地區的訪問還需要優化？某個業務的轉化率是高是低？用戶流失最多的是哪個功能或頁面？是什么原因？

在一個公司中，需要有人回答上面的問題，我們認為這是DevOps的職責所在。那么，去了解一個線上的系統，有哪些手段呢？

在線監控

在線監控是監控系統中最重要的一環，它提供最實時的系統運行狀態的信息，通常信息反饋的速度是按秒來計算。在線監控最重要的功能是告警，當系統的某 些指標不符合預期，或基礎設施出現故障，在線監控系統都應該立刻告警，告警的方式通常是郵件和短信。構建在線監控系統，我推薦使用zabbix，原是是：

使用zabbix來構建基本的在線監控系統十分方便和簡單，這里不再展開討論，官方文檔 zabbix.com 可以解答幾乎所有疑問。

第三方在線監控

從事故的預警來看，在線監控可以覆蓋大部分的故障，但有一些IDC一級的網絡問題內部監控是無法察覺的，這時我們需要使用一些外部監控來更全面的覆 蓋可能發生的故障。第三方的監控我推薦使用監控寶一類的監控服務，這類監控服務可以在全國多個地區發起監控請求，我們只需要將自己的業務邏輯，比如打開頁 面，登陸，上傳，下載等的http請求方式配置好，這類服務就可以模擬真實的用戶發起請求，如果出現機房網絡故障或區域性的網絡故障，或者請求的返回不符 合預期，這類監控服務就會立刻通過郵件和短信告警。適當使用第三方的監控服務，成本不高，但可以有效得彌補內部監控的缺陷，值得一試。

第三方測量

除了告警外，監控系統還應該關注最終的用戶體驗，這也是監控系統中最難測量的一塊。幸運的是現在出現了一些第三方的測量服務，比如基調、博銳等，這 類測量服務在全國擁有大量的真實客戶端，可以支持從這些客戶端發起預設的請求，使用最真實的方式還原終端用戶的訪問，收集性能、可能性等指標。我推薦大家 使用這類服務，把自己最核心的業務流程監控起來，通常這類服務都有自己的數據展示和報表頁面，也支持發送日報、周報和月報。當時，如果你對它的報表不滿 意，或者有自己特殊的報表需求，也可以通過api將最原始的監測數據導出，自己進行分析和展示。

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

我們花了一點時間，聊了幾個DevOps的話題，這幾個話題串起來，基本構成了DevOps的流程。我們也看到了DevOps并不復雜，使用一些常 見的工具就可以方便地構建自己的DevOps架構，我鼓勵大家從現在開始就動手嘗試，邊完善邊推動，邊推邊使用，邊使用邊完善，在生產中摸索適用于自己公 司的DevOps實踐。

運維二字承載了太多的內容，DevOps極大的豐富了運維的外延，但我認為運維的內涵始終沒有變過，流程固然重要，但也不能忘記本質。所以說 DevOps并不是運維的全部內容，我也想請各位從事運維工作的朋友時刻謹記這點，抓住運維工作的內核，輔以不斷優化的生產過程，定是如虎添翼，成為業務 和產品的強有力的守護神。