前文鏈接：

上一篇分享介紹了產(chǎn)品和設(shè)計(jì)師不得不了解技術(shù)的理由和入門方法，這一篇內(nèi)容趁熱打鐵，再繼續(xù)分享最近在整理的 DevOps 相關(guān)的原理和流程的說(shuō)明。

DevOps 是國(guó)內(nèi)所有大型企業(yè)都在實(shí)踐和應(yīng)用的項(xiàng)目改革，不管是互聯(lián)網(wǎng)大廠如騰訊、字節(jié)、阿里、美團(tuán)，還是老牌企業(yè)華為、移動(dòng)、電信或銀行。也孕育出一系列新興的 SaaS 產(chǎn)品，如極狐、Coding、藍(lán)鯨和博云等。

了解 DevOps 不僅能跟上時(shí)代的步伐和主流項(xiàng)目開(kāi)發(fā)流程接軌，拓展進(jìn)入相關(guān)項(xiàng)目的可能性，同時(shí)也是一個(gè)很好的了解技術(shù)的窗口，不再做技術(shù)方面的小白。

DevOps 是 Development 開(kāi)發(fā)和 Operations 運(yùn)維的組合縮寫(xiě)，多數(shù)中文翻譯叫開(kāi)發(fā)運(yùn)維一體化，它并不是一種技術(shù)或編程語(yǔ)言，而是一種面向項(xiàng)目編程管理的方法論，類似于傳統(tǒng)制造業(yè)中的精益制造理論。

它的主要作用，是在開(kāi)發(fā)過(guò)程中促進(jìn)團(tuán)隊(duì)成員（主要是開(kāi)發(fā)、運(yùn)維、測(cè)試）的溝通和協(xié)作，實(shí)現(xiàn)更高效、更頻繁、更可靠的軟件交付，以完成業(yè)務(wù)目標(biāo)。

相信看到這里會(huì)產(chǎn)生第一個(gè)疑問(wèn)，程序員碼代碼質(zhì)量越高和交付成果速度越快不是天經(jīng)地義的嗎，這種要求難道是最近才提出來(lái)，以前就不用高效、頻繁、可靠了嗎？

問(wèn)題就出在以前的工作模式上，不是不要求，而是很難做到。所以我們要首先理解沒(méi)有應(yīng)用 DevOps 前的產(chǎn)品開(kāi)發(fā)流程和問(wèn)題是什么。

一個(gè)傳統(tǒng)的項(xiàng)目流程，在確定需求以后，開(kāi)發(fā)人員（Dev）完成相關(guān)的功能代碼，然后交付給運(yùn)維人員（Ops）部署到測(cè)試環(huán)境，然后測(cè)試人員進(jìn)行測(cè)試并提交問(wèn)題，修改完成后再提交到生產(chǎn)環(huán)境正式運(yùn)行。

這種流程很直觀也很好理解，多數(shù)企業(yè)初期和小團(tuán)隊(duì)都會(huì)使用這種最樸素的方式。但隨著企業(yè)的發(fā)展，團(tuán)隊(duì)成員開(kāi)始增加，本來(lái)只有幾個(gè)人的研發(fā)部門可能增長(zhǎng)到幾十上百人，一個(gè)單一的團(tuán)隊(duì)被拆解成若干的小團(tuán)隊(duì)，每個(gè)團(tuán)隊(duì)負(fù)責(zé)自己對(duì)應(yīng)業(yè)務(wù)和模塊功能的開(kāi)發(fā)。比如做個(gè)電商網(wǎng)站，會(huì)員、購(gòu)物、活動(dòng)、社交、會(huì)員、廣告、搜索分別由不同的團(tuán)隊(duì)負(fù)責(zé)并開(kāi)發(fā)。

這就導(dǎo)致，團(tuán)隊(duì)之間往往不清楚其它團(tuán)隊(duì)在做什么，大家各寫(xiě)各的，等到臨近上線日期的時(shí)候，各部門再把寫(xiě)好的代碼進(jìn)行合并（形成完整的新版本代碼），交給運(yùn)維進(jìn)行部署做測(cè)試。

這時(shí)候問(wèn)題就開(kāi)始集中爆發(fā)，因?yàn)椴煌块T成員寫(xiě)的代碼可能在本地運(yùn)行的環(huán)境里正常，但是合并到一起就會(huì)引發(fā)一系列難以預(yù)估的問(wèn)題，如服務(wù)運(yùn)行時(shí)的報(bào)錯(cuò)、中斷、泄露等。每個(gè)問(wèn)題的解決往往要投入大量的時(shí)間精力，嚴(yán)重干擾了上線的進(jìn)度。

