我們一直說DevOps是“誰開發(fā)誰運維、開發(fā)運維一體化”，但具體怎么做并沒有幾個人說的清楚的。特別是“誰開發(fā)誰運維”，這明顯是不符合實際情況的。試想一下，一個開發(fā)人員開發(fā)的應用服務都由他自己來運維，他能運維幾個應用服務？然后又有多少時間能繼續(xù)做開發(fā)？到最后豈不是所有開發(fā)人員都成了運維人員。有點極端，但是也正說明了我們對DevOps的認識存在很大的誤解。
DevOps提倡“開發(fā)運維一體化”，但不是“誰開發(fā)誰運維”。但怎么開發(fā)運維一體化往往也都沒有說清楚，也沒有很好的實踐案例。Google SRE更多的其實是運維階段的工作，雖然Google SRE很多工作是運維工具和運維服務的開發(fā)工作，但其本質(zhì)上是做運維。但是它給我們的一個很好的啟示是，把“運維開發(fā)”和“運維維護”一體化了，也就是運維人員不再是簡單的系統(tǒng)管理和維護，而是通過運維工具的研發(fā)，使運維流程自動化和智能化，將一些日常重復性的運維工作通過自研工具自動化和智能化了，這就大大減輕了運維人員的維護工作量，提升了運維效率。這些工作不再靠“研發(fā)人員”，而是“運維自身”的能力來實現(xiàn)的。
DevOps開發(fā)運維一體化并不是讓開發(fā)去做運維，而是使開發(fā)和運維通過一些機制有機結(jié)合、高效統(tǒng)一，成為一個整體，從而消除開發(fā)團隊和運維團隊之間的gap，有效提升應用服務的研發(fā)和運維運營效率。
那么通過什么樣的機制，如何來消除開發(fā)和運維之間的利益沖突，如何提升效率是我們在實施DevOps之前或者實施過程中需要認真思考的問題。
Google SRE實踐給我們了很好的運維階段的DevOps實施啟示。運維還是需要專職做運維，而且比傳統(tǒng)運維做的更多。運維人員需要對自己運維的環(huán)境、工具、流程、資源等有深入的理解和認識，能獨立開發(fā)運維工具，獨立實現(xiàn)運維的自動化、智能化、高可用、穩(wěn)定性、安全性等要求。支撐應用的運維和運營。這就使運維成為了一個有機的小閉環(huán)，包括了運維工具、流程等的需求、設(shè)計、開發(fā)、測試、部署、運營、反饋、改進等完整生命周期過程。這和業(yè)務應用的開發(fā)和運維運營是不同層次的。SRE的工作在提升運維效率的同時也很好的支撐了業(yè)務應用的運維運營效率。
SRE側(cè)重于DevOps的Ops運維階段。DevOps的Dev開發(fā)階段包括需求、設(shè)計、編碼、測試、部署等過程。開發(fā)階段則強調(diào)持續(xù)開發(fā)、持續(xù)部署或持續(xù)開發(fā)、持續(xù)交付，強調(diào)敏捷開發(fā)。目的還在于提高效率。環(huán)境的敏捷準備、環(huán)境的一致性是Dev階段高效的重要基礎(chǔ)。
傳統(tǒng)開發(fā)、測試、UAT等環(huán)境都是由開發(fā)人員自己來維護。這也導致了往往和生產(chǎn)環(huán)境不一致，所以在生產(chǎn)部署時可能會存在很多意向不到的問題。因此在DevOps實踐中，環(huán)境的運維一定要交由運維人員統(tǒng)一來維護，開發(fā)人員只是使用環(huán)境而不運維環(huán)境。
誰有權(quán)限使用環(huán)境誰沒有權(quán)限使用環(huán)境這又涉及到了DevOps中的統(tǒng)一權(quán)限管理和統(tǒng)一認證管理部分。統(tǒng)一權(quán)限和認證管理可以作為企業(yè)的技術(shù)中臺服務由技術(shù)中臺運維團隊來統(tǒng)一運維運營。為企業(yè)內(nèi)外用戶提供認證和權(quán)限服務。各個環(huán)境使用技術(shù)中臺的統(tǒng)一認證權(quán)限平臺的服務來完成認證和權(quán)限管控，也避免了重復的投入和建設(shè)。開發(fā)人員只需要用自己的賬號隨時登錄不同的環(huán)境來完成自己的工作。這其實就是PaaS的理念。當然，你也可以在企業(yè)內(nèi)部實現(xiàn)單點登錄，一次登錄，可以在擁有權(quán)限的不同環(huán)境之間切換來完成工作。這些是DevOps的基礎(chǔ)工作。看似沒有關(guān)系，卻帶來完全不同的效果。
環(huán)境一致性可以簡單的通過容器化來實現(xiàn)。但容器環(huán)境只能達到相對一致性，并不能實現(xiàn)完全一致性。容器運行在不同配置的宿主機或虛擬化節(jié)點上，都會帶來一定的差異。所以你也可能經(jīng)常會遇到在某個節(jié)點性能很高，而某個時刻遷移到另外一個節(jié)點性能卻不如預期。
環(huán)境的敏捷準備則是一個相對不容易的工作。傳統(tǒng)研發(fā)過程中通常很多時間都是花在環(huán)境準備上。不管是否采用容器化，這塊的效率都是需要考慮提升的。在開發(fā)階段涉及的流程和工作也比較多。比如開發(fā)環(huán)境準備、測試環(huán)境的準備、測試數(shù)據(jù)的準備、測試用例的自動構(gòu)建、測試缺陷的自動記錄等。而且這部分工作可以通過相應的工具實現(xiàn)敏捷能力，盡可能使工具和流程標準化，這樣就可以實現(xiàn)自動化，就能更快的提升效率。
而軟件編碼的標準化程度也相對就比較低，往往依賴于開發(fā)人員的個人能力和態(tài)度。軟件研發(fā)其實質(zhì)是智力投資，不同的人帶來的效果完全是不一樣的。所以很多想以外包的方式實現(xiàn)自有軟件的自主可控基本上是不現(xiàn)實的。
開發(fā)階段最終需要交付標準化交付件，不管是容器鏡像、或是jar、war、exe文件等，這些文件需要統(tǒng)一管理起來，鏡像可以用鏡像倉庫，jar等可以通過配置管理工具等統(tǒng)一來管理，而部署則可以實現(xiàn)自動化，不管使用自動化腳本或者自動化工具，以減少部署問題和提升效率，支持持續(xù)部署的能力。
我們在《容器云平臺運維架構(gòu)設(shè)計》也清楚地解釋了開發(fā)和運維之間的標準化交付環(huán)節(jié)。這是減少開發(fā)和運維之間溝通成本和提升效率的重要機制。如果使用容器，鏡像和鏡像倉庫將充當這樣的一個標準化交付件和標準化交付管理媒介。它可以很好的劃分和有效連接開發(fā)、測試、UAT、生產(chǎn)運維等應用生命周期階段。
另外我們知道DevOps很重要的是要形成閉環(huán)。運維運營對開發(fā)的反饋是非常重要的，不僅僅是bug和缺陷的反饋修復，包括用戶體驗等都是很重要的內(nèi)容。這就需要合理合適的反饋機制和流程。既包括技術(shù)的，也包括非技術(shù)的因素。
所以橫向上我們可以簡單的看作是開發(fā)、標準化交付和運維的劃分，標準化交付就像是人的關(guān)節(jié)，起到潤滑和彈性伸張的作用，使開發(fā)和運維成為一體并充分發(fā)揮各自的專業(yè)優(yōu)勢。而縱向上，可以通過分層來實現(xiàn)高度專業(yè)化運維。最下層是基礎(chǔ)設(shè)施資源的運維，之上是平臺、工具、環(huán)境的運維，在這些平臺、工具、環(huán)境之上是業(yè)務應用的運維。所有這些工作都是為了保證業(yè)務運營的可用與安全。通過業(yè)務運營才能有收益、有利潤。
從應用整個生命周期管理過程看，80%的基本工作可能是在運維階段，運維的事項也比較多，從效率上講，使各運維事項專業(yè)化、自動化甚至智能化則容易提升效率。開發(fā)運維一體化重點在于提升運維的效率，包括應用、環(huán)境、平臺、工具、基礎(chǔ)設(shè)施資源等。有高效、高可用的運維環(huán)節(jié)能力，則能保證業(yè)務應用的高可用與穩(wěn)定性，也就是Google SRE的Site Reliabilities。而對于應用開發(fā)人員，即便是出現(xiàn)意外情況，運維也有應對措施，開發(fā)人員則有充足的時間進行細致的設(shè)計和問題處理，追求更穩(wěn)定、可靠、高效的能力，從而使運維更容易和便利。
開發(fā)運維一體化追求開發(fā)和運維的利益一致，而不是一個人既做開發(fā)也做運維。這需要通過一定的機制和借助相應的工具等來保證，使開發(fā)和運維之間能夠有活動關(guān)節(jié)、有潤滑劑。這應該是我們在構(gòu)建DevOps的時候需要認真考慮實現(xiàn)的核心內(nèi)容。
