[譯] 到底什麼是DevOps？

簡單歷史回顧

爲了更好地理解DevOps，咱們得穿越回到除了程序員外什麼都沒有的那個古老的年代。

正如道告訴咱們那樣：

古老的程序員，神祕而又知識淵博。咱們難以揣測他們內在的思想，惟一能作的只是試着描述外在的樣子：

• 有意識的（Aware），猶如一隻在水中穿越的狐狸

• 警戒的（Alert），猶如一位駐立在戰場上的將軍

• 好心的（Kind），猶如一位接待來賓的東道主

• 簡單的（Simple），猶如未經雕琢的木塊

• 隱晦的（Opaque），猶如黑暗洞穴中的黑水池

程序員產生了機器語言。機器語言產生了彙編語言。彙編語言產生了編譯器。到如今已經有了成千上萬種語言。每一種語言，無論多麼簡陋，都有其各自的目的。每一種語言都解釋着軟件的陰和陽。每一種語言都在軟件中有其一席之地。

在那個時候，軟件開發辦公室大部分被稱爲實驗室，而程序員則稱爲科學家。爲了更好地創造更好的應用，程序員不得不徹底理解應用正在解決的問題。他們須要知道這些應用將會用在哪裏，以及運行在哪些類型的系統上。這也就意味着，程序員知道從應用到規格，從開發到部署再到維護之間的所有事情。

接着人類開始介入，而且但願獲得更多。更快的速度，更多的特性，更多的用戶，更多的一切。

做爲謙虛、低下而又安靜的創造者，程序員只有不多機會去探索用戶要求如此之多的慾望。要想取得勝利的最好機會就是開啓對不一樣領域方向的演進，以及創造一種層級關係。很快，程序員被稱爲開發人員、軟件工程師、網絡管理員、數據庫開發人員、系統架構師、QA工程師和更多的種類取而代之。快速演進並適應來自外部世界的挑戰成爲了他們DNA的一部分。新的種類又能夠在大約幾周內進行演化。如網站開發人員又分爲後端開發、前端開發、PHP開發、Ruby開發、Angular開發等等，一發不可收拾。

很快他們就忘了他們都來自同一個祖先：程序員。一位簡單、安靜、僅僅是想把世界更得更美好一些的科學家。他們開始互相爭執，聲稱他們本身才是「程序員」真正的後裔而且比其餘種類的血液更正統。

隨着時光飛逝，他們將之間的相互協做降到了最低程序，只有當不得已的時候纔會跟其餘人說話。他們再也不爲遠方家庭成員的成功而慶祝，甚至最後一度連明信片也不發了。

若是留意他們的感覺，他們會發現他們的心裏中，有一股程序員的星星之火，正等待着燎燃並準備着爲這宇宙帶來和平。

在他們自私，以自我爲中心征服世界的途中，程序員的後裔忘記了他們工做的初心 -- 爲他們的客戶解決問題。客戶開始感受到了諸如項目延期、太昂貴甚至失敗的痛楚。

曾經一度，一顆閃亮之星光芒四射，讓每一個人都受到了鼓舞去嘗試和衆多的後裔保護和平。它就是瀑布流。它真是一個傑出的想法，由於它利用了不一樣的開發人羣只有當他們須要時才溝通這一實事。當一個組完成了他們工做的那一部分，它就聯繫下一個組將工做流轉下去並不再回過頭來看一眼。

這種方式奏效了一段時間，但一如往常，人類（客戶）又想獲得更多。客戶想在創造軟件的過程當中參與更多，更頻繁地給開發人員提供建議，而且即便是在後期也要求作出改變。

軟件項目變得如此容易失敗，以至這個現象都做爲一個行業標準被接受。相關統計代表超過50%的項目是失敗的，而且看起來咱們對此無能爲力（ZDNet，CNet）。

每一代都有極少數具備遠見的人深知，這些不一樣羣組的開發人員須要找到一種方式來共同工做、交流，並能讓其相信他們客戶能獲得更好可能的解決方案。這些嘗試最先可回溯到1957年，由約翰·馮·諾伊曼的同事提出的。然而直到2001年早期，敏捷宣言的12條原則面世後，咱們纔開始此次變革。

