軟件工程師羅小東，多年平臺架構(gòu)設(shè)計和落地經(jīng)驗，以下針對于中小微團隊在數(shù)字中臺的實踐管理，主要偏于實操描述。

背景

這里的產(chǎn)品并不是互聯(lián)網(wǎng)運營的，而是內(nèi)部研發(fā)產(chǎn)品，后期用于項目。

數(shù)字中臺產(chǎn)品管理，產(chǎn)品線大概有20個，產(chǎn)品工程管理基線是50個左右，自動化任務(wù)大概有250+個，當前維護ACP產(chǎn)品的屬于微小團隊，當前產(chǎn)品線的管理維護人員為6個人，主要偏向于產(chǎn)品功能的優(yōu)化管理和升級，前端ISV團隊的支撐，項目的技術(shù)支撐，還有針對于運行的數(shù)據(jù)治理上的二次開發(fā)（比如基于日志分析的安全感觸服務(wù)），配合商務(wù)的輸出等。

過程的管理主要是基于過程規(guī)范標準化、自動化操作、微服務(wù)、容器化管理、數(shù)字中臺架構(gòu)、云計算等。

概述

在這個建設(shè)過程中，基于原來alinesno-cloud開源項目進行升級優(yōu)化，這里主要是針對在過程的實踐情況，還有團隊的使用情況，包括主要使用的技術(shù)能力，運維管理，運營管理等，以低成本進行運維，提升團隊的能力的競爭力，希望可以給一些在往這塊方向的團隊一些參考，在這個過程中主要使用的技術(shù)場景如下：

這里闡述主要通過幾個方面進行實踐闡述，偏向于落地：

以上的所有操作過程基于整個DevOps/GitOps/DataOps架構(gòu)進行整合，過程形成流水線管理，每個架構(gòu)師設(shè)計有自己的情況，我有我思。

過程實踐

這里通過幾個階段過程，將過程節(jié)點進行細化說明，以下為主要維護產(chǎn)品的團隊。

標準化和規(guī)劃化的要求，怎么樣做到項目和工程架構(gòu)的統(tǒng)一，怎么樣要求

如果說這個制定過程需要做很多部門、溝通、還有使用過程問題矛盾等，那就規(guī)避掉這些。

前幾次在其它團隊做平臺的時候，前期最大的問題，就是溝通和團隊人員的提升，這個會花掉很多力氣，特別是在意見上幾乎很難統(tǒng)一，團隊越大，這個問題就越突出，會給培訓(xùn)、還有各種技術(shù)思維的輸入等，做好前期的準備。但是這個成本在中小團隊成本是極高的，而且還有一個問題是人員流失的問題，培養(yǎng)出來了人走了，后來換了一個思路，做這塊的只需要一兩個高級人員，后期提供出代碼生成器和標準文檔，發(fā)給項目組和開發(fā)就行，其它的人員并不需要特別關(guān)注。

比如開發(fā)人員一定要會使用微服務(wù)？一定要會springcloud的么？其實不然，自己并不一定需要學(xué)習(xí)這個，會寫controller，還有查詢mybatis編寫即可，后面學(xué)習(xí)中會有遇到，這個過程可以做到無感。

開發(fā)人員會主動去查詢材料和學(xué)習(xí)，主動跟被動的區(qū)別，效果差異是極大的，后面定義好崗位職責的考核，根據(jù)過程做適當?shù)呐嘤?xùn)，這個過程團隊成長更快。

標準化前期部分主要參考社區(qū)的流程，還有架構(gòu)也一樣，但是這些不要緊，先有一版本，技術(shù)還有能力很快就會沉淀在前期架構(gòu)的人員上，這個過程會不斷的迭代，所以在這塊上的選人是很重要，至少能總結(jié)和有興趣，有優(yōu)化的主動性。在建設(shè)出來一版本標準規(guī)范之后，將代碼做核心公共包的封裝，再加上代碼生成器，出來即是規(guī)范，幾乎是可以做到對團隊人員的無感知。

這個過程差不多1個月左右。

在前期的框架封裝上避免過度封裝，這個是新人架構(gòu)師的一個痛點，會有非常多的idea，但是前期基本上都禁掉了，換成的思路是先出一版簡版的，再根據(jù)一些項目過程中，了解問題，再進一步的升級封裝。

這個過程經(jīng)歷過1個項目就基本上就比較成熟，包括架構(gòu)人員，具體時間看項目的情況。這個過程會遇到一些問題，也是允許的，這個是之前的培訓(xùn)成本遺留下來導(dǎo)致的，這個時候可以多一些使用培訓(xùn) ，針對問題來進行統(tǒng)一的培訓(xùn)或者指導(dǎo)處理，過程多與團隊溝通解決掉即可。

