本文講的是DevOps 5.0版本的150天曆程，做DevOps産品差不多三年了，中間經曆了諸多架構變遷、團隊變動、業務目标調整，終于在七月下旬，正式釋出了DevOps産品的 5.0 LA版本。這個版本從三月到七月，曆經大概150天，每個階段都面臨着一些痛點，在此與大家簡單分享。
目錄：
寫在前面：不滿意随處可見
三/四月：內建模型之痛
五/六月：MVP帶來的變化
七月：規模驅動工程優化
後續：長期規劃、短期見效
先簡單介紹下此版本的主要特性：
此版本覆寫了産品管理、項目管理、持續內建、自動部署、傳遞流水線、精益度量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的本質，要保證每個沖刺後傳遞的版本都是可用的，讓大部分角色能參與進來。還有一句話，我覺得也很适合現在的大型産品研發模式：“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還無法覆寫全能力，比如測試管理與自動化，比如監控預警，都還需要逐漸建立完善，從産品發展角度，我們更希望業務目标要大而全，但實作要快速見效（實作大而全，說實話确實也投入不起）。
最後分享下這個版本的主要功能矩陣，望大家對我們的一些經驗和産品能力給予建議或指正：
原文釋出時間為：2017-08-25
本文作者：顧偉
本文來自雲栖社群合作夥伴EAWorld，了解相關資訊可以關注EAWorld。