作者介紹

顧偉

現任普元資訊主任架構師。長期致力於IT技術研究、產品設計與開發、架構諮詢等工作，擅長Web、OSGI、CI/CD、服務治理、雲端計算等領域技術。對DevOps、自動化運維、微服務架構有著濃厚的興趣。

本文目錄：

一、 再談DevOps定位

二、談談幾個實踐設計

三、普元DevOps核心

越來越多的廠商開始研發DevOps產品，有的基於專案管理工具衍生，有的從運維工具或容器雲過渡，不管怎樣，大家都是為了給客戶帶來一條全新生產線，支撐其數字化運營。

記得2015年初產品剛起步時，我們也是從CICD開始、變更觸發程式碼構建、再到自動化部署到容器雲；隨著不斷地客戶實施，普元對DevOps的定位、價值、特性等有了更多的認識，借本篇文章，與大家分享我們的持續認知和改進。

經過一段時間的實施與改進，本月底我們將正式釋出DevOps的5.0版本，相比於常規功能，DevOps更重要的是一些最佳實踐的引入，真正對企業IT的生產起到精益運營的效果。

一、再談DevOps定位

之前我們同事已經談過DevOps的定位，但隨著越來越多的交流和實施，我們發現大部分客戶會提出這些要求：

很顯然，這些想法都很實際，又都存在著一些問題，拿第一個說法（給一些工具或系統做統一門戶）舉例：

很多客戶企業確實已經用了不少開源或商業產品，只是現在都是一個個獨立存在，沒有統一登入、認證，使用起來比較麻煩，所以提出了第一個要求，並認為這就一定程度上實現了DevOps。

但事實上，這個做法對旨在精益的目標來說，顯然是不夠的：

1. 我們還是不知道某個系統需求最終跑在了哪些機器上

2. 我們也不知道現在併發的20個專案中哪些專案存在風險

3. 同樣我們可能基於現有的資訊，也不知道敏捷釋出火車一年能開幾回

所以，在我們定位裡，DevOps不是簡單的整合或整合，而是一條數字化生產線，覆蓋從需求到最終運營的全週期；

當然也少不了對於質量、安全方面的支撐，為IT運營提供足夠的保障。

想一次性從需求做到運營往往是一個理想，更多的是選擇生命週期中最需優化的點來逐步建設，但現在也看到一個現象：

越來越多的廠商開始研發DevOps產品，有的基於專案管理工具衍生，有的從運維工具開始，有的從容器雲過渡，有的從開發平臺著手，貌似大家把所有工作都歸結為DevOps。

顯然在定位上犯了一個問題，就像之前很多人說一切皆程式碼、一切皆***的，而忽略了DevOps的初衷（當然我們不排除豐富一切對IT生產線有用的能力，但不能把一切都強行說成DevOps）。

其實SAFe中給了DevOps一個比較有原則、並且接地氣的定義：

DevOps重在快速交付，通過將研發管理與部署交付的緊密結合，驅動企業敏捷。

所以，我們應該首先著眼在交付流水線上，通過視覺化協同、標準化、一定的自動化等手段，讓企業、讓團隊在流水線上更好的協作。

接著在運營並持續產生資料的基礎上，通過各維度的度量手段，快速發現瓶頸，逐步優化，迭代建設並形成企業數字化標準。

絕不是不管三七二十一，上來就買個容器雲、或者智慧排程、或者自動運維、甚至是不切實際的“零運營”產品，然後考慮怎麼遷移。

二、談談幾個實踐設計

回到今天的重點，分享一下我們在DevOps實施中的一些實踐設計。

回想起2015-2016年初，我們也很喜歡給客戶講：開發者如何通過提交程式碼到git，觸發jenkins開始構建，打包出鏡像，通過與配置管理配合，一鍵釋出到容器雲。

就像下面的阿里雲的這張圖：

回到今天的重點，分享一下我們在DevOps實施中的一些實踐設計。