基礎(chǔ)環(huán)境能力的搭建，使用的資源有多少，后期怎么管理

這里基礎(chǔ)環(huán)境搭建分幾個部分，一個是devops/gitops/dataops的環(huán)境搭建，還有公共服務(wù)組件的發(fā)布搭建，比如數(shù)據(jù)治理組件、技術(shù)組件、運維組件等。

這也是基于規(guī)范標準的要求，比如自動發(fā)布管理，這里做成參數(shù)型的配置，還有數(shù)據(jù)抽取組件也一樣，做成腳本型和參數(shù)型的設(shè)計，使用Git統(tǒng)一的管理，主要是為了更好的做好記錄，權(quán)限，留痕等，結(jié)合jenkins整合起來的，包括運維腳本、CICD、數(shù)據(jù)抽取等，使用人員比較少，所以在這塊上的資源壓力倒不大。

目前整個環(huán)境使用了3臺服務(wù)器，主要是一臺jenkins/技術(shù)組件/數(shù)據(jù)組件，主要的配置如下：

這主要是得益于微小團隊的產(chǎn)品開發(fā)維護，另外我們數(shù)據(jù)倉庫并不一定要求使用Hadoop套件，而且針對項目情況來進行適配選型，所以這并不是很大的壓力，而且一些高峰的操作，比如備份和巡檢、數(shù)據(jù)抽取等會在晚上執(zhí)行。

在實際項目中，會根據(jù)項目的情況抽取產(chǎn)品部署，這主要利益于微服務(wù)架構(gòu)，可拆分的能力，將耦合降到最低，比如有些可能需要的數(shù)據(jù)組件只有一兩個，那就部署一兩個，做好對應(yīng)的適配資源即可。以降低項目成本和維護成本，還有客戶成本等。

這個過程的管理基本上是寫好腳本之后，就根據(jù)監(jiān)控即可，這里集成了釘釘，主要是方便管理，這個任務(wù)大概是250多個任務(wù)，基本上都是利益于GitOps的理念，這里需要的是它的理念，然后整合起來的，過程主要是針對于Git基線，而不是需要針對于所有，從Git流程的最終結(jié)果是釘釘通知，這樣以降低學(xué)習(xí)成本還有規(guī)避掉過多的人工操作。

這個的搭建和規(guī)范建設(shè)，大概是2個星期左右，當然，這主要得益于經(jīng)驗的積累，只需要做調(diào)試，如果從零開始，可能需要1-2個月左右考慮會比較合適。

產(chǎn)品的迭代升級管理，還有過程怎么降低產(chǎn)品管理成本

這里類似于運營管理，這里的運營主要是指內(nèi)部團隊的運營，將ISV和其它部門當做客戶即可。

這里的組件比較多，針對于微型團隊來說，如果沒有統(tǒng)一的基礎(chǔ)設(shè)施和規(guī)范是很難的，這里主要是利益于微服務(wù)架構(gòu)和容器化管理，還有中臺架構(gòu)思維。

公共和基礎(chǔ)服務(wù)已經(jīng)將大部分非業(yè)務(wù)邏輯的都做了，也抽取成公共的服務(wù)能力，比如日志、登陸、公共權(quán)限、前端埋點、數(shù)據(jù)抽取、監(jiān)控等，都已經(jīng)是打成基礎(chǔ)的能力，每個服務(wù)都是可以一開始就擁有這些能力，也可拔插，主要升級組件內(nèi)的邏輯，比如集成監(jiān)控。

當然還有很多。

將公共組件進行沉淀，在各個產(chǎn)品只需要，也只能保留業(yè)務(wù)部分，而且一定不能過分的建設(shè)每個組件的公共部分，這樣會導(dǎo)致后期的升級和版本管理的困難，這也是中小微團隊的靈活性，就是因為小，在調(diào)整的時候，可以統(tǒng)一，每次升級會把需要調(diào)整的部分列出來，然后發(fā)給對應(yīng)的組件即可?，F(xiàn)在基本上是調(diào)整版本號即可，因為公共部分的抽取已經(jīng)很好了，比如前端，后臺，還有ORM層等，基本上業(yè)務(wù)組件并不需要調(diào)整。

另一種是功能的升級，這個過程根據(jù)業(yè)務(wù)調(diào)整單獨組件即可，小的功能升級會做好接口的兼容，大的單獨提供出新的接口，同時加上版本號。在這部分比較擔心的是穩(wěn)定性，所以在工程模塊上的劃分，也是做了嚴格的限制，也主要得益于DDD架構(gòu)思維，但并不是完全照搬，而是根據(jù)實際做了調(diào)整，取其優(yōu)勢即可，工程模塊如下：

