?前言

要基于 DevOps 構(gòu)建 DevOps 平臺體系，需要深入理解 DevOps 的目標，厘清 DevOps 體系中的能力和職責(zé)，設(shè)計適合自身實際情況的 DevOps 組織，這樣才能讓生產(chǎn)關(guān)系適應(yīng)新的生產(chǎn)力的要求，促進企業(yè)生產(chǎn)效率的提升。

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

理解 DevOps 的目標

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

如何實現(xiàn)敏捷研發(fā)和穩(wěn)定運行

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

研發(fā)的敏捷依賴于運維的敏捷響應(yīng)

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

實現(xiàn)敏捷自服務(wù)，減少團隊之間的交互

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

DevOps 體系職責(zé)設(shè)計

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

標準化交付、研發(fā)和運維自動化

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

自服務(wù)賦能，分層實現(xiàn)向上支撐

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

全局架構(gòu)、應(yīng)用、服務(wù)規(guī)劃團隊

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

DevOps 組織設(shè)計

按照前面的討論， DevOps 組織可以從服務(wù)層次上進行設(shè)計劃分，比如基礎(chǔ)設(shè)置資源運維團隊、平臺環(huán)境運維團隊、應(yīng)用生命周期管理團隊（可再分應(yīng)用研發(fā)、應(yīng)用測試、應(yīng)用運維團隊等）及業(yè)務(wù)運營團隊（業(yè)務(wù)團隊）。

基礎(chǔ)設(shè)施資源運維團隊

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

平臺、工具、環(huán)境運維團隊

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

應(yīng)用運維、測試、開發(fā)團隊

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

業(yè)務(wù)運營團隊

業(yè)務(wù)運營團隊也就是業(yè)務(wù)團隊，使用運行中的業(yè)務(wù)應(yīng)用系統(tǒng)服務(wù)終端客戶。在使用過程遇到問題能夠便利的反饋到應(yīng)用研發(fā)團隊，及時改進變更，形成閉環(huán)，不斷提升客戶體驗和客戶滿意度。

總的來說， DevOps 組織設(shè)計需要深入理解 DevOps 建設(shè)的目的和目標，合適和設(shè)置 DevOps 組織職責(zé)，指導(dǎo) DevOps 組織設(shè)計。通過分層賦能，明確層次職責(zé)劃分，減少部門和團隊之間的交互，形成交付與使用反饋、評價閉環(huán)，整個公司的 DevOps 組織架構(gòu)就相對很清晰。各個團隊以滿足其上層團隊需求為己任，提供自服務(wù)的能力?；谑褂梅答伜驮u價，促進工具和能力的持續(xù)改進，從而提升效率，實現(xiàn)運維的敏捷響應(yīng)，以匹配研發(fā)的敏捷。

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