作者|馮文輝

(相關(guān)資料圖)

我們都知道DevOps誕生于互聯(lián)網(wǎng)企業(yè)。Netflix、AWS等互聯(lián)網(wǎng)企業(yè)號(hào)稱(chēng)每天往生產(chǎn)環(huán)境部署成百上千次。如此之快的部署頻率讓眾多傳統(tǒng)企業(yè)也躍躍欲試。所以大量的傳統(tǒng)企業(yè)都紛紛投入巨資打造自己的DevOps基礎(chǔ)設(shè)施 ，希望就此可以顯著提高開(kāi)發(fā)效率，加快新項(xiàng)目或新產(chǎn)品的投產(chǎn)速度。但是，他們對(duì)于DevOps基礎(chǔ)架構(gòu)是什么樣子，需要具備哪些能力，如何構(gòu)建，并沒(méi)有一個(gè)很清晰的規(guī)劃。

要想規(guī)劃與打造適合傳統(tǒng)企業(yè)的DevOps基礎(chǔ)設(shè)施，首先需要弄清楚它必須具備哪些能力。我們嘗試從基礎(chǔ)、開(kāi)發(fā)、測(cè)試、運(yùn)維、項(xiàng)目管理五個(gè)維度來(lái)分析對(duì)DevOps的需求，從而探索DevOps基礎(chǔ)設(shè)施與之對(duì)應(yīng)的能力，并映射到一款業(yè)界流行的軟件工具來(lái)承載這個(gè)能力。需要注意的是這里的目的是具象與實(shí)例化，而不是推薦使用某款軟件工具。大家要根據(jù)自身實(shí)際來(lái)進(jìn)行工具選型。

基礎(chǔ)

對(duì)于DevOps來(lái)說(shuō)，最重要的基本能力就是健全的云計(jì)算能力。對(duì)于傳統(tǒng)企業(yè)來(lái)說(shuō)，就是要構(gòu)建完善的云平臺(tái)。DevOps所需的高度自動(dòng)化必須得有強(qiáng)大的云平臺(tái)支撐。如基礎(chǔ)設(shè)施即代碼，彈性伸縮等高效的實(shí)踐，沒(méi)有云平臺(tái)的保障，根本實(shí)現(xiàn)不了。云是DevOps基礎(chǔ)設(shè)施架構(gòu)的基石。沒(méi)有完善的云平臺(tái)與云計(jì)算能力，基本上不用考慮DevOps。云平臺(tái)主要從以下3個(gè)方面對(duì)DevOps提供支撐（括號(hào)內(nèi)為承載此能力的軟件工具）：

基于IaaS的自服務(wù)與環(huán)境編排能力（VMWare）基于PaaS的彈性伸縮能力（K8s）基于SaaS的軟件服務(wù)能力

其中，自服務(wù)主要指的是環(huán)境的按需快速生成；環(huán)境編排主要指的是基礎(chǔ)設(shè)施即代碼；彈性伸縮主要指的是對(duì)于計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)等資源的自動(dòng)擴(kuò)容機(jī)制。

對(duì)于傳統(tǒng)企業(yè)來(lái)說(shuō)，考慮到安全性，一般還是會(huì)優(yōu)先考慮自建私有云，至少是混合云。當(dāng)然，完全選擇公有云也是可以的。如果企業(yè)有這個(gè)膽識(shí)與魄力完全基于公有云搭建云平臺(tái)，某種意義上也反映出它的DevOps規(guī)劃是完善與考慮周全的。對(duì)于他們來(lái)說(shuō)，構(gòu)建DevOps基礎(chǔ)設(shè)施或許是一件把握十足的事情。

開(kāi)發(fā)

對(duì)于開(kāi)發(fā)來(lái)說(shuō)，最重要的需求來(lái)自三方面：開(kāi)發(fā)效率、代碼質(zhì)量、實(shí)時(shí)反饋。對(duì)應(yīng)的能力如下：

開(kāi)發(fā)效率：

分布式代碼管理能力（GitLab）持續(xù)集成能力（Jenkins）持續(xù)部署能力（Jenkins）依賴(lài)管理能力（Nexus）

代碼質(zhì)量：

靜態(tài)代碼掃描能力（Sonar/Fortify/InSpec）執(zhí)行單元測(cè)試能力（Jenkins）測(cè)試環(huán)境制品管理能力（Nexus）

