如何构建高效可信的持续交付能力，华为云有绝活！
摘要：持續交付的最終目的是高效和可信兩者的結合。
一、高效可信的持續交付
1.1 軟件研發的目的
持續交付是一個大家平時提得比較多的話題，高效是持續交付的目的，具體到華為云的場景下，持續交付的最終目的是高效和可信兩者的結合。
總體而言，軟件研發的目的是持續并且快速地交付高質量的有價值的軟件給客戶。首先研發是一個快速且持續交付的過程；其次研發是面向客戶的，交付的軟件必須是對客戶而言高質量且有價值的，而質量是多方位多維度的，其衡量標準除了價值以外，還包括穩定性、安全性、可靠性、可擴展性等。
1.2 軟件生命周期
從軟件生命周期管理的全過程來看，產品的idea產生后，進入開發，然后到部署發布，最后到運維，這是一個端到端的完整的流程，每個環節缺一不可。
開發環節，會有針對性地做各種測試，包括靜態測試、動態測試、黑盒測試、白盒測試、灰盒測試等，這些測試會在不同的環境之上分層進行，由不同的角色去承載；
發布環節包括對在制品的管理，發布什么是由前端的發布計劃決定的；
每個環節都有部署的動作，自動化部署的過程會銜接前端的開發過程。
往深一層：
整個前端更多的是創新的過程，在這個過程中可以看到很多方法論，比如設計思維、精益創業、數字化轉型等，這里的創新代表的是業務側的訴求，傳統業務需要通過新的方法、新的技術來實現賦能和轉型；
創新的idea落到研發環節去實現，開發部署發布有CI/CD進行支撐；
最后到運維和運營，不只是上線后需要運營，像現在服務類的產品都講究云化，既然是一個service，就需要對service構建整套面向用戶、面向內容、面向產品的運營體系。
回到業務側，將上述從產品到研發的流程映射到整個產品生命周期。
偏前端的階段是增值類的，產品創新是有價值的，寫的代碼也是有價值的；
而偏后端的階段則是非增值的，比如測試，對最終客戶來說是必要但不增值的。
增值的部分，我們追求的是最終的效果；非增值的部分，我們追求的是效率，即我要高效地完成這個過程，以便于達到最后的結果。
要通過過程來保證效果，因此過程也是必不可少的。但在這些過程中有很多工作是重復的，比如測試、部署，我們需要通過自動化的方式去賦能。這就是我們通常講的DevOps的意義，通過自動化的流程和工具，讓機器去完成重復性的工作。
觀全貌我們不難發現，在整個軟件/產品生命周期，質量通過逐層的測試、驗證、反饋等貫穿始終。另外，其中也包括大量安全類的活動，比如在產品創新階段要考慮安全性的訴求；在開發過程通過黑盒、白盒、靜態、動態等測試保證安全。
最后落到可信的層面，華為整個研發體系服務于整體的業務訴求，大家都知道，華為處于通信行業，通信是一個關乎國計民生的領域，對安全的要求非常高，提供的產品和服務必須可靠可信，因此我們做了很多可信工程的設計。
二、可信工程
2.1 華為軟件工程建設歷程
自上世紀四五十年代起，開始有了第一臺大型計算機，軟件工程也隨之興起并發展至今。華為成立于1987年，最開始是單兵作業或小團隊作業的方式，后來隨著業務的增長團隊規模不斷擴大，如何支撐大規模集團軍作業？為解決這一問題，我們開始引入IPD，由此進入IPD1.0時代。隨著互聯網技術的發展，有了敏捷開發、CMMI、DevOps持續交付、云原生等方法論和實踐，我們將這些優秀的方法論和實踐合并到IPD1.0的框架中，使之更靈活地適應實際的軟件研發需求。
2019年起，我們開始做IPD2.0，其中一個非常關鍵的點是可信。
2.2 何為“可信”
我們先來給“可信”下個定義。
可信是每個系統在業務意圖之外同時具有韌性、Security安全性、隱私性、Safety安全性、可靠性、可用性六個特征的確定性程度。
也就是說，每個系統在業務意圖（即功能性訴求）之外，還需要同時具備6個特性：
韌性，服務宕機是否能夠自動拉起來？系統能否經受得住大規模并發沖擊？
安全性，這里有兩個單詞代表安全性特質：Security和Safety。其中Security側重數據安全、信息安全，Safety側重環境安全等。
除此以外，還需要考慮隱私性、可靠性、可用性等特質。
華為的可信工程將這6個特性作為基本的訴求，再關聯業務意圖，高效地完成業務目標，帶給客戶價值的同時兼顧可信。
2.3 可信價值流框架
如果大家了解精益等實踐，就知道研發實際上是一個價值流交付的過程。那么，可信價值流框架是什么樣的呢？可信價值流框架是產品生命周期端到端的過程，以終為始，我們要的是結果安全、結果可信、過程可信，即我們通過過程的可信達到結果可信賴、可依賴、安全的目標。
將整個產品生命周期進行拆解：
在安全治理層面，我們需要有可信治理，包括可信要求、責任和權利、分層級治理、人才和文化等；
在過程可信層面，要有相關的確定性預防、確定性應對、機密性、完整性、一致性和雙向可跟蹤性、風險管理等，在過程中做到整體把控；
最后到結果可信層面，包括前文提到的6個特性。
再細化下來，又涉及到產品定義階段、產品實現階段、產品預發布階段、產品使用階段等，每個階段都在傳統軟件工程的基礎之上，加入具體的動作去滿足整體可信的要求。比如，產品定義階段，在規劃和設計中考慮可信訴求；產品實現階段，考慮編碼是否安全、編譯是否多次可用，交付給不同客戶的軟件包是否正確，測試是否可重復……在產品預發布和使用階段也會有很多相應的策略實現可信。
技術層面，我們通過使用建模和仿真技術、密碼學的加解密協議、操作系統可信等技術使能可信。
這是一條完整的通過過程可信達到結果可信的路徑，最終我們通過各級度量進行持續改進。
2.4 華為云HE2E DevOps框架v2.0
華為云集合業界先進理念和華為30年研發經驗，總結出一套可操作可落地的端到端一站式開發方法論和工具鏈——華為云HE2E DevOps框架。
首先，它是端到端的DevOps開發框架，包括從規劃設計到迭代開發到持續測試再到持續交付的全過程。我們認為僅僅只做好工程端不足以支撐整個業務，一定要延伸并回歸到業務側，實現端到端的閉環。
其次，它的整個過程融合了大量以可信為目的的手段，去支撐整個DevOps流程。
華為云HE2E DevOps自2018年發布1.0版本，到今年發展為2.0版本。華為云HE2E DevOps框架v2.0整體分為6大階段：規劃與設計、開發與集成、測試與反饋、安全與審計、部署與發布、運維與監控。本文將著重介紹工程端的內容，包括開發與集成、測試與反饋、安全與審計、部署與發布。
三、開發與集成
3.1 CloudNative實踐
云的服務本身就是生于云長于云的，因此我們一直在做CloudNative實踐，在架構、工程交付、全功能團隊、云環境四部分不斷優化，持續提升質量。
架構優化，架構整體進行微服務改造，統一微服務框架到SpringCloud里，進行業務拆分架構解耦，輕量級通信。
全功能團隊，架構拆分后，團隊需要根據架構做相應的驗收和匹配。我們試點服務化全功能團隊，單個Service由2-Pizza小團隊對開發、測試、部署上線、運維端到端負責。
工程交付，踐行DevOps交付模式，構建端到端交付流水線，微服務獨立開發、構建、測試、部署、發布、現網運維。
研發全云化，依賴研發云I層和P層資源和成熟基礎服務，基于華為云打造云化服務工具鏈和環境。
3.2 Cloud Native能力構建鐵三角
從以上4個方面我們不難得出構建云原生的Cloud Native能力必不可少的鐵三角：架構、組織、工程，我認為中間還應該加上價值交付。回到最初那句話：研發的目的是持續并且快速的交付高質量的有價值的軟件給客戶。
1）架構層面
采用服務化架構/微服務架構實現全面解耦。把系統劃分為多個功能內聚、粒度合適、業務邊界清晰、獨立自治的服務/微服務。
使用自服務、敏捷的云化基礎設施服務。依賴底層云化基礎設施的服務提供運行資源，使用云監控服務監控自身運行狀態，同時根據運行狀態出發運維事件，實現彈性伸縮、故障自愈等。
通過API重用云原生公共服務提供的基礎能力和架構能力。不管內部還是外部的服務之間，都可以通過API的方式自動生成相關接口和用例，來進行構建和定義，包括數字化轉型里的開放平臺、開放銀行等都是通過API來進行支撐。現在比較流行的說法“API經濟”可以了解一下，此處不展開。
2）工程層面
系統與環境、流程、配置解耦，人員團隊之間也進行相應的解耦與匹配。
DevOps，運維和開發相互融合，高度協同，共擔職責。
實踐極速迭代，持續交付，快速相應業務變化，縮短TTM。
3）組織層面
全功能團隊，團隊中包括產品、架構、設計、開發、測試、運維等角色，吃自己的狗糧，自己的產品一定要自己去上線發布和維護，每個人輪崗去負責發布的過程，這樣所有人都知道產品上線發布的流程。這樣做有幾個好處：技能的相互傳遞、打造全棧，不會依賴于某一個角色。
云化運維團隊，基于云平臺提供的監控、報警等能力，成立專門的團隊負責系統運行時的質量，保證系統可用性和業務無中斷的升級、回滾。運維團隊更多的是構建工具平臺和流程，進行賦能。
3.3微服務化目標
系統解耦，功能內聚，提升需求交付效率。通過業務的拆解和解耦，讓系統敏捷起來。
踐行API First。通過服務化，讓服務提供者和消費者之間通過微服務API建立契約。
低成本可伸縮架構。可靈活進行水平、橫向擴展，平滑上云，架構上支撐應用市場業務的快速發展。
服務自治。通過在線的微服務治理結合云平臺，實現微服務的彈性伸縮、熔斷降級等。
探索一體化服務團隊。建立2-Pizza Team，通過全功能團隊的建設，讓業務真正敏捷起來。
3.4微服務實踐 - 頂層統一設計
總結起來是：大兵團作戰，頂層設計，統一認識，組織賦能。角色上分為研發&運維團隊、設計&開發&測試骨干、架構師，每個角色要做什么，通過培訓和賦能的方式來進行定義和支撐。
3.5 微服務12設計原則
我們有一套一站式的微服務管理平臺來支撐微服務的12設計原則。
3.6 Clean Code
1）Clean Code機制
業界一致認為，編寫Clean Code能有效減少漏洞，降低系統脆弱性，是實現軟件可信的重要舉措。我們內部也非常強調Clean Code（代碼整潔），建立起一整套完整、具備快速反饋能力、可持續生成好代碼的機制。
華為有自己的Clean Code定義和文化。通過Committer機制、門禁機制、代碼極致共享等做相關過程的支撐，通過開發者測試對整體質量進行把控；并建立三層模型和六級標準，支撐實時代碼評估、版本交付階段性評估和產品長期演進的年度評估。
2）Clean Code評估
業界Clean Code評估標準是：高效、可移植、安全、簡介、可靠、可測試。華為持續對業界最新標準進行有效的代碼評估，并結合實踐建立了三層質量模型和六級質量評分標準。
關鍵舉措包括：建設分級標準，我們會對不同系統進行評級；開發可視化工具；建立定期評估指導場景；持續對標業界刷新評估模型。
3.7 華為Committer工程實踐
Committer來源于開源社區，大家都知道開源社區的協作模式是分布在全球各地的開發者以協同貢獻的方式進行開發，代碼貢獻者的能力、水平、責任心等參差不齊，因此必須在代碼入庫之前進行Committer評審以保證質量。華為內部也有開源的機制，借鑒這一實踐，形成自己的Committer機制。
華為的Committer機制實際上是一套流程來保證整體的代碼質量，包括三個角色：
Developer，負責創建本地代碼分支、本地開發、開發自檢與測試等工作；
Reviewer，負責對代碼進行檢視；
Committer，負責做最后的質量把關。
底層通過IT基礎設施來保證編譯部署、測試等過程，通過自動化工具使能，減輕評審的重復勞動。
整個Committer流程由幾個核心點：
代碼的開發、提交與合入權限應要分離，以避免攻擊者冒用員工權限植入惡意代碼；
通過檢視和審核的意見對工程師進行輔導提升團隊軟件能力。
入庫審核還能反向驅動前端代碼檢視提升，促進Developer具備編寫Clean Code的能力。
四、測試與反饋
4.1 華為云全場景測試服務框架
華為云全場景測試服務框架提供一站式端到端測試自動化智能化解決方案，為企業構建測試中臺，提升企業測試專業度及測試效能。整個測試框架分為三大塊：測試設計、設計執行、測試分析，包括測試設計、測試用例管理、服務接口測試、WebUI測試、終端測試、性能測試、安全測試、導流測試、在線測試及測試分析報告等功能。底層有一套完整的測試管理平臺來支撐。
全場景測試服務有3個要點：
Test Left，測試左移。在研發或產品生命周期的早期階段就可以介入和開展測試，并且測試的工作不是只由測試人員來承擔，也就是說測試是一個活動，而不是一個獨立的角色。
Automate Everything：盡可能多自動化。在業務早期階段，快速構建起來做一些驗證，所有這些測試用例逐漸都要變成自動化的方式，這樣才能重復性地、一遍一遍地支撐業務快速交付的過程。
Test Right，測試右移。類生產環境始終不是真正的生產環境，沒辦法模擬所有生產環境的場景，我們還需要開展大量的線上測試。
全流程測試，每個階段都有對應的測試動作：開發環節有驗收測試、單元測試、功能測試、coding里的代碼質量把控也是測試；測試環節有回歸測試、集成測試、性能測試、安全合規類測試等；部署環節有A/B測試、在線上環境和生產環境做一些復雜測試，還包括吃自己的狗糧等。
整個測試會分三級進行，分別是個人級、服務級、產品級。每級的流水線都會涉及到質量活動，流水線也會分層分級：
個人級流水線的質量活動是從本地開發環境到Alpha環境，包括代碼檢查單元測試、編譯構建、安全掃描、接口測試等，然后通過分支合并到Beta環境；
服務級流水線的質量活動是從Beta環境到Gamma環境，除了上述測試以外，還需要跑老特性回歸測試、瀏覽器兼容性測試、性能測試等；
產品級流水線的質量活動是從Gamma環境到生產環境，本層級需要加入專項測試，比如產品級性能測試、可靠性測試、長穩測試、安全測試等。
4.2 微服務交付過程持續開展質量活動
在微服務交付過程中有不同的環境，比如Alpha環境、Beta環境、Gamma環境等，每個環節有相關的質量檢查門禁和驗收標準，以及現網的質量活動。這些質量活動由不同的角色來承擔：
前端設計階段，參與的主要是架構師和開發工程師；
開發過程主要由開發工程師來承擔，架構師也會承擔開發的工作，但他做得更多的是關鍵的跨服務之間的設計和開發；
發布階段，開發工程師執行發布的動作，測試工程師會從端到端進行質量把控，并對開發工程師進行支撐和賦能。
生產環境，開發工程師和運維工程師一起對系統進行支撐，測試工程師會做一些現網測試、導流測試、混沌測試等。
4.3 測試度量指標體系
除了流程以外，我們還會有一些質量定義和度量標準。測試度量標準總體分為兩類：過程指標和結果指標。過程度量包括：覆蓋率、執行率、測試效率等；結果度量包括：功能測試、性能測試、安全測試、可靠性測試等。
五、安全與審計
5.1 DevSecOps的價值和實踐
安全和可信直接相關，說到可信，大家自然會聯想到安全。權衡DevOps速度與現有安全要求的需求，催生了一個名為DevSecOps的模型。
什么是DevSecOps？DevSecOps基于“安全問題，人人有責”的原則，它強調應用程序開發人員可以怎樣把安全檢查與他們的集成和部署流水線構建到一起。簡單來說，就是把安全層面的活動滲入到DevOps開發過程的各個環節中。 在華為云的實踐中，我們更關注在軟件開發過程中植入安全活動保證軟件生產的可信可靠和穩定。
5.2 華為企業級安全工程實踐
同樣從軟件生命周期來看，華為企業級安全工程實踐基于DevOps流水線，在計劃、編碼與構建、驗證、發布與運維運營等每個階段都有相應的安全考核點和實踐介入，底層會有標準和規范、技術和能力、工具和流程來支撐，全流程保障網絡安全，實現安全設計、安全編碼、安全測試、安全運維。
5.3 CodeCheck安全
華為內部自研了一個工具：CodeCheck，以應對嚴苛的安全要求，保證整體代碼質量和安全。我們分別從能力、效率和生態運營來看CodeCheck。
能力上對應三個級別：桌面級-編碼開發環節，嵌入IDE，編碼時執行快速檢查；個人門禁級-代碼提交入庫時，提供入庫門禁和規則集，快速檢查；版本級-持續集成、持續交付的過程中，提供全量檢查、告警閉環處理工程化能力。
效率上，前端桌面級和個人門禁級可做到秒級至分鐘級標準；到了線上環節，因為要跑的環節非常多，所以是小時級。
生態運營上，我們的工具是對內做服務，對外做客戶支撐。
5.4 安全規則
我們的安全規則來源于兩個層面：
外部視角：借鑒外部的規則，將業界的標準和最佳實踐沉淀下來，變成安全編碼的知識庫和規則集。
內部視角：華為內部有大量的產品線和產品形態，我們定義出TOP10的質量和安全問題，將長期場景梳理和安全檢查的經驗積累成規則。
業界經常提及的靜態分析安全測試（SAST）包括四層：編譯、構建、語法分析、語義分析，安全檢查涉及的技術棧明顯更深，華為提供全棧能力、多語言支持，支持深入的語義分析能力。如果把質量和安全結合到一起，需要一些規則和引擎來支撐，還需要引入一些智能化的手段，自動檢查、自動修復。
華為內部將規則集分為三層：公司級、產品線級、產品級/版本級/工程級。公司級規則集包括強制規則集，比如低誤報，默認必須掃除，而檢視規則集則可根據需要勾選；產品線級規則集和產品級規則集，產品線管理員配置為強制要求，其余的規則集可根據產品特性進行選擇。
整個工具不僅僅是簡單的安裝+運行，而是一個MN矩陣式的運營體系。從規則定義上來講，有公司級、產品線級、產品級等不同層級的規則；從時間周期上看，哪些規則放在開發者桌面IDE里、哪些規則要放在流水線里、哪些規則要放在版本構建里，都有一個設計的過程。
5.5 企業級專家服務
在安全層面，我們提供了企業級專家服務，其服務策略類似于醫院看診。普通“發燒感冒”的診治，提供基礎服務；針對“大病重癥”，提供專業的自動化檢查能力及工程配套能力；針對“疑難雜癥”，提供顧問式專家服務。
六、部署與發布
6.1 持續交付核心實踐
持續交付的過程是和持續開發與集成、自動化測試等關聯在一起的。比如分層快速閉環，在測試的時候就會分不同的層級去執行，分層的目的是為了快速反饋和閉環。
持續交付的核心實踐除分層快速閉環外，還包括：小迭代高節奏交付、自動化&可視化流水線、自動化持續部署、縮短單點耗時、高效標準化環境等。
6.2 發布的分支模型和CI/CD流水線
自動化部署的背后是標準化環境，需要代碼的分支結構和整體的CI/CD流水線有很好的匹配和映射關系。
我們從代碼主干上拉出來一個代碼分支，在上面做相關的開發，提交后自動拉起來一個CI流水線，對代碼進行靜態檢查和自動化構建，包括部署包準備、代碼合并等，最終通過個人級別的流水線后，跑到生產環境上，整個過程都是和CI/CD流水線關聯在一起的。
6.3 可信Built-In的流水線
我們把可信的概念內建到整個流水線里，自動化檢查、驗證，過程中獲取反饋，支持實現CI/CD過程的高效可信。
如果代碼層面是可信的，到編譯構建的時候，可以可重復地高效地構建出來；同時，測試活動中也會加入可信相關的檢查點；到上線后，Chaos Monkey等實踐也都是跟可信直接相關的，比如我們經常強調的彈性、穩定性等。
6.4 Everything as Code 一切皆代碼
可能有人會問：怎么防范我的環境里被人植入漏洞？其實環境也好、過程也好，都可以代碼化，代碼化后就可以把它納入到整個版本管控中，這樣的話所有的修改和變更都可以自動化，也可以針對這些環境和過程進行安全審計。
我們稱之為Everything as Code 一切皆代碼。除了基礎設施以外，編排、配置、測試、數據庫、流水線、代碼都可以這種方式呈現出來，這樣就可以實現版本化、自動化和標準化。再往上到Service也如此，Service as Code實際上就是我們想要強調的API。
6.5 灰度發布策略驅動自動化部署與回滾
在發布的時候，我們會有各級發布的機制。首先我們會做一級的灰度發布，找一些重點MVP客戶，或者內部使用者，發布給自用環境；沒問題的話再進行二級灰度，這時會適度擴大范圍，開放給全網10%左右的用戶；然后再做三級灰度；最后才是全量發布。
在這個過程中，一旦任何一級出現問題，馬上就可以進行修復和回滾。同時我們會做一些在線導流測試，結合AB測試進行業務層面的探索，我們一直強調通過技術的手段賦能業務。
七、總結
以上介紹的是華為云的DevOps體系，其核心除了通常我們所說的“高效”、“持續交付”以外，更重要的一點是“可信”。我們將這一體系稱為“云與安生時代的DevOps體系框架”。
頂層是商業決策，我們會持續規劃、定期審視，固定節奏對其進行相應調整；往下是服務化組織、架構解耦，開發&運維落地；再往下是工具、環境支撐；最底下是服務流程支撐。
如何去構建這樣一套體系？我們要始終圍繞整體的研發效率目標，選擇應用相關的研發工具，以工具承載新型能力，支撐高效作業、持續交付、高效協同、智能化輔助開發、持續反饋與改進，進而構建整個的持續交付能力。
——————————————————————————————————————
內容來源：【2020 CSDI SUMMIT中國軟件研發管理行業技術峰會】分享實錄，原文首發于“百林哲”。作者：姚冬
嘉賓簡介：華為云應用平臺部首席技術解決方案架構師，資深DevOps與精益/敏捷專家，華為云享專家，中國DevOps社區核心組織者，IDCF（國際DevOps教練聯合會）發起人
點擊關注，第一時間了解華為云新鮮技術~
總結
以上是生活随笔為你收集整理的如何构建高效可信的持续交付能力，华为云有绝活！的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： android开发 RecyclerVi
- 下一篇： Elasticsearch 调优之 写入