這10年來我一直從事中介軟體產品研發，從以前的UI設計器、開發工具到現在的大資料、雲端計算等，遇到的挫折其實並不多。但去年的DevOps產品研發，最終成果很難令人滿意，到底是什麼問題導致？凡事都講天時地利人和，產品研發亦然，而作為DevOps產品架構設計者，我到底犯了哪些錯誤？在此，我會從架構、技術、團隊等方面進行問題剖析、總結，希望能與各位大牛產生共鳴。

從去年6、7月份開始，我相繼研發了普元新一代雲平臺（The Platform）0.1，0.2版本，預計今年年底會發布1.0版本。前兩個版本都是圍繞DevOps、CaaS、MicroService三個業務進行研發的，版本雖然已釋出，但離既定目標尚有不短的距離，回過頭來總結，我在總體設計這塊犯下了6個錯誤，在這裡與各位分享，希望能產生共鳴。

這裡通過一張圖，簡單介紹一下平臺架構：

產品以容器作為底層資源管理支撐，微服務架構作為執行支撐，形成了以三類PaaS（整合類、流程類、資料類）作為執行環境，DevOps作為全生命週期自動化支撐的雲平臺。

對於我們來說，希望做的是大生命週期的支撐，所以對於DevOps產品的定位如下（從產品定義到最終上線運維）：

OK，迴歸主題，不知道各位在做大型產品的總體設計時，一般思路是怎樣的？我們當時從五方面著手：

1.概念先行

從概念模型著手，梳理產品中的核心實體物件，DevOps平臺的核心是開發交付和運營反饋，具體如下：

2.場景驅動

對DevOps業務場景進行梳理，定義平臺相關角色，定義主流程。DevOps平臺通過分工協作與質量管控，力求全生命週期的自助與自動，具體如下：

3.模組劃分

定義平臺子系統（微服務），我們在設計時，一則是想DevOps平臺本身採用微服務架構，二則是DevOps平臺支撐微服務執行，最終平臺形成了10個左右的子系統，具體：

上圖的幾個簡寫術語：SRM-軟體資源管理，SPM-軟體產品管理，SEM-軟體環境管理，BPR-二級制倉庫，DPR-可部署包倉庫。

4.團隊分工

團隊這塊的劃分採用了兩個維度，一個是子系統責任制，一個是技術分層，將團隊個人特長最大化，具體如下：

5.規範約束

處理一些管理過程規範外，在開發規範上，定義了子系統之間的邊界規範，以API和SPI的模式來實現，每個小團隊與上下游團隊共同制定和review介面設計，具體如下：

上面的配圖是一些草圖，不太嚴謹，我之前在另一個群分享過我們平臺的總體設計，大家若對材料有興趣，可聯絡我，也可從我們的公眾號上獲取。（傳送門：雲端計算平臺架構設計與核心流程）

從大面上粗看貌似沒什麼問題，但大家或許心裡已經有疑問了，比如說：

資料模型在哪兒？DevOps平臺本身講究工具鏈的整合，對於擴充套件性，尤其是資料庫的擴充套件性設計要求非常高（大家有時間可看看Team Foundation Service、Rational Team Concert這些平臺的擴充套件性設計，非常不錯）

DevOps平臺本身採用微服務架構，同時支撐微服務在上面執行，難免會陷入一個雞生蛋、蛋生雞的問題，如何解決？

開發架構上只是定義了一些子系統邊界，對於DevOps平臺具體的依賴產品或框架是怎麼制定標準的？

團隊分工採用了兩維設計，一些兩維度衝突的地方是怎麼解決的？

……

是的，這些都是問題，也正是這些問題以及我的經驗不足，讓我犯了標題中提到的6個錯誤：

錯誤1:概念耦合。

最典型的就是沒有將DevOps、CaaS、MicroService拆分開來看。

這是現在業界的一個普遍現象，大家會看到，很多人把微服務，Docker，DevOps都放在一起談。比如下面這些大會分享上的截圖：

當然不是說這些作者本身概念混了，而是說現在的很多講法，容易造成讀者的誤解。

事實上，這三者是獨立的三個領域概念，DevOps的本質是：

而微服務是一種架構風格，難點在於開發規範與運維支撐。而容器呢，可以這麼說，微服務架構給容器技術的風靡加了一把火：

所以，這三者完全是可以分開建設的，DevOps平臺更應該關心多工具鏈及應用整合，異構環境的統一管理，流程的驅動支撐。