且能在測(cè)試環(huán)境解決的問(wèn)題都還算小問(wèn)題，最讓人擔(dān)心的還是在測(cè)試環(huán)境中明明已經(jīng)測(cè)好了，上線后卻出故障了，導(dǎo)致諸如用戶交易記錄丟失、限量商品無(wú)限庫(kù)存、重要頁(yè)面訪問(wèn)無(wú)效等災(zāi)難性后果。這時(shí)候只能下線服務(wù)，團(tuán)隊(duì)繼續(xù)耗費(fèi)大量的精力加班加點(diǎn)修復(fù)BUG讓服務(wù)恢復(fù)正常運(yùn)轉(zhuǎn)。

所以每一次發(fā)版都是一次折磨，項(xiàng)目越龐大折磨越大，不僅造成產(chǎn)品本身質(zhì)量變差，同時(shí)項(xiàng)目執(zhí)行效率大打折扣，不但提高了企業(yè)的人力成本，還會(huì)對(duì)業(yè)務(wù)造成非常負(fù)面的影響。

這時(shí)候不得不提一提運(yùn)維這個(gè)崗位，很多人都知道開(kāi)發(fā)即前后端的程序員，主要負(fù)責(zé)產(chǎn)品功能模塊的開(kāi)發(fā)。而運(yùn)維則是負(fù)責(zé)搭建可以運(yùn)行該產(chǎn)品的網(wǎng)絡(luò)環(huán)境，并保持服務(wù)運(yùn)行的穩(wěn)定。

最早這些工作是由后端工程師負(fù)責(zé)，但隨著互聯(lián)網(wǎng)基礎(chǔ)設(shè)施的發(fā)展和完善（越變?cè)綇?fù)雜），運(yùn)維相關(guān)的工作也變得越來(lái)越專業(yè)和繁瑣，除了代碼倉(cāng)庫(kù)、集成、部署、編譯外，還涉及服務(wù)器的硬件維護(hù)、網(wǎng)絡(luò)布線、虛擬化，以及負(fù)載均衡、內(nèi)容分發(fā)、環(huán)境管理、鏡像備份等工作。

所以工程師團(tuán)隊(duì)就分離出了運(yùn)維這個(gè)崗位，他們的作用和重要性毋庸置疑。但是他們的工作本質(zhì)就是—— 維穩(wěn)，因?yàn)榇罱ǔ龇€(wěn)定運(yùn)行的環(huán)境是很費(fèi)勁的，對(duì)這個(gè)系統(tǒng)加入任何新的代碼都可能打破它的穩(wěn)定制造出新的問(wèn)題。

而開(kāi)發(fā)的責(zé)任則是——改變，通過(guò)修改代碼或添加新的代碼才能實(shí)現(xiàn)產(chǎn)品的需求，所以他們的工作就勢(shì)必會(huì)對(duì)運(yùn)維工作目標(biāo)造成阻力。

這兩者之間的職能天生就有沖突，以前面的開(kāi)發(fā)流程為例，在前期的開(kāi)發(fā)階段中，開(kāi)發(fā)人員不僅是在完成產(chǎn)品需求，也是在給運(yùn)維制造問(wèn)題。開(kāi)發(fā)周期和規(guī)模越大，就會(huì)創(chuàng)造出越多運(yùn)維問(wèn)題進(jìn)行積壓，之后再將代碼和問(wèn)題一起交付給運(yùn)維，讓它們?cè)谶\(yùn)維手里合起來(lái)爆炸……

在這種分工體系下，開(kāi)發(fā)人員會(huì)認(rèn)為自己只需專注功能代碼的開(kāi)發(fā)就可以了，“運(yùn)維的工作關(guān)我什事？”。而運(yùn)維團(tuán)隊(duì)面對(duì)這種不負(fù)責(zé)任的行為是束手無(wú)策的，但不滿的情緒是會(huì)累積，并反應(yīng)到實(shí)際工作中，降低項(xiàng)目的執(zhí)行效率和完成質(zhì)量。

