很久沒有寫文章記錄了，上一篇文章像流水賬一樣，把所見所聞一個個記錄下來。這次專門聊聊DevOps平臺的建設(shè)吧，有些新的體會和思考，希望給正在做這個事情的同學(xué)們一些啟發(fā)吧。
DevOps落地實(shí)踐點(diǎn)滴和踩坑記錄-(1)

企業(yè)落地DevOps該買商用還是自己研發(fā)呢？

很多團(tuán)隊(duì)剛開始都會問這個問題，我的回答如下

• 如果團(tuán)隊(duì)人數(shù)少，技術(shù)棧或者技術(shù)債務(wù)不是很多，歷史包袱不重，領(lǐng)導(dǎo)急于看到成果，可以使用devops商業(yè)產(chǎn)品。前提還是看商業(yè)產(chǎn)品是否滿足你們目前場景。
• 自建工具鏈，分成簡單工具搭建 和 更上一層的二次開發(fā)做平臺，看你們需要哪種。
  • 前者相對容易點(diǎn)，比如常見的gitlab+jenkins+harbor/nexus+kubernetes等這樣的組合
  • 后者 前期需要投入成本，還是看 你們目標(biāo)是什么，解決什么問題。

以終為始，看目標(biāo)，找合適的方案，是比較合適的。平臺可大可小，功能也可大可小，解決的問題也可大可小，看看目前的問題是什么？

有哪些好用的DevOps價值流交付平臺推薦？

國外

• Azure DevOps

國內(nèi)

• Coding
• 藍(lán)鯨
• JD行云
• 阿里云效
• 簡單云ezone
• 華為DevCloud

國內(nèi)很多，以上這些都算是整合各個環(huán)節(jié)比較綜合的，其他像禪道、Ones等這些項(xiàng)目管理類平臺雖然號稱DevOps平臺，但是他們更擅長垂直領(lǐng)域，不是綜合性平臺。

有哪些好用的DevOps VSDP（DevOps價值流交付平臺）推薦？ - 知乎

自研DevOps平臺面臨的問題

上面說的平臺都很好，但是面對上千規(guī)模的研發(fā)團(tuán)隊(duì)，往往會有“心有余力不足”，“殺雞用牛刀，但是還殺不了雞”的感覺。說白了，就是買了還是做二次開發(fā)，并且往往還不是簡單二次開發(fā)這么簡單。聽我細(xì)細(xì)道來

1. 企業(yè)內(nèi)部各平臺魚龍混雜

對于中小型企業(yè)，你可以通過采購?fù)獠緿evOps平臺服務(wù)的方式，快速形成戰(zhàn)斗力。但是對于一定規(guī)模的企業(yè)，并不是一窮二白，而是各種平臺已經(jīng)存在了。
這是一個企業(yè)的案例，很明顯管需求的在OA, 管工單在一個系統(tǒng)，項(xiàng)目管理在另外一個系統(tǒng)。那我買了外面的平臺（一般都是全家桶的解決方案），到底和我內(nèi)部系統(tǒng)怎么融合呢？

• 舉個例子，如果公司已經(jīng)用了JIRA, 外面大部分DevOps平臺都自帶同類功能的模塊，你讓我把JIRA干掉，買你的產(chǎn)品，盡管JIRA國內(nèi)有點(diǎn)水土不服，但是這需要管理者做出抉擇，哪怕是數(shù)據(jù)遷移也是需要成本和時間的。

2. 自研平臺本質(zhì)還是“企業(yè)的數(shù)字化轉(zhuǎn)型”

對于傳統(tǒng)軟件企業(yè)，他們要的平臺不僅僅是一個跑CI/CD，做部署的平臺，更重要的是能夠度量內(nèi)部變革成果的平臺。提到度量，就意味著你要打通整個研發(fā)過程所有環(huán)節(jié)，從外部客戶需求，到內(nèi)部研發(fā)環(huán)節(jié)，到對外發(fā)布，再到產(chǎn)品反饋，形成閉環(huán)。
可以想象，變革過程會遇到多少不同的角色，不同的平臺，所以研發(fā)打造自己平臺的過程也是企業(yè)內(nèi)部自我變革的過程，這個過程會很漫長，也會很痛。

