作者|馮文輝
我們都知道DevOps誕生于互聯(lián)網(wǎng)企業(yè)。Netflix、AWS等互聯(lián)網(wǎng)企業(yè)號(hào)稱每天往生產(chǎn)環(huán)境部署成百上千次。如此之快的部署頻率讓眾多傳統(tǒng)企業(yè)也躍躍欲試。所以大量的傳統(tǒng)企業(yè)都紛紛投入巨資打造自己的DevOps基礎(chǔ)設(shè)施 ，希望就此可以顯著提高開發(fā)效率，加快新項(xiàng)目或新產(chǎn)品的投產(chǎn)速度。但是，他們對(duì)于DevOps基礎(chǔ)架構(gòu)是什么樣子，需要具備哪些能力，如何構(gòu)建，并沒有一個(gè)很清晰的規(guī)劃。
(資料圖片僅供參考)
要想規(guī)劃與打造適合傳統(tǒng)企業(yè)的DevOps基礎(chǔ)設(shè)施，首先需要弄清楚它必須具備哪些能力。我們嘗試從基礎(chǔ)、開發(fā)、測試、運(yùn)維、項(xiàng)目管理五個(gè)維度來分析對(duì)DevOps的需求，從而探索DevOps基礎(chǔ)設(shè)施與之對(duì)應(yīng)的能力，并映射到一款業(yè)界流行的軟件工具來承載這個(gè)能力。需要注意的是這里的目的是具象與實(shí)例化，而不是推薦使用某款軟件工具。大家要根據(jù)自身實(shí)際來進(jìn)行工具選型。
基礎(chǔ)對(duì)于DevOps來說，最重要的基本能力就是健全的云計(jì)算能力。對(duì)于傳統(tǒng)企業(yè)來說，就是要構(gòu)建完善的云平臺(tái)。DevOps所需的高度自動(dòng)化必須得有強(qiáng)大的云平臺(tái)支撐。如基礎(chǔ)設(shè)施即代碼，彈性伸縮等高效的實(shí)踐，沒有云平臺(tái)的保障，根本實(shí)現(xiàn)不了。云是DevOps基礎(chǔ)設(shè)施架構(gòu)的基石。沒有完善的云平臺(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è)來說，考慮到安全性，一般還是會(huì)優(yōu)先考慮自建私有云，至少是混合云。當(dāng)然，完全選擇公有云也是可以的。如果企業(yè)有這個(gè)膽識(shí)與魄力完全基于公有云搭建云平臺(tái)，某種意義上也反映出它的DevOps規(guī)劃是完善與考慮周全的。對(duì)于他們來說，構(gòu)建DevOps基礎(chǔ)設(shè)施或許是一件把握十足的事情。
開發(fā)對(duì)于開發(fā)來說，最重要的需求來自三方面：開發(fā)效率、代碼質(zhì)量、實(shí)時(shí)反饋。對(duì)應(yīng)的能力如下：
開發(fā)效率：
分布式代碼管理能力（GitLab）持續(xù)集成能力（Jenkins）持續(xù)部署能力（Jenkins）依賴管理能力（Nexus）代碼質(zhì)量：
靜態(tài)代碼掃描能力（Sonar/Fortify/InSpec）執(zhí)行單元測試能力（Jenkins）測試環(huán)境制品管理能力（Nexus）實(shí)時(shí)反饋：
可視化能力（電視墻）構(gòu)建與單元測試結(jié)果通知的能力（Email）需要解釋的第一點(diǎn)是在代碼管理上，分布式的代碼管理會(huì)比中央式的代碼管理高效。中央式的代碼倉庫依賴中心化的代碼托管服務(wù)器，如果它有問題或者網(wǎng)絡(luò)中斷，代碼將不能被提交，這將嚴(yán)重影響開發(fā)效率；分布式的代碼倉庫是去中心化的，并沒有中央代碼托管服務(wù)器，每個(gè)開發(fā)者本機(jī)都是一份完整的代碼副本，這意味著即使網(wǎng)絡(luò)出現(xiàn)問題了，開發(fā)者仍然可以提交代碼。除此之外，分布式代碼倉庫提供的靈活性也是中央式代碼倉庫所不能比擬的。所以，這里我們選擇GitLab作為代碼倉庫，而不建議使用SVN等的中央代碼倉庫。
第二點(diǎn)是在依賴管理上。一個(gè)具象化的例子是關(guān)于Maven依賴的管理。在很多傳統(tǒng)企業(yè)里面，尤其是金融企業(yè)，外網(wǎng)訪問權(quán)限是受限的，很多開發(fā)人員都不能訪問外網(wǎng)。所以非常有必要在內(nèi)網(wǎng)建立所謂的私庫，作為代理與外網(wǎng)的公共庫同步。開發(fā)人員在本地構(gòu)建時(shí)通過訪問私庫來解決依賴問題。如果沒有建立私庫，開發(fā)人員必須得花費(fèi)大量時(shí)間解決依賴問題。而且這種問題在日后有新的依賴引入時(shí)會(huì)不斷出現(xiàn)，開發(fā)人員將為此焦頭爛額，開發(fā)效率嚴(yán)重受影響。
另外在代碼掃描上，由于企業(yè)安全性的要求，比較全面的是從質(zhì)量、安全和合規(guī)三個(gè)方面進(jìn)行掃描。Sonar、Fortify、InSpec與此三個(gè)能力對(duì)應(yīng)。還有從架構(gòu)方面進(jìn)行掃描的，但考慮到相關(guān)的技術(shù)其實(shí)還不是特別成熟，暫不考慮。不過有這方面特殊要求的可以深入研究一下。
對(duì)于持續(xù)集成，持續(xù)部署與執(zhí)行單元測試，通常是通過持續(xù)交付流水線來串聯(lián)實(shí)現(xiàn)，所以把承載能力的工具都?xì)w結(jié)到Jenkins上。需要注意的一點(diǎn)是這里的持續(xù)部署指的是部署到測試環(huán)境，并不包括生產(chǎn)環(huán)境。我把對(duì)生產(chǎn)環(huán)境的部署放到運(yùn)維。實(shí)際上，對(duì)于大都數(shù)傳統(tǒng)企業(yè)來說，現(xiàn)階段很難做到真正意義上的DevOps to Production。能做到DevOps to Pre-Production，甚至只是DevOps to UAT就已經(jīng)很不錯(cuò)了。造成這樣的原因是復(fù)雜而多方面的，包括要滿足監(jiān)管的需要，要通過生產(chǎn)環(huán)境審批的流程等等，這里就不展開了。
可視化是為了實(shí)時(shí)展現(xiàn)持續(xù)交付流水線執(zhí)行情況與單元測試的執(zhí)行報(bào)告，提高團(tuán)隊(duì)的反饋速度與響應(yīng)力。它需要可視化設(shè)備，如大屏幕電視，CI報(bào)警燈的支持；同時(shí)，我們也需要通過郵件的方式把自動(dòng)化構(gòu)建與單元測試的結(jié)果自動(dòng)發(fā)送給相關(guān)的人員。
測試而對(duì)于測試來說，最主要的需求來自測試效率與實(shí)時(shí)反饋兩方面。對(duì)應(yīng)所需的能力如下：
測試效率：
自動(dòng)化測試能力（Jenkins）并行測試能力 (Selenium-Grid)實(shí)時(shí)反饋：
可視化能力（電視墻）測試結(jié)果通知的能力（Email）比較好的實(shí)踐是通過持續(xù)交付流水線串聯(lián)自動(dòng)化測試，在測試環(huán)境部署成功后觸發(fā)自動(dòng)化測試。另外自動(dòng)化測試種類繁多，對(duì)應(yīng)的工具也比較多，例如利用Jmeter來 實(shí)施接口測試或者輕量級(jí)的壓力測試，利用Cucumber來實(shí)施BDD測試等，這里就不一一列出了。另外，為了提供測試的效率，有必要考慮把自動(dòng)化測試用例分組，進(jìn)行并行測試。這需要具備快速的測試執(zhí)行環(huán)境生成能力，應(yīng)該通過基礎(chǔ)設(shè)施即代碼在云平臺(tái)的PaaS層滿足。
與開發(fā)一樣，測試階段也需要測試報(bào)告的可視化與結(jié)果通知。
運(yùn)維而對(duì)于運(yùn)維來說，最主要的需求來自變更風(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）正如在分析開發(fā)階段所需能力時(shí)所說的，我把對(duì)生產(chǎn)環(huán)境的部署放到運(yùn)維。原因是企業(yè)的持續(xù)交付流水線往往都打不通到生產(chǎn)環(huán)境。表面的原因是因?yàn)橐裱璉TSM，一個(gè)歷史久遠(yuǎn)的被大量企業(yè)廣泛采納的IT服務(wù)管理框架，所以存在一個(gè)生產(chǎn)變更的手工審批流程，深層次的原因就復(fù)雜了，這里不展開。變更管理與事件管理的理念也來自于ITSM 。但隨著DevOps的流行，ITSM似乎顯得過于重量級(jí)，與DevOps的理念相違背。于是業(yè)界有人提出輕量級(jí)ITSM，但也僅僅是提出，沒有看到進(jìn)一步的落地細(xì)節(jié)。所以，對(duì)于傳統(tǒng)企業(yè)來說，在運(yùn)維階段，還是不得不具備變更審批管理與事件管理的能力以遵循ITSM，否則將會(huì)有合規(guī)審計(jì)的風(fēng)險(xiǎn)。
另外，對(duì)于運(yùn)維來說，知識(shí)的傳承非常重要，非常有必要建立運(yùn)維的知識(shí)庫。一方面 有利于對(duì)事件的復(fù)盤回顧，另一方面也有助于日后參加運(yùn)維的人員盡快熟悉與掌握系統(tǒng)的運(yùn)維技能。
這里需要注意的一點(diǎn)是Service Desk不是某一款軟件的名字，而是ITIL（信息技術(shù)基礎(chǔ)架構(gòu)庫，可認(rèn)為是ITSM的落地實(shí)現(xiàn)）里面承載變更管理與事件管理的工具統(tǒng)稱。業(yè)界有很多產(chǎn)品實(shí)現(xiàn)，但基本不開源，也沒有一款是公認(rèn)比較好的，所以這里不表明具體產(chǎn)品。
項(xiàng)目管理對(duì)于項(xiàng)目管理，最主要的需求是迭代支持、分析度量、變更追蹤、實(shí)時(shí)反饋四個(gè)方面。對(duì)應(yīng)所需的能力如下：
迭代支持：
產(chǎn)品代辦列表管理能力（Jira）用戶故事管理能力（Jira）分析度量：
數(shù)據(jù)統(tǒng)計(jì)能力（Jira）變更追蹤：
需求、代碼變更、CI關(guān)聯(lián)能力（Jira）用戶故事與設(shè)計(jì)、測試等相關(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ù)提升。
通過這幅全景圖，我們可以看到大部分的能力都以SaaS服務(wù)的形式呈現(xiàn)。這意味著企業(yè)可以建立中心化的SaaS服務(wù)提供給所有開發(fā)團(tuán)隊(duì)使用。并行測試的執(zhí)行環(huán)境通過PaaS平臺(tái)按需自動(dòng)生成，測試執(zhí)行完畢后自動(dòng)銷毀。唯一比較特殊的是持續(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)建完畢后立刻銷毀。
再談一站式DevOps平臺(tái)來到這里，肯定有人會(huì)有疑問，為什么這里我不把持續(xù)集成作為SaaS 服務(wù)？或者干脆直接引入成熟的DevOps效能平臺(tái)取代零散的工具鏈不更好嗎？不需要自己從0開始一步一步搭建啊？在我之前咨詢過的客戶里面，的確有很多是直接引入如華為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)重的問題。
第一個(gè)問題是缺乏靈活性。越偏向開發(fā)端，越需要靈活性。企業(yè)內(nèi)的項(xiàng)目都是千差萬別的，它們對(duì)CI/CD等的需求也往往差異巨大；即使是雷同的項(xiàng)目，在對(duì)編譯構(gòu)建上的一些細(xì)枝末節(jié)的差別也很可能導(dǎo)致它們的持續(xù)交付流水線設(shè)計(jì)非常不一樣。中心化的DevOps效能平臺(tái)往往不能提供足夠的靈活性滿足這些需求，反而導(dǎo)致開發(fā)者必須適應(yīng)其限制來設(shè)計(jì)流水線。第二個(gè)問題是運(yùn)維支持跟不上。企業(yè)往往把中心化的DevOps效能平臺(tái)作為產(chǎn)品提供運(yùn)維支持，運(yùn)維人員才幾個(gè)人，卻要支持整個(gè)開發(fā)部門所有開發(fā)人員的DevOps需求，支持響應(yīng)肯定跟不上。由此而引出的來自開發(fā)者的抱怨在我自己的工作經(jīng)歷中曾多次遇到過。如果是自研的平臺(tái)，問題可能更嚴(yán)重，可能連一些基本的需求都還沒實(shí)現(xiàn)，開發(fā)者就要開始使用；開發(fā)者提的新的需求更不知道要等到什么時(shí)候才能上線。以上提到的種種問題的結(jié)果就是開發(fā)團(tuán)隊(duì)會(huì)慢慢拋棄中心化的DevOps效能平臺(tái)，選擇自己搭建自己的持續(xù)集成平臺(tái)。針對(duì)這兩個(gè)問題，業(yè)界一些一站式的DevOps平臺(tái)也在著手去解決與平衡，其中來自華為的CodeArts算是做得比較好的。CodeArts脫胎于華為的DevCloud，凝聚了華為內(nèi)部這么多年來在軟件研發(fā)中實(shí)踐DevOps的經(jīng)驗(yàn)總結(jié)，本身從能力上來說是相當(dāng)完備的。它提供了從需求管理、代碼托管、流水線、代碼檢查、構(gòu)建與部署的端到端的研發(fā)流程的支持，基本上滿足了一般開發(fā)者對(duì)于DevOps的訴求。考慮到移動(dòng)開發(fā)越來越普及，CodeArts也集成了移動(dòng)端的測試平臺(tái)，開發(fā)者可以在CodeArts選擇需要用戶運(yùn)行測試的主流真機(jī)型號(hào)（包括安卓和蘋果），然后就可以把測試下發(fā)到對(duì)應(yīng)的真機(jī)上執(zhí)行。可以說，發(fā)展到了現(xiàn)在，CodeArts已經(jīng)完全可以滿足一般開發(fā)者的需求了。
如果開發(fā)者確實(shí)需要一定的靈活性，比如說需要與外部的Jenkins集成，或者需要從外部的倉庫拉取代碼，CodeArts也是提供了足夠的靈活性來實(shí)現(xiàn)。CodeArts支持新增服務(wù)擴(kuò)展點(diǎn)，通過服務(wù)擴(kuò)展點(diǎn)，就可以跟Jenkins、Docker Repo、Nexus等外部系統(tǒng)集成，實(shí)現(xiàn)更強(qiáng)大的功能。同時(shí)，CodeArts本身也默認(rèn)提供了許多開放的API，可供外部系統(tǒng)調(diào)用。可以說，在提供全面DevOps能力的同時(shí)，CodeArts也是提供全方位的靈活性，使得開發(fā)者能夠更得心應(yīng)手的專注于業(yè)務(wù)領(lǐng)域的開發(fā)工作，助力開發(fā)者邁向商業(yè)成功。
關(guān)鍵詞：