DevOps 的作用，本質(zhì)上就是要改變這種現(xiàn)狀，通過(guò)新的項(xiàng)目方法和一系列工具、自動(dòng)化處理，來(lái)促進(jìn)開(kāi)發(fā)和運(yùn)維人員（還包括其他項(xiàng)目崗位）的溝通和協(xié)作效率，讓產(chǎn)品的開(kāi)發(fā)過(guò)程更透明，發(fā)布可以更快捷、頻繁和可靠。

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

單體服務(wù)架構(gòu)

深入理解 DevOps，就涉及到對(duì)一些基礎(chǔ)服務(wù)架構(gòu)的認(rèn)識(shí)，這就要從這幾年的演變說(shuō)起。

最早期和最簡(jiǎn)單的網(wǎng)絡(luò)服務(wù)架構(gòu)叫單體應(yīng)用架構(gòu)，比如開(kāi)發(fā)人員編寫(xiě)一套電商的系統(tǒng)和代碼，將對(duì)應(yīng)的程序上傳到某個(gè)服務(wù)器中運(yùn)行，就可以發(fā)布且讓用戶訪問(wèn)了。開(kāi)發(fā)人員只要監(jiān)控這臺(tái)服務(wù)器的狀況就能實(shí)現(xiàn)該產(chǎn)品的運(yùn)行和維護(hù)。

比如我們自己買一臺(tái)Nas或軟路由放在家里接上網(wǎng)線，在上面安裝好相應(yīng)的系統(tǒng)和服務(wù)，實(shí)現(xiàn)遠(yuǎn)程的登錄和訪問(wèn)，就是最基礎(chǔ)的單體應(yīng)用架構(gòu)。

想要對(duì)運(yùn)行中的軟件進(jìn)行更新只要先中斷服務(wù)（類似關(guān)閉軟件），然后把新的代碼和文件替換掉線上的文件，再重啟服務(wù)即可，比如 FTP 傳輸工具就是用來(lái)實(shí)現(xiàn)這種文件傳輸?shù)??？梢韵胂蟪煞?wù)器就是一臺(tái)獨(dú)立的電腦，上面安裝運(yùn)行的軟件是由很多零碎的文件組成的，比如代碼文件、配置文件、圖片、音視頻等，想要修改或者更新軟件就是將新編輯好的文件上傳覆蓋掉原有的，是你們?cè)陔娔X軟件升級(jí)和 “破解” 中都操作過(guò)的步驟，非常簡(jiǎn)單。

雖然單體架構(gòu)操作起來(lái)很簡(jiǎn)單，但是面向規(guī)模更大、更嚴(yán)肅的場(chǎng)景就顯得太簡(jiǎn)陋了。如果訪問(wèn)量過(guò)大，或者斷網(wǎng)、斷電、機(jī)器故障，或者機(jī)器被流星砸中物理毀滅……

所以，單體架構(gòu)只適用于個(gè)人和一些小型企業(yè)的基礎(chǔ)服務(wù)，隨著項(xiàng)目規(guī)模的擴(kuò)大，就需要進(jìn)行架構(gòu)的升級(jí)。

分布式架構(gòu)

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

在這個(gè)集合中，每臺(tái)服務(wù)器都是一臺(tái)獨(dú)立運(yùn)行的個(gè)體，無(wú)論哪臺(tái)服務(wù)器下線還是損壞其它服務(wù)器都能保持正常運(yùn)轉(zhuǎn)。Nginx負(fù)載均衡器負(fù)責(zé)將用戶的訪問(wèn)請(qǐng)求自動(dòng)分配給不同的服務(wù)器，讓它們進(jìn)行計(jì)算并返回相關(guān)的數(shù)據(jù)，避免服務(wù)器過(guò)載，提升服務(wù)最大的處理能力和訪問(wèn)速度。所以，這個(gè)集合里的服務(wù)器數(shù)量越多，支持同時(shí)訪問(wèn)的人數(shù)（并發(fā)量）、處理的任務(wù)也就越多。

除此以外，在這種架構(gòu)下還會(huì)應(yīng)用CDN、緩存、主從數(shù)據(jù)庫(kù)等其它基礎(chǔ)服務(wù)，對(duì)任何一臺(tái)服務(wù)器的調(diào)整都涉及到一系列其它服務(wù)的開(kāi)關(guān)和配置。

