[譯]一個系統管理員眼中的DevOps

前言

原文發表在Patrick Debois大神的官網上，傳送門>>

通篇圍繞運維工做進行闡述，始終是在強調運維人員和開發人員須要通力協做，這大概也是DevOps理念的核心價值所在吧！大概是由於做者來自比利時吧！翻譯的時候仍是有些吃力。儘可能保證原汁原味，不足之處，敬請指正！

寫做背景

2011年的LISA (Large Installation System Administration)峯會有一個關於**「DevOps」**的主題。

與會者都是從事了至關長時間的自動化工做，而且不少人都認爲天天都在作着有關於DevOps的工做。

而後，他們想請我爲Usenix ;Login magazine寫一篇文章，從系統管理員視角闡述一下DevOps。由於看這篇文章還須要訂閱這本雜誌，因此我乾脆把它發表到個人網站，供其餘讀者閱讀。

介紹

儘管對於DevOps尚未一個真正意義上的定義，可是DevOps大體能夠分爲四個關鍵點（CAMS）：

• 文化（Culture）
• 自動化（Automation）
• 度量指標（Measurement）
• 分享（Sharing）

在這篇文章裏，咱們能夠看到這四要素是如何影響系統管理員的。

做爲一名系統管理員，你或許對自動化（Automation）和度量指標（Measurement）兩部分比較熟悉，業界也有最佳實踐，使得自動化的工做變得更快速和可重複。此外，爲了確保系統運行更流暢，收集一些系統運行指標，採起一些必要的監控措施已經成爲平常工做不可或缺的部分了。

痛點

長期以來，運維（一般是系統管理員的工做的一部分）已經被視做是軟件交付的最後一個步驟了。

在整個項目中，開發人員的編碼工做獨立於運維工做，而且一旦軟件已經開發完畢了，他們認爲是時候將其交給運維部門執行了。

在開發過程當中暴露出了不少問題。在開發和測試環境中，一些典型的用例並不能表明在生產環境也有效，或者是說缺少有效的備份和還原策略。在項目開發過程當中，去修改系統架構和代碼結構顯然是爲時已晚，開發人員也只能給出一些臨時解決方案。

這樣的摩擦致使了開發人員和運維人員相互的不尊重。開發人員認爲運維人員根本不瞭解本身所開發的軟件，而運維人員認爲開發人員對於服務器運行一無所知。

將這兩個部門獨立管理，彼此之間溝通甚少，致使兩個部門之間造成了一道隔閡：混亂之牆（Wall of Confusion）。

合做的藝術（Culture of collaboration）

事實上，有兩個因素驅動着DevOps的發展：

第一個是敏捷開發。敏捷開發模式使得不少公司的運維人員的部署工做比之前要多不少。（譯者注：小步試錯，快速迭代）

第二個就是大規模的雲計算和雲存儲的運維要求，在這種規模下，開發和操做須要更緊密的協做。

每當出現問題了，公司常常是建立一個多任務的工做組來解決生產問題。可現實是，現在的IT基礎設施環境以及變得很是複雜了，不是靠一我的或是一個組織能徹底管理的。所以，與其像以前那樣讓開發和運維人員分開，不如將他們合併起來。

不過這方面咱們還須要更多的實踐，咱們始終堅信：熟能生巧（if it's hard, do it more often）。

DevOps理念認爲只有發佈到生產環境，軟件才能發揮價值，而一個沒有運行任何軟件的服務器是毫無價值可言的。

研發部門和運維部門的共同目標是服務客戶，而不是各自爲政。

儘管系統系統管理員已經和其餘部門有過協做，可是這種合做歷來不被認爲是一種戰略優點。DevOps的核心文化價值是爲了更好地知足業務需求，促進跨部門間的持續協做。DevOps不失爲一種減小衝突，促進跨部門/跨學科交流的手段。

開始協做的一個突破口是討論常常要改進的地方：部署、打包、測試、監視、構建環境。

這些均可以視爲「邊界對象」，每一個人對其都有本身的理解。一樣也是技術債務累積的重災區，因此也涵蓋了日常工做的種種痛點。

分享的藝術（Culture of sharing）

