轉(zhuǎn)載本文需注明出處：微信公眾號EAWorld，違者必究。

做DevOps產(chǎn)品差不多三年了，中間經(jīng)歷了諸多架構(gòu)變遷、團隊變動、業(yè)務(wù)目標調(diào)整，終于在七月下旬，正式發(fā)布了DevOps產(chǎn)品的 5.0 LA版本。這個版本從三月到七月，歷經(jīng)大概150天，每個階段都面臨著一些痛點，在此與大家簡單分享。

目錄：

1. 寫在前面：不滿意隨處可見

2. 三/四月：集成模型之痛

3. 五/六月：MVP帶來的變化

4. 七月：規(guī)模驅(qū)動工程優(yōu)化

5. 后續(xù)：長期規(guī)劃、短期見效

先簡單介紹下此版本的主要特性：

此版本覆蓋了產(chǎn)品管理、項目管理、持續(xù)集成、自動部署、交付流水線、精益度量6個領(lǐng)域能力：

• 平臺對外提供全面的開發(fā)運維一體化方案，已經(jīng)受過大規(guī)模生產(chǎn)驗證。

• 平臺不強調(diào)全自動，更傾向于在企業(yè)流程體系下，通過持續(xù)運營，提升生產(chǎn)效率。

• 平臺與微服務(wù)、容器無縫融合，兼容不同基礎(chǔ)設(shè)施，為開發(fā)、部署等能力要求提供支撐。

寫在前面：不滿意隨處可見

每一次版本研發(fā)，看著前序版本，都特別不是滋味（一般開發(fā)同時會很通俗的講：“每次看到以前自己寫的代碼都想抽自己”）。

比如，之前的版本中太強調(diào)項目管理的敏捷，卻完全沒有考慮企業(yè)版本火車式的敏捷，記得去某個銀行時，客戶上來就問版本火車在DevOps平臺怎么支持？我承認，真的沒細想過。

再比如，之前的版本太注重基礎(chǔ)能力的建設(shè)，沒有太考慮DevOps要千人千面，把概念模型簡單粗暴的映射到界面設(shè)計中，是個很嚴重的錯誤。

諸如此類的錯誤還是很多，暫且先不自我批評了，回到現(xiàn)在這個版本，我們在研發(fā)過程中遇到的一些挑戰(zhàn)，是如何面對的。

三/四月：集成模型之痛

對于DevOps平臺來說，核心價值在于將不同階段、不同工具有機串聯(lián)，數(shù)據(jù)打通（所謂橫向打通部門墻，縱向打通工具鏈），所以勢必要集成常用的一些工具鏈。

做集成類項目的同學都會比較清楚，集成類項目常常面臨以下三個難點：

• 集成類項目最大的難點是模型適配，比如禪道和jira，都是項目管理工具，但底層模型區(qū)別很大，這就要求在集成時能夠抽象出通用模型，甚至要做一定的能力取舍，形成標準模型。

  
  

• 從技術(shù)來看，大部分三方工具都提供了rest接口或?qū)?yīng)客戶端，但對于一些長任務(wù)調(diào)用，需要考慮異步或者CQRS模式。比如Jenkins集成，通過api調(diào)用得到key，后續(xù)通過任務(wù)key獲取pipeline狀態(tài)，也可以通過pipeline對DevOps進行hook回調(diào)。

  
  

• 從數(shù)據(jù)流來看，DevOps平臺現(xiàn)階段的比較現(xiàn)實的目標，是支撐80%的日常工作，很多專業(yè)工作還是要到原有專業(yè)工具上進行，所以在集成時，需要分清數(shù)據(jù)流向（哪些以查詢?yōu)橹?，哪些以操作變更為主等）?/span>

舉個例子，對Jira的集成，DevOps模型是這樣映射的：

可以看出，DevOps做了不少取舍，同時引入了jira沒有的產(chǎn)品概念，來統(tǒng)一管理需求。而對于數(shù)據(jù)流，DevOps在項目管理中更注重看板與項目報表（進度、效率、質(zhì)量），日常工作還是建議在jira上去做，畢竟jira的工作流等能力非常強，不是某個新的項目管理平臺能夠覆蓋到的。

通過不斷的抽象和調(diào)整，最終在這個版本里，集成了如下工具鏈：

五/六月：MVP帶來的變化