這么做雖然讓服務(wù)變得更穩(wěn)定和可靠，但也產(chǎn)生了很多負(fù)面的影響，那就是讓軟件服務(wù)的更新變得非常的繁瑣。本來(lái)只需要面對(duì)一臺(tái)服務(wù)器變成面對(duì)幾十上百臺(tái)，以及涉及的若干其它服務(wù)項(xiàng)的調(diào)節(jié)。就使得每次安裝、更新軟件變得非常麻煩，需要執(zhí)行非常多的操作步驟，我們將這個(gè)安裝 、更新的過(guò)程稱為 “部署”。

尤其是更新軟件，過(guò)去架構(gòu)簡(jiǎn)單，項(xiàng)目規(guī)模小文件少，每次更新就是用 FTP 手動(dòng)更新下文件，刪除一些冗余的文件。而隨著項(xiàng)目規(guī)模變大，文件數(shù)量急劇膨脹，每次更新可能涉及好幾個(gè)團(tuán)隊(duì)，上百個(gè)開(kāi)發(fā)完成的數(shù)百個(gè)文件的調(diào)整，那就不可能再用原有的方式執(zhí)行。

于是在本地階段，工程師需要先各自提交寫(xiě)好的代碼，運(yùn)維再對(duì)這些代碼測(cè)試后進(jìn)行CI集成，即將不同開(kāi)發(fā)寫(xiě)的代碼合并成最終的文件，這個(gè)文件往往是某種安裝包的形式。然后部署的過(guò)程就是把原有服務(wù)器中的軟件刪除，再安裝新的安裝包，而不僅僅是手動(dòng)進(jìn)行文件更換。

但因?yàn)榉?wù)器數(shù)量變多，部署是沒(méi)有那么容易的，也不會(huì)輕易關(guān)閉所有服務(wù)器中斷網(wǎng)絡(luò)服務(wù)然后進(jìn)行升級(jí)。所以部署會(huì)具備一定的策略，如先部署到一小部分服務(wù)器中正式運(yùn)行，用戶使用沒(méi)有問(wèn)題后再部署剩余的服務(wù)器，這也叫灰度部署，是灰度測(cè)試在運(yùn)維層面的應(yīng)用。還有將服務(wù)器劃分成兩套，先關(guān)閉升級(jí)一套，運(yùn)行穩(wěn)定后再升級(jí)另一套的藍(lán)綠部署，以及每臺(tái)輪流升級(jí)的滾動(dòng)部署。

這些部署策略的發(fā)明，原因就是前面說(shuō)過(guò)的，開(kāi)發(fā)階段制造了大量的問(wèn)題會(huì)在運(yùn)維手上爆炸，而爆炸就發(fā)生在部署的階段，因?yàn)樵谡竭\(yùn)行新軟件前我們都不知道會(huì)發(fā)生什么問(wèn)題，所以必須分批進(jìn)行，先測(cè)試再全部部署。

在真出現(xiàn)問(wèn)題的情況下，一方面問(wèn)題的排查特別困難，修復(fù)也麻煩，另一方面往往一個(gè)小改動(dòng)都會(huì)導(dǎo)致前代碼集成、測(cè)試、部署的環(huán)節(jié)重新跑一遍，就是俗話說(shuō)的為了一點(diǎn)醋還得包一頓餃子。

所以分布式架構(gòu)的應(yīng)用雖然理論上讓產(chǎn)品的服務(wù)變得更可靠和穩(wěn)定，但使得從研發(fā)到上線的流程變得異常復(fù)雜，很多公司的 IT 部門不得不花費(fèi)大量的時(shí)間和這套架構(gòu)做博弈，而不是將精力花在如何服務(wù)業(yè)務(wù)提升產(chǎn)出量上。

如果產(chǎn)品的體量再進(jìn)一步擴(kuò)大，變成像京東、拼多多這種量級(jí)的服務(wù)怎么辦？每次新版本從集成到部署的時(shí)間可能就比之前長(zhǎng)幾十到上百倍，這就會(huì)讓產(chǎn)品越發(fā)跟不上業(yè)務(wù)的進(jìn)展，讓所有的產(chǎn)品戰(zhàn)略實(shí)施都增加了額外的滯后性，從而丟失競(jìng)爭(zhēng)力。

于是，在大廠中分布式架構(gòu)就慢慢被放棄，要轉(zhuǎn)用新的架構(gòu)類型。

微服務(wù)架構(gòu)