實(shí)時(shí)反饋：

可視化能力（電視墻）構(gòu)建與單元測(cè)試結(jié)果通知的能力（Email）

需要解釋的第一點(diǎn)是在代碼管理上，分布式的代碼管理會(huì)比中央式的代碼管理高效。中央式的代碼倉(cāng)庫(kù)依賴(lài)中心化的代碼托管服務(wù)器，如果它有問(wèn)題或者網(wǎng)絡(luò)中斷，代碼將不能被提交，這將嚴(yán)重影響開(kāi)發(fā)效率；分布式的代碼倉(cāng)庫(kù)是去中心化的，并沒(méi)有中央代碼托管服務(wù)器，每個(gè)開(kāi)發(fā)者本機(jī)都是一份完整的代碼副本，這意味著即使網(wǎng)絡(luò)出現(xiàn)問(wèn)題了，開(kāi)發(fā)者仍然可以提交代碼。除此之外，分布式代碼倉(cāng)庫(kù)提供的靈活性也是中央式代碼倉(cāng)庫(kù)所不能比擬的。所以，這里我們選擇GitLab作為代碼倉(cāng)庫(kù)，而不建議使用SVN等的中央代碼倉(cāng)庫(kù)。

第二點(diǎn)是在依賴(lài)管理上。一個(gè)具象化的例子是關(guān)于Maven依賴(lài)的管理。在很多傳統(tǒng)企業(yè)里面，尤其是金融企業(yè)，外網(wǎng)訪(fǎng)問(wèn)權(quán)限是受限的，很多開(kāi)發(fā)人員都不能訪(fǎng)問(wèn)外網(wǎng)。所以非常有必要在內(nèi)網(wǎng)建立所謂的私庫(kù)，作為代理與外網(wǎng)的公共庫(kù)同步。開(kāi)發(fā)人員在本地構(gòu)建時(shí)通過(guò)訪(fǎng)問(wèn)私庫(kù)來(lái)解決依賴(lài)問(wèn)題。如果沒(méi)有建立私庫(kù)，開(kāi)發(fā)人員必須得花費(fèi)大量時(shí)間解決依賴(lài)問(wèn)題。而且這種問(wèn)題在日后有新的依賴(lài)引入時(shí)會(huì)不斷出現(xiàn)，開(kāi)發(fā)人員將為此焦頭爛額，開(kāi)發(fā)效率嚴(yán)重受影響。

另外在代碼掃描上，由于企業(yè)安全性的要求，比較全面的是從質(zhì)量、安全和合規(guī)三個(gè)方面進(jìn)行掃描。Sonar、Fortify、InSpec與此三個(gè)能力對(duì)應(yīng)。還有從架構(gòu)方面進(jìn)行掃描的，但考慮到相關(guān)的技術(shù)其實(shí)還不是特別成熟，暫不考慮。不過(guò)有這方面特殊要求的可以深入研究一下。

對(duì)于持續(xù)集成，持續(xù)部署與執(zhí)行單元測(cè)試，通常是通過(guò)持續(xù)交付流水線(xiàn)來(lái)串聯(lián)實(shí)現(xiàn)，所以把承載能力的工具都?xì)w結(jié)到Jenkins上。需要注意的一點(diǎn)是這里的持續(xù)部署指的是部署到測(cè)試環(huán)境，并不包括生產(chǎn)環(huán)境。我把對(duì)生產(chǎn)環(huán)境的部署放到運(yùn)維。實(shí)際上，對(duì)于大都數(shù)傳統(tǒng)企業(yè)來(lái)說(shuō)，現(xiàn)階段很難做到真正意義上的DevOps to Production。能做到DevOps to Pre-Production，甚至只是DevOps to UAT就已經(jīng)很不錯(cuò)了。造成這樣的原因是復(fù)雜而多方面的，包括要滿(mǎn)足監(jiān)管的需要，要通過(guò)生產(chǎn)環(huán)境審批的流程等等，這里就不展開(kāi)了。

可視化是為了實(shí)時(shí)展現(xiàn)持續(xù)交付流水線(xiàn)執(zhí)行情況與單元測(cè)試的執(zhí)行報(bào)告，提高團(tuán)隊(duì)的反饋速度與響應(yīng)力。它需要可視化設(shè)備，如大屏幕電視，CI報(bào)警燈的支持；同時(shí)，我們也需要通過(guò)郵件的方式把自動(dòng)化構(gòu)建與單元測(cè)試的結(jié)果自動(dòng)發(fā)送給相關(guān)的人員。