在公司裏面會出現形形色色的隔閡，不只是存在於開發人員和運維人員，有的公司甚至在運維部門內部就有不少隔閡：網絡、安全、存儲、服務器等部分都沒有很好的協做，各自在本身的世界裏運行。這被稱爲「Ops-Ops」的問題，所以，在極客語言中，DevOps實際上被描述爲devops*。（譯者注：即開發部門須要對接多個運維部門）

DevOps並不意味着系統管理員須要懂得編程，也不是說全部開發人員須要知道如何部署服務器。就協做自己的意義來看，兩個部門的人員其實能夠相互學習，在平常工做中也能及時迴應彼此。這是在敏捷開發中，用於開發人員和測試人員溝通的一個手段。DevOps能夠視做是將系統管理員引入敏捷開發工程的一個延伸。

有時候，開發人員和運維人員開啓一段交流是須要必定的勇氣的，可是考慮到這樣作的好處，也是值得的：隨着應用規模的增加，你能夠在這個過程當中不斷學習，而且你能夠經過本身的投入來積極地塑造它。

系統管理員可以給開發人員提供不少內容：你（運維人員）知道生產環境是怎麼樣的，因此你能夠據此構建一個更具表明性的開發/測試環境（譯者注：與 痛點 一小節提到的問題進行呼應），你能夠參與到壓力測試、故障轉移測試中，或者你能夠安裝一套監控系統，讓開發人員可以看到究竟哪裏出錯了。而且開發生產環境的日誌訪問權限，以便開發人員瞭解應用在生產環境真實運行狀況。

（運維人員）分享信息和知識的一個很好的方式是與開發人員或同事結對：當你（運維人員）在部署的時候，他（開發人員）會對所部署的代碼進行影響評估，並且你能夠直接向他提問。

這樣的互動對於瞭解彼此的工做是很是有價值的。

回顧自動化（Revisiting Automation）

就像敏捷宣言（Agile Manifesto）所說的，DevOps重視「個體和互動高於流程和工具」。工具的偉大之處在於，它們是具體的，而且能夠直接受益於文化。

若是不真正開始實踐，是很難領會虛擬化和雲技術帶來的影響。各類工具能夠塑造咱們的工做方式，進而改變咱們的行爲。

配置管理（Configuration Management）和架構即代碼（Infrastructure as code）就是一個很好的例子。

許多人都稱讚自動化的強大和靈活，若是你從節約時間成本方面考慮，你會發現它還有一個很是大的好處：就像建立了一種「共享」語言，它容許你與其餘同事交流管理系統的方法，甚至能夠在GitHub上發佈cookbook。

由於咱們（運維人員）知道一些版本控制和測試的概念，咱們和開發人員都會有一些共通的問題。最重要的是，自動化將咱們從瑣碎的事情中解放出來，讓咱們能夠討論和關注那些真正重要的事情。

回顧度量指標（Revisiting Metrics）

協做的指標不能簡單的用溝通次數來衡量，畢竟再多的溝通也不必定意味着會有更好的效果。它相似於黑洞，你必須觀察附近的物體。

因此，你該如何看待狀況有沒有改善呢？

做爲一個運維工程師，你收集有關於生產事故的次數，部署失敗/成功的次數等相關指標。與其將這些數據保留在部門內部，還不如將它們分享給公司的其餘部門，以便讓其餘部門的人也能從中學到一些東西。與全部利益干係人一塊兒作過後檢查，並進行改進。

與此同時，這也改變了度量和監控的焦點，從運維人員的快速修復變成了及時反饋到整個組織。目標就是從總體上進行優化，而不只僅是侷限在本身工做的部分。

獨家祕方（The secret sauce）

有幾家「新」公司在這些實踐中都是領先者。

Google的 two-pizza team，Flick的 10 deploys a day 都算是這個領域的先行者。

但也有不少傳統的公司，好比National Instruments，從這種合做文化中看到了價值。

這些公司將這種協做模式認爲是一種「獨家祕方」，可讓他們在競爭中取勝。

這是爲何呢？

由於它認識到個體不是一種資源，而是一種應對在這個複雜的世界中存在的挑戰的智慧。

###附：

參考文獻：

一、John Willis, What devops means to me

二、Damon Edwards, what is devops

三、Israel Gat, boundary objects in devops

四、Amazon Architecture

五、John Allspaw, 10 deploys per day - dev and ops cooperation at flickr

六、Jesse Robbins, Operations is a competitive advantage

每日干貨分享，傳遞互聯網世界有價值的訊息，盡在**「技術匯」**