第一個錯誤給我的啟示是：概念模型需要從領域著手，多領域需嚴格分開，當然，這也符合時下DDD倡導的設計模式。

錯誤2：關鍵設計未集中來做。最典型的問題就是資料模型（ER）的設計下放到每個子系統去設計。

業界現在有很多總體設計的方法，比如4+1模式（一般不帶資料架構）、再比如togaf模式（一般包括資料架構），其實最關鍵的是哪種最適合現在的產品及團隊。當時拆成小團隊後，把資料模型的設計完全交給子團隊在詳設裡去做了，造成了諸多設計不一致性。大家都知道，在DevOps這樣的很難標準化的平臺中，資料模型的擴充套件性設計要求非常高，比如對橫表、拉鍊表、歷史表的使用會特別頻繁。

再者還有些細節問題，總體設計雖然定了表命名、列命名、主鍵型別、索引策略等規範，但是還是出現了一些問題，比如同樣是某個實體的唯一程式碼，這邊叫ID，那邊叫CODE，還有兩者做冗餘都有的，造成API引數傳遞時，尤其是跨子系統傳遞時，引數命名很不一致，再者就是下游往上游系統返回資料時，上游系統還要做額外的對映處理。

第二個錯誤給我的啟示是：在一些傳統的管理域系統中，像ERP，OA這種，資料模型往往是重中之重，必須集中來做，完全扁平化的設計下放，是一個風險非常大的行為。

錯誤3：MVP未深思熟慮，未採用最工程化方式來實現。

這應該是我最大的一個錯誤，對MVP的理解過於膚淺。MVP一般有很多路可走：

比如：你要解決交通問題，那可以先造一輛自行車，再造一輛三輪車，再造小汽車……

再比如：同樣你要解決交通問題，你可以先造非常裸的小汽車（四輪子、發動機、無內飾、無空調、手動等），然後逐步加配件、升級系統……

上述的兩個都是MVP，但卻完全是不同的執行路徑。所以對於DevOps平臺的MVP之路，應該是什麼樣子？

我之前的理解：先做了一個比較裸的微服務框架，包括rpc呼叫，服務註冊與發現，上下文處理，token處理等，基於這個框架來進行DevOps平臺開發，同時在DevOps平臺研發中，先做產品管理、持續構建和持續釋出。

但上述這個做法忽略了一個關鍵問題，我們的最終目標是DevOps的全生命週期支撐，到底是先做生命週期中的部分階段，還是先完成整個階段的驅動，再豐富每個階段的血肉。

現在看來，全生命週期打通才是最重要的，定義階段與階段間的輸入輸出，也許某些階段還是手工方式，但不影響整個DevOps的理念的滲入和逐步精益的大原則。

同時，大家知道，作為第一個版本，採用一個全新的架構，而且是還不完善的架構（比如缺了微服務架構的資料一致性支撐能力），風險是很大的。更何況我們普元做了16年的中介軟體，很多技術平臺和框架的積累，在DevOps產品研發中都沒有使用，而是採用了純開源模式新做，這一點大大違背了IT工程化的建設思路。

第三個錯誤給我的啟示是：MVP並不是功能的MVP，是實踐之路的MVP，每個產品都有自己的最核心理念，再小的MVP也要能闡述理念。MVP的實施要用最穩妥的方式，切勿激進，市場、尤其企業市場絕不會像很多網際網路宣傳那樣，給你試對試錯的機會，即使你的速度和反應再快也不會。

錯誤4：沒有引入流程引擎作為底層支撐，更何況是我們有流程引擎成熟產品的前提下。

現在談DevOps平臺的最佳實踐維度，很多會用這張圖：

不難看出，流程部分是非常重要的部分，其實引入流程引擎的好處，不僅僅是用來做簡單的狀態流轉（比如bug、任務等），更可以用流程引擎來編排不同子系統提供的能力，即使編排的都是自動活動。因為：

首先，流程引擎一般本身提供足夠的API能力，統計分析能力，適配能力等，為後續優化、反饋、變更提供了足夠的底層支撐。

