DevOps是最近非?；鸬囊粋€(gè)概念，談IT流程建設(shè)不說點(diǎn)DevOps都不好意思和人打招呼。但是DevOps究竟是個(gè)什么東西，這個(gè)東西能不能用？怎么用？什么樣的情況才叫做DevOps落地成功？對(duì)于這些問題的答案，雖然網(wǎng)上有鋪天蓋地的文章和教程，但是一般來說都是從理論或者方法論上去闡述，也有大廠的實(shí)施經(jīng)歷。個(gè)人就感覺這里的它山之石，很難攻玉了。最終還是得思考下DevOps的由來，綜合自己所在企業(yè)的現(xiàn)實(shí)狀況去考慮。
在這篇文章中，本人無意對(duì)DevOps從理論或者方法論上做說明和講解，只是想綜合自己工作過程中的一些現(xiàn)實(shí)情況，在解決和優(yōu)化一些現(xiàn)實(shí)情況的過程中，接觸到了DevOps這樣一個(gè)概念，想試著在DevOps這條路上找到一些解決問題的可行性和落地方式。本文是基于這個(gè)目的來做的一些總結(jié)，提到的概念和方法不一定和網(wǎng)上其他的教程/文章描述的一樣，我只是想提出我的理解，希望各位看客輕拍，可以留言或者私信交流。
一. DevOps作為一種軟件開發(fā)手段和方法
先引用下百度百科上對(duì)DevOps的描述：“DevOps（Development和Operations的組合詞）是一組過程、方法與系統(tǒng)的統(tǒng)稱，用于促進(jìn)開發(fā)（應(yīng)用程序/軟件工程）、技術(shù)運(yùn)營和質(zhì)量保障（QA）部門之間的溝通、協(xié)作與整合?！蔽覍?duì)這句話的理解，就是利用各種技術(shù)和管理手段來使整個(gè)軟件工程更加的高效。為了更好的理解這樣一個(gè)概念。就有必要去了解下在DevOps出現(xiàn)之前，有哪些軟件工程流程，為什么在當(dāng)前的情況下，需要有DevOps的出現(xiàn)，才能更好的理解這些技術(shù)或者管理手段的目的和意義。
軟件行業(yè)的江湖中一直流傳著這樣類型的傳說，某位大神閉關(guān)若干月，憑借自己無上的神功，在車庫/地下室等各種不同簡(jiǎn)陋的地點(diǎn)開發(fā)出牛逼的一塌糊涂的產(chǎn)品。行內(nèi)的各位肯定對(duì)這樣的傳說并不陌生。但是我個(gè)人認(rèn)為其中有夸大的成分，不可否認(rèn)，某位大神可以憑借自己無上神功搭出產(chǎn)品的核心框架，但是最終成熟的商業(yè)產(chǎn)品肯定是需要一個(gè)穩(wěn)定的團(tuán)隊(duì)，依靠可靠的流程手段來維持和推進(jìn)，缺乏有效管理的產(chǎn)品會(huì)變成一個(gè)焦油坑(人月神話)。
那么，這樣一個(gè)可靠的流程手段就是我們通常講到的軟件工程：
a. 最初的階段，我們的軟件產(chǎn)品只有有限的需求，業(yè)務(wù)對(duì)軟件的依賴也不是那么的大，因此有相對(duì)較長(zhǎng)的交付周期。對(duì)于這樣的一個(gè)應(yīng)用場(chǎng)景，就有了最初的瀑布模型：
瀑布模型為了保證整個(gè)軟件可控，從而保證軟件產(chǎn)品質(zhì)量，對(duì)每個(gè)階段進(jìn)行管控，只有前一個(gè)階段的輸出穩(wěn)定和質(zhì)量過關(guān)后，才能進(jìn)入下一個(gè)階段。
這種模型在需求量相對(duì)簡(jiǎn)單和少的情況下，可以做到可控。但是隨著社會(huì)的發(fā)展，各行各業(yè)對(duì)軟件的依賴越來越大，各種復(fù)雜的業(yè)務(wù)都需要有軟件的介入，復(fù)雜的業(yè)務(wù)場(chǎng)景，更短的開發(fā)周期，更頻繁的業(yè)務(wù)場(chǎng)景變更，導(dǎo)致瀑布模型的開發(fā)模式無法保證有效和高質(zhì)量的產(chǎn)品開發(fā)。因此我們需要有更好更適合的開發(fā)模型。
b. 最簡(jiǎn)單的，我們采用分而治之的方法，將整個(gè)軟件需求拆分成若干個(gè)子集，將整個(gè)過程拆分成若干個(gè)迭代，每個(gè)迭代挑選出若干子集采用瀑布模型的方式進(jìn)行開發(fā)。稱之為迭代模型。
這樣，可以保證在每個(gè)迭代開發(fā)周期中，形成一個(gè)可交付的產(chǎn)品子集，逐步增量的進(jìn)行交付。
理論上講，通過控制迭代的需求范圍，迭代開發(fā)可以適用大多數(shù)軟件開發(fā)場(chǎng)景了。但是隨著互聯(lián)網(wǎng)和移動(dòng)業(yè)務(wù)的崛起，對(duì)于軟件的更新/構(gòu)建速度提出了前所未有的要求。在迭代開發(fā)中，每個(gè)迭代還是走的需求設(shè)計(jì)/概要設(shè)計(jì)/詳細(xì)設(shè)計(jì)/開發(fā)/測(cè)試/部署的流程。一旦一個(gè)迭代的范圍和時(shí)間確定，為保證質(zhì)量，原則上是不調(diào)整需求的。而一個(gè)迭代的流程下來，少說一個(gè)月兩個(gè)月的。但是在移動(dòng)互聯(lián)網(wǎng)時(shí)代，為了快速響應(yīng)用戶需求來占領(lǐng)市場(chǎng)，需求是不斷變化的，根本沒有可能等待一個(gè)迭代結(jié)束之后再重新調(diào)整需求。因此，面向用戶需求的軟件開發(fā)理念就迅速在業(yè)界流行起來，也就是敏捷開發(fā)。
c. 我們來看一下敏捷開發(fā)的定義，引用百度百科上的定義：
敏捷軟件開發(fā)（英語：Agile software development），又稱敏捷開發(fā)，是一種從1990年代開始逐漸引起廣泛關(guān)注的新型軟件開發(fā)方法，是一種能應(yīng)對(duì)快速變化需求的軟件開發(fā)能力。它們的具體名稱、理念、過程、術(shù)語都不盡相同，相對(duì)于“非敏捷”，更強(qiáng)調(diào)程序員團(tuán)隊(duì)與業(yè)務(wù)專家之間的緊密協(xié)作、面對(duì)面的溝通（認(rèn)為比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團(tuán)隊(duì)、能夠很好地適應(yīng)需求變化的代碼編寫和團(tuán)隊(duì)組織方法，也更注重軟件開發(fā)過程中人的作用。
我個(gè)人對(duì)這個(gè)定義的理解是敏捷開發(fā)是一套方法論，為了適應(yīng)頻繁變化的需求而產(chǎn)生的。而在軟件開發(fā)流程上相對(duì)于上述的瀑布和傳統(tǒng)迭代模型而言，最關(guān)鍵的變化就是從面向書面的文檔轉(zhuǎn)變?yōu)槊嫦蛉藛T合作。在上述的流程中，強(qiáng)調(diào)的是每個(gè)階段的可靠性，只有當(dāng)每個(gè)階段的輸出完成后才進(jìn)入下一個(gè)階段（包括文檔輸出，文檔也會(huì)作為一個(gè)重要的輸出，成為下一階段的輸入）。而敏捷開發(fā)更強(qiáng)調(diào)的是人與人之間的合作和溝通，而不是依賴文檔（當(dāng)然，不是不需要文檔，必要的文檔記錄是很重要和必要的工作）。為了保持足夠有效的人員溝通，團(tuán)隊(duì)的規(guī)模就不可能很大。因此就只能是小而精的團(tuán)隊(duì)，通過有效的溝通快速將需求實(shí)現(xiàn)。從而小步快跑的進(jìn)行快速迭代。
上面是一個(gè)敏捷開發(fā)的一個(gè)方法論，不是一個(gè)具體的實(shí)現(xiàn)方法，一個(gè)比較著名的方法就是scrum。
而在快速迭代的過程中，每個(gè)需求和階段的重點(diǎn)是通過人員之間的合作來推動(dòng)，而人總是沒有機(jī)器和工具的可靠（也就是說，人總是會(huì)犯錯(cuò)），為了保證質(zhì)量和流程的穩(wěn)定，一系列的工具被開發(fā)出來，這些工具也成為了敏捷開發(fā)的一部分。
因此，我理解的敏捷開發(fā)應(yīng)該是一套實(shí)現(xiàn)了方法論的實(shí)踐 + 工具集合。
講到這里，就想先引入下所在企業(yè)的現(xiàn)狀，碰到的問題及問題的思考，在這層思考的基礎(chǔ)上去考慮DevOps的可行性和落地方法。也就是說，本人是想將DevOps作為解決方案之一來做思考的。
二. 企業(yè)軟件開發(fā)流程現(xiàn)狀
本人所在企業(yè)的業(yè)務(wù)是ToB的業(yè)務(wù)，和移動(dòng)互聯(lián)網(wǎng)從需求層面來講是有很大區(qū)別的。一般來說，ToB的業(yè)務(wù)都是面向某一個(gè)特定的行業(yè)，行業(yè)屬性極強(qiáng)，比如醫(yī)療，工業(yè)等領(lǐng)域，作為IT界的專業(yè)人士完全無法了解到其中的專業(yè)知識(shí)，更有甚者連最基本的常識(shí)都沒有。這點(diǎn)和大多面向ToC的移動(dòng)互聯(lián)網(wǎng)不一樣，移動(dòng)互聯(lián)網(wǎng)的業(yè)務(wù)一般都是基于常識(shí)，比如基于個(gè)人消費(fèi)的電商，音樂軟件等，產(chǎn)品經(jīng)理都可以基于常識(shí)+個(gè)人體驗(yàn)做到對(duì)用戶的引導(dǎo)來提出需求。這點(diǎn)在本人看來，對(duì)于開發(fā)流程是至關(guān)重要的，因?yàn)椴还苁鞘裁礃拥牧鞒蹋际窃醋杂谛枨螅浖旧碇皇且粋€(gè)人類生活中實(shí)現(xiàn)各種業(yè)務(wù)需求的工具，偏離了需求，軟件也就沒有存在的價(jià)值。
上面的一大段提到的問題會(huì)衍生出下面幾個(gè)關(guān)鍵問題：
我們團(tuán)隊(duì)在產(chǎn)品的需求上話語權(quán)太低。在碰到不同客戶的不同需求上，對(duì)于客戶的引導(dǎo)難度非常大。一個(gè)簡(jiǎn)單的例子就是，對(duì)于一個(gè)需求的優(yōu)先級(jí)和重要性，無法有一個(gè)客觀的判斷，而對(duì)于客戶而言，他提出的每一個(gè)需求對(duì)他而言都是重要和關(guān)鍵的，而我們的團(tuán)隊(duì)無法對(duì)其進(jìn)行判別，更別說去對(duì)客戶進(jìn)行引導(dǎo)。
企業(yè)是一個(gè)初創(chuàng)團(tuán)隊(duì)，沒有足夠的行業(yè)經(jīng)驗(yàn)積累。產(chǎn)品是基于某幾家合作單位客戶需求搭建起來的，是否具有業(yè)務(wù)上的普適性有待考證。
由于上述兩個(gè)問題，就會(huì)造成在多個(gè)項(xiàng)目同時(shí)推進(jìn)時(shí)，無法判斷是否能由一個(gè)產(chǎn)品或者說時(shí)一套代碼來交付
ToB的業(yè)務(wù)往往是需要強(qiáng)可靠性和非常低的錯(cuò)誤容忍度。簡(jiǎn)單的一個(gè)說明就是，你在發(fā)朋友圈的時(shí)候，由于程序bug導(dǎo)致發(fā)送失敗，而且導(dǎo)致輸入沒有保存，你除了發(fā)點(diǎn)牢騷，心想著換個(gè)app，再默默的重新輸入一次之外沒有別的想法，而tob的業(yè)務(wù)可能就會(huì)導(dǎo)致某條流水線失敗，工業(yè)事故或者更有甚者就是影響到人的生命。
因此，在實(shí)際的軟件開發(fā)過程中，企業(yè)的開發(fā)模式應(yīng)該是處于半敏捷開發(fā)的模式。整體來說還是需求->設(shè)計(jì)->開發(fā)->測(cè)試的模式。在產(chǎn)品開發(fā)初期及產(chǎn)品成型后的交付初期，需求相對(duì)確定，產(chǎn)品規(guī)模和業(yè)務(wù)復(fù)雜度較低，團(tuán)隊(duì)規(guī)模也不大。
每個(gè)迭代的時(shí)長(zhǎng)控制在一周到兩周左右。
需求文檔往往就是一個(gè)截圖和excel列表，在團(tuán)隊(duì)中通過會(huì)議進(jìn)行同步和說明。
測(cè)試往往提前介入，及時(shí)將開發(fā)輸出的需求進(jìn)行測(cè)試，在過程中完善測(cè)試用例（測(cè)試的用例文檔的目的往往是為了留檔，進(jìn)行知識(shí)儲(chǔ)備）。讓每個(gè)迭代的構(gòu)建和發(fā)布時(shí)間相對(duì)縮短。
在半年到一年的交付之后，需求復(fù)雜度和代碼耦合性越來越高。這個(gè)流程越來月陷入到焦油坑中：
需求往往要經(jīng)過多次討論，需要集合越來越多上下游的開發(fā)測(cè)試人員參與討論，討論的時(shí)間往往就是半天到一天
開發(fā)代碼牽一發(fā)動(dòng)全身，if-else堆積如山，圈復(fù)雜度急劇上升。
測(cè)試很難保證測(cè)試質(zhì)量，任何一個(gè)bug的修復(fù)都會(huì)導(dǎo)致意想不到的bug出現(xiàn)，根本無法提前介入測(cè)試，或者說提前介入測(cè)試基本沒有起到應(yīng)用的作用，在交付壓力的情況下，測(cè)試會(huì)成為交付進(jìn)度的犧牲品。
為了保證交付質(zhì)量，每個(gè)環(huán)節(jié)不得不加入大量的文檔和評(píng)審，保證上下游對(duì)改動(dòng)的理解和范圍一致
到了不重構(gòu)就無法推進(jìn)的境地，而進(jìn)度和人員規(guī)模很難保證互不影響
可以看到，敏捷開發(fā)模式逐步退回到迭代模型中。由人員合作為導(dǎo)向變成了由文檔為導(dǎo)向，每個(gè)階段的“墻”越來越厚。
2. 堆積如山的環(huán)境
一般來說，剛開始我們是規(guī)劃了幾套環(huán)境來保證日常的開發(fā)工作
本地環(huán)境：很好理解，每個(gè)開發(fā)人員的辦公環(huán)境，不管是物理機(jī)還是虛擬機(jī)。用于開發(fā)人員本地調(diào)試，保證需求代碼開發(fā)完成。
開發(fā)環(huán)境：開發(fā)人員維護(hù)，所有的代碼提交之后，可以較為頻繁和靈活的構(gòu)建，作為代碼的第一次整合。
測(cè)試環(huán)境：每個(gè)迭代規(guī)劃若干次構(gòu)建，每次構(gòu)建后不做改動(dòng)，由測(cè)試團(tuán)隊(duì)在此發(fā)現(xiàn)問題。
生產(chǎn)環(huán)境：測(cè)試確認(rèn)無誤后，將相應(yīng)的改動(dòng)部署，投入業(yè)務(wù)生產(chǎn)當(dāng)中。
當(dāng)項(xiàng)目越來越多時(shí)，每個(gè)項(xiàng)目都需要配置相同的環(huán)境。還有一些專用的環(huán)境，比如性能測(cè)試環(huán)境，為了保證穩(wěn)定和演練上線步驟出現(xiàn)的預(yù)發(fā)布環(huán)境等等。光是環(huán)境都有一大把。雖然在現(xiàn)在虛擬化和容器技術(shù)的支撐下，不需要機(jī)房里堆上一大堆的物理服務(wù)器，但是對(duì)于每臺(tái)虛擬機(jī)的管理也是一個(gè)相當(dāng)繁瑣的工作。也是影響交付效率下降的一個(gè)重要原因。
3. Dev VS Ops，難以調(diào)和的矛盾
我們的團(tuán)隊(duì)中沒有專門負(fù)責(zé)部署和運(yùn)維的團(tuán)隊(duì)，一般由開發(fā)或者測(cè)試的人來兼任這部分工作。但是不阻礙我們可以把這兩部分工作區(qū)分開來考慮。對(duì)于已經(jīng)商用的項(xiàng)目，規(guī)劃多少需求到一個(gè)迭代中去開發(fā)和交付，是對(duì)整個(gè)團(tuán)隊(duì)的選擇題。是盡可能多的上新的需求還是降低風(fēng)險(xiǎn)盡量少的控制需求是每次都會(huì)糾結(jié)的問題。
盡快的響應(yīng)客戶需求，將新開發(fā)的功能盡可能多的排入計(jì)劃。上線失敗的風(fēng)險(xiǎn)就會(huì)增加。
為了穩(wěn)定盡可能少的逐步上需求，會(huì)導(dǎo)致客戶滿意度下降。
雖然沒有兩個(gè)團(tuán)隊(duì)之間的部門墻問題，同樣還是存在Dev和Ops之間的矛盾。
4. 解決方案之一 -- DevOps
上面說了這么一些，總的說來就是研發(fā)和交付效率隨著業(yè)務(wù)和代碼的復(fù)雜度上升而顯著下降，就需要有更好的流程和工具來解決這樣的問題。自然而然的，團(tuán)隊(duì)就將注意力放到了大火的DevOps上。
是否要用DevOps，不是因?yàn)閯e人用了，我們就要用。首先想了解下DevOps是什么，能解決什么問題，和現(xiàn)在的方式方法有什么區(qū)別，然后才能對(duì)癥下藥。
在敏捷開發(fā)中，已經(jīng)將整個(gè)軟件開發(fā)流程中的 需求->開發(fā)->測(cè)試三個(gè)環(huán)節(jié)囊括在內(nèi)，指導(dǎo)這三個(gè)階段的相關(guān)團(tuán)隊(duì)提升效率。
從上述的圖中看到，在整個(gè)軟件生命周期中的最后一個(gè)環(huán)節(jié)：部署沒有被囊括進(jìn)去，也就是你前面玩的再High，對(duì)于部署團(tuán)隊(duì)而言，輸出件都是不被信任的(指輸出質(zhì)量，不帶我玩，為啥要信你，你說啥就是啥？)。而DevOps就是想把最后這個(gè)環(huán)節(jié)也囊括到這個(gè)大循環(huán)中。
最終的目的是想讓在這個(gè)循環(huán)中的各個(gè)階段團(tuán)隊(duì)都對(duì)整個(gè)產(chǎn)品和整個(gè)交付過程負(fù)責(zé)，而不是只對(duì)某個(gè)階段負(fù)責(zé)。
回到文章的最開頭，DevOps的定義里提到用的是一系列的工程方法和工具來提高效率。也就是說，用工具使得這個(gè)循環(huán)能順利的轉(zhuǎn)起來，并且要自動(dòng)化的運(yùn)轉(zhuǎn)起來，在保證質(zhì)量的前提下再越轉(zhuǎn)越快。
三. DevOps的實(shí)踐方式
上面提到了當(dāng)前的幾個(gè)問題：
業(yè)務(wù)/代碼復(fù)雜度高，任何修改無法評(píng)估，失敗風(fēng)險(xiǎn)大。逐步退化成靠文檔去規(guī)范每個(gè)階段
環(huán)境多，需要大量的人力成本來維護(hù)
需求開發(fā)速度和穩(wěn)定性之間的矛盾
那么就考慮下DevOps提供了哪些方法和工具來解決這些問題，從網(wǎng)上盜了一張圖，是每個(gè)階段的工具集合(侵刪)
看完了簡(jiǎn)直是一腦殼包，所以要梳理下。
是否引入一個(gè)新的工具或者方法的時(shí)候，總要有一個(gè)判斷標(biāo)準(zhǔn)，根據(jù)數(shù)字化的標(biāo)準(zhǔn)去判斷是否由于當(dāng)前的方法和工具。對(duì)于研發(fā)效率這個(gè)方向而言，有下面幾個(gè)指標(biāo)可以參考：
部署頻率：指應(yīng)用和服務(wù)向生產(chǎn)環(huán)境部署代碼的頻率。
變更前置時(shí)間：指代碼從提交到成功運(yùn)行在生產(chǎn)環(huán)境的時(shí)長(zhǎng)。
服務(wù)恢復(fù)時(shí)間：指線上應(yīng)用和服務(wù)出現(xiàn)故障到恢復(fù)運(yùn)行的時(shí)長(zhǎng)。
變更失敗率：指應(yīng)用和服務(wù)在生產(chǎn)環(huán)境部署失敗或者部署后導(dǎo)致服務(wù)降級(jí)的比例。
或者說，我們就是要從這想辦法提高這幾個(gè)指標(biāo)。
或者從軟件工程的角度理解，我們可以把往DevOps演進(jìn)可以逐步分成下面幾個(gè)階段：
持續(xù)集成，代碼統(tǒng)一管理，持續(xù)構(gòu)建，開發(fā)持續(xù)輸出到測(cè)試。
持續(xù)發(fā)布，持續(xù)測(cè)試，完成到產(chǎn)品發(fā)布的持續(xù)輸出
持續(xù)部署/交付，完成產(chǎn)品到生產(chǎn)環(huán)境上的持續(xù)輸出
也就是說，我認(rèn)為提高效率的過程中(不管是不是DevOps)，都是可以針對(duì)性的去提高這幾個(gè)指標(biāo)，逐步的演進(jìn)到下一個(gè)階段。在這個(gè)過程中來針對(duì)性的選擇工具。使用工具就是想讓各個(gè)流程步驟自動(dòng)化，避免對(duì)人的依賴。
1. 開發(fā)自動(dòng)化，主要從配置管理，代碼托管(Git)，代碼評(píng)審(GitHub)，代碼靜態(tài)檢查(sonar)，單元測(cè)試(JUnit)，配合Jenkins工具來提高。
2. 測(cè)試自動(dòng)化，引入自動(dòng)化測(cè)試
3. 運(yùn)維自動(dòng)化，引入環(huán)境監(jiān)控(Portainer)，日志收集等工具
具體的工具介紹就不寫了，這個(gè)不是本篇文章的重點(diǎn)。策略就是發(fā)現(xiàn)瓶頸，解決瓶頸。發(fā)現(xiàn)人工部分，考慮工具來替代人工操作，不斷循環(huán)往復(fù)的過程。
實(shí)際上，這里必須擺脫“器”或者“術(shù)”的思路，而要采用“道”的思路：
不僅僅限于某種工具，再通過工具去解決某些問題。而應(yīng)該是反過來的，發(fā)現(xiàn)了什么問題，可以用什么樣的方法去解決這個(gè)瓶頸問題，再去找相關(guān)的工具。
解決問題不一定要采用某種流行的工具，不是他用了你就好用的，別人通過這個(gè)工具解決的問題，你不一定能通過這個(gè)工具解決問題，一定要從實(shí)際場(chǎng)景和應(yīng)用出發(fā)。舉個(gè)簡(jiǎn)單的例子，我們的一個(gè)產(chǎn)品想做日志收集，第一反應(yīng)就是使用ELK + ES的方案。調(diào)研之后發(fā)現(xiàn)ELK的資源占用比我們產(chǎn)品本身的資源占用還大，ELK + ES的集群設(shè)置比產(chǎn)品本身的設(shè)置還困難。如果這樣選型的話就是本末倒置了。而仔細(xì)分析之后我們僅僅是想將各個(gè)組件和服務(wù)之間產(chǎn)生的生產(chǎn)日志收集到一起而已，可能一個(gè)簡(jiǎn)單的SHELL腳本就可以收集了。
在這樣的一個(gè)思路的指導(dǎo)下，不是使用了DevOps這個(gè)鏈條上的工具就表示我們是一個(gè)DevOps實(shí)踐的團(tuán)隊(duì)了，而是團(tuán)隊(duì)在不停的解決瓶頸，不斷提高自動(dòng)化效率之后，促進(jìn)了研發(fā)效率，提高了人員合作效率，我就可以說團(tuán)隊(duì)已經(jīng)走在DevOps的康莊大道了。
四. DevOps是一種態(tài)度和文化
絕大多數(shù)提到DevOps的文章都會(huì)提到，DevOps包含了兩個(gè)部分，工具和文化。上面已經(jīng)針對(duì)工具做了一個(gè)簡(jiǎn)單的思考總結(jié)?，F(xiàn)在來談?wù)勎幕?/p>
本人在另外一篇文章 【管理】IT公司管理團(tuán)隊(duì)結(jié)構(gòu)思考 提到了：企業(yè)文化就是一群人的做事風(fēng)格，或者說是在做選擇題，做決策的一種指導(dǎo)思想。而DevOps就是想提供一種有效的選擇和指導(dǎo)思想。
統(tǒng)一目標(biāo)而不是分割目標(biāo)，DevOps的目的是想讓整個(gè)軟件開發(fā)生命周期中的所有環(huán)節(jié)都對(duì)結(jié)果負(fù)責(zé)，這里的結(jié)果是整體、業(yè)務(wù)或者商業(yè)上的結(jié)果，而不是割裂成若干個(gè)小環(huán)節(jié)的局部結(jié)果。而術(shù)業(yè)有專攻，每個(gè)階段肯定是由若干個(gè)專業(yè)團(tuán)隊(duì)負(fù)責(zé)的，在管理流程上很容易的將每個(gè)團(tuán)隊(duì)分開管理考核，很容易導(dǎo)致團(tuán)隊(duì)之間的對(duì)立。因此需要在管理流程上對(duì)這個(gè)目標(biāo)進(jìn)行合理的引導(dǎo)(制度上)，而不是去阻礙這種態(tài)度的形成。
預(yù)防大于治療，基于上面一點(diǎn)，負(fù)責(zé)每個(gè)階段的團(tuán)隊(duì)都需要多走出一步，向前一步，向后一步。這樣才能彌補(bǔ)每個(gè)環(huán)節(jié)之間的間隙。而不是等到上一個(gè)環(huán)節(jié)出了問題之后再去返回去修改，這時(shí)追責(zé)的意義實(shí)際上已經(jīng)不大。因此必須整個(gè)團(tuán)隊(duì)達(dá)成一致，是要主動(dòng)邁出一步，而不是事后追責(zé)。才能形成一個(gè)有效的循環(huán)。
擁抱變化，軟件開發(fā)是一個(gè)變化巨大的行業(yè)，需求、技術(shù)、甚至是人員本身都在快速的變化中，因此持續(xù)改進(jìn)是應(yīng)對(duì)變化的最有效的辦法?？焖侔l(fā)現(xiàn)問題，再快速解決問題。在團(tuán)隊(duì)統(tǒng)一目標(biāo)，每個(gè)環(huán)節(jié)伸出左右手拉住上下游，形成一個(gè)車輪迅速往前推進(jìn)。
另外，我想說下我理解的全棧工程師，不是一個(gè)人通吃整個(gè)開發(fā)的生命周期，當(dāng)然剛開始可能是需要有幾個(gè)一專多能的牛人構(gòu)建出產(chǎn)品的雛形。但是只有融合不同的專才的團(tuán)隊(duì)才能讓整個(gè)開發(fā)生命周期更長(zhǎng)久，更穩(wěn)定。而全棧指的是在目標(biāo)統(tǒng)一的前提下，利用全局的思路去指導(dǎo)每個(gè)環(huán)節(jié)的研發(fā)工作。
很多人討論是文化先行還是工具先行的問題，本人認(rèn)為這不是一個(gè)串行關(guān)系，工具是一個(gè)自底向上的過程，在持續(xù)改進(jìn)中積累。而文化需要一個(gè)自頂向下的過程，在演進(jìn)到某個(gè)階段，需要取得企業(yè)管理層的一致后，在公司導(dǎo)向，制度制定等方面向下推廣。兩個(gè)方向同時(shí)發(fā)展，才能取得比較好的效果。
最后，引用網(wǎng)絡(luò)上的一句話，文化 = 人 + 流程 來做一個(gè)小小的總結(jié)。