測(cè)試

而對(duì)于測(cè)試來(lái)說(shuō)，最主要的需求來(lái)自測(cè)試效率與實(shí)時(shí)反饋兩方面。對(duì)應(yīng)所需的能力如下：

測(cè)試效率：

自動(dòng)化測(cè)試能力（Jenkins）并行測(cè)試能力 (Selenium-Grid)

實(shí)時(shí)反饋：

可視化能力（電視墻）測(cè)試結(jié)果通知的能力（Email）

比較好的實(shí)踐是通過(guò)持續(xù)交付流水線(xiàn)串聯(lián)自動(dòng)化測(cè)試，在測(cè)試環(huán)境部署成功后觸發(fā)自動(dòng)化測(cè)試。另外自動(dòng)化測(cè)試種類(lèi)繁多，對(duì)應(yīng)的工具也比較多，例如利用Jmeter來(lái) 實(shí)施接口測(cè)試或者輕量級(jí)的壓力測(cè)試，利用Cucumber來(lái)實(shí)施BDD測(cè)試等，這里就不一一列出了。另外，為了提供測(cè)試的效率，有必要考慮把自動(dòng)化測(cè)試用例分組，進(jìn)行并行測(cè)試。這需要具備快速的測(cè)試執(zhí)行環(huán)境生成能力，應(yīng)該通過(guò)基礎(chǔ)設(shè)施即代碼在云平臺(tái)的PaaS層滿(mǎn)足。

與開(kāi)發(fā)一樣，測(cè)試階段也需要測(cè)試報(bào)告的可視化與結(jié)果通知。

運(yùn)維

而對(duì)于運(yùn)維來(lái)說(shuō)，最主要的需求來(lái)自變更風(fēng)險(xiǎn)控制、實(shí)時(shí)運(yùn)維反饋、生產(chǎn)事件響應(yīng)三方面。對(duì)應(yīng)所需的能力如下：

變更風(fēng)險(xiǎn)控制：

生產(chǎn)環(huán)境變更管理能力（Service Desk）生產(chǎn)環(huán)境制品管理能力（Nexus）生產(chǎn)環(huán)境自動(dòng)部署能力（CodeDeploy）

實(shí)時(shí)運(yùn)維反饋：

生產(chǎn)環(huán)境運(yùn)行狀況監(jiān)控能力（Prometheus）可視化能力（Grafana / 電視墻）

生產(chǎn)事件響應(yīng)：

實(shí)時(shí)告警能力（Support Mobile）生產(chǎn)事件管理能力（Service Desk）知識(shí)傳承能力（Confluence）

正如在分析開(kāi)發(fā)階段所需能力時(shí)所說(shuō)的，我把對(duì)生產(chǎn)環(huán)境的部署放到運(yùn)維。原因是企業(yè)的持續(xù)交付流水線(xiàn)往往都打不通到生產(chǎn)環(huán)境。表面的原因是因?yàn)橐裱璉TSM，一個(gè)歷史久遠(yuǎn)的被大量企業(yè)廣泛采納的IT服務(wù)管理框架，所以存在一個(gè)生產(chǎn)變更的手工審批流程，深層次的原因就復(fù)雜了，這里不展開(kāi)。變更管理與事件管理的理念也來(lái)自于ITSM 。但隨著DevOps的流行，ITSM似乎顯得過(guò)于重量級(jí)，與DevOps的理念相違背。于是業(yè)界有人提出輕量級(jí)ITSM，但也僅僅是提出，沒(méi)有看到進(jìn)一步的落地細(xì)節(jié)。所以，對(duì)于傳統(tǒng)企業(yè)來(lái)說(shuō)，在運(yùn)維階段，還是不得不具備變更審批管理與事件管理的能力以遵循ITSM，否則將會(huì)有合規(guī)審計(jì)的風(fēng)險(xiǎn)。

另外，對(duì)于運(yùn)維來(lái)說(shuō)，知識(shí)的傳承非常重要，非常有必要建立運(yùn)維的知識(shí)庫(kù)。一方面 有利于對(duì)事件的復(fù)盤(pán)回顧，另一方面也有助于日后參加運(yùn)維的人員盡快熟悉與掌握系統(tǒng)的運(yùn)維技能。