分布式架構(gòu)問(wèn)題，就是沒(méi)辦法很好的適應(yīng)大規(guī)模產(chǎn)品的運(yùn)維，所以微服務(wù)的概念就產(chǎn)生了。既然項(xiàng)目規(guī)模特別大，那我們就把項(xiàng)目根據(jù)業(yè)務(wù)模塊進(jìn)行劃分，拆分成若干小的獨(dú)立的產(chǎn)品，每個(gè)產(chǎn)品都是獨(dú)立運(yùn)行在不同的服務(wù)器集群中。

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

而這些拆分出來(lái)的獨(dú)立模塊，就是一個(gè)微服務(wù)。實(shí)際的微服務(wù)往往比我現(xiàn)在的舉例更小，它們雖然獨(dú)立但服務(wù)之間依舊需要進(jìn)行交互和數(shù)據(jù)的傳輸。而這些微服務(wù)中會(huì)有非常多通用的服務(wù)（比如短信驗(yàn)證碼、廣告郵件發(fā)布），一方面可以直接找網(wǎng)上開(kāi)源的代碼使用，另一方面也可以使用外包服務(wù)，或開(kāi)發(fā)完成后剝離出來(lái)進(jìn)行共用，

比如，公司運(yùn)行好幾款產(chǎn)品，服務(wù)內(nèi)容有一定交叉和重疊（比如淘寶、天貓、咸魚(yú)、極有家），那么基礎(chǔ)賬戶、交易、商品這些服務(wù)就可以共用，整合成一個(gè)新的平臺(tái)，讓不同的產(chǎn)品從這里面的調(diào)用服務(wù)或數(shù)據(jù)，這就是前幾年鼓吹的 “中臺(tái)” 概念。

微服務(wù)是目前大型產(chǎn)品和企業(yè)都在使用的服務(wù)類型，雖然讓代碼的發(fā)布變得更容易，但整套架構(gòu)也改變得越來(lái)越復(fù)雜。團(tuán)隊(duì)的協(xié)作需要經(jīng)過(guò)特定的規(guī)范，并且需要依賴大量的自動(dòng)化工具和數(shù)據(jù)可視化工具來(lái)減輕運(yùn)維的壓力。

比如前面說(shuō)到的代碼集合、測(cè)試、部署，這么多服務(wù)、集群、服務(wù)器全靠手動(dòng)那運(yùn)維肯定是這個(gè)星球上最肝的人。所以我們必須采用自動(dòng)化的策略，讓這些繁瑣但是重復(fù)性的勞動(dòng)可以交給機(jī)器自己完成。同時(shí)，運(yùn)維還需要監(jiān)控各個(gè)不同服務(wù)和硬件的各項(xiàng)指標(biāo)，而可視化的工具是最佳的解決方案。

面對(duì)這樣的背景，DevOps 的方法論就被提出來(lái)了，想要讓產(chǎn)品更好的交付，那就需要制定出一套更有針對(duì)性的工作流，匹配新架構(gòu)的應(yīng)用，以及在不同工作階段結(jié)合各類不同的工具，來(lái)提升產(chǎn)出的效率和質(zhì)量。

之所以前面講那么多架構(gòu)有關(guān)的內(nèi)容，原因就是 DevOps 是在遇到實(shí)際項(xiàng)目的問(wèn)題以后提出的解決方案，而不是某些人憑空想出來(lái)的管理概念。

而 DevOps 作為一種方法論，也是經(jīng)過(guò)演化后得到的結(jié)果，所以我們要再認(rèn)識(shí)一下開(kāi)發(fā)所經(jīng)歷的流程有哪些。

瀑布流

瀑布流，最樸素簡(jiǎn)單的開(kāi)發(fā)方式，即開(kāi)發(fā)收到需求和設(shè)計(jì)以后，花一段時(shí)間進(jìn)行開(kāi)發(fā)，然后交付給 QA 統(tǒng)一測(cè)試并找出 bug，本地修改完成后部署上線。

這也是外行對(duì)項(xiàng)目開(kāi)發(fā)的普遍認(rèn)識(shí)，它在小項(xiàng)目和單體式架構(gòu)中確實(shí)可以比較快的完成任務(wù)。但這種簡(jiǎn)單的工作方法在應(yīng)對(duì)大項(xiàng)目時(shí)是非常脆弱的，因?yàn)槁L(zhǎng)的開(kāi)發(fā)階段中，如果工作的產(chǎn)出沒(méi)有持續(xù)被審核、檢驗(yàn)、校對(duì)，那么很可能產(chǎn)出的質(zhì)量根本無(wú)法保障。甚至一開(kāi)始開(kāi)發(fā)理解的需求就是錯(cuò)的，那么等到測(cè)試階段才發(fā)現(xiàn)就為時(shí)已晚。