這個版本屬于實施帶動研發(fā)，客戶要求月迭代上線，這對我們的計劃安排、研發(fā)質(zhì)量等要求都很高，遵循MVP的交付尤為重要。

先說說何為MVP，如下圖，要讓每個階段都能有可用的產(chǎn)品，全稱“最小可行性產(chǎn)品”。

但順著上圖不難看出來，其實從可重復利用的角度來看，MVP的方式反而有一定浪費。畢竟造出的滑板車，在汽車產(chǎn)品上是完全沒用的。所以，如果是低質(zhì)量的MVP，后續(xù)耗費在迭代改進上的精力反而要更加恐怖（畢竟不是每個版本都是一刀切的）。

而對于大型產(chǎn)品來說，使用MVP交付最重要的一點在于故事的合理分配（大小、優(yōu)先級等），回歸產(chǎn)品經(jīng)理的本質(zhì)，在“人人都是產(chǎn)品經(jīng)理”中，會告訴大家如何找到最有價值故事，優(yōu)先交付：

• 從意愿角度來看，要做的故事往往是非常多的，在有限的時間里都完成是不現(xiàn)實的。

• 從競爭角度來看，業(yè)界都不易做的，往往價值更高。

• 從自身能力來看，不要一味的盯著那些還沒有太好方案的需求，快速完成能做的。

當然，永遠不能離開MVP的本質(zhì)，要保證每個沖刺后交付的版本都是可用的，讓大部分角色能參與進來。還有一句話，我覺得也很適合現(xiàn)在的大型產(chǎn)品研發(fā)模式：“think big, start small, do smart.”

結(jié)合上面的思路，在迭代過程中，我們對故事進行嚴格甄選，有機會大家看到我們產(chǎn)品時，會發(fā)現(xiàn)有些特性，在上面明顯花了不少精力，而一些比較普遍的特性，可能反而沒有做的很完善：

一種是我們認為理解較好的，我們會優(yōu)先并花更多精力去做，比如自動化部署：參考了oneops設(shè)計，將邏輯部署與物理部署架構(gòu)分離，通過在線部署架構(gòu)的設(shè)計，再將其與目標環(huán)境或資源、以及具體部署策略等關(guān)聯(lián)。

拿標準的三層架構(gòu)舉例，nginx+tomcat+mysql，開發(fā)環(huán)境中tomact部署單點，生產(chǎn)環(huán)境中tomcat部署集群，其實就可以做到一套設(shè)計，多次轉(zhuǎn)換形成最終的可執(zhí)行腳本，完成整體應(yīng)用的多環(huán)境部署。設(shè)計思路如下：

另一種是我們自認為有技術(shù)優(yōu)勢的，比如交付流水線：因為我們有流程引擎組件，使得面向不同的企業(yè)交付流程，可以做到動態(tài)可配。比如某個企業(yè)流水線上，是有預發(fā)這一步的，又或者上生產(chǎn)前是需要人工干預和多級審批的，對我們來說會比較容易實現(xiàn)，最終參考界面如下：

正是在這么一個個“有取舍“的迭代中，我們才能在有限的時間里，完成了近30W行代碼的版本交付，并在每個月完成從測試環(huán)境到生產(chǎn)環(huán)境的發(fā)布。

七月：規(guī)模驅(qū)動工程優(yōu)化

一直有客戶在問，你們的DevOps有沒有使用微服務(wù)架構(gòu)？業(yè)務(wù)和技術(shù)上究竟是怎么拆分的？

我的回答是：早在1.0版本我們采用過微服務(wù)架構(gòu)，將其拆成了十多個領(lǐng)域系統(tǒng)，但在這個版本我們合了。

做事要有激情，但切勿激進。同樣是造車夢，馬斯克和賈躍亭，至少從現(xiàn)階段來看，結(jié)果是不一樣的。

對于我們這么一家以產(chǎn)品為核心的公司來講，如果產(chǎn)品線和產(chǎn)品線之間采用太多不同技術(shù)棧，產(chǎn)品部門與事業(yè)部（服務(wù)部門）不能一起往前演進的話，即使某個產(chǎn)品技術(shù)棧很先進，缺無法讓公司所有人短期接受并掌控，就永遠做不到全面推廣。

話說回來也許有人覺得我們還是太保守，但事實確實如此，這沒法和互聯(lián)網(wǎng)或創(chuàng)業(yè)公司去比，傳統(tǒng)企業(yè)在技術(shù)演進路上肯定是相對慢一些的，更追求工程化和穩(wěn)定性。