1.經過早期和連續型的高價值工做交付知足「客戶」。
2.大工做分紅能夠迅速完成的較小組成部門。
3.識別最好的工做是從自我組織的團隊中出現的，
4.爲積極員工提供他們須要的環境和支持，並相信他們能夠完成工做。
5.建立能夠改善可持續工做的流程。
6.維持完整工做的不變的步調。
7.歡迎改變的需求，即時是在項目後期。
8.在項目期間天天與項目團隊和業務全部者開會。
9.在按期修正期，讓團隊反映如何能高效，而後進行相應地行爲調整。
10.經過完車的工做量計量工做進度。
11.不斷地追求完善。
12.利用調整得到競爭優點。

對於爲世界帶來和平以及恢復平衡，敏捷宣言邁進偉大的第一步。歷史上第一次，軟件開發過程當中的所有干係人是基於文明和「人類」的方式鏈接起來，一如過程式和機械式的方式。人們開始一直相互交談，平常會議，以及交換想法與評論。他們意識到他們的想法比他們想像中有更多的共同之處，客戶也成爲了團隊中的一部分，而再也不僅僅是做爲一些只發錢不提問的編外人員而存在。

依然還有一些障礙須要克服，但前途已經比以前顯得更加光明。敏捷意味着開放、願意適應一般的變化。然而，變化如此之多，以致很難專一於無限制的目標和交付。這就是爲何精益軟件開發誕生的緣由。

沉迷於LSD（雙關語）和冒着被放逐和流浪的危險，一些後裔從他們的種類的軟件行業以外尋找解決方案。他們從大量汽車製造商的工做中發現瞭解救方法。Toyota產品系統簡單得讓人如此驚訝以至明顯地它的精益製造能夠輕鬆地應用於軟件開發。

如下精益中的7條原則：

1.避免浪費
2.創建質量
3.加強學習能力
4.延遲決策
5.快速發佈
6.受權與尊重
7.系統思考

附添加在敏捷之上，精益原則支持其思想，在整個過程當中保持靈活的同時，關注於作正確的事情。

曾經敏捷和精益被軟件開發團隊所接受，只差一步就能夠將整套原則做爲一個總體應用到IT行業，而正是由於這樣，咱們迎來了DevOps！

DevOps - 三車道高速公路

傳統軟件開發團隊的視圖包括業務需求分析，系統架構，前端開發人員，後端開發人員，測試人員等。擁有敏捷和精益原則，更完善的軟件開發過程則大部分關注如下這些。一旦應用去到了「產品準備就緒」狀態，它將傳遞給系統工程師，發佈工程師，數據庫管理員，網絡工程師、安全專家等」操做人員「。消除Dev（開發）和Ops（操做）之間的巨大隔閡是DevOps的主要驅動力。

DevOps是把精益原則應用到整個IT價值流的結果。IT價值流包含了從開發到產品，並將從原始程序員演化出來的」遠方親戚「都融合起來。

對於DevOps最好的解釋來自Gene Kim，若是你還沒讀過菲尼克斯項目，我建議你花一些時間去了解它。

你不該該招聘一位DevOps工程師，又或者爲DevOps設立一個新的部門。DevOps是一種文化，一種觀念，它應該是整個IT中的一部分。沒有工具能夠把你的IT變成一個DevOps組織，也沒有自動化的東西能讓你的團隊把最大化的價值交付給你的客戶。

DevOps一般涉及三種方法，但我則把這三種方法看做爲同一條高速公路上的三條車道。你從車道一開始，而後加速並變到車道二，最後你繼續加速直到你進入了車道三。

車道一，總體的系統性能是主要的焦點，並強調重視系統中的各個個體、各個元素。

車道二，確保與上流之間的持續反饋，沒被忽視

車道三，現場參與，持續提升，快速失敗

車道一 - 開始加速

當接受DevOps原則時，也許IT組織須要學習的第一件事就是明白總體系統的重要性，並工做細項按優先級進行排序。在整個IT價值流中，不容許任何一個工做流成爲瓶頸，並且每個都是不可或缺的。

保證工做流不被中斷是每一個參與此過程人員的終極目標。儘管每一個人或者團隊都有其角色和位置，他們致力於作到對系統有深刻的瞭解 是很是有必要的。適應了這種思考的方式後，會對質量有着直接的影響，由於引發瓶頸的缺陷不會再流下去。

