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