在7月，隨著外部項目的增多，DevOps的實施面臨著更多工程化管理的壓力。如何從單一團隊負責交付，發(fā)展到多團隊配合？如何從孤立產(chǎn)品迭代，發(fā)展到企業(yè)版本火車交付？這些都是工程化要解決的問題。

我們的思路一直是，從BAPO角度來解決問題：

業(yè)務(wù)角度：多產(chǎn)品形態(tài)，往往不同客戶的需求從大塊上來看就是不一樣的，有客戶要CI，有客戶要CD，有客戶要項目管理，所以面向不同的業(yè)務(wù)目標，產(chǎn)品需形成對外多形態(tài)、插件化。

架構(gòu)角度：微服務(wù)、容器等生態(tài)逐漸完善，前端技術(shù)也變成了react與vue等少數(shù)之爭，這個時候我們對架構(gòu)逐步升級，面臨的風險會更小。

流程角度：DevOps強調(diào)持續(xù)迭代、持續(xù)交付，面對不同企業(yè)，細節(jié)流程雖有不同，但開發(fā)流水線，測試流水線，發(fā)布流水線這些卻都是必需品，所以可以通過流程梳理，形成落地實施規(guī)范。

組織角度：團隊加強配合和學習，比如與事業(yè)部部門的代碼共享，我們推薦使用fork模式，事業(yè)部逐步掌控，并能將一些實施過程中的優(yōu)秀特性pull request過來，反向幫助提升產(chǎn)品。

后續(xù)：長期規(guī)劃、短期見效

如何讓DevOps平臺保持生命力，我覺得最重要的是以下四點：

易擴展，平臺作為企業(yè)產(chǎn)線的一部分，需要與大量的工具、平臺交互，像攔截機制、hook機制都必不可少，盡可能讓平臺與更多能力串接，才能形成一條全周期的生產(chǎn)線。

可度量，MVP強調(diào)快速推出，通過有效的反饋機制，為后續(xù)優(yōu)化方向提供參考。DevOps面向的部門和角色較多，千人千面的需求更為明顯，所以快速收集反饋，持續(xù)度量尤為重要。

連通性，這里更強調(diào)數(shù)據(jù)的連通性，是否知道jira上的某個task，花費了多少行代碼？是否知道jira上的某個story，現(xiàn)在運行在哪臺server上？這些都是數(shù)據(jù)聯(lián)通的例子，也是DevOps設(shè)計中最重要的一環(huán)。

標準化，或者我們也可稱為”最佳實踐“，也許現(xiàn)在還很難標準化客戶流程與規(guī)范，但在某些細分行業(yè)里，總會有一些榜樣企業(yè)或標準，平臺更應(yīng)該將這些標準作為規(guī)范落地，通過模板配置、流程配置，幫助客戶形成最佳實踐。

目前我們的DevOps還無法覆蓋全能力，比如測試管理與自動化，比如監(jiān)控預警，都還需要逐步建立完善，從產(chǎn)品發(fā)展角度，我們更希望業(yè)務(wù)目標要大而全，但實現(xiàn)要快速見效（實現(xiàn)大而全，說實話確實也投入不起）。

最后分享下這個版本的主要功能矩陣，望大家對我們的一些經(jīng)驗和產(chǎn)品能力給予建議或指正：

作者介紹

顧偉

現(xiàn)任普元信息主任架構(gòu)師。長期致力于IT技術(shù)研究、產(chǎn)品設(shè)計與開發(fā)、架構(gòu)咨詢等工作，擅長Web、OSGI、CI/CD、服務(wù)治理、云計算等領(lǐng)域技術(shù)。對DevOps、自動化運維、微服務(wù)架構(gòu)有著濃厚的興趣。

關(guān)于EAWorld

微服務(wù)，DevOps，元數(shù)據(jù)，企業(yè)架構(gòu)原創(chuàng)技術(shù)分享，EAii（Enterprise?Architecture?Innovation?Institute）企業(yè)架構(gòu)創(chuàng)新研究院旗下官方微信公眾號。

微信號：eaworld，長按二維碼關(guān)注

8月-9月，PWorld系列技術(shù)趴還將繼續(xù)上演。目前，8月27日將在北京舉行PWorld MeetUP“微服務(wù)&DevOps專場”已啟動報名，戳“閱讀原文”可直達報名頁面，并了解更多詳情~