這里需要注意的一點(diǎn)是Service Desk不是某一款軟件的名字，而是ITIL（信息技術(shù)基礎(chǔ)架構(gòu)庫(kù)，可認(rèn)為是ITSM的落地實(shí)現(xiàn)）里面承載變更管理與事件管理的工具統(tǒng)稱(chēng)。業(yè)界有很多產(chǎn)品實(shí)現(xiàn)，但基本不開(kāi)源，也沒(méi)有一款是公認(rèn)比較好的，所以這里不表明具體產(chǎn)品。

項(xiàng)目管理

對(duì)于項(xiàng)目管理，最主要的需求是迭代支持、分析度量、變更追蹤、實(shí)時(shí)反饋四個(gè)方面。對(duì)應(yīng)所需的能力如下：

迭代支持：

產(chǎn)品代辦列表管理能力（Jira）用戶(hù)故事管理能力（Jira）

分析度量：

數(shù)據(jù)統(tǒng)計(jì)能力（Jira）

變更追蹤：

需求、代碼變更、CI關(guān)聯(lián)能力（Jira）用戶(hù)故事與設(shè)計(jì)、測(cè)試等相關(guān)文檔關(guān)聯(lián)能力（Jira / Confluence）

實(shí)時(shí)反饋：

可視化能力（TV / 物理看版）DevOps基礎(chǔ)設(shè)施架構(gòu)規(guī)劃全景

綜合以上5點(diǎn)分析，可以得出一個(gè)傳統(tǒng)企業(yè)的DevOps基礎(chǔ)設(shè)施架構(gòu)架構(gòu)規(guī)劃的全景圖：

其中，三角形的左側(cè)負(fù)責(zé)構(gòu)建底層的云平臺(tái)，是整個(gè)DevOps基礎(chǔ)架構(gòu)的基石；三角形右側(cè)是DevOps基礎(chǔ)架構(gòu)需要具備的能力，對(duì)應(yīng)的工具示例以及其在云平臺(tái)的部署層次。這個(gè)架構(gòu)不是一成不變的，而是應(yīng)該隨著實(shí)際需求變化而持續(xù)演化，能力也要跟著持續(xù)提升。

通過(guò)這幅全景圖，我們可以看到大部分的能力都以SaaS服務(wù)的形式呈現(xiàn)。這意味著企業(yè)可以建立中心化的SaaS服務(wù)提供給所有開(kāi)發(fā)團(tuán)隊(duì)使用。并行測(cè)試的執(zhí)行環(huán)境通過(guò)PaaS平臺(tái)按需自動(dòng)生成，測(cè)試執(zhí)行完畢后自動(dòng)銷(xiāo)毀。唯一比較特殊的是持續(xù)集成。首先我在這里是把持續(xù)集成放在了IaaS層。原因稍后解釋。如果是基于Jenkins，可以利用其Master-Slave機(jī)制實(shí)現(xiàn)分布式并行構(gòu)建。Master作為控制的Host，主要負(fù)責(zé)任務(wù)分配與調(diào)度，利用虛擬機(jī)部署IaaS層比較合適；slave作為執(zhí)行機(jī)，利用容器部署在PaaS，在構(gòu)建時(shí)立刻拉起，構(gòu)建完畢后立刻銷(xiāo)毀。

再談一站式DevOps平臺(tái)

來(lái)到這里，肯定有人會(huì)有疑問(wèn)，為什么這里我不把持續(xù)集成作為SaaS 服務(wù)？或者干脆直接引入成熟的DevOps效能平臺(tái)取代零散的工具鏈不更好嗎？不需要自己從0開(kāi)始一步一步搭建?。吭谖抑白稍?xún)過(guò)的客戶(hù)里面，的確有很多是直接引入如華為DevCloud（已改名CodeArts）等成熟的第三方DevOps平臺(tái)供所有團(tuán)隊(duì)使用，自研能力強(qiáng)的甚至?xí)?gòu)建自己的一站式DevOps效能平臺(tái)。

這種中心化的效能平臺(tái)固然是大勢(shì)所趨，但是如果規(guī)劃欠妥，會(huì)出現(xiàn)兩個(gè)比較嚴(yán)重的問(wèn)題。

