DevOps 是國內所有大型企業都在實踐和應用的項目改革，不管是互聯網大廠如騰訊、字節、阿里、美團，還是老牌企業華為、移動、電信或銀行。也孕育出一系列新興的 SaaS 產品，如極狐、Coding、藍鯨和博云等。

了解 DevOps 不僅能跟上時代的步伐和主流項目開發流程接軌，拓展進入相關項目的可能性，同時也是一個很好的了解技術的窗口，不再做技術方面的小白。

更多掃盲干貨:

一、DevOps 是什么

DevOps 是 Development 開發和 Operations 運維的組合縮寫，多數中文翻譯叫開發運維一體化，它并不是一種技術或編程語言，而是一種面向項目編程管理的方法論，類似于傳統制造業中的精益制造理論。

它的主要作用，是在開發過程中促進團隊成員（主要是開發、運維、測試）的溝通和協作，實現更高效、更頻繁、更可靠的軟件交付，以完成業務目標。

相信看到這里會產生第一個疑問，程序員碼代碼質量越高和交付成果速度越快不是天經地義的嗎，這種要求難道是最近才提出來，以前就不用高效、頻繁、可靠了嗎？

問題就出在以前的工作模式上，不是不要求，而是很難做到。所以我們要首先理解沒有應用 DevOps 前的產品開發流程和問題是什么。

一個傳統的項目流程，在確定需求以后，開發人員（Dev）完成相關的功能代碼，然后交付給運維人員（Ops）部署到測試環境，然后測試人員進行測試并提交問題，修改完成后再提交到生產環境正式運行。

這種流程很直觀也很好理解，多數企業初期和小團隊都會使用這種最樸素的方式。但隨著企業的發展，團隊成員開始增加，本來只有幾個人的研發部門可能增長到幾十上百人，一個單一的團隊被拆解成若干的小團隊，每個團隊負責自己對應業務和模塊功能的開發。比如做個電商網站，會員、購物、活動、社交、會員、廣告、搜索分別由不同的團隊負責并開發。

這就導致，團隊之間往往不清楚其它團隊在做什么，大家各寫各的，等到臨近上線日期的時候，各部門再把寫好的代碼進行合并（形成完整的新版本代碼），交給運維進行部署做測試。

這時候問題就開始集中爆發，因為不同部門成員寫的代碼可能在本地運行的環境里正常，但是合并到一起就會引發一系列難以預估的問題，如服務運行時的報錯、中斷、泄露等。每個問題的解決往往要投入大量的時間精力，嚴重干擾了上線的進度。

且能在測試環境解決的問題都還算小問題，最讓人擔心的還是在測試環境中明明已經測好了，上線后卻出故障了，導致諸如用戶交易記錄丟失、限量商品無限庫存、重要頁面訪問無效等災難性后果。這時候只能下線服務，團隊繼續耗費大量的精力加班加點修復 BUG 讓服務恢復正常運轉。

所以每一次發版都是一次折磨，項目越龐大折磨越大，不僅造成產品本身質量變差，同時項目執行效率大打折扣，不但提高了企業的人力成本，還會對業務造成非常負面的影響。

這時候不得不提一提運維這個崗位，很多人都知道開發即前后端的程序員，主要負責產品功能模塊的開發。而運維則是負責搭建可以運行該產品的網絡環境，并保持服務運行的穩定。

最早這些工作是由后端工程師負責，但隨著互聯網基礎設施的發展和完善（越變越復雜），運維相關的工作也變得越來越專業和繁瑣，除了代碼倉庫、集成、部署、編譯外，還涉及服務器的硬件維護、網絡布線、虛擬化，以及負載均衡、內容分發、環境管理、鏡像備份等工作。

所以工程師團隊就分離出了運維這個崗位，他們的作用和重要性毋庸置疑。但是他們的工作本質就是—— 維穩，因為搭建出穩定運行的環境是很費勁的，對這個系統加入任何新的代碼都可能打破它的穩定制造出新的問題。

而開發的責任則是——改變，通過修改代碼或添加新的代碼才能實現產品的需求，所以他們的工作就勢必會對運維工作目標造成阻力。

這兩者之間的職能天生就有沖突，以前面的開發流程為例，在前期的開發階段中，開發人員不僅是在完成產品需求，也是在給運維制造問題。開發周期和規模越大，就會創造出越多運維問題進行積壓，之后再將代碼和問題一起交付給運維，讓它們在運維手里合起來爆炸……

在這種分工體系下，開發人員會認為自己只需專注功能代碼的開發就可以了，“運維的工作關我什事？”。而運維團隊面對這種不負責任的行為是束手無策的，但不滿的情緒是會累積，并反應到實際工作中，降低項目的執行效率和完成質量。

