當我們談論 DevOps 時，我們在談論什麼？

本文字數約 3700 字，閱讀時間約 8 分鐘。

2018 年對許多人來說是艱難與變革的一年，勢如破竹的發展勢頭似乎被打破，小微創新型企業生存艱難。「產業互聯網」「企業數字化轉型」等尋求從內破局的呼聲也越來越高。

有趣的是，類似的情況不是第一次出現。1999 年金融海嘯來襲，經濟下行周期內，大家都寄希望於當時先進的信息技術，希望能以此提升自身的管理水平，增強企業競爭力。導致當年 ERP 進入中國後迅速走紅，令無數缺乏管理經驗的中國企業心馳神往。

而到了數字化轉型的浪潮之年，這個風口上的詞變成了 DevOps（/dev?ps/）。大家紛紛開始討論要不要採用 DevOps、DevOps 到底有沒有那麼神奇。

Google Trends 中 DevOps 歷年的熱度數據

DevOps 到底是什麼

2018 年，我們走訪了近百個分布在各行各業中的 IT 團隊，意外的發現，大多數的 IT 團隊尋求改革並非來源於部門內部的自我革新，而是來源於業務部門的服務壓力。正如同當年企業尋找 ERP，今天的企業將目光投向了 DevOps。但是 DevOps 並非像 ERP 那樣可以直接部署的東西，而是一種由主流互聯網巨頭們所總結出來的的研發管理理念，是 Google、Netflix 等大型互聯網公司實現快速迭代的秘訣。

作為一家專註於研發 DevOps 工具鏈的公司創始人，我在接觸客戶的時候，發現一個很有趣的現象：所有人都想「做」 DevOps 並期待其能為他們帶來商業上的成功，卻對 DevOps 的核心理念知之甚少。這很大一部分原因是市面上對 DevOps 有著各種各樣的說法，導致大家概念的混淆。想要弄清楚 DevOps 到底是什麼，必須先從它的本質說起。

軟體開發最高效的組織形式是「One Man Work」，只有一個人幹活，寫個小項目，從需求到開發，從測試到部署全部獨立完成，非常高效。但隨著業務的增長，項目開始逐漸變得龐大，變成團隊，出現了分工，出現了產品經理、項目經理、開發、數據、測試、運維等等角色。這些角色間存在天然的工作目標上的矛盾。

舉個例子，對於運維來說，穩定壓倒一切，新 Feature 越少越好。而對於研發來說，卻希望能開發更多的功能。這種矛盾會導致大量的資源和時間的浪費。就像兩匹馬拉一輛車，如果馬頭向著的方向不一致，肯定是沒法全速前進的。

DevOps 的理念就是希望能打破這種屏障，讓研發（Development）和運維（Operations）一體化，讓團隊從業務需求出發，向著同一個目標前進。

字面意思上說 DevOps 是指「開發運維一體化」，即通過工具輔助開發完成運維的部分工作，減少成本。但深入理解了 DevOps 之後，你會發現 DevOps 其實是一種軟體研發管理的思想，方法論，他追求的是一種沒有隔閡的理想的研發協作的狀態，可能涉及到的角色有開發、測試、產品、項目管理、運維等等。所以我們認為，為了幫助研發團隊在保持質量的前提下提高交付效率的方法和方法論都隸屬於 DevOps 的範疇。

比如 Google 提出的 5 個 DevOps 原則，這套原則中必須依賴於工具輔助的部分只有後兩點，更多的則是對於開發組織形式的內省：

精簡組織架構；
願意承擔一部分試錯帶來的損失；
分階段地一小步一小步地進行轉型；
最大化地利用工具和自動化流程；
對所有的過程和結果進行記錄和分析。

所以 DevOps 不是簡單的開發軟體化，而是企業的學習能力不斷提升的結果，將企業改造成敏捷應對的學習型組織，運用新的工具，優化組織架構和流程，不斷地進行自我革命和創新的方式。工具是輔助，而非基礎。

困難重重的 DevOps 落地

在弄清楚了 DevOps 的宏觀定義之後，我們再來觀察一下 DevOps 目前在國內的實踐現狀。根據南京大學 ?DevOps 中國?2018 年度調研? 的調研報告，目前設有 DevOps 實踐團隊的公司中，科技和互聯網行業佔比接近 70%。其他行業的從業者對 DevOps 的認知還存在一定的不足。

這與我們的調研走訪體驗一致：大多數企業都願意嘗試運用 DevOps ，但是在實踐 DevOps 中，普遍碰到了比較大的困難。主要是以下三個原因：

對 DevOps 有不切實際的預期

部分團隊為了做 DevOps 而做 DevOps，並沒有真正的從業務的角度出發來考慮。

如前文所說，DevOps 不是銀彈，高水平的研發團隊在 DevOps 實踐中將快速找到研發質量與業務增長的平衡點。但對於許多仍然在使用中心化的研發組織形式的團隊來說，DevOps 的嘗試無法立即獲得肉眼可見的增長數據，思索與嘗試帶來的對團隊的訓練可能會是第一份收穫。

步子邁得太大

新生代互聯網公司誕生於 DevOps 理念已經相對成熟的年代，且互聯網公司天生地將迭代速度作為追求目標之一，使得這些公司能夠在發展的初期，就將 DevOps 的理念融入到公司的架構設計中。

上圖是 Netflix 的整個系統架構。如此複雜的系統架構同時還能每天迭代幾十個版本，無法通過傳統的研發管理模式來維護，只有通過實踐 DevOps 的理念，來優化組織的分工、資源和能效，才能得以實現。在這樣的組織里，已經不需要有人了解所有模塊是做什麼，每個人只需要對自己的模塊負責。

