本文轉自微信號EAWorld。掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！
恍惚間，DevOps已經被討論十年了
“如果系統是集中式的、環境是同質化的，從開發環境向生產環境推送程序變化的過程非常簡單，不需要太多的自動化；但是今天的應用需要7×24小時運行、採用分佈式架構、部署到多種環境，變更過程變得愈加複雜、難以自動化……不論在大型組織還是小型組織，施行DevOps在技術上都非常具有挑戰性。”
上面這段文字如果放在今天，那只是段關於DevOps的、稀鬆平常的討論，但是如果它寫於十年前，各位讀者會不會感到有一些驚訝？
這段文字寫於2007年8月的下旬，很快就距今整十年了，這是我所知道的業內最早的關於DevOps的系統性討論，我在整理收藏夾的時候偶然發現了它，這讓我突然意識到：DevOps已經十年了。
可是，爲什麼雷聲大雨點小？
博客網站dev2ops.org（據說是devops.org被搶注了，所以他們只能加個2，而devops.org至今仍是個空域名）的文章“What makes dev2ops so hard anyway?” 文中還羅列了阻礙DevOps施行的幾個因素：
變更結果的可靠性和可預見性
不同類型的變更（數據、代碼、配置、內容、平臺等）對系統造成的不同影響未被充分評估
對分佈式系統各部分的變更非常難以協調
開發與運維的組織邊界難以界定
這幾個因素在今天依然阻礙着DevOps的施行。由於滾動更新、金絲雀測試等方法和Kubernetes等系統的流行，前三個阻礙有了一定的改善，但是由於方法和系統僅僅提供了操作原語，所以帶來的改善十分有限。而第四個阻礙在很多組織中依然如故。
而且，這四個因素遠遠不是全部，我想每個正在實踐DevOps的讀者在讀到這裏的時候，頭腦中都會閃現出其他的一些因素，例如老系統的雲化和測試自動化需要很大的投入、DevOps的工具鏈過於繁雜等。所以，DevOps的施行依舊非常的困難。
說到這裏，作者還很應景的補充了一句：“儘管如此，DevOps最終仍然可以施行，辦法很簡單，讓最強的技術人員通宵加班即可。”這句話簡直是神補刀，前段時間我剛好支持了一個老項目上線，那感覺簡直就像是誤入了一個野蠻的原始部落，這使我不禁反思：十年來，DevOps究竟改變了什麼？
公認首個DevOps成功案例，Flickr的每天10+次部署？
2007年，比利時獨立IT諮詢師Patrick Debois參與了一個政府部門的數據中心遷移項目。在這個項目中Patrick需要交替的和開發團隊還有運維團隊一起工作：第一天在開發團隊跟隨敏捷的節奏，第二天又要以傳統的方式像消防隊員那樣維護這些系統，兩種工作的切換令他十分惱火。
正是因爲這段經歷，Patrick充分體會到了開發團隊和運維團隊的工作方式和思維方式存在巨大差異：他們簡直是活在兩個不同的世界之中，兩個團隊的工作之間到處都是衝突。Patrick Debois開始思索如何彌補開發團隊和運維團隊之間的鴻溝，這些思考的結果就是DevOps的雛形。
兩年之後的2009年，John Allspaw和Paul Hammond在Velocity 大會上發表了名爲“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”的演講，演講的PPT有五十多兆，裏面充滿了來自Flickr的高質量的圖片，DevOps也由此正式走入公衆視野。演講中有兩個想法在我看來非常重要：
運維工作的目的並不是保持系統穩定，而是促進業務敏捷；如此，開發和運維工作的目的就統一起來。
開發團隊和運維團隊爲了促進業務敏捷，應該打造一系列支持快速發佈軟件的工具和文化。其中工具包括：自動化基礎架構、共享的版本控制系統、持續集成、持續部署、共享的度量和消息機器人。
近年來，自動化基礎架構、共享的版本控制系統、持續集成這三種工具已經普及，而持續部署、共享的度量、消息機器人這三種工具應用的還不是很多，也沒有很好的標準化，相關的開源項目還處於戰國時期，不過按照目前這個趨勢，想必很快也會塵埃落定。在這三種工具也得到了普及之後，前文羅列的阻礙因素會得到相當大的改善，那麼，DevOps能夠隨之得到普及嗎？
普及DevOps，工具纔是關鍵
警惕空談陷阱，文化轉變不一定是必要條件
很多人認爲工具的普及和DevOps的普及是兩碼事，因爲DevOps不僅僅是一系列的工具，更是一種文化；甚至很多人認爲文化要比工具重要的多。Cloud Technology Partners公司的首席架構師Mike Kavis曾說：“DevOps是一種文化轉變，或者說是一個鼓勵更好地交流和協作以便於更快地構建可靠性更高、質量更好的軟件的運動。”
但是恕我直言，我非常反對這種說法，衆所周知，一個組織在成型之後再對組織文化進行根本性的轉變，難度之大超乎想象，如果把文化轉變作爲施行DevOps的必要條件，那無異於把DevOps送上了絕路。
在我看來，DevOps更應該是一系列工具加上如何使用這些工具的知識，鑑於任何工具都需要相應的使用知識，所以簡單的說，DevOps就是一系列工具。
讓我們回顧一下，持續集成和Scrum都已經提出了有二十餘年之久，易於工具化的持續集成在近幾年已經普及，而不易於工具化的Scrum卻沒有，在很多團隊裏僅僅是站會都會淪爲一種形式。所以，你應該明白我的意思：如果DevOps更多的是一種文化，那麼它的普及將遙遙無期。或者說即使DevOps是一種文化，那也需要有工具來支撐這種文化，否則極易落入空談。
所以，DevOps應該像個生產軟件的流水線，開發人員、測試人員和運維人員在補充了必要的知識之後，就能在這個流水線上以DevOps的方式生產軟件。
這是一種軟件開發模式和方法論
還有人認爲DevOps是一種軟件開發模式和方法論，從瀑布模式到敏捷模式、再到DevOps，一脈相承，這個觀點我基本認同。我們目前在做支撐DevOps的產品，有次我問我們同事：“如果DevOps也是一種軟件開發模式或者軟件工程方法論，那麼它如何能成爲一種產品呢？之前的瀑布、迭代、螺旋和敏捷又爲何沒有成爲一種產品？”同事答到：“因爲DevOps吹的大。”
我不認爲他是在戲謔，因爲拉里·佩奇曾經說過：“只要你想的足夠大，那就很難全盤皆輸，即使是失敗，其中往往也會隱藏着珍寶。”吹之前當然需要想，所以吹的大也就包含想的大，所以我想，即使多年以後，DevOps潮水退去，也會留下一些由DevOps工具鏈演化成的優秀產品。而且應該有很多人還記得， 統一軟件開發過程，即RUP（Rational Unified Process），就是一種和產品相輔相成的軟件開發模式和方法論，其支撐產品Rational幾乎是上一時代最爲成功的軟件開發套件。雖然Rational很貴，很多人都沒有用過，RUP也是一種重量級方法，但是很多組織都在或多或少的應用RUP的某些子集，它的迭代開發、可視化建模、需求管理和變更控制在今天依然有非常好的指導性意義。
我們應該從RUP和Rational的聯合運作中學到一些東西，並把它應用到DevOps的推廣和支撐DevOps的產品的開發中，那麼，DevOps會成爲覆蓋更廣、更易用和更普及的全民RUP嗎？隨着DevOps會誕生一些像Rational一樣成功的產品嗎？既然用戶有需求，歷史上也有類似模式的成功案例，那麼就值得我們這些工具類的軟件企業努力去做。
繼續生長和完善的DevOps工具鏈
另外還有一點就是，雖然很多人在詬病Java，尤其是詬病Java EE，但是很多其他語言的開發者非常羨慕Java完善的工具鏈和周邊， 有些開發語言甚至連個完善好用的打包工具都沒有。DevOps剛好可以提供這種補充，尤其是在微服務模式下，這種補充變得史無前例的重要，Docker、Kubernetes、Istio、Namerd、Linkerd這些開源項目，對於其他語言就像Java的應用服務器和Spring Cloud，當然它們同樣也可以給Java使用。它們都是DevOps工具鏈和產品的必備環節和組件。這是歷史上第一有望將所有開發語言納入到同一個全流程的管理框架之中，目標一旦達成，那將是軟件工業的一次重大轉變。
Mike Kavis在說明DevOps是一種文化的時候，曾提到很多DevOps團隊通過編寫Chef、Puppet或Ansible腳本來施行DevOps，而Mike Kavis認爲大量的專有腳本實際上是增加了系統的浪費，而DevOps提倡的是效率，這些團隊的行爲並沒有體現DevOps的理念。
但是在我看來，這種狀況的產生正是因爲工具的缺失，如今Docker和Kubernetes在很大程度上提供了標準化的部署環境和流程，讓很多用戶不必再花大量精力編寫專有腳本，還有一個更大的優勢就是，Kubernetes可以在讓系統達到用戶定義的狀態之後繼續維持這種狀態，而Chef、Puppet和Ansible的腳本則不能。
所以，我想說的是，也許DevOps曾經是一種文化，但是正在越來越成爲、也必須成爲一系列工具，文化的比重逐漸變小，直至成爲非常次要的條件，因爲只有這樣，DevOps才能獲得廣泛的應用。
寫在最後
持續集成在提出了十幾年之後才獲得廣泛應用，而DevOps剛剛十年，雖然DevOps的戰線要遠長於持續集成，但是讓我們保持樂觀，也許未來的幾年就是DevOps的加速階段，我們還有幾年的時間來打磨支撐DevOps的產品，以幫助客戶解決開發和運維的效率問題，幫助客戶實現業務敏捷。
十年了，如果你覺得DevOps改變的還不夠多，那麼DevOps自身首先應該做出改變，那就是由虛無縹緲的文化，變成看得見摸得着的工具。
7月21日，本文作者所在的公司普元從企業敏捷深度需求出發，正式發佈了全面的開發運營一體化方案Primeton DevOps 5.0，並已助力萬達網絡科技集團實現IT精益運營。
關於作者：
宋瀟男
普元雲計算架構師，Unix和分佈式系統專家，網格時代的倖存者，在雲計算行業有近十年的研發和市場工作經驗，對操作系統、中間件和雲平臺有深入研究和大型項目經驗。曾在華爲雲計算部門負責產品規劃、商業洞察、以及EMEA地區的市場推廣與技術合作工作。
關於EAWorld
微服務，DevOps，元數據，企業架構原創技術分享，EAii（Enterprise Architecture Innovation Institute）企業架構創新研究院旗下官方微信公衆號。
掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！
微信號：EAWorld，長按二維碼關注。
