http://baijiahao.baidu.com/s?id=1576759408183291678&wfr=spider&for=pc

做 DevOps 產品差不多三年了，中間經歷了諸多架構變遷、團隊變動、業務目標調整，終於在七月下旬，正式釋出了 DevOps 產品的 5.0 LA 版本。這個版本從三月到七月，歷經大概 150 天，每個階段都面臨著一些痛點，在此與大家簡單分享。

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

此版本覆蓋了產品管理、專案管理、持續整合、自動部署、交付流水線、精益度量 6 個領域能力：

平臺對外提供全面的開發運維一體化方案，已經受過大規模生產驗證。

平臺不強調全自動，更傾向於在企業流程體系下，通過持續運營，提升生產效率。

平臺與微服務、容器無縫融合，相容不同基礎設施，為開發、部署等能力要求提供支撐。

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

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

比如，之前的版本中太強調專案管理的敏捷，卻完全沒有考慮企業版本火車式的敏捷，記得去某個銀行時，客戶上來就問版本火車在 DevOps 平臺怎麼支援？我承認，真的沒細想過。

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

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

三 / 四月：整合模型之痛

對於 DevOps 平臺來說，核心價值在於將不同階段、不同工具有機串聯，資料打通（所謂橫向打通部門牆，縱向打通工具鏈），所以勢必要整合常用的一些工具鏈。

做整合類專案的同學都會比較清楚，整合類專案常常面臨以下三個難點：

整合類專案最大的難點是模型適配，比如禪道和 jira，都是專案管理工具，但底層模型區別很大，這就要求在整合時能夠抽象出通用模型，甚至要做一定的能力取捨，形成標準模型。

從技術來看，大部分三方工具都提供了 rest 介面或對應客戶端，但對於一些長任務呼叫，需要考慮非同步或者 CQRS 模式。比如 Jenkins 整合，通過 api 呼叫得到 key，後續通過任務 key 獲取 pipeline 狀態，也可以通過 pipeline 對 DevOps 進行 hook 回撥。

從資料流來看，DevOps 平臺現階段的比較現實的目標，是支撐 80% 的日常工作，很多專業工作還是要到原有專業工具上進行，所以在整合時，需要分清資料流向（哪些以查詢為主，哪些以操作變更為主等）。

舉個例子，對 Jira 的整合，DevOps 模型是這樣對映的：

可以看出，DevOps 做了不少取捨，同時引入了 jira 沒有的產品概念，來統一管理需求。而對於資料流，DevOps 在專案管理中更注重看板與專案報表（進度、效率、質量），日常工作還是建議在 jira 上去做，畢竟 jira 的工作流等能力非常強，不是某個新的專案管理平臺能夠覆蓋到的。

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

五 / 六月：MVP 帶來的變化

這個版本屬於實施帶動研發，客戶要求月迭代上線，這對我們的計劃安排、研發質量等要求都很高，遵循 MVP (最小可行產品)交付尤為重要。

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

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

而對於大型產品來說，使用 MVP 交付最重要的一點在於故事的合理分配（大小、優先順序等），迴歸產品經理的本質，在“人人都是產品經理”中，會告訴大家如何找到最有價值故事，優先交付：

從意願角度來看，要做的故事往往是非常多的，在有限的時間裡都完成是不現實的。

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

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

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

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

一種是我們認為理解較好的，我們會優先並花更多精力去做，比如自動化部署：參考了 oneops 設計，將邏輯部署與物理部署架構分離，通過線上部署架構的設計，再將其與目標環境或資源、以及具體部署策略等關聯。

拿標準的三層架構舉例，nginx+tomcat+mysql，開發環境中 tomact 部署單點，生產環境中 tomcat 部署叢集，其實就可以做到一套設計，多次轉換形成最終的可執行指令碼，完成整體應用的多環境部署。設計思路如下：

另一種是我們自認為有技術優勢的，比如交付流水線：因為我們有流程引擎元件，使得面向不同的企業交付流程，可以做到動態可配。比如某個企業流水線上，是有預發這一步的，又或者上生產前是需要人工干預和多級審批的，對我們來說會比較容易實現，最終參考介面如下：

正是在這麼一個個“有取捨“的迭代中，我們才能在有限的時間裡，完成了近 30W 行程式碼的版本交付，並在每個月完成從測試環境到生產環境的釋出。

七月：規模驅動工程優化

一直有客戶在問，你們的 DevOps 有沒有使用微服務架構？業務和技術上究竟是怎麼拆分的？

我的回答是：早在 1.0 版本我們採用過微服務架構，將其拆成了十多個領域系統，但在這個版本我們合了。

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

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

話說回來也許有人覺得我們還是太保守，但事實確實如此，這沒法和網際網路或創業公司去比，傳統企業在技術演進路上肯定是相對慢一些的，更追求工程化和穩定性。

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

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

業務角度：多產品形態，往往不同客戶的需求從大塊上來看就是不一樣的，有客戶要 CI，有客戶要 CD，有客戶要專案管理，所以面向不同的業務目標，產品需形成對外多形態、外掛化。

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

流程角度：DevOps 強調持續迭代、持續交付，面對不同企業，細節流程雖有不同，但開發流水線，測試流水線，釋出流水線這些卻都是必需品，所以可以通過流程梳理，形成落地實施規範。

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

後續：長期規劃、短期見效

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

易擴充套件，平臺作為企業產線的一部分，需要與大量的工具、平臺互動，像攔截機制、hook 機制都必不可少，儘可能讓平臺與更多能力串接，才能形成一條全週期的生產線。

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

連通性，這裡更強調資料的連通性，是否知道 jira 上的某個 task，花費了多少行程式碼？是否知道 jira 上的某個 story，現在執行在哪臺 server 上？這些都是資料聯通的例子，也是 DevOps 設計中最重要的一環。

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

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

最後分享下這個版本的主要功能矩陣，望大家對我們的一些經驗和產品能力給予建議或指正：

作者介紹

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