而更重要的是，在開(kāi)發(fā)階段制造的問(wèn)題在測(cè)試部署階段改起來(lái)是很費(fèi)勁的，因?yàn)榉e壓 Bug 數(shù)量過(guò)多，代碼質(zhì)量差且系統(tǒng)脆弱，最容易發(fā)生的就是修復(fù)好一個(gè) Bug，又產(chǎn)生新的 Bug，然后越改越多。

所以專業(yè)的團(tuán)隊(duì)都會(huì)直接放棄瀑布流的模式，需要更有效更靈活的工作模式。

精益/敏捷開(kāi)發(fā)

然后精益和敏捷的開(kāi)發(fā)模式就營(yíng)運(yùn)而生了，它們本質(zhì)上都遵從 MVP 最小可行性原則，先開(kāi)發(fā)出一個(gè)最簡(jiǎn)陋的版本用于評(píng)審測(cè)試，驗(yàn)證可用性，然后再完善細(xì)節(jié)。

一個(gè)完整的項(xiàng)目，就可以拆分成若干的模塊，每個(gè)模塊使用這種原則去執(zhí)行，就能更早的發(fā)現(xiàn)問(wèn)題，提升產(chǎn)出的效率和質(zhì)量。簡(jiǎn)單解釋起來(lái)，就是把測(cè)試流程前置，盡量減少問(wèn)題的堆積分批次處理。

當(dāng)然，這個(gè)模型描述起來(lái)很簡(jiǎn)陋，如果只是簡(jiǎn)單的分段和測(cè)試說(shuō)到底還是瀑布，它們真正的價(jià)值在于每次測(cè)試除了發(fā)現(xiàn) Bug 外還可以找出更好的開(kāi)發(fā)、產(chǎn)品思路，從而修改原先的想法達(dá)到更好的效果，讓產(chǎn)出物處于可變更的狀態(tài)（所謂的擁抱變化），并優(yōu)于最初的方案。

雖然大多數(shù)瀑布流的最終產(chǎn)出也和初始方案南轅北轍，但主要是受各種問(wèn)題的影響而產(chǎn)生的妥協(xié)，質(zhì)量只能遠(yuǎn)遠(yuǎn)低于預(yù)期。而精益/敏捷的目標(biāo)是在兼顧項(xiàng)目目標(biāo)和流程的同時(shí)，最大化發(fā)揮團(tuán)隊(duì)的創(chuàng)造力并給出更好的結(jié)果（理想情況下）。

因?yàn)槠P(guān)系，我就不打算去拓展精益和敏捷的概念，尤其是敏捷，這是一套非常復(fù)雜的項(xiàng)目管理系統(tǒng)，很少會(huì)有團(tuán)隊(duì)能真正理解并運(yùn)用它，多數(shù)團(tuán)隊(duì)的敏捷僅僅都是魔改版的精益流程。

之后有機(jī)會(huì)我會(huì)單獨(dú)寫(xiě)一個(gè)敏捷的掃盲系列出來(lái)，大家只要知道它們大概得價(jià)值和作用即可。

DevOps 流程

在這里終于要進(jìn)入 DevOps 的相關(guān)解釋了，DevOps 的核心出發(fā)點(diǎn)是為了解決開(kāi)發(fā)和運(yùn)維的協(xié)作效率而提出的概念，不然也不會(huì)用 Dev+Ops 的命名方式。

但既然要引入到項(xiàng)目中，只解決開(kāi)發(fā)和運(yùn)維的兩個(gè)崗位之間的協(xié)作局限性太大了，所以索性拓展它的范圍，加入產(chǎn)品、設(shè)計(jì)、質(zhì)量工程、安全相關(guān)的成員和工作內(nèi)容，使這些角色的工作相互依賴，成為影響整個(gè)應(yīng)用程序生命周期（版本發(fā)布周期）的管理工具。

在微軟的官方說(shuō)明中，DevOps 影響的產(chǎn)品生命周期包含四個(gè)主要的階段，計(jì)劃 Plan、開(kāi)發(fā) Develop、交付 Deliver、運(yùn)維 Operate。