確保了工做不被拖延還不夠。一個產品化的組織應該不斷尋找能夠提升整個工做流的方法。這裏有許多能夠提升工做流的方法。你能夠自由地進行選取，構想你本身的，或者把他們結合起來。

• 保持系統工做流不被中斷

• 不斷提升和優化工做流
  

車道二 - 換檔加速

非中斷的系統流是其中一個方向，它指望從開發到操做。在一個想法的國度裏，這意味着高質量的軟件能快速創造，部署上線，爲客戶交付價值。

然而，DevOps並不是烏托邦，沒有任何一個方向能夠充當整個瀑布流的方法。評估可交付性以及將工做流聯繫起來對於保證質量是很是重要的。首先須要實現與」上流「的溝通渠道就是從Ops到Dev。

給本身一個舉手鼓掌是容易的，但要求反饋並提供反饋是看到本質的途徑。每個被下流跟進的小步驟被上游持續確認是有必要的。

無論你用什麼方式來展現你的反饋環。你能夠邀請開發人員加入進來支持團隊的會議，或者在每週衝刺會議中把網絡管理拉進來。只要你有了你的反饋，評論就會隨之而來而且是可控的，你的組織也就加速進入了DevOps車道。

車道三 - 柔道十段

DevOps最後一個車道不是針對於薄弱的頭腦。爲了能夠進入DevOps的最後一條車道，你的組織必須是足夠成熟的。與此相關的是勇於冒險的勇氣，從失敗中學習，持續試驗，而且接受重複與實踐是達到精通的必要條件。這也正是爲何你會常常不斷聽到空手道的緣由。持續訓練和重複能通往精通是由於它能把複雜的步驟變得平常化。

但在你開始合併這些步驟以前，首先你有必要掌握每個獨立的步驟。

」適合師傅的不必定適合於徒弟。在超越以前，你得明白什麼是道。「

DevOps第三條車道/最後一條車道包括爲在平常基礎上進行持續試驗，持續獎勵團隊進行冒險，和將失敗介紹進系統以提升容錯性之間分派時間。

爲了確保你的組織在實現這些測量時不暴露出過多的問題，你必須在確保所有的瓶頸都透明，系統流沒有中斷的同時，也確保全部的團隊之間創建反饋環。

實現這些方法可使得你的組織在任什麼時候候都保持警戒，能夠在面對各類挑戰時做出快速有效的響應。

總結 - DevOps組織清單

如下是一份能夠用於驗證你的組織是否符合DevOps的清單。歡迎請對此文章進行評論以及添加你本身的觀點。

• 開發團隊與操做團隊之間沒有隔閡。他們都是相同流程中的一部分。

• 從一個團隊派發到另外一個團隊的工做老是經過驗證的，以及是高質量的。

• 沒有」堆積「的工做，所有的瓶頸在掌控之中

• 開發團隊不使用操做團隊的時間做爲其活動時間，由於部署和維護都是同一時間箱的一部分

• 開發團隊不會在星期五下午5點後把代碼提交到部署環境，而讓操做團隊整個週末都在作善後處理

• 開發環境是標準化的，而且操做團隊能夠輕易進行復制、擴展到生產環境

• 當發現合適時開發團隊能夠交付新的版本，而操做團隊能輕易部署到生產環境

• 全部的團隊之間的溝通途徑是清晰的

• 團隊的所有成員都有時間嘗試和致力於提高系統

• 系統中的缺陷會在平常的事項中提出（或模擬）並處理掌控之中。從每一個實驗中學習到的課程都紀錄到文檔，而且分享給所有相關人員。事故處理是一個例程，而且大部分都以一種熟悉的方式處理

結論

使用現代化的DevOps工具，如Chef，Docker，Ansible，Packer，Troposphere，Consul，Jenkins，SonarQube，AWS等，並不意味着你正在應用DevOps原則。DevOps是一種思惟方式。咱們是同一流程中的一部分，咱們分享着相同的時間，一塊兒交付有價值的產品。每個參與到軟件交付流程的人均可以加快或下降整個系統的速度。和錯誤的防火牆配置同樣，開發過程當中的一個bug可讓系統崩潰。

全部的人都是DevOps中的一部分，一旦你的組織明白了這一點，能幫助你進行管理的工具和技術將會奇蹟般地出現。

本文翻譯做者爲：dogstar，發表於開源中國我的博客；歡迎轉載，但請註明出處，謝謝！