理想化的DevOps团队里只需要有Dev就够了？
（圖片來源于網(wǎng)絡(luò)）
幾天前，本公眾號發(fā)布的一篇譯文列舉了9種DevOps團隊結(jié)構(gòu)適用類型與7種反型（點擊查看原文）。文章轉(zhuǎn)發(fā)到朋友圈之后，很多DevOps同行留言（吐槽）了自己團隊的現(xiàn)狀，其中大部分人都反饋自己的團隊命中了7種反型中的“DevOps作為工具團隊”這種結(jié)構(gòu)。
為什么會出現(xiàn)這種現(xiàn)象？DevOps團隊適合的結(jié)構(gòu)應(yīng)該是什么樣的呢？難不成，所謂的DevOps從業(yè)者都只是一個“工具管理員”？
針對這些疑問，我們在“DevOps案例深度研究討論群”組織了一場關(guān)于“DevOps團隊結(jié)構(gòu)”的群討論，集中探討以下2個問題：
1、為什么很多團隊DevOps會成為工具鏈、流水線？
2、DevOps團隊?wèi)?yīng)該長什么樣？
本文整理了這次討論的精華內(nèi)容，和大家分享。
話題一：為什么很多團隊DevOps會成為工具鏈、流水線？
針對這個問題，大家的普遍觀點是：DevOps本身的定義不清晰，但又需要有可衡量的標(biāo)準(zhǔn)和可執(zhí)行的動作，而工具鏈?zhǔn)强梢钥吹靡娒弥臇|西，簡單直接，執(zhí)行看得見，效果可衡量。
當(dāng)然，這也不能全怪DevOps本身，更多的問題還是出在了人身上。關(guān)于這一點，可以從執(zhí)行者和組織結(jié)構(gòu)2個方面來看。
執(zhí)行者層面，通常我們將知識劃分為道法術(shù)器四個層面，器就是工具，是最好入門的，就像我們?nèi)W(xué)java，會打出來一個hello world就算入門了。
歸根結(jié)底還是因為真正能踏踏實實鉆研技術(shù)的人少了，DevOps的概念出現(xiàn)以后，像是一根救命稻草一樣給大家營造了一個“理想國”，一窩蜂地?fù)渖先?#xff0c;但發(fā)現(xiàn)并不是那么回事兒，DevOps的落地同樣需要鉆研，需要踩坑，但打出來一個hello world容易，具備編程思維難，這時候怎么辦呢？
思維不夠工具湊唄，畢竟...我們最擅長的就是站在巨人的肩膀上睡大覺了，“拿來主義”思維驅(qū)使下，讓DevOps成為了工具鏈，做DevOps的人也就像是流水線的操作工一樣。
很多人認(rèn)為，有了工具就是CI/CD了，認(rèn)為有了武器就能打怪升級，但是卻忽略了心法和招式，其實武器只是對打怪效果的加成。
組織結(jié)構(gòu)方面，DevOps是一種敏捷化的團隊，打破了原本軟件研發(fā)團隊的分工模式，DevOps這個名字就是由開發(fā)和運維2部分組合起來的，好處在于方便了開發(fā)和測試的溝通，但事實上這只是小范圍的溝通便捷了，而并不代表2個團隊的溝通變得便捷了。
在執(zhí)行過程中，DevOps更像是一個創(chuàng)新小組，創(chuàng)新小組意味著在不停地嘗試和探索，而探索型的工作方式就需要組織，或者說老板，足夠的寬容和有耐心，但實際上，這是99%的組織都不具備的“實驗”精神。
再加上DevOps和老板之間的溝通障礙，很多時候老板/領(lǐng)導(dǎo)沒有理解DevOps要做什么，為啥這么做。
DevOps的實施除了需要老板的支持外，還需要有很好的基礎(chǔ)條件。但實際上呢，我們通常遇到的問題是微服務(wù)化不夠、基礎(chǔ)設(shè)施治理不靈活、單元測試不成熟、測試好做但測試數(shù)據(jù)不好解決等等問題。
在提出假設(shè)-實驗-反饋驗證-優(yōu)化假設(shè)這個不斷循環(huán)的實驗演進過程中，我們需要時間和資源，但跑下去就會發(fā)現(xiàn)，很多節(jié)點我們打不通。比如測試的問題，測試的時候需要準(zhǔn)備各種環(huán)境條件，逼著我們很多測試只能去預(yù)發(fā)布測試環(huán)境，但預(yù)發(fā)布環(huán)境和生產(chǎn)的數(shù)據(jù)是一致的，很多場景和數(shù)據(jù)是不能拿來做測試的。再加上復(fù)雜業(yè)務(wù)的應(yīng)用特別多，準(zhǔn)生產(chǎn)環(huán)境的維護本身就很困難，很難對齊到生產(chǎn)環(huán)境。
那么好了，測試數(shù)據(jù)搞不定，不能做驗收測試，再加上驗收的程度和范圍很難定義，這就導(dǎo)致測試很難推進下去，怎么辦？沒辦法，這個節(jié)點打不通，真正的DevOps就很難往下落。
面對著人、組織、資源協(xié)調(diào)等眾多問題，我們發(fā)現(xiàn)似乎只有持續(xù)集成持續(xù)發(fā)布還能做，為了更快的出成績，先跑起來再說。所以，DevOps的一種常見反型就是成為了工具鏈和流水線。
話題二：DevOps團隊?wèi)?yīng)該長什么樣？
上圖是一個標(biāo)準(zhǔn)的DevOps團隊結(jié)構(gòu)，這張圖中6種角色對應(yīng)的顏色如果結(jié)合六頂思考帽的不同顏色代表的含義來思考，也許更有意思：
白色思考帽：白色是中立而客觀的，戴上白色思考帽，人們思考的是關(guān)注客觀的事實和數(shù)據(jù)；
綠色思考帽：綠色代表茵茵芳草，象征勃勃生機，綠色思考帽寓意創(chuàng)造力和想象力，具有創(chuàng)造性思考、頭腦風(fēng)暴、求異思維等功能；
黃色思考帽：黃色代表價值與肯定，戴上黃色思考帽，人們從正面考慮問題，表達(dá)樂觀的、滿懷希望的、建設(shè)性的觀點；
黑色思考帽：戴上黑色思考帽，人們可以運用否定、懷疑、質(zhì)疑的看法，合乎邏輯的進行批判，盡情發(fā)表負(fù)面的意見，找出邏輯上的錯誤；
紅色思考帽：紅色是情感的色彩，戴上紅色思考帽，人們可以表現(xiàn)自己的情緒，人們還可以表達(dá)直覺、感受、預(yù)感等方面的看法。
藍(lán)色思考帽：藍(lán)色思考帽負(fù)責(zé)控制和調(diào)節(jié)思維過程，負(fù)責(zé)控制各種思考帽的使用順序，規(guī)劃和管理整個思考過程，并負(fù)責(zé)做出結(jié)論。
這張圖中的6個人構(gòu)成了DevOps團隊的標(biāo)準(zhǔn)結(jié)構(gòu)，我們不妨大膽地思考一下：如果老板要裁員，這6個人中，你覺得要先裁掉哪一個？
也就是說，流程主管、服務(wù)主管、運維團隊、開發(fā)團隊、DevOps工程師、把關(guān)人，要先干掉哪個？
在這個問題上，大家出現(xiàn)了幾種觀點：
觀點一：砍掉運維團隊和把關(guān)人，通過工具鏈固化流程，團隊一起制定驗收標(biāo)準(zhǔn)，將驗收標(biāo)準(zhǔn)工具化。
觀點二：DevOps其實應(yīng)該是DevOpsiblity，是所有參與生產(chǎn)經(jīng)營的人都要具備的能力和思維，從CEO到掃地阿姨都應(yīng)該有，如果能做到這一點，都不需要組織結(jié)構(gòu)了，大家的角色可以互換。當(dāng)然，這只是一種烏托邦的美好世界。
觀點三：觀點二是不可能實現(xiàn)的，但我一直堅信Dev可以搞定一切，Ops不應(yīng)該存在，或者說，除了Dev之外的角色都是浪費。接下來就是對人的培養(yǎng)的問題，只要組織允許，讓一個人做過Dev，也做Ops，那么就會成為既懂運維又懂開發(fā)的DevOps人才。
觀點四：DevOps是開發(fā)+運維，其實并不需要開發(fā)和運維團隊，服務(wù)直接接口把運維給頂替了，或者運維兼職服務(wù)的事情，開發(fā)幫運維分擔(dān)一些工作就好了。
關(guān)于這個問題，其實并沒有直接的結(jié)論，DevOps的團隊結(jié)構(gòu)并沒有統(tǒng)一的標(biāo)準(zhǔn)，一切以解決生產(chǎn)經(jīng)營問題為核心。
無論是DevOps，精益還是敏捷，都是為了解決生產(chǎn)經(jīng)營問題，但是有句話說得非常好，管理水平永遠(yuǎn)不能超越經(jīng)營現(xiàn)狀，從方法去推標(biāo)準(zhǔn)，實際上是為自己開脫，為自己的懶惰找借口。
生產(chǎn)經(jīng)營的問題是在不斷變化的，因為市場在變，技術(shù)在變，解決問題的手段在變，我們可以結(jié)合現(xiàn)狀制定出解決當(dāng)下問題的標(biāo)準(zhǔn)，自上而下地通過標(biāo)準(zhǔn)讓組織更高效，但這個標(biāo)準(zhǔn)并不能是一成不變的，有可能明天就會被推翻。
以豐田為代表的日本車企，把大部分精力放在了精細(xì)化管理和持續(xù)改進上，到現(xiàn)在用的還是60-70年代的技術(shù)。而美國的車企則把太多的精力放在踐行MBA的管理理論上，能外包的都外包了，同樣失去了創(chuàng)新能力。
這就構(gòu)成了日本經(jīng)濟社會的現(xiàn)狀，也造成了美國的經(jīng)濟現(xiàn)狀，我們所學(xué)習(xí)的這些管理理論是不是真的好，真的適合自己，還是要看是不是能解決具體問題，借鑒可以，照搬不行。
學(xué)習(xí)和借鑒是一個守、破、離的過程，先固化，再優(yōu)化，再升華。從實踐的角度，以及從企業(yè)的角度看，創(chuàng)造價值解決問題才是關(guān)鍵。
冒昧地拋出一個觀點：每一套成功的敏捷、DevOps體系，都是具有自己特色的，甚至是唯一的。
總結(jié)
消滅分工是技術(shù)進步的結(jié)果，理想的DevOps團隊里只有Dev 做軟件。
值得注意的是：Developer（Dev）這個詞被大家誤解和狹義化了。Developer的原意指的是把東西“做”出來的人，而不是僅僅指編碼開發(fā)。從這個角度理解，Dev需要從策劃到設(shè)計，從編碼到測試，從部署到運營等所有把東西做出來必須的能力。而且，在技術(shù)快速發(fā)展前提下，一個人具備所有能力的可能性越來越高，需要通過分工完成一件事情的必須性越來越低，這其實是整個人類技術(shù)發(fā)展的終極追求。因此除非分工角色中還有無法被技術(shù)進步取代的獨特價值，不然早晚會替代，最終被個體能力吸納。這個過程中會有很多類似那個沒飯吃的高速公路收銀員的人的抱怨，但是無論怎樣都阻擋不了技術(shù)的發(fā)展對個體的賦能，以及對拒絕學(xué)習(xí)者的拋棄！DevOps僅僅是這個發(fā)展過程的一個表象而已，因此我們也可以想象，給DevOps訂立一個標(biāo)準(zhǔn)是多么的可笑！
一個真正的DevOps團隊，就一定是以Dev為中心的，我們一直在說DevOps要敏捷要敏捷，敏捷是一種讓團隊協(xié)作變得更高效的手段，而最高效的，是一個人的獨立思考和執(zhí)行，也就是所謂的“full stack”全棧。
所以說，全棧開發(fā)者是理想化的DevOps。全棧難嗎？其實不難，而是大多數(shù)組織都被傳統(tǒng)管理思路束縛了，總覺得分工才是組織提高效率的唯一辦法，管理才是組織高效的核心能力。
其實都錯了，提高效率最好的方法就是每個細(xì)胞都可以有自主活動的能力，高效的最簡單辦法就是給每個人的電腦加16G內(nèi)存。
分工是社會化進步的結(jié)果，消滅分工是技術(shù)進步的結(jié)果。
當(dāng)工作需要精細(xì)化的時候，就不得不進行分工；而當(dāng)技術(shù)進步，對技術(shù)細(xì)節(jié)進行了很好的封裝以后，曾經(jīng)的一部分分工就被融合了。
現(xiàn)在Google/Facebook/微軟等公司的測試工程師幾乎被取消，并不是說不需要測試了，而是測試的能力已經(jīng)融入到所有工程師身上。
當(dāng)然，這并不是說Google/Facebook/微軟等公司完全沒有測試工程師了，只不過，測試不再追著開發(fā)跑，不再是開發(fā)的背鍋俠，而是更加專注的去做一些探索性測試、測試鏈路設(shè)計、端到端測試等相關(guān)工作。
所以，如果DevOps團隊需要裁員的話，保留Dev就夠了，Dev是最基礎(chǔ)，也是最核心的部分，這就像當(dāng)測試進入了自動化測試時代，技術(shù)細(xì)節(jié)封裝好了，剩下的就交給開發(fā)做就好了。
當(dāng)然，DevOps團隊里只需要保留Dev這一個角色，是一種理想化的狀態(tài)，這需要開發(fā)人員的自我進化，以及像數(shù)據(jù)等各種基礎(chǔ)條件的完備。想要通過工具和技術(shù)完全替代于人，還需要出現(xiàn)革命性的工具或者技術(shù)。
如果一個崗位徹底被替代肯定需要大量的實踐驗證，而且對替代者的要求也更高，但在DevOps這樣一組開發(fā)+測試的組合中，現(xiàn)在實際情況就是開發(fā)來完成一部分測試的工作，比如自動化測試，這樣測試人員會越來越少，但是對測試要求也會越來越高，我倒覺得測試和開發(fā)之間分工的差別會越來越大。
一個崗位對另一個崗位追殺的結(jié)果，就是被追殺崗位逐漸變得更加差異化，做更多讓別人無法替代的事情，所謂適者生存嘛。
（以上內(nèi)容來自“DevOps案例深度研究討論群”的討論，感謝各位群成員的分享。如果對文章內(nèi)容有不同意見和觀點歡迎在評論區(qū)留言）
DevOps黑客馬拉松?
9月7-8日 北京
專業(yè)大咖陪你一起進化
歡迎企業(yè)組隊PK，企業(yè)團隊報名有特惠
目前已經(jīng)有兩家企業(yè)組隊！！
趕緊報名吧~??????
總結(jié)
以上是生活随笔為你收集整理的理想化的DevOps团队里只需要有Dev就够了？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： EZNEW.NET开发框架100%重磅开
- 下一篇： 架构杂谈《七》