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