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