?前言

要基于 DevOps 構建 DevOps 平臺體系，需要深入理解 DevOps 的目標，厘清 DevOps 體系中的能力和職責，設計適合自身實際情況的 DevOps 組織，這樣才能讓生產關系適應新的生產力的要求，促進企業生產效率的提升。

開發最終依賴于運維團隊的敏捷響應能力。如果運維做不到敏捷，開發的敏捷對整個應用生命周期來說，價值就沒那么大。而運維通常追求的是穩定，能不變更就不變更，因為每次的改變都面臨著不確定性，面臨著意外異常，影響著績效、評價和客戶滿意度。因此需要通過合理的組織和職責設計來平衡運維和研發的利益訴求，通過自動化的工具和自服務在保障業務穩定性的同時來提升運維的敏捷性，以匹配研發的敏捷響應需求。

理解 DevOps 的目標

DevOps 是一種思想、理念和方法論，以其來構建的工具、平臺、組織、應用系統等都是這個 DevOps 體系的一部分。DevOps 的目標是平衡開發效率和穩定運維之間的利益分歧。既要追求研發的敏捷變更和交付，也要保障運行環境和業務應用的穩定與可靠。因此筆者在最早建設容器云平臺的時候，就強調 “ 以應用管理為核心 ” 實現業務應用運行支撐環境的穩定和可靠。只有這樣，才能實現研發的敏捷，保障運維的可靠。Google SRE 為什么強調站點可靠性？而國內大多數所謂的 DevOps 平臺只考慮交付流水線、以及指標管控等研發過程，實和 DevOps 的目標有些背離。無論研發多么敏捷，如果運維做不到敏捷和穩定，一切都是徒勞的。

如何實現敏捷研發和穩定運行

研發追求的敏捷交付和運維追求的穩定運行之間是存在一定矛盾的。軟件的質量往往取決于研發人員的個人素質，不過人的思維總是有局限的，所以軟件總會有缺陷的。不是說敏捷交付一定會帶來缺陷，但卻無法保證不帶來缺陷。在應用開發和運維由不同的團隊人員來負責的時候，環境的每次變動都可能帶來意外和異常，因此，對運維人員來說，不變動才是最佳的選擇。人都有本能的避重就輕逃避傾向，這也是很多公司業務上線流程很復雜的原因之一。只有理順了彼此的關系，解決了矛盾，才能實現敏捷研發和業務的穩定運行。如同 Google SRE 一樣，可以在業務應用穩定運行之前由開發來維護和運維， SRE 只提供環境和工具支撐，這樣開發導致的變更異常由開發負責。業務穩定運行之后交給運維來負責日常的維護。

研發的敏捷依賴于運維的敏捷響應

準確的說，研發的敏捷依賴于運維的敏捷響應。如果運維設置很多的流程和步驟，研發再怎么敏捷也沒有意義。運維不只是應用運維，還有基礎設施資源、安全、網絡等，任何一個地方有阻礙，都會帶來瓶頸和阻礙。比如說，應用的部署運行需要服務器、需要開通防火墻、需要配置 IP 地址、需要上線申請等，如果有一堆的流程需要申請審批，這個時間可能就需要好幾天。在這幾天里，研發可能已經迭代發布好幾個版本了，但是發布再多的版本也無法及時更新上線，就是因為運維做不到敏捷響應。因此， DevOps 建設的關鍵是首先確保穩定的情況下實現運維的敏捷。這就需要消除團隊之間協作的繁瑣流程，合理設置 DevOps 團隊，使運維支撐團隊通過自服務能力來賦能上層團隊，實現秒級或分鐘級的響應能力。比如申請虛擬機，可能會涉及網絡域、 IP 、網段、防火墻端口等，如果能實現自服務化，幾分鐘就可以完成虛擬機的申請、創建、配置和交付，會極大的提升效率。再者比如說應用的部署運維，通過容器化 PaaS 平臺，自動調度匹配資源、自動彈性伸縮、自動故障恢復，用戶無需關注服務運行在哪里，無需運維管理服務器，通過 PaaS 平臺的可觀測能力可以隨時掌握應用的運行狀況，通過 PaaS 平臺的可管理能力隨時進行應用的變更和配置調整。這就極大的提升了應用的敏捷性。

實現敏捷自服務，減少團隊之間的交互

要實現敏捷，重要的一點是往往需要考慮團隊之間的低交互。這就是為什么敏捷研發團隊總是強調幾人小團隊的原因。DevOps 體系中涉及各個團隊和眾多系統和工具，總的團隊規模是無法縮減的，那么要實現敏捷，減少團隊之間的交互，就需要實現自服務的能力，賦能上層團隊，使其實現自助（向上賦能）。在 DevOps 體系建設中，運維需要根據運維的職能職責進行分層，比如基礎設施資源運維、平臺工具運維、應用運維、業務運營等。基礎設施資源運維為平臺工具運維提供自服務的資源申請、擴容、維護能力；平臺工具運維為應用運維提供資源服務、平臺工具服務能力，比如通過容器云 PaaS 提供應用的托管、部署、運維自服務能力；而應用運維為業務運營團隊提供應用服務，業務團隊可以使用這些應用系統服務終端客戶。

DevOps 體系職責設計

理解了 DevOps 的目標，來規劃設計 DevOps 體系職責，作為劃分定義 DevOps 組織的基礎和參考。以標準化交付來銜接開發和運維，便于實現自動化的 CI 、 CD 流程；以基礎設施資源、平臺工具、應用運維需求進行分層，實現自服務，向上賦能；用 DevOps 全局、頂層視角來規劃應用、工具、平臺、資源、團隊、架構等才能真正體現其價值。這有點類似于 PMO 的職責。