• 對于互聯(lián)網(wǎng)企業(yè)，他們必須擁抱變化，快速搶占市場，所以從基礎(chǔ)設(shè)施到人員素質(zhì)，一定程度上比傳統(tǒng)軟件企業(yè)會好很多，數(shù)字化程度會好很多，他們關(guān)注更多其實(shí)是線上的快速發(fā)布，回滾，試錯，監(jiān)控告警。技術(shù)棧上，相對容易統(tǒng)一，個性化定制會很少，一般都是主干開發(fā)主干發(fā)布，或者主干開發(fā)分支發(fā)布。
• 可是，對于傳統(tǒng)企業(yè)，他們的特點(diǎn)是產(chǎn)品線豐富，客戶定制化需求多，重產(chǎn)品定制（輕運(yùn)維），他們更需要規(guī)范化的管理和規(guī)則限制。但是往往他們的技術(shù)設(shè)施（容器化，環(huán)境快速生成）比較落后，研發(fā)人員不太重視工程化手段解決問題，技術(shù)棧沒有很好統(tǒng)一，工具各個團(tuán)隊(duì)各自為政，因此整合工具鏈條就變得更艱難。

所以自研平臺本質(zhì)還是企業(yè)自我的變革和決心，如果把傳統(tǒng)軟件企業(yè)比作工廠，通過自研平臺進(jìn)行功能和數(shù)據(jù)的整合，就是希望構(gòu)建一個真正的“數(shù)字化“工廠，讓信息流動和共享。

3. 自研平臺建設(shè)離不開部門間的拉通對齊

如下圖所示，DevOps涉及諸多研發(fā)階段和領(lǐng)域

• 項(xiàng)目管理
• 需求/缺陷跟蹤
• 代碼管理
• 構(gòu)建/部署/測試
• 發(fā)布
• 日志監(jiān)控

在企業(yè)內(nèi)部剛起步階段，可能缺乏專業(yè)的DevOps專家和人員，以為只是通過建設(shè)不同領(lǐng)域的工具平臺，不知道如何拉通，為什么拉通，甚至可能不同的部門團(tuán)隊(duì)負(fù)責(zé)不同領(lǐng)域的工具。
缺乏最終目標(biāo)的對齊和部門間拉通，可能導(dǎo)致如下問題

• 影響整體技術(shù)架構(gòu)設(shè)計(jì)，可能導(dǎo)致很多返工
• 部門間配合缺失，各自為政，不僅無法形成合力，還可能相互掣肘，相互可能在做重復(fù)工作
• 無法制定長遠(yuǎn)平臺演進(jìn)規(guī)劃
• 數(shù)據(jù)拉通遙遙無期
• 最終可能導(dǎo)致DevOps變革的失敗，團(tuán)隊(duì)士氣低沉，領(lǐng)導(dǎo)層看不到預(yù)期效果

解決思路-組織結(jié)構(gòu)

1. 成立虛擬的過程改進(jìn)團(tuán)隊(duì)，包含組織級研效管理團(tuán)隊(duì)，平臺工具建設(shè)團(tuán)隊(duì)，效能/工程教練團(tuán)隊(duì)，對業(yè)務(wù)研發(fā)團(tuán)隊(duì)進(jìn)行支撐
2. 業(yè)務(wù)研發(fā)團(tuán)隊(duì)對效能提高負(fù)主要責(zé)任，每個月業(yè)務(wù)技術(shù)leader 匯報(bào)進(jìn)展；業(yè)務(wù)研發(fā)團(tuán)隊(duì)需要證明自己技術(shù)架構(gòu)改進(jìn)，解決成員的抱怨；需要對自己團(tuán)隊(duì)負(fù)責(zé)；
3. 杜絕“工具平臺團(tuán)隊(duì)”對效能結(jié)果負(fù)責(zé)的局面，工具團(tuán)隊(duì)一般提供的是通用的功能，對于“北極星”指標(biāo)（ps:產(chǎn)品成功的關(guān)鍵指標(biāo)）影響有限； 對技術(shù)負(fù)責(zé)，打包更快，上線工作流更好
4. 效能/工程教練團(tuán)隊(duì)要走進(jìn)一線，和團(tuán)隊(duì)成員面談，深刻了解團(tuán)隊(duì)“痛點(diǎn)”，進(jìn)行輔導(dǎo)
5. 組織級研效管理團(tuán)隊(duì)（一般是PMO組織），建立組織級規(guī)范進(jìn)行發(fā)布；（PS: 實(shí)際情況中，該部門可能需要DevOps工具/教練團(tuán)隊(duì)的支撐，特別是工程技術(shù)方面，避免規(guī)范無法落地）
6. 需要一位德高望重，技術(shù)能力威望都還可以的領(lǐng)導(dǎo)統(tǒng)領(lǐng)過程改進(jìn)團(tuán)隊(duì) （PS: 解決拉通過程的困難，幫助協(xié)調(diào)資源，敢于拍板）

