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