標準化交付、研發和運維自動化

DevOps 最重要的就是協調研發和運維的關系，滿足彼此的訴求。通過標準化交付（比如鏡像），實現研發和部署流程的自動化，無需開發和運維之間的溝通和交互。應用研發和應用運維可以是一個團隊來完成，也可以是兩個獨立團隊，共同完成應用生命周期管理過程。在這個過程中需要眾多的工具和自動化能力的支撐，比如說異常、 bug 的反饋與修復等，使之成為一個應用生命周期管理閉環。

自服務賦能，分層實現向上支撐

在 DevOps 設計時，筆者一直強調分層，很重要的就是通過分層來厘清職責，實現自服務，向上賦能。這也是 DevOps 設計的重要參考。比如說筆者一直強調通過多云管理平臺管理各種基礎設施資源，給容器云平臺提供各種資源服務、支持彈性伸縮、按需調度。傳統運維幾乎從服務器資源、網絡存儲配置、環境、數據庫中間件、應用服務等什么都負責，是一種豎井的管理方式，難以實現敏捷的彈性和快速響應，也帶來很多的冗余和浪費。通過分層自服務，封裝了底層細節，實現共享和復用，也帶來了效率。

全局架構、應用、服務規劃團隊

在設計 DevOps 組織時，筆者覺得最重要的一個團隊是全局的規劃團隊。不止要做架構規劃，也要考慮項目、應用、服務等規劃，厘清項目之間的聯系和關系，定義項目依賴性和優先級，明確團隊之間的職責界線和需要提供的服務能力，構建企業可復用中臺服務，提升復用效率。SRE 側重于運維端的穩定性，沒有從全局進行考量，不過做為初始的 DevOps 組織設計也無不可。但如果要真正理順 DevOps 體系之間的關系，還是需要一個中心化的頂層設計團隊來進行規劃設計。

DevOps 組織設計

按照前面的討論， DevOps 組織可以從服務層次上進行設計劃分，比如基礎設置資源運維團隊、平臺環境運維團隊、應用生命周期管理團隊（可再分應用研發、應用測試、應用運維團隊等）及業務運營團隊（業務團隊）。

基礎設施資源運維團隊

基礎設施資源運維團隊主要職責是保障服務器、虛擬機、網絡、存儲等資源的穩定運行和供給。可以通過統一的資源管理平臺或多云管理平臺來為上層平臺、中間件工具等提供資源服務。比如說虛擬機服務、 GPU 服務、網絡 IP 服務、網段服務、 NAS 存儲服務、對象存儲服務等等。這些資源需要構建為可復用的資源池，按需使用，其實就是云計算的思想。至于和傳統網絡域劃分沖突的問題，可以考慮通過能力封裝來解決，對上層透明。

平臺、工具、環境運維團隊

平臺主要是指應用運行支撐平臺比如容器云平臺、容器化 PaaS 平臺等；工具指 Kafka 、 ES 、 Redis 、 MySQL 等中間件；環境等基于這些平臺工具所構建的開發、測試、生產等環境。這些都是由運維團隊來進行管理和維護。為應用研發團隊提供平臺服務、工具服務和環境服務。這些服務能力其實也就是企業要構建的中臺服務能力，各個業務所復用和共享的。由于各種工具平臺很多，每個工具平臺都可能需要相應的運維人員來負責，所以平臺工具及環境運維團隊可能需要根據實際情況來進行設置，可以分成幾個小的團隊，也可以作為一個大的團隊，比如基于容器云平臺的監控、日志、認證、權限、消息、緩存、安全等形成一個統一的平臺服務團隊。

應用運維、測試、開發團隊

應用生命周期過程中涉及開發、測試、運維等職責。DevOps 提倡開發運維一體化（并不是既做開發又做運維），將開發運維作為一個整體來考慮，實現應用生命周期的平滑閉環：持續集成、持續部署、持續交付、持續監控、持續反饋。這個生命周期過程需要應用運行平臺、中間件工具、運行環境等的支撐。應用研發、測試和運維不需要去關心基礎設施資源、平臺、工具、環境搭建，只是使用，類似于 SaaS 服務，這樣就會簡單很多。SRE 在應用穩定運行之后會接手運維，讓研發人員有更多的時間去做業務研發，這很好的解決了研發人員關鍵能力釋放的問題。研發可能不止一個團隊，可能有很多業務研發團隊，但運維可以不必那么多。研發和運維團隊總體上來說還是可以職責分開的。

業務運營團隊

業務運營團隊也就是業務團隊，使用運行中的業務應用系統服務終端客戶。在使用過程遇到問題能夠便利的反饋到應用研發團隊，及時改進變更，形成閉環，不斷提升客戶體驗和客戶滿意度。

總的來說， DevOps 組織設計需要深入理解 DevOps 建設的目的和目標，合適和設置 DevOps 組織職責，指導 DevOps 組織設計。通過分層賦能，明確層次職責劃分，減少部門和團隊之間的交互，形成交付與使用反饋、評價閉環，整個公司的 DevOps 組織架構就相對很清晰。各個團隊以滿足其上層團隊需求為己任，提供自服務的能力。基于使用反饋和評價，促進工具和能力的持續改進，從而提升效率，實現運維的敏捷響應，以匹配研發的敏捷。

汪照輝，中國銀河證券架構師，專注于容器云、微服務、DevOps、數據治理、數字化轉型等領域，對相關技術有獨特的理解和見解。擅長于軟件規劃和設計，提出的“平臺融合”的觀點越來越得到認同和事實證明。發表了眾多技術文章探討容器平臺建設、微服務技術、DevOps、數字化轉型、數據治理、中臺建設等內容，受到了廣泛關注和肯定。