再者，從擴充套件性來考慮，舉例子，同樣做敏捷，Agile、Scrum、CMMI流程，以及其workitem狀態流都是有區別的，如果通過對各個模式的硬編碼，後續的變更是非常麻煩的，同時還要建立在對這些模式的充分理解的前提下（說實話，現在的很多模式分支實在太多了），而流程的好處在於快速調整適應，同時，即使流程定義後變更很難，還可以用自由流等手段來實現，一般現在的流程引擎都是有自由流能力的，以前做過廠商，這種特殊能力通過編碼實現的話還是非常難的，很難做的完善，尤其上下文的管理。

第四個錯誤給我的啟示是：DevOps產品（這裡說的是產品，不是某個企業的特定專案），一大難點在於流程差異性的遮蔽和流程快速調整的支撐，大到企業部門間協作流程，小到活動狀態流轉，所以流程引擎的引入會對產品的持續發展提供積極作用。

錯誤5：康威定律的實踐問題，異地團隊與子系統的結合方式有些欠妥。

以前一直和別人說康威，做著做著才發現自己的理解是多麼片面。先說下我們的團隊情況，我們的研發團隊分在西安和上海兩地，有一段時間甚至是三地（還有北京），整個團隊偏新，之前共事較少。

在出現異地的時候，其實技術特長不應該作為分組的首選條件，因為這樣很可能會出現某個小團隊跨兩地，這是一個很不好的狀態，因為溝通才是異地的最大挑戰。所以在分組之初，儘可能讓異地的交集工作最少、溝通最暢，最理想的情況是做到兩地分別只有一個介面人，其餘人完全不存在異地溝通。

第五個錯誤給我的啟示是：單管道模式雖然有瓶頸，但比起多管道模式來說，更易治理，所以異地協作我更推崇單管道模式。

錯誤6：架構師的參與度不足。

總體設計離最終落地往往都還有一段距離，這個距離是需要架構師在後續過程階段去彌補的，這就是概念到落地的距離，也是很多架構師的瓶頸所在。

一個很形象的說法，架構師是做拍板的，要對任何決定負責。說這句話突然想到了最近的美國大選，從兩個候選人的辯論中，感覺都挺缺乏擔當的，呵呵，扯遠了！

許多細節的設計是要逐步完善的，舉個我們做的不好的例子，在Git庫主幹與分支的使用模式上，我們在前期VCS子系統設計時就沒有考慮清楚，當時只考慮了常用TBD模式的支撐，後續架構師在這個子系統上的投入太少，使得後續在對客戶需求的應答上能力缺口太大。既然提到版本控制庫使用問題，有不少不錯的blog大家可參考，比如阮一峰大俠的：http://www.ruanyifeng.com/blog/2012/07/git.html

這裡我有兩個建議：

首先，架構師不要過早撤出專案。當然，很多架構師可能身兼數職，在某一個具體專案中的投入很難保障，如果是這樣，只能說高層對這個產品的重視度不夠，或者這根本就不是個明星產品，其造成風險會很大。

其次，架構師儘可能參與核心部分開發。前段時間圈裡總是在吵CTO該不該編碼的問題，我個人覺得CTO可不參與，但架構師還是要參與的，不能只是簡單的預研、設計、驗證等工作，容易造成與實際落地的脫節。

第六個錯誤給我的啟示是：架構師作為現代IT中一個蠻有爭議的角色，需主動尋求更多的價值點。而在DevOps產品研發中，作為架構師，需非常瞭解各工具鏈原理、整合方案等，才能有機串聯整個平臺。

現在，我們1.0版本的研發中，做了這樣的一些調整，來應對上述的一些發現的問題。

組織架構的調整，拆成了獨立的三部分來做，分成DevOps團隊、容器雲團隊、微服務團隊。

引入EOS（開發平臺）、BPS（流程引擎），支撐平臺下一個MVP的工程化交付。

概念模型到資料模型的總體設計，將DevOps分為產品管理、專案管理、交付中心、程式碼&構建、許可權管理五部分。

不再自己杜撰需求（當然之前也不是杜撰的，只是與實際結合還不夠緊密），結合燈塔客戶的具體需求與狀況，來輔助完成產品研發。

團隊分工，異地做一定犧牲，前期需求與設計階段在一起辦公，同時獨立分出架構師，全職參與DevOps產品研發和實施。

對今天的分享做個總結，在DevOps產品研發中，因為總體設計不夠充分，技術選型過於激進，對異地團隊協作的困難預估不足，本身的參與度不夠等問題，使得產品質量目標未能完全達到。目前已通過一定手段有效解決，並希望通過燈塔客戶需求的實施，完成產品能力的改造與完善。

普元公眾號：