我眼中的DevOps(轉)

 過去一年以來，一批來自歐美的、不墨守陳規的系統管理員和開發人員一直在談論一個新概念：DevOps。DevOps 就是開發（Development）和運維（Operations）這兩個領域的合併。（若是沒錯的話，DevOps還包括產品管理、QA、*winces* 甚至銷售等領域）

脫節(The Broken)

那麼……爲何要合併這兩個領域？緣由不少，但首要緣由是：咱們目前的工做流程是脫節的。絕對的脫節。不少公司的開發部門和運維部門之間存在的深入矛盾，其實就是這個「脫節」形成的。（意譯，求斧正）

下面是一個你們都基本熟悉的例子：部署軟件產品。

 

開發部門要開發一款新產品。這款產品要使用最新最炫的技術，來保證客戶的全部花俏的需求，從而給公司帶來百萬美圓的利潤。這款產品被要求使用最新的技術和運行平臺，還得立刻交付。因而開發部門沒日沒夜的加班、趕代碼（cuts code like crazy），終於如期完成了任務。而後他們把本身的「傑做」一股腦的甩給了運維部門，後者還沒能徹底接手，前者已經火燒眉毛的開始了慶功會。

接到產品後，運維部門每一個人的心中都充滿了恐懼。

下面就是運維部門的恐懼之源：（{A.B.C}表示A或B或C之一）

• 這款優秀的產品在目前的底層平臺上沒法運行，由於這個平臺{太古老了，空間不足，不支持某某版本}
• 這款產品的體系結構跟咱們的{存儲，網絡，部署，安全}模型不匹配。
• 這款產品的{ 報告，安全，監視，備份，服務提供} 咱們搞不懂 ，因此無法把它作成實際可用的產品。

儘管伴隨着不絕於耳的抱怨和咒罵，運維部門最終仍是把這款產品安裝好了。不幸的是，因爲作了不少蹩腳的修改和不合理的強迫式運行，這款產品的性能最後被歸結爲：終極失敗（Epic Fail）。

因而很是沮喪的運維部門開始記錄各類問題，源源不斷的給開發部門提Issue。而開發部門的迴應基本上都是：

• 這不是咱們的錯 —— 咱們的代碼很是完美——而是（運維部門的）部署作的太差勁了。
• 運維部門比較笨，他們不懂新技術—— 爲何他們無法實現最新的技術呢？爲何他們這麼落伍呢？
• 在個人機器上運行的沒問題啊……

兩個部門之間的交流很快變成了一場狂風暴雨。客戶（以及股東、投資方和管理層）則成了蒙受損失的失敗方。最終公司損失了無數的金錢，你們也都失業了。終極的失敗。

DevOps 又有啥不一樣？它有什麼好處？

DevOps 就是千方百計的避免這種「終極失敗」，同時讓你們用更聰明更有效的方式去工做。它是一種框架，包含了不少優秀想法和原則，它鼓勵開發部門和運維部門通力合做。在DevOps環境中，開發人員和系統管理員會構建一些關係、流程和工具，從而更好的與客戶互動，最終提供更好的服務。

DevOps 也不只僅是一種軟件的部署方法。它經過一種全新的方式，來思考如何讓軟件的做者（開發部門）和運營者（運營部門）進行合做與協同。使用了DevOps模型以後，會使兩個部門更好的交互，使二者的關係獲得改善，從而讓不少領域從中受益，例如：自動化、監視、能力規劃和性能、備份與恢復、安全、網絡以及服務提供（provisioning）等等。

「對於DevOps是什麼？」 這個問題，DevOps社區中的每一個人的回答都不盡相同。由於咱們的工做經驗不一樣，關注的問題也不一樣。就我我的而言，DevOps分紅四大部分：

簡單

KISS（Keep it Simple and Stupid，簡單就是美）原則是最重要的。因此本段文字也很簡單。咱們要儘可能提供簡單、可重用的解決方案。「簡單」節約了書寫文檔、培訓和提供支持的時間。「簡單」增長了溝通的速度、避免混淆、減小了開發和運維出錯時的風險。「簡單」讓人更快的發佈產品。

部門之間關係

早參與，多參與。對於開發人員，要讓運維人員常駐到開發部門，全程參與開發流程。邀請運維人員參與你的Scrum或者開發會議，與他們分享項目計劃、分享新技術的點子和心得。蒐集功能性需求（指開發人員用到的需求）的同時也要蒐集運維方面的需求。把對於「發佈、備份、監控、安全、配置管理和系統功能」的測試做爲一項獨立的項目流程。軟件產品在開發時解決的問題越多，那麼在使用時暴露給用戶的問題就越少。給運維人員作培訓，讓他們弄清楚項目的體系結構和核心代碼。若是運維人員在反饋bug時提供的信息越多，那麼你花在排查問題（trouble-shooting) 的時間就越少，這個bug也就會更快的被解決掉。