DevOps 的作用，本質上就是要改變這種現狀，通過新的項目方法和一系列工具、自動化處理，來促進開發和運維人員（還包括其他項目崗位）的溝通和協作效率，讓產品的開發過程更透明，發布可以更快捷、頻繁和可靠。

看到這里相信你們已經對 DevOps 是什么有了大概的認識，但對于它具體的內容和執行方法依舊一頭霧水。所以下面，我就要進一步深入，講一講 DevOps 的流程和內容是怎么一回事。

二、網絡服務架構的演變

1. 單體服務架構

深入理解 DevOps，就涉及到對一些基礎服務架構的認識，這就要從這幾年的演變說起。

最早期和最簡單的網絡服務架構叫單體應用架構，比如開發人員編寫一套電商的系統和代碼，將對應的程序上傳到某個服務器中運行，就可以發布且讓用戶訪問了。開發人員只要監控這臺服務器的狀況就能實現該產品的運行和維護。

比如我們自己買一臺 Nas 或軟路由放在家里接上網線，在上面安裝好相應的系統和服務，實現遠程的登錄和訪問，就是最基礎的單體應用架構。

想要對運行中的軟件進行更新只要先中斷服務（類似關閉軟件），然后把新的代碼和文件替換掉線上的文件，再重啟服務即可，比如 FTP 傳輸工具就是用來實現這種文件傳輸的。可以想象成服務器就是一臺獨立的電腦，上面安裝運行的軟件是由很多零碎的文件組成的，比如代碼文件、配置文件、圖片、音視頻等，想要修改或者更新軟件就是將新編輯好的文件上傳覆蓋掉原有的，是你們在電腦軟件升級和 “破解” 中都操作過的步驟，非常簡單。

雖然單體架構操作起來很簡單，但是面向規模更大、更嚴肅的場景就顯得太簡陋了。如果訪問量過大，或者斷網、斷電、機器故障，或者機器被流星砸中物理毀滅……

所以，單體架構只適用于個人和一些小型企業的基礎服務，隨著項目規模的擴大，就需要進行架構的升級。

2. 分布式架構

分布式架構就是單體架構的對立面，它將原本只有一臺的服務器拓展成多臺，并且讓每臺服務器都具備相同的功能，且運行完全一致的程序和服務，這些服務器可以在一個機房里也可以在不同的機房和城市，通過負載均衡技術 Nginx 將它們組成一個集合，共同為用戶提供服務。

在這個集合中，每臺服務器都是一臺獨立運行的個體，無論哪臺服務器下線還是損壞其它服務器都能保持正常運轉。Nginx 負載均衡器負責將用戶的訪問請求自動分配給不同的服務器，讓它們進行計算并返回相關的數據，避免服務器過載，提升服務最大的處理能力和訪問速度。所以，這個集合里的服務器數量越多，支持同時訪問的人數（并發量）、處理的任務也就越多。

除此以外，在這種架構下還會應用 CDN、緩存、主從數據庫等其它基礎服務，對任何一臺服務器的調整都涉及到一系列其它服務的開關和配置。

這么做雖然讓服務變得更穩定和可靠，但也產生了很多負面的影響，那就是讓軟件服務的更新變得非常的繁瑣。本來只需要面對一臺服務器變成面對幾十上百臺，以及涉及的若干其它服務項的調節。就使得每次安裝、更新軟件變得非常麻煩，需要執行非常多的操作步驟，我們將這個安裝 、更新的過程稱為 “部署”。

尤其是更新軟件，過去架構簡單，項目規模小文件少，每次更新就是用 FTP 手動更新下文件，刪除一些冗余的文件。而隨著項目規模變大，文件數量急劇膨脹，每次更新可能涉及好幾個團隊，上百個開發完成的數百個文件的調整，那就不可能再用原有的方式執行。

于是在本地階段，工程師需要先各自提交寫好的代碼，運維再對這些代碼測試后進行 CI 集成，即將不同開發寫的代碼合并成最終的文件，這個文件往往是某種安裝包的形式。然后部署的過程就是把原有服務器中的軟件刪除，再安裝新的安裝包，而不僅僅是手動進行文件更換。

但因為服務器數量變多，部署是沒有那么容易的，也不會輕易關閉所有服務器中斷網絡服務然后進行升級。所以部署會具備一定的策略，如先部署到一小部分服務器中正式運行，用戶使用沒有問題后再部署剩余的服務器，這也叫灰度部署，是灰度測試在運維層面的應用。還有將服務器劃分成兩套，先關閉升級一套，運行穩定后再升級另一套的藍綠部署，以及每臺輪流升級的滾動部署。

這些部署策略的發明，原因就是前面說過的，開發階段制造了大量的問題會在運維手上爆炸，而爆炸就發生在部署的階段，因為在正式運行新軟件前我們都不知道會發生什么問題，所以必須分批進行，先測試再全部部署。