第一個(gè)問(wèn)題是缺乏靈活性。越偏向開(kāi)發(fā)端，越需要靈活性。企業(yè)內(nèi)的項(xiàng)目都是千差萬(wàn)別的，它們對(duì)CI/CD等的需求也往往差異巨大；即使是雷同的項(xiàng)目，在對(duì)編譯構(gòu)建上的一些細(xì)枝末節(jié)的差別也很可能導(dǎo)致它們的持續(xù)交付流水線(xiàn)設(shè)計(jì)非常不一樣。中心化的DevOps效能平臺(tái)往往不能提供足夠的靈活性滿(mǎn)足這些需求，反而導(dǎo)致開(kāi)發(fā)者必須適應(yīng)其限制來(lái)設(shè)計(jì)流水線(xiàn)。第二個(gè)問(wèn)題是運(yùn)維支持跟不上。企業(yè)往往把中心化的DevOps效能平臺(tái)作為產(chǎn)品提供運(yùn)維支持，運(yùn)維人員才幾個(gè)人，卻要支持整個(gè)開(kāi)發(fā)部門(mén)所有開(kāi)發(fā)人員的DevOps需求，支持響應(yīng)肯定跟不上。由此而引出的來(lái)自開(kāi)發(fā)者的抱怨在我自己的工作經(jīng)歷中曾多次遇到過(guò)。如果是自研的平臺(tái)，問(wèn)題可能更嚴(yán)重，可能連一些基本的需求都還沒(méi)實(shí)現(xiàn)，開(kāi)發(fā)者就要開(kāi)始使用；開(kāi)發(fā)者提的新的需求更不知道要等到什么時(shí)候才能上線(xiàn)。以上提到的種種問(wèn)題的結(jié)果就是開(kāi)發(fā)團(tuán)隊(duì)會(huì)慢慢拋棄中心化的DevOps效能平臺(tái)，選擇自己搭建自己的持續(xù)集成平臺(tái)。

針對(duì)這兩個(gè)問(wèn)題，業(yè)界一些一站式的DevOps平臺(tái)也在著手去解決與平衡，其中來(lái)自華為的CodeArts算是做得比較好的。CodeArts脫胎于華為的DevCloud，凝聚了華為內(nèi)部這么多年來(lái)在軟件研發(fā)中實(shí)踐DevOps的經(jīng)驗(yàn)總結(jié)，本身從能力上來(lái)說(shuō)是相當(dāng)完備的。它提供了從需求管理、代碼托管、流水線(xiàn)、代碼檢查、構(gòu)建與部署的端到端的研發(fā)流程的支持，基本上滿(mǎn)足了一般開(kāi)發(fā)者對(duì)于DevOps的訴求?？紤]到移動(dòng)開(kāi)發(fā)越來(lái)越普及，CodeArts也集成了移動(dòng)端的測(cè)試平臺(tái)，開(kāi)發(fā)者可以在CodeArts選擇需要用戶(hù)運(yùn)行測(cè)試的主流真機(jī)型號(hào)（包括安卓和蘋(píng)果），然后就可以把測(cè)試下發(fā)到對(duì)應(yīng)的真機(jī)上執(zhí)行?？梢哉f(shuō)，發(fā)展到了現(xiàn)在，CodeArts已經(jīng)完全可以滿(mǎn)足一般開(kāi)發(fā)者的需求了。

如果開(kāi)發(fā)者確實(shí)需要一定的靈活性，比如說(shuō)需要與外部的Jenkins集成，或者需要從外部的倉(cāng)庫(kù)拉取代碼，CodeArts也是提供了足夠的靈活性來(lái)實(shí)現(xiàn)。CodeArts支持新增服務(wù)擴(kuò)展點(diǎn)，通過(guò)服務(wù)擴(kuò)展點(diǎn)，就可以跟Jenkins、Docker Repo、Nexus等外部系統(tǒng)集成，實(shí)現(xiàn)更強(qiáng)大的功能。同時(shí)，CodeArts本身也默認(rèn)提供了許多開(kāi)放的API，可供外部系統(tǒng)調(diào)用?？梢哉f(shuō)，在提供全面DevOps能力的同時(shí)，CodeArts也是提供全方位的靈活性，使得開(kāi)發(fā)者能夠更得心應(yīng)手的專(zhuān)注于業(yè)務(wù)領(lǐng)域的開(kāi)發(fā)工作，助力開(kāi)發(fā)者邁向商業(yè)成功。

關(guān)鍵詞：