回想起2015-2016年初，我們也很喜歡給客戶講：開發者如何通過提交程式碼到git，觸發jenkins開始構建，打包出鏡像，通過與配置管理配合，一鍵釋出到容器雲。

就像下面的阿里雲的這張圖：

比如很多集團要支援二級單位模式，那應該是什麼樣的部署要求，如何做資料的隔離？

又比如客戶辦公網和測試網肯定是單向的，那對於自動化測試（尤其是帶裝置的，比如手機真機測試肯定是放在辦公網的），該如何應對自動部署和測試用例的推送執行？

類似問題一實施起來就遇到很多，這個片子先準備了下面幾個實踐：

1. 剛才一直在說需求跑在哪些機器上，這是個典型的資料打通的問題，或者叫數字化問題，那資料關聯我們怎麼考慮的

2. 版本，現在不同於以前單塊架構，微服務架構下，有著各類都叫版本的元資訊，比如釋出版本、api版本、快照版本、產品規劃版本等，是否建立了規範機制和關聯性管理能力

3. 看板，做DevOps的自然之道看板的重要性，但不同的角色，期望從看板中看到的資訊肯定是有所區別的，該如何設計看板

4. 租戶的問題對於很多大集團運營是不可避免的，平臺該如何考慮租戶的資料隔離，被整合的系統又改如何配合

5. 安全，這個領域比較大，我這邊談到的只是平臺本身的一些安全處理，應對合規審計等要求

先說說資料關聯性處理的實踐：

要想需求知道執行在哪裡，至少必須打通上述的幾個環節：

1. 需求到任務的拆分，這個很簡單，無論jira、禪道，這都是必須支撐的

2. 任務到編碼的關聯，或者可以這麼說，提交的程式碼必須知道是完成了哪個或哪些任務，這個有幾種實現方式，一則是完成任務時，輸入commitid，一則是提交程式碼時，統一模板，再通過hook將關聯關係持久化。顯然第二種更優。

3. 編碼與構建的關聯，本質上是要建立每次構建涵蓋了哪些新增的Commit資訊的管理，這個也有幾種實現方式，一則是編譯資訊體現到庫上，後續遠端獲取增量，一則是完全自身儲存，相當於完全接管commit資訊的儲存。兩者沒有太多優劣，都可以。

4. 構建與部署的關聯，其實是每次部署關聯的工件資訊的持久化，這個倒不是難事。

基於上述環節的打通，當然還要把變更、升級等結合進去，想做到資訊打通就不難了。

再說一個關聯的例子，之前我們有同時講過我們平臺上的部署三部曲：部署設計、部署轉換、上線運維。不僅僅是部署，為什麼要做線上的很多設計呢？

傳統模式下，架構師寫架構設計文件，包括應用架構、部署架構、資料架構等，但隨著專案的執行，後續實際開發、構建、部署和文件上難免有偏差，好像也很少有人再反向更新文件保持所有同步了。

那為何不將設計放到線上，同時提供多版本管理，支撐優化變更，指導後續工作呢？

比如部署架構，後續可生成部署計劃；

比如介面設計，後續可檢視變更，線上文件化；

比如應用架構，後續指導構建依賴，某個構建應該觸發哪些構建；

這就是我們為什麼要把設計階段很多工作線上化的關起來的原因，做到各階段的關聯性驅動和管控。

接著說說第二個實踐，現在對於版本這個詞的管理，比以前複雜太多了：

記得萬達客戶實施時，客戶自身就把這些版本規則、資訊等做了嚴格的規範，什麼地方用幾位表示，何時變更。

那對於DevOps平臺來說，重在建立關聯資訊的看板，為不同的角色提供不同的資訊圖，看板的實踐中正好也提到了一些版本的問題。

我們就接著來說說看板的實踐，很多人第一反應是需求或任務看板，這個當然是必須的，不過視覺化協同的不僅僅是需求或任務，很多資訊都需要看板的方式呈現。