對於運維人員，在遇到問題時須要把開發人員加進來，你們一塊兒解決問題。邀請開發人員參與大家的會議，分享項目進度（roadmaps），而且共同修訂工做計劃。運維人員必定要了解開發部門下一步的工做方向，從而確保產品運行的底層平臺可以良好的支持最新技術。開發人員也會帶來相關的技術、知識和工做，幫助大家改善產品的運行環境，使其更加易於維護、簡潔有效。

有一些開發領域的概念，例如：「要根據API而非封閉的interface來構建工具」，分佈式版本控制，驅動測試開發，以及諸如敏捷開發、看板管理（Kanban）和Scrum等方法論。若是把這些概念應用在運維領域，一樣會產生革命性的變革。

不要害怕新點子和新技術。咱們能夠隨時隨地的向他人學習，哪怕是一句「咱們不再要那樣作了！」也會讓咱們從中獲益。儘管處於不一樣的部門，可是咱們要共同窗習、共同成長，這樣才能協同工做的更好！

按照從高到低的順序，有效的溝通方式應該是：面對面交流 、視頻會議、電話、即時通信軟件、Email。

工做中的流程

有本身的流程管理(process engineering)—— 從原始的筆錄到 ISO9001。但它們都存在一個關鍵的缺陷：過於理想化，它要求每一個步驟都必須成功執行。例如：爲了搭建一臺新主機，會有下列一套簡單的流程：

• 步驟一：裝機（把各個硬件組裝到一塊兒）。
• 步驟二：接線、通電。
• 步驟三：安裝操做系統。
• 接下來還有步驟4、5、六。

若是一切順利的話，第N步結束以後就會有一個功能完整、運行正常的新主機。但萬一有個流程沒跑通怎麼辦？好比說在某個步驟斷了，走不下去了，或者在這一步獲得了異常的輸出，有沒有另外的步驟來處理這個異常？

因此，流程絕對不會從頭至尾一路順風，因此咱們要把每一步流程都認真對待，找出全部潛在的問題和障礙。跟軟件產品同樣，在流程的管理中也要有異常處理。咱們沒必要作到精確預見每個問題，但必定要保證：即便流程出錯，它還能往下走。

把不一樣領域的全部流程串到一塊兒。這些領域包括：部署、監控、能力計劃(capacity planning) 等等。從邏輯上講，「部署」是軟件開發週期的最後一環，因此它應該屬於「開發流程」，而非「運維流程」。另外一個例子是度量和監控。在開發領域，若是不理解底線標準和估算，就什麼評估都作不了。把開發部門和運維部門的流程銜接在一塊兒，也會讓兩個部門更好的配合、相互理解、承擔共同的責任。最後還有個優勢：文檔只須要一份而不是兩份（開發一份、運維一份），從而節省了資金。

自動化，自動化，仍是自動化。構建或使用簡單、可擴展的工具（確保提供API, 機器可讀的輸入、輸出 -- 參考 James White的文章：Infrastructure Manifesto）。使用Puppet一類的工具作配置管理。要擴展這些自動化工具，使其可以支持多個領域（開發領域和運維領域），而且在產品的不一樣環境（開發環境、測試環境、發佈環境和生產環境）中使用相同的工具（也叫end-to-end）。這樣不但會在產品支持和管理方面帶來經濟效益，並且也能夠在編寫新代碼的同時，進行產品的發佈和管理。

最後，在構建流程和自動化時，要把KISS原則牢記於心。越複雜就越易錯。只有簡單的流程和工具才易於實現、易於管理和易於維護。

持續改進

不要中止創新和學習。當今技術發展的很快，客戶的需求也每每如此。把「持續改進和持續集成」 加入到你的工具和流程中去，這也是運維人員向（優秀的）開發人員學習的好途徑，能夠學到諸如測試驅動開發等最佳實踐。例如：能夠向你的部署流程中加入單元測試。作監控時也應該增長些行爲測試，提升交付質量。嘗試用開發領域中的工具（例如Hudson）在運維領域中作些工做（例如瀏覽數據(explore）、測量性能（measure)等等）。

要不斷的總結教訓。要積極主動的、在不一樣領域尋找錯誤的根源。 一旦收到錯誤報告，就果斷把開發小組和運維小組找來，一塊兒解決這個問題。有時候開發人員很簡單的幾回代碼重構，就能夠很好的避免底層運行環境的改變，減小運維人員的負擔。總之，遇到問題時，開發部門和運維部門要密切配合、共同解決，而不是互相推諉、踢皮球。

對我來講...

最後，對我來講，DevOps 的主要內容是：跟誰共同工做、如何共同工做。它最吸引個人地方就是致力於把不一樣部門不一樣分工的人召集到一塊兒，共同努力解決問題。這樣的工做環境，是我所憧憬的樂園。

關於譯者

申思惟，2005年本科畢業於華南理工大學計算機學院。一直從事Web領域的開發，3年多Java、2年多Ruby on Rails的工做經驗。目前在摩托羅拉公司工做，一名普通的程序員。

聲明：本文已獲原創做者James Turnbull的許可。

原文連接：http://article.yeeyan.org/view/139924/170387

英文連接：http://www.kartar.net/2010/02/what-devops-means-to-me/