這里抽取了一個domain服務(wù)組件，這個服務(wù)組件一定要資深人員才能處理，其它的非核心邏輯都在gateway和provide模塊里面，調(diào)用domain工程的寫好的邏輯，其它的人員寫前端和接口即可。

這么做的原因是為確保服務(wù)的穩(wěn)定性，以前遇到過挺多類似的情況，初級的維護人員和經(jīng)驗不足的碰到和核心服務(wù)的邏輯，但是熟悉程度不夠，導(dǎo)致了很多不穩(wěn)定的因素，在這塊上是做了很嚴格的要求限制。

實在不行，就重寫接口，但是不會影響到核心邏輯，核心邏輯部分主要是由更高一級的人員來編寫維護的，一個是編碼的質(zhì)量，另一個是穩(wěn)定性，以確保后期的產(chǎn)品的質(zhì)量。

基于上面的技術(shù)思維和管理規(guī)范，組件的升級，比如當前的國產(chǎn)庫適配、漏洞的升級等基本上是調(diào)整核心包的版本號即可，功能的升級也是通過核心和外圍接口兩個概念進行區(qū)別，不需要說再花時間去深入到模塊和業(yè)務(wù)等，調(diào)用接口實現(xiàn)。

提交代碼之后，就是走剛剛上面提到自動化流程，等釘釘通知和容器監(jiān)控狀態(tài)，然后結(jié)合界面測試。

項目交付實施的過程是怎么樣的，怎么做項目交付支撐

這個是數(shù)字中臺價值輸出體現(xiàn)之一，主要是偏向于跟ISV團隊的整合，讓ISV團隊主要考慮業(yè)務(wù)邏輯的事情。這里主要提供幾個能力：

通過以上為ISV團隊賦能，主要的目標是項目的落地，提升ISV的能力提升，這也是數(shù)字中臺的價值體現(xiàn)之一。

ISV團隊要考慮的是業(yè)務(wù)，而我們主要的目標是不要讓他們深入到技術(shù)、還有非業(yè)務(wù)性的內(nèi)容上，同時提升出好的工具給他們。

這樣更好的進行區(qū)分職責邊界，這個其實也是個矛盾點。目前是通過代碼生成器生成出業(yè)務(wù)組件，然后在這個組件里面只包含業(yè)務(wù)，其它非技術(shù)的組件交互（比如賬號權(quán)限）通過Api來進行處理，有哪個API就有哪個能力，以規(guī)避掉職責不清的問題。

業(yè)務(wù)組與整個數(shù)字中臺進行對接的是Git還有可視化的界面，并不需要它關(guān)注太多的東西，業(yè)務(wù)邏輯提交到Git之后，其它的流水線會自動走下來，然后得到對應(yīng)的訪問鏈接即可。

而數(shù)字中臺就使用產(chǎn)品型的交付，根據(jù)項目情況進行服務(wù)的抽取，其它的商務(wù)不做太多的接觸，只需要關(guān)注數(shù)字中臺產(chǎn)品體系的內(nèi)容，一個是沉淀，另一個是項目涉及到的面比較多，避免平臺人員沉入到里面，而無法抽出，同時也規(guī)避掉ISV團隊過度依賴平臺人員，為后期的維護考慮。

這里也有一個特別需要注意的項，就是職責角色一定要區(qū)分，不能互相深入，比如平臺人員做項目的事情，項目人員做平臺的事情，這會無形中增大成本和提高項目風險，可能會導(dǎo)致后期的管理混亂，商務(wù)和項目上糾結(jié)不清，如果項目更多的的，會以提工單的形式來進行反饋，比如需求和問題。

這個過程一般是在項目前期一兩個星期會有比較多的溝通，ISV后期和熟悉之后，后面的合適會比較順利，即使是在ISV新人切入，這個過程成本也會低很多。

總結(jié)

數(shù)字中臺本身是一個很大的概念，但是在過程怎么使用和抽取，還有適配團隊，其實并不代表會有一個非常高的成本管理，而是根據(jù)團隊來進行適配，以體驗和獲取到云原生時代、新技術(shù)的便捷紅利，以提升團隊的技術(shù)能力、競爭能力、還有新的商業(yè)模式，在數(shù)字化的時代做好準備，以適應(yīng)當前行業(yè)的發(fā)展。

以上為在數(shù)字中臺建設(shè)和管理的一些實踐，希望可以給一些在往這塊方向的團隊一些參考。