比如：

這是面向交付的看板，可以清楚的看到本次釋出到底已經過了哪些環境的驗證，最終走到PROD的，事實上就是釋出的版本。同時對於釋出的版本，內部對應的元件（或服務）具體的版本是什麼，也要呈現出來。

這個看板對於專案經理和架構師很重要，可清楚看到版本一次次持續交付的過程。

再比如：

這個看板其實做的不太好（正在改），其實應該是一個專案環境全集的展示，體現出目前專案的所有環境中到底部署的是什麼版本，執行狀態如何。

再比如：

這是流水線，涉及到了多個環境部署、測試知道最後生產上線，這是團隊成員在穩定期到最終釋出的中間迭代環節，不同的人關注不同的活動，專案經理關注執行階段與執行情況。

再比如：

面對PMO，可能有些企業是CTO，會關注當前所有專案的狀態，這張圖與IBM的JAZZ中的一個圖類似，顯示一些專案處於預警狀態，另一些是健康狀態，橢圓大小代表專案的計劃人月多少，越大的越要關注。有這種看板，就不用找每個專案經理溝通或開會了，只要關注有風險專案即可。

再比如：

這是專案的基礎資訊看板，專案經理關注里程碑的情況（延期、進行中、完成等），由此再深入到具體的需求、任務、Bug等具體資訊。

很多企業都有二級單位，DevOps同樣會開發給二級單位使用，這就涉及到了對於租戶能力支撐的實踐：

業界租戶方案主要是應用隔離和資料隔離，對於devops產品來說，顯然資料隔離足夠了，對於資料隔離，又有邏輯資料隔離（每張錶帶租戶欄位）和物理資料隔離（分庫）兩種方式。

目前我們的產品設計是兩者都支援，前者應對資料量不大的情況，後者應對隔離要求很高且量很大的情況。

上圖應對的是第二種租戶設計，更多的通過申請+初始化的方式，同時繫結不同二級域名，解決入口問題。

除了DevOps平臺本身，對於整合的三方系統，也要考慮租戶能力的支撐：

比如Jenkins，建議共享，通過給work node打label，來區分租戶；

再比如Nexus，建議每個租戶三個獨立產品庫，當然，如果採用artifactory則更好了

再說說今天的最後一個實踐，關於安全的問題，首先DevOps本身定位在管理了多套環境，那平臺本身該如何部署：

DevOps本身一般部署於生產環境中，通過部署引擎與各環境打通；而對於nexus、或者harbor，目前實施客戶中既有可多環境共享的，也有通過多環境同步的。

對於平臺本身，也要注意：

可用性：支援可靠的部署架構

機密性：對於日誌、資料表中的敏感資訊，一定要支援不同級別的加密配置

可控制：資料許可權、操作許可權、api許可權等，都要進行嚴格控制

還要完整性，審計等等

三、普元DevOps核心

一個是領域概念的設計：

還是從產品、專案、組織、整合、部署領域考慮，通過流水線將能力串聯

另一個是我們的核心觀點：

• DevOps平臺需覆蓋產品、專案的全週期
• DevOps平臺更重要的是提供最佳實踐
• DevOps平臺，重在讓所有角色在流水線上協作，共同驅動過程的精益
• DevOps平臺，管理前移，有效指導和約束後續工作
• 所謂打通，不是一味的打通部門牆，更重要的對於各階段管理物件的關聯性打通
• 對於已有系統，DevOps平臺不僅僅是通過新的工具鏈實現快速交付，更是一種驅動優化的變革
• DevOps平臺，並不是自動化一切，而是在可控中有選擇的自動化

最後，對於最佳實踐這種東西，仁者見仁，每個企業都有不同的需求和想法，需要在建設期一步一步的做進來（當然，這就要求產品本身的延展性設計等）。

文章來自微信公眾號：EAWorld