在真出現問題的情況下，一方面問題的排查特別困難，修復也麻煩，另一方面往往一個小改動都會導致前代碼集成、測試、部署的環節重新跑一遍，就是俗話說的為了一點醋還得包一頓餃子。

所以分布式架構的應用雖然理論上讓產品的服務變得更可靠和穩定，但使得從研發到上線的流程變得異常復雜，很多公司的 IT 部門不得不花費大量的時間和這套架構做博弈，而不是將精力花在如何服務業務提升產出量上。

如果產品的體量再進一步擴大，變成像京東、拼多多這種量級的服務怎么辦？每次新版本從集成到部署的時間可能就比之前長幾十到上百倍，這就會讓產品越發跟不上業務的進展，讓所有的產品戰略實施都增加了額外的滯后性，從而丟失競爭力。

于是，在大廠中分布式架構就慢慢被放棄，要轉用新的架構類型。

3. 微服務架構

分布式架構問題，就是沒辦法很好的適應大規模產品的運維，所以微服務的概念就產生了。既然項目規模特別大，那我們就把項目根據業務模塊進行劃分，拆分成若干小的獨立的產品，每個產品都是獨立運行在不同的服務器集群中。

這就極大的提升了產品維護、更新的靈活性，比如更新這款社交相關的功能，要增加短視頻服務，那么開發人員寫完代碼后運維也只需要集成社交模塊的代碼，并部署進社交相關的服務器集群中，不用牽扯到其它服務。即使上線后產生問題，定位問題的范圍也就在這個模塊內，而不需要牽扯到其它所有模塊。

而這些拆分出來的獨立模塊，就是一個微服務。實際的微服務往往比我現在的舉例更小，它們雖然獨立但服務之間依舊需要進行交互和數據的傳輸。而這些微服務中會有非常多通用的服務（比如短信驗證碼、廣告郵件發布），一方面可以直接找網上開源的代碼使用，另一方面也可以使用外包服務，或開發完成后剝離出來進行共用，

比如，公司運行好幾款產品，服務內容有一定交叉和重疊（比如淘寶、天貓、咸魚、極有家），那么基礎賬戶、交易、商品這些服務就可以共用，整合成一個新的平臺，讓不同的產品從這里面的調用服務或數據，這就是前幾年鼓吹的 “中臺” 概念。

微服務是目前大型產品和企業都在使用的服務類型，雖然讓代碼的發布變得更容易，但整套架構也改變得越來越復雜。團隊的協作需要經過特定的規范，并且需要依賴大量的自動化工具和數據可視化工具來減輕運維的壓力。

比如前面說到的代碼集合、測試、部署，這么多服務、集群、服務器全靠手動那運維肯定是這個星球上最肝的人。所以我們必須采用自動化的策略，讓這些繁瑣但是重復性的勞動可以交給機器自己完成。同時，運維還需要監控各個不同服務和硬件的各項指標，而可視化的工具是最佳的解決方案。

面對這樣的背景，DevOps 的方法論就被提出來了，想要讓產品更好的交付，那就需要制定出一套更有針對性的工作流，匹配新架構的應用，以及在不同工作階段結合各類不同的工具，來提升產出的效率和質量。

三、開放方式的流程演變

之所以前面講那么多架構有關的內容，原因就是 DevOps 是在遇到實際項目的問題以后提出的解決方案，而不是某些人憑空想出來的管理概念。

而 DevOps 作為一種方法論，也是經過演化后得到的結果，所以我們要再認識一下開發所經歷的流程有哪些。

1. 瀑布流

瀑布流，最樸素簡單的開發方式，即開發收到需求和設計以后，花一段時間進行開發，然后交付給 QA 統一測試并找出 bug，本地修改完成后部署上線。

這也是外行對項目開發的普遍認識，它在小項目和單體式架構中確實可以比較快的完成任務。但這種簡單的工作方法在應對大項目時是非常脆弱的，因為漫長的開發階段中，如果工作的產出沒有持續被審核、檢驗、校對，那么很可能產出的質量根本無法保障。甚至一開始開發理解的需求就是錯的，那么等到測試階段才發現就為時已晚。

而更重要的是，在開發階段制造的問題在測試部署階段改起來是很費勁的，因為積壓 Bug 數量過多，代碼質量差且系統脆弱，最容易發生的就是修復好一個 Bug，又產生新的 Bug，然后越改越多。

所以專業的團隊都會直接放棄瀑布流的模式，需要更有效更靈活的工作模式。

2. 精益/敏捷開發

然后精益和敏捷的開發模式就營運而生了，它們本質上都遵從 MVP 最小可行性原則，先開發出一個最簡陋的版本用于評審測試，驗證可用性，然后再完善細節。

