[持續交付實踐] 研發協做平臺：DevOps背景下的組織結構

前言

今年以來作的事情愈來愈雜，負責的技術方向愈來愈廣，精力愈來愈分散（創業公司的典型特色），編碼的時間愈來愈少，有時候也會以爲很疲憊沒辦法專一一個事情。

除了技術方向上的實踐，組織上如何組建一個最優的DevOps團隊形式，實際工做中也面臨着大量的挑戰和困惑，抽點時間總結一些不太成熟的實踐。

雖然下面不少的內容與測試開發已經無關了，但對這個論壇仍是比較有感情的，過往的系列文章也都在這裏，因此仍是在這裏發下分享給正走在這條路上的朋友。

DevOps對傳統職能部門的挑戰

對於傳統技術組織架構，團隊一般是按照技能劃分，除了業務開發部門，一般還會有測試部、運維部、安所有，項目管理部等技術支撐部門，你們按照職責各行其是搭建各自的工具平臺，並經過項目的方式協做，完成系統的交付。

互聯網時代，DevOps和敏捷文化已經深刻人心，DevOps文化提倡打破原有職能組織的限制，每一個職能團隊都開始擁抱和接受DevOps高度協同，研發和交付一體化的思惟，同時也看到各個團隊都正面臨着轉型、痛苦和挑戰。

運維團隊，大概10年前個人一個老大曾經問我一個問題：若是一個公司快倒閉了，最後一個失業的崗位會是誰？他給的答案是運維，由於一個公司只要存在一天就須要有運維去確保機器運行正常。這個答案看似正確，然而在公有云的大潮下，一切都被衝擊的支離破碎，傳統運維工程師的需求大量減小開始面臨着崗位危機，運維開發團隊開發的傳統的資產管理、運維監控等系統在公有云上都已經有成熟的產品。流程導向的ITIL運維管理體系已通過時，優秀的運維開發工程師開始轉向技術導向的DevOps平臺建設，研究和開發docker容器、自動化運維、智能運維等技術，順利的完成了自身技能和職能的轉變。可能的問題是因爲長期工做在交付末端，不少人會面臨着對軟件研發工程理解不足的問題。

測試團隊，測試工做貼近業務，業務千差萬別，測試自動化相比運維自動化難度天然要大不少，再加上高技能測試開發人員的匱乏，大多數公司的自動化測試並無發揮太大的效力，國內手工業務測試人員崗位彷佛也並無減小的趨勢。但在一些國內外的大公司，業務測試人員其實一直是在收縮，大量的測試工做轉交給了開發工程師執行，有理想的測試開發工程們都開始融入到DevOps、CI/CD的大潮中，測試人員對研發過程的痛點理解是最透徹的，而測試自動化在DevOps裏也是很是關鍵的環節，這裏仍保留了大量須要研究探索並使其流水線化的領域，因此會是一個良好的轉型方向，固然前提是須要具有較好的開發能力。測試團隊過於龐大後，若是缺乏核心的競爭力，每每就會被拆散到各個業務線與業務線深度結合，潛臺詞就是不太會有大質量團隊了，測試總監的崗位或許也不復存在。

安全團隊，這幾年的新起之秀，得益於國家監管部門對網絡安全的關注以及《網絡安全法》的實施，互聯網時代數據安全的重要性開始超越業務質量和穩定性，各個公司都能看到正在組建獨立的信息安全團隊，裏面的職責也再也不僅限於安全漏洞的測試挖掘，還包括安全合規，安全風控，安全攻防，安全審計，安全管理等等，貫穿研發業務管理各個環節，正在造成一個獨立穩定的基礎設施團隊。信息安全團隊風光的背後，咱們常常也會聽到之前在傳統測試團隊常常聽到的質疑，「安全滲透測試主要都依靠手動挖掘，如何提高安全團隊的測試效能？」、「安全漏洞問題，都是安全團隊的責任嗎，直接負責編碼的工程師沒有責任？」，他們一般與DevOps團隊脫節，安全從業者也一直在反思並嘗試將自動化的安全檢測，自動化的安全代碼檢查融入到DevOps的體系中，所謂DevSecOps。

