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

本文做者：張海龍，CODING 創始人兼 CEO
本文字數約 3700 字，閱讀時間約 8 分鐘。

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

有趣的是，相似的狀況不是第一次出現。1999 年金融海嘯來襲，經濟下行週期內，你們都寄但願於當時先進的信息技術，但願能以此提高自身的管理水平，加強企業競爭力。致使當年 ERP 進入中國後迅速走紅，令無數缺少管理經驗的中國企業心馳神往。

而到了數字化轉型的浪潮之年，這個風口上的詞變成了 DevOps（/de'vɒ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 原則，這套原則中必須依賴於工具輔助的部分只有後兩點，更多的則是對於開發組織形式的內省：

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

因此 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 服務相對於傳統的運維業務幫助企業節省大量硬件維護的成本和時間，讓企業能專一於業務的發展與創新。

結語

孫子兵法有云，凡兵法韜略，在道不在術。面對突飛猛進的的市場，企業必須逼迫本身不斷的進行革新來應對市場變化。就像馬化騰在互聯網大會上提到的，如今互聯網已經發展到了深水區，甚至是無人區。只有不斷的迭代，迅速反應，才能應對將來的變化，而這也正是 DevOps 所強調的。

點擊當即體驗一站式 DevOps 工具鏈。