一個完整的項目，就可以拆分成若干的模塊，每個模塊使用這種原則去執行，就能更早的發現問題，提升產出的效率和質量。簡單解釋起來，就是把測試流程前置，盡量減少問題的堆積分批次處理。

當然，這個模型描述起來很簡陋，如果只是簡單的分段和測試說到底還是瀑布，它們真正的價值在于每次測試除了發現 Bug 外還可以找出更好的開發、產品思路，從而修改原先的想法達到更好的效果，讓產出物處于可變更的狀態（所謂的擁抱變化），并優于最初的方案。

雖然大多數瀑布流的最終產出也和初始方案南轅北轍，但主要是受各種問題的影響而產生的妥協，質量只能遠遠低于預期。而精益/敏捷的目標是在兼顧項目目標和流程的同時，最大化發揮團隊的創造力并給出更好的結果（理想情況下）。

因為篇幅關系，我就不打算去拓展精益和敏捷的概念，尤其是敏捷，這是一套非常復雜的項目管理系統，很少會有團隊能真正理解并運用它，多數團隊的敏捷僅僅都是魔改版的精益流程。

3. DevOps 流程

在這里終于要進入 DevOps 的相關解釋了，DevOps 的核心出發點是為了解決開發和運維的協作效率而提出的概念，不然也不會用 Dev+Ops 的命名方式。

但既然要引入到項目中，只解決開發和運維的兩個崗位之間的協作局限性太大了，所以索性拓展它的范圍，加入產品、設計、質量工程、安全相關的成員和工作內容，使這些角色的工作相互依賴，成為影響整個應用程序生命周期（版本發布周期）的管理工具。

在微軟的官方說明中，DevOps 影響的產品生命周期包含四個主要的階段，計劃 Plan、開發 Develop、交付 Deliver、運維 Operate。

計劃：確定產品需求的階段，并使用敏捷的方式（如 backlog 或看板）規劃后續的工作。

開發：進行開發的過程，包含編寫、測試、評審，并集成代碼構建成可部署的文件。

交付：包含對基礎環境的搭建和配置，然后將相關的文件部署到對應環境中。

運維：在產品上線后對產品進行維護、監視、故障排除的工作。

為了最大化發揮這四個階段的效果，就會結合不同的工作流程、編程技巧、運維思路、數字工具。早期的 DevOps 流程搭建，會針對重要的工作節點配套一款數字化產品，提升生產力釋放人力需求。

比如下面這樣的例子：

要強調，DevOps 只是一種方法論并沒有具體的執行要求，上面只是搭建 DevOps 平臺時可選的配置方式，不同團隊完全可以定義不同的工作節點（類似審批、安全管理、編排等）并搭配其它工具。

但每個節點選個工具來完成確實是太麻煩了，所以就有一部分開發商針對這些需求，提供了一站式的 DevOps 平臺，將這些零散的功能整合到一起，讓項目成員只需要訪問一個工具就能實現大多數的服務，這就是 DevOps 的 SaaS 工具。

不要把 DevOps 當成一個用來選擇數字工具的過程，這些工具是用于執行 DevOps 流程的基礎但不是全部。所以我們最后再總結一遍 DevOps 的操作過程是什么：

“結合敏捷的工作思路，在前期將項目分解成多個細分模塊（Sprint），然后在執行過程（Scrum）中最快讓測試和運維可以參與進來驗證，并應用自動化工具高效的備份、集合、檢查、構建、部署代碼，逐一完成所有模塊的更新完成整個項目，并有效的進行上線后的監控和維護……”

分布式+微服務結合 DevOps 的管理模式，讓企業更新產品的速度和效率大大提升了，就可以用以周、或者天為單位的頻率做更新，更快速地響應市場需求。比如下面就是互聯網大廠和落后企業的部署節奏對比。

1. Amazon：23000 次/天
2. Google：5500 次/天
3. Netflix：500 次/天
4. Facebook：1 次/天
5. Twitter：3 次/周
6. 典型企業：1 次/9 個月

同時，它也讓開發和運維的目標保持一致，關系更緊密而不是對立，激發團隊的活力和創造性，這就是 DevOps 的價值。

結尾

針對 DevOps 更細致的認識，我相信光靠上面的解釋還是有欠缺的，尤其是針對部分專業名詞和敏捷開發的理解不足，就會不可避免的產生更多的疑問，這證明你們有在認真思考了。

而針對 DevOps 更完整的解析，我會在后面以 Wiki 的模式來整理。

本次的分享就到這里結束，如果中間有錯誤的地方，大家可以再下方評論中指出。

我們下篇再賤~

歡迎關注作者的微信公眾號：「超人的電話亭」