[譯]一個系統管理員眼中的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 its 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，從這種合作文化中看到了價值。

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

這是為什麼呢？

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

附：

參考文獻：

1. Patrick Deboiss Devopsdays Melbourne Keynote
2. John Willis, What devops means to me
3. Damon Edwards, what is devops
4. Israel Gat, boundary objects in devops
5. Agile Manifesto
6. Ernest Mueller, Originality and Operations
7. Cliff Stoll, The Cuckoos Egg
8. Andrew Shaefer, Israel Gat, Patrick Debois Velocity Conference 2011 Devops Metrics"
9. Amazon Architecture
10. John Allspaw, 10 deploys per day - dev and ops cooperation at flickr
11. Jesse Robbins, Operations is a competitive advantage

推薦閱讀：