項目管理團隊，敏捷文化對PM這樣一個最注重流程的角色來講，是一個不小的衝擊，隨着組織的垂直化，之前嚴格的工做流被迅速弱化，傳統的瀑布式工做流程顯得臃腫繁贅，除了一些傳統軟件廠商，如今已經沒有多少互聯網企業會去作CMMI這樣的認證了，取而代之的是輕量級的敏捷工做流程，在大團隊協同時PM依然會發揮不小的做用，不少優秀的PM也開始轉型向敏捷教練的角色，輸出有效的項目管理文化和方式給各個業務團隊。

業務開發團隊，產品開發測試等角色混合組建成一個完整的業務團隊閉環正成爲趨勢。職能的獨立性和業務的連續性須要保持一個微妙的平衡，在職能部門尚未足夠大時，從業務交付角度以業務爲導向組建跨職能項目團隊，從人員技能培養角度以職能爲導向組建技術職能團隊也許是個不錯的選擇。閉環業務團隊可以高效運行的前提，是這個企業須要有完善的研發工具和研發協做平臺，否則光是人坐在一塊兒提高的可能也就是業務團隊內部的溝通效率，而後又是各個業務團隊各作一套，各業務團隊間的協做會成爲很大的問題。

多功能平臺型的DevOps團隊

在技術層面由誰來主導和推進DevOps平臺的組建，在組織或者團隊層面，如何傳遞DevOps 文化的價值並讓團隊理解DevOps 文化的價值，不一樣的公司能看到有不一樣的作法，好比有運維開發團隊驅動，有測試開發團隊驅動，有基礎架構團隊驅動等等，這種單一功能團隊推進的形式每每會面臨孤島化和片面化的問題，重視自身的領域但對其餘團隊的痛點關注較少。

單一自下而上的DevOps團隊雖然能夠在個別領域解決效能問題，但對整個技術組織的影響仍是比較有限。相比之下若是有一種自上而下的方式讓開發團隊基於已有業務基礎之上去優化交付流程，並對每個提交的最終價值負責，將產品思惟真正植入到開發團隊，從而達到全局優化的效果，這種作法才更符合真正的 DevOps 精神。

近期咱們在技術組織上作了大膽的改變，除了各個閉環的業務開發團隊之外，同時組建了技術中臺部門（包括通用架構平臺、大數據平臺和技術支撐平臺等）。其中技術支撐平臺包括原有質量架構、運維平臺、信息安全、項目管理這些技術職能的總體技術規劃和管理，並正式組建研發效能部(包括原有測試開發、運維開發、敏捷教練等多個角色，同時補充了部分專職開發工程師)，爲整個技術團隊提供DevOps總體解決方案，提供一站式需求-->開發-->測試-->運維（運營）全通道的研發協做平臺。組織上也從原有的職能組織結構，正式轉換成業務線+技術中臺的組織結構。

相似的組織結構並不新鮮，在BATJ等大廠也早已經有成功的先例，最典型的就是阿里「大中臺+小前臺」的技術組織結構，中臺部門負責基礎設施建設，業務部門利用這些成熟的基礎組件快速搭建業務應用，其中比較特殊的是研發效能和信息安全兩個組織，縱向貫穿全部技術團隊，爲整個技術團隊提供效能和安全的賦能，而研發效能團隊主要是由原有的運維開發，測試開發，敏捷教練以及部分專職開發人員組成，爲阿里幾萬名技術工程師提供一站式的研發協做平臺。

內部組織結構涉及公司機密，這裏能夠貼下阿里一個公開的技術組織結構圖。

雖然這種組織形式仍存在很多爭議，實踐中也有些過於理想化的地方，但整體來講從技術角度竊覺得是更優於騰訊提倡賽馬，各組織徹底分立的組織方式（TEG技術工程部門的掌控力頗有限），這點從阿里和騰訊在基礎技術設施能力上的對比就能夠深入體會。純屬我的意見，估計會收到很多板磚哈哈。

跨組織DevOps平臺建設的一些基礎

以應用爲中心

任何一個成熟的公司，根據職能不一樣，內部都有不少的研發平臺，研發端有代碼管理平臺，代碼檢查平臺，codeReview平臺，配置管理中心等，測試端有接口測試平臺，UI自動化測試平臺、測試數據中心、Mock中心等，運維運營端有資產管理平臺、發佈做業平臺以及各類監控平臺，安全上也會有安全資產管理、安全情報感知，業務安全風控、網絡安全監控等等平臺。在過往的職能結構裏，每每各個職能部門會各自建設這些系統，研發說系統，PM說項目，運維說機器，安全說url請求，各個職能部門缺乏一個共性的東西能把這些系統打通是部門之間信息溝通不順暢的重要緣由。