4. 圍繞“版本”和“關(guān)聯(lián)”做文章，構(gòu)建研發(fā)領(lǐng)域模型

• **”版本“ **記錄了整個研發(fā)過程的演進(jìn)，通過“版本”作為紐帶，串聯(lián)起來真?zhèn)€研發(fā)過程的元數(shù)據(jù)，再合適不過。
• ”版本“的規(guī)范化，也是流程規(guī)范化的重要體現(xiàn)，只有“版本”規(guī)范化，過程才可能規(guī)范化。試想，如果你的組織連規(guī)范的版本號以及發(fā)布規(guī)范都沒有，其他自動化手段就根本不用提
• “版本”關(guān)聯(lián)元數(shù)據(jù) - 在筆者看來，是整個DevOps平臺的重要目標(biāo)之一，如果沒有做到這一點(diǎn)，必然影響價值流打通

構(gòu)建研發(fā)過程領(lǐng)域模型，可以幫助平臺建設(shè)者理清業(yè)務(wù)實(shí)體之間的關(guān)系，指導(dǎo)平臺的技術(shù)演進(jìn)，串聯(lián)起領(lǐng)域?qū)嶓w也是整個DevOps平臺的重要目標(biāo)一致

5. 圍繞組織內(nèi)真實(shí)業(yè)務(wù)場景，避免照虎畫貓

在我們自己建設(shè)DevOps平臺過程中，往往會參考一些商用的平臺，這個無可厚非，但是要避免“機(jī)械模仿”。任何一家公司的DevOps演進(jìn)都不是一蹴而就，或多或少都有歷史原因，模仿的同時要思考他們?yōu)槭裁匆@樣做，是不是真的適合自己的場景，借鑒可以，但是要弄清楚為什么需要。
舉例說明

• 大部分公有云的DevOps平臺基因里都或多或少都有互聯(lián)網(wǎng)的基因，它們的對于持續(xù)部署發(fā)布（灰度，藍(lán)綠）會格外重視，那么作為傳統(tǒng)軟件企業(yè)，你是否真的需要？
• 再比如，這些平臺的流水線編排都很靈活，但是在你的企業(yè)過度的靈活是否真的有用？ 也許開發(fā)團(tuán)隊(duì)只需要傻瓜式的，甚至無腦，嚴(yán)格控制的流程呢？

熟悉組織的軟件研發(fā)活動，通過和業(yè)務(wù)研發(fā)團(tuán)隊(duì)座談的方式，收集真實(shí)的痛點(diǎn)，在“靈活模式”和“死板模式”中需求平衡。功能做的再酷炫，不能解決實(shí)際問題，也是沒有任何價值的。
如圖所示，可以通過繪制業(yè)務(wù)流程圖的方式，將平臺的業(yè)務(wù)流程和實(shí)際的業(yè)務(wù)場景結(jié)合，指導(dǎo)平臺分階段建設(shè)，業(yè)務(wù)與技術(shù)演進(jìn)相結(jié)合。

總結(jié)

上面我分享的幾個問題，相信你都會遇到，這里僅供參考。每個組織想要的DevOps平臺是完全不一樣的，別人的場景功能未必就適合自己，主要還是以解決問題為目的。
DevOps實(shí)踐過程是漫長和艱難的，平臺能力是整個組織一起努力的結(jié)果，不要試圖你的團(tuán)隊(duì)單槍匹馬搞成這個事情，離不開你的“客戶”（需求），離不開上層領(lǐng)導(dǎo)的支持（自上而下推動），離不開組織運(yùn)營規(guī)范的牽引（流程規(guī)范）。