計(jì)劃：確定產(chǎn)品需求的階段，并使用敏捷的方式（如 backlog 或看板）規(guī)劃后續(xù)的工作。

開(kāi)發(fā)：進(jìn)行開(kāi)發(fā)的過(guò)程，包含編寫(xiě)、測(cè)試、評(píng)審，并集成代碼構(gòu)建成可部署的文件。

交付：包含對(duì)基礎(chǔ)環(huán)境的搭建和配置，然后將相關(guān)的文件部署到對(duì)應(yīng)環(huán)境中。

運(yùn)維：在產(chǎn)品上線后對(duì)產(chǎn)品進(jìn)行維護(hù)、監(jiān)視、故障排除的工作。

為了最大化發(fā)揮這四個(gè)階段的效果，就會(huì)結(jié)合不同的工作流程、編程技巧、運(yùn)維思路、數(shù)字工具。早期的 DevOps 流程搭建，會(huì)針對(duì)重要的工作節(jié)點(diǎn)配套一款數(shù)字化產(chǎn)品，提升生產(chǎn)力釋放人力需求。

比如下面這樣的例子：

要強(qiáng)調(diào)，DevOps 只是一種方法論并沒(méi)有具體的執(zhí)行要求，上面只是搭建 DevOps 平臺(tái)時(shí)可選的配置方式，不同團(tuán)隊(duì)完全可以定義不同的工作節(jié)點(diǎn)（類似審批、安全管理、編排等）并搭配其它工具。

但每個(gè)節(jié)點(diǎn)選個(gè)工具來(lái)完成確實(shí)是太麻煩了，所以就有一部分開(kāi)發(fā)商針對(duì)這些需求，提供了一站式的 DevOps 平臺(tái)，將這些零散的功能整合到一起，讓項(xiàng)目成員只需要訪問(wèn)一個(gè)工具就能實(shí)現(xiàn)大多數(shù)的服務(wù)，這就是 DevOps 的 SaaS 工具。

不要把 DevOps當(dāng)成一個(gè)用來(lái)選擇數(shù)字工具的過(guò)程，這些工具是用于執(zhí)行 DevOps 流程的基礎(chǔ)但不是全部。所以我們最后再總結(jié)一遍 DevOps 的操作過(guò)程是什么：

“結(jié)合敏捷的工作思路，在前期將項(xiàng)目分解成多個(gè)細(xì)分模塊（Sprint），然后在執(zhí)行過(guò)程（Scrum）中最快讓測(cè)試和運(yùn)維可以參與進(jìn)來(lái)驗(yàn)證，并應(yīng)用自動(dòng)化工具高效的備份、集合、檢查、構(gòu)建、部署代碼，逐一完成所有模塊的更新完成整個(gè)項(xiàng)目，并有效的進(jìn)行上線后的監(jiān)控和維護(hù)……”

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

Amazon：23000次/天

Google：5500次/天

Netflix：500次/天

Facebook：1次/天

Twitter：3次/周

典型企業(yè)：1次/9個(gè)月

同時(shí)，它也讓開(kāi)發(fā)和運(yùn)維的目標(biāo)保持一致，關(guān)系更緊密而不是對(duì)立，激發(fā)團(tuán)隊(duì)的活力和創(chuàng)造性，這就是 DevOps 的價(jià)值。

結(jié)尾

針對(duì) DevOps 更細(xì)致的認(rèn)識(shí)，我相信光靠上面的解釋還是有欠缺的，尤其是針對(duì)部分專業(yè)名詞和敏捷開(kāi)發(fā)的理解不足，就會(huì)不可避免的產(chǎn)生更多的疑問(wèn)，這證明你們有在認(rèn)真思考了。

而針對(duì) DevOps 更完整的解析，我會(huì)在后面以 Wiki 的模式來(lái)整理，同時(shí)也會(huì)專門準(zhǔn)備一篇內(nèi)容來(lái)解釋什么是敏捷開(kāi)發(fā)，保證是你姥姥都能看懂的辣種……

本次的分享就到這里結(jié)束，如果中間有錯(cuò)誤的地方，大家可以再下方評(píng)論中指出。

我們下篇再賤~

第一期B端產(chǎn)品經(jīng)理入門課7.3開(kāi)課，目前還可以參加，需要報(bào)名聯(lián)系我~