舉例來講，之前運維團隊建設CMDB資源管理平臺，傳統思惟上老是會以物理層資產角度去建設，聚焦在物理資產的管理，各臺機器什麼配置，什麼品牌，資產編號，資產價格，資產型號，資產位置甚至資產照片等等，自建機房的時候物理資產的管理仍是存在必定的價值，但在雲時代這些信息基本已經失去了意義，容器雲時代已經徹底不用關心容器的物理載體。對研發過程來講，僅僅聚焦在物理資源管理是沒有意義的，資源是靜態的。必需要創建一個逆向思惟，不要從資源的角度維護資源，而是從應用的角度來維護資源。主機是什麼？是應用的一個資源；Docker是什麼？能夠當作應用的附屬資源；PaaS平臺中分佈式RDS服務是什麼？是應用的附加資源等等。

創建了統一的應用管理平臺後（通常包括應用的語言，jdk版本，編譯工具和版本號，構件路徑，代碼地址，應用負責人，中間件等基礎信息），後面的流水線、發佈平臺、監控平臺、資產管理平臺等等均可以公用這些公共信息，從而保持了各個系統應用信息的一致性，並以應用名貫穿了跨組織的各個系統。

仍是以CMDB爲例，在申請資源的時候，研發團隊以應用爲主體申請須要的資源，在研發環境能夠一鍵申請生成，在正式環境則在運維團隊審批後自動分配，並在CMDB中記錄了每一個應用對應的資源信息；應用停用後，這些佔用資源很簡單的就能夠實現自動的回收和釋放，經過創建業務維度的資產管理體系，CMDB纔開始真正發揮出它應有的價值。

統一的認證受權管理

 要聚合技術體系內原有分散的各個內部平臺，使用統一的SSO認證受權機制是基礎。這裏有兩個概念，一個是認證，一個是受權。

咱們最先的內部用戶體系是基於LDAP，LDAP能夠實現用戶名密碼的統一管理，但因爲缺乏受權機制，跨多個系統時仍然存在須要重複登陸受權的問題，因此如今基於OIDC(OAuth2+OpenID)從新構建了新的認證受權體系，並在全公司的內部研發系統作了統一。

OIDC由於是標準協議，開源應用通常也都支持，這樣除了咱們內部研發的系統，其餘開源的如Jenkins、Gitlab、Redmine等系統均可以打通，免除了各個系統整合時重複登陸的苦惱，各個系統的安全性也可獲得有效的保障。

統一的權限管理

這裏主要仍是應用權限管理的統一，按照角色，維護每一個應用的人員權限（應用負責人，開發人員，測試人員，運維人員等等）。

由於全部研發協做系統是以應用爲核心，應用權限統一後，每一個系統能夠不須要再獨立去建權限系統，誰能修改代碼，誰須要接收報警，誰能夠構建流水線，誰能申請資源，均可以得到高度的統一。

統一的配置管理

全部的內部研發系統，使用統一的配置管理後臺，配置參數靈活管理，調整後實時分發。

統一的操做審計管理

確保全部內部研發系統的操做能夠審計，操做日誌統一管理。

一站式的研發協同

在上面幾個關鍵技術環節統一後，再加上UI設計上的統一，各內部研發系統的統一要作到一站式的統一就已是水到渠成的事情。各個系統仍是能夠獨立研發，但有選擇的整合到一個統一的DevOps研發協做平臺很是有必要，讓整個研發協同過程變得連續而有節奏，再也不必去記一堆的系統不停的去切換登陸操做了，一站式的解決研發協同過程當中的全部問題是DevOps平臺建設的主要目標。

結語

公司的組織結構和技術結構直接相關，有時候甚至會直接決定技術的架構。

組織結構是個很大的命題，能力有限觀點不免有些偏頗，但這些東西思考了挺久以爲仍是有必要總結下，也算是對本身有個交代。

話題比較沉重通篇也沒什麼技術乾貨，後面仍是總結點純技術的文章比較省心，哈。