而很多企業，為了鞏固和提高自己的市場競爭力，非常急於達成上述高效的狀態，並且希望能一步到位。國內其實大部分團隊都沒到大規模實踐 DevOps 的時間點，有些團隊甚至連分支開發、並行開發的方式都沒有。我給這類的企業建議是：不要想著一口氣吃成個胖子，一步一步來，先理解 DevOps 的理念和對業務的實際意義，然後搭建一隻小的 DevOps 團隊來承接一項新業務，舊的業務仍然使用舊系統，雙軌並行，等待小團隊適應了 DevOps 的管理節奏之後再向其他團隊進行推廣。

之前出過一篇關於 DevOps 的專題報告《四周年 · 專題報告：雙速 IT》，也可以作為參考。

Toolchain Crisis

實踐 DevOps 的原則中很重要的一點就是對工具的運用及依賴工具搭建合適企業的自動化流程。但是目前市面上缺乏成熟的 DevOps 工具鏈，各個服務商的細分工具層出不窮，企業為了搭建整套 DevOps 流程，需要研究幾十種工具，並選取其中的 7-8 種進行落地實踐。非常依賴於管理者的項目經驗，沒有 DevOps 經驗的團隊起步將會比較困難。

以 CODING 為例。2018 年之前 CODING 產品僅有任務及代碼管理模塊。我們是這樣進行工作的：產品經理在 CODING 上撰寫文檔創建任務，研發 Leader 將任務分配給開發，開發完成後提交代碼，並創建 MR，我們在本地部署了 Jenkins 進行持續集成進行構建和測試，再由其他工程師進行人工評審，通過後併到發布分支，進行預發布，再通過持續集成進行構建，自建 Docker registry 進行構建物管理。構建出的 Docker 鏡像在測試環境和預發布環境上依次進行自動化測試及人工測試，測試通過後，使用我們運維自己搭建的工具進行部署管理。

目前 CODING 每天都進行產品迭代，可以快速響應用戶需求並保證服務質量，但搭建這一整套的流程高度依賴於團隊能力，門檻非常高。

為了降低工具的成本和使用門檻，包括 CODING 在內的很多雲服務廠商都在做打通全流程的 DevOps 工具鏈的嘗試，希望可以做到讓企業開箱即用，低成本的踐行 DevOps 理念，不過目前產品仍處於迭代期，無法滿足所有企業的需求。

DevOps 是未來的趨勢

既然 DevOps 這麼難，坑這麼多，為什麼還要做呢？因為這是企業未來的長期訴求。

從大趨勢上分析，未來所有企業都將是軟體企業，製造軟體、服務軟體、構建於軟體。比如全世界最大的出行公司 Uber，其實是一個軟體公司，而非計程車公司。從企業自身訴求出發，中國的中大型企業已經逐步進入了創新驅動的階段。無論是供給側改革還是智能製造 2025 都要求企業修鍊內功，提高效率促進創新。過去幾年中在塑造前沿行業的 DevOps 理念將在 2019 年左右成為主流，成為企業能否在行業內脫穎而出的關鍵性因素。

在 Statsia 2018 年的報告中，有超過 72% 的企業或多或少地開始踐行 DevOps 的理念，其中完整採用 DevOps 的比例高達 17% ，而在 2017 年這個數字僅有 10%。

真正能夠實踐 DevOps 的團隊也會為自身的業務帶來巨大的提升。根據 Puppt 的2017 DevOps State Report，DevOps 型團隊將部署頻率提高46倍，交付速度提高 440 倍。

可見，在國際上來說，DevOps 已經處於企業爆發性需求的前夜。而在國內公司中，新興企業的成功實踐也在為中國企業的 DevOps 輸送方法論與有經驗的專家。

位元組跳動可以說是 DevOps 最佳踐行者之一。在其創始人張一鳴看來：

公司的業務越複雜，人越多，組織就越大。這導致信息失效、（下屬）向上管理和業務變大。他把類似組織的負規模效應稱為「自嗨」，這是他所不能接受的。

故而位元組跳動在組織架構上，總共只有 3 個核心部門：技術、Growth 和商業化，分別負責研發、推廣和收入。

今日頭條、抖音、西瓜視頻……位元組跳動的每款 App 都基於這三個部門來發展。在項目開始時，公司會為每個項目設置虛擬項目組，由三個核心部門抽調人員組成，試水成功後直接推廣。所有產品共用一條技術線，快速試錯。針對 App 類產品的快速迭代的業務特性，位元組跳動依據 DevOps 理念對組織架構進行調整和優化，從結構上保證了技術支持業務創新的能力。

Why Now？

DevOps 的理念和優勢被說了很多年，但一直都只在少量公司有能力實踐。軟體的工程化歷史還比較短暫，業務需求與技術理念都日新月異，前兩年大量的團隊還在為了研發新的業務疲於奔命，沒有精力關注研發效能升級的問題。許多團隊的研發管理還停留在靠微信喊話和 Excel 管理的階段。

而如今，在市場遇冷和企業數字化轉型的契機下，更多的公司開始將目光放在企業內部的效率提升和研發成本的控制上。

在 Netflix、Google 這樣發展比較久的的巨型公司可以耗費大量的內部資源從底層服務開始從零搭建 DevOps 流程。而像位元組跳動這樣的新型公司可以如此快速實現敏捷，也得益於雲服務的逐步成熟。

尤其是在當前環境下，運維業務逐步多樣化和複雜化，很多傳統的運維技術和解決方案已經不能滿足當前運維所需，越來越多的團隊選擇使用 Docker kubernetes 等技術提升運維能力。同時，雲廠商的 SaaS、IaaS 和 PaaS 服務相對於傳統的運維業務幫助企業節省大量硬體維護的成本和時間，讓企業能專註於業務的發展與創新。