華為微服務轉型DevOps實踐

近年來軟件開發領域熱點不斷，服務化、云計算、大數據、微服務、人工智能、區塊鏈……不勝計數，對應于開發和運維的對象變化，研發模式也在逐步發生演進。

以華為而言，華為是一家17萬員工的ICT企業，開發人員12萬，有眾多業績出色、產品豐富、人員眾多的產品線，耳熟能詳的比如無線、路由器、終端。

在這些組織里，幾十人甚至上百人的交付團隊比比皆是，所交付的產品經常是大型解決方案，故我們把在這些中大型組織內部推行持續交付的實踐，稱之為規模化持續交付。

2012年之前，華為內部對于持續集成已經非常普及；

2013年開始隨著大規模解決方案和版本化的需要，我們開展了系統的持續交付能力建設；

2014年ICT融合勢不可擋，服務化轉型驅使華為研發體系開始深入的了解和應用DevOps；

2015年之后，云化、云原生（CloudNative）和微服務這些概念的提出與興起，華為研發再次針對微服務進行DevOps的一些有益實踐。

規模化持續交付

在這里我們主要討論規模化持續交付能力建設過程中的幾個核心實踐：

第一個，節奏小批量快速迭代。華為2007年開始實踐敏捷，快速迭代在團隊中已經有比較好的基礎，

第二個，層分級自動化流水線。這包括幾個關鍵字：分層分級、自動化、流水線，自動化是為了提高效率，流水線流動的是交付價值。

第三個，短單點耗時。華為做了大量的工作，從極速編譯，到并發測試，再到基于PaaS的快速部署，都是為了節約關鍵路徑時間。

第四個，自動化持續部署。這是持續交付的核心實踐。

第五個，質量防護網。做質量保障的持續交付就是偽命題了，每一級的價值流轉必須保證高質量，傳遞的是價值不是缺陷。

第六個，可視化。過程可視化才能做到掌握和優化，沒有度量也就沒有優化的空間，所以要做可視化。

對于規模化的持續交付，從個人提交代碼到最后版本生產交付，需要多級流水線的配合。個人提交代碼，啟動個人級流水線，實現持續集成和單元測試；項目組件集成驗證，啟動項目級流水線，實現開發測試和集成功能驗證；版本集成打包驗證，啟動版本級流水線，實現版驗證和相應的兼容性、性能、專項測試等。每一級流水線都會形成交付物，可以是提交的代碼，可以是用于構建的組件二進制包，可以是用于集成打包的可執行二進制包等等。每一級流水線向上一級交付時，都必須實現質量保障，也就是質量門禁的檢查，這樣才能將缺陷和問題盡早發現，減少解決問題的成本。

圖上左邊的漏斗是應用質量門禁之前的結果，越集成問題越多，總是在最后版本驗證中發現大量基礎問題；右邊的圓錐是應用多級質量門禁之后的結果，大量問題都在底層門禁被攔截和修復，版本集成只會存在少量問題，大大節約了解決問題的代價。

服務化轉型促進DevOps

華為從2014年開始逐步進行ICT融合轉型，越來越多的業務開始以服務的方式提供給用戶（內部的/外部的），這就迫切的需要新的研發流程來適配產品轉型，于是內部有團隊開始實踐DevOps。

DevOps在不同書本有不同的解釋，這里是從華為年報中摘錄的華為公司對于DevOps的理解。不論如何定義，DevOps的核心實踐都包括主體：PPT（People，Process，Tool），以及三個核心實踐：正向交付價值，反向反饋結果，和持續的改進優化。

首先我們的組織開始發生變化，以華為云的軟件開發服務團隊為例。在組件初期，我們是以項目為單位的，人員分為項目管理、架構、開發、測試、版本、運維等多個組，所有的服務都是統一開發。發現這樣效率低下之后，開始進行組織轉變，以服務為單位組建全功能團隊，內含產品經理、用戶設計、開發代表、運營代表、架構師、開發、測試、運維各職能，通常一個人是身兼數職的，當然這對人的能力提出了比較高的要求。最開始的時候，這其中有一個團隊最難被拆分，那就是運維團隊，因為基礎設置自動化能力不足。

從流程上，認真遵循敏捷開發的過程，高速迭代，小步快跑。每一個迭代周期，PD會和SL開發代表確定計劃，周一完成需求串講，周中開發交付，認真履行每日站會進展和問題通報，周末完成迭代回顧和功能演示。下一周進入單元、集成、性能、專項測試過程，實現雙周迭代的滾動交付。

工具層面，為了保證正向的價值持續交付，引入了項目管理、開發IDE、編譯構建、部署、發布、測試、流水線等眾多工具服務；為了保證運營運維質量數據的反饋，引入了監控、分析反饋服務；作為所有的基礎，代碼托管、軟件倉庫、云化環境服務，這是必不可少的。

這些所有工具的出現都是為了保證DevOps核心實踐中的兩個重點，正向價值交付與反向效果反饋。開發人員完成代碼提交后，通過單級或者多級流水線，通過工具鏈將代碼承載的價值（就是需求、特性、缺陷修復等），通過流水線的運行，最終實現在生產環境的部署升級。當然流水線只是一個載體，需要代碼倉庫、編譯構建、測試、部署、發布等各個工具的支撐。同理，反向的反饋通道上，現網運行有大量的日志、運維數據、運營數據、用戶反饋信息，通過反向通道，就是通過監控工具、反饋工具、VOC信息通道、數據分析平臺，返回到研發手里，對我們下一輪的價值交付起到指導和修正的作用。

微服務場景下的DevOps

2014年Martin Fowler與James Lewis共同提出微服務概念，華為從2015年開始有團隊在業務中去實踐微服務開發，2015到2016年微服務開發在華為內部形成了蓬勃發展的勢頭。一方面是我們眾多產品線、業務線在實踐和嘗試實踐服務化和微服務化轉型，另外一方面，華為開始進軍云端業務，正式成立了云BU（華為云），催生針對微服務的DevOps能力進一步優化和演進。

在工具層面，我們主要做了兩個重要的演化：

一是工具云化。從我們最初實踐持續交付的時候，部分工具還是依賴本地化，能夠實現服務化的工具已經是比較好的結果，工具基本還是單點、孤島，使用的可靠性、效率、性能還不能讓人滿意。進入微服務的時代，微服務（MicroServices）和云原生（CloudNative）是一對相輔相成的概念，應用都要云原生了，那么工具勢必要求云化和鏈化。工具上云、環境上云是我們的一個重要演進。

二是增加針對微服務的設計和創建、管理工具。微服務一般都是通過接口實現外在交互，同步的、異步的，那么在微服務接口設計、依賴設計、框架創建標準化、微服務集中管理方面，工具做了一些有益的支持，提升創建、實現、管理微服務的方便性和效率。

進入了微服務時代，不得不說一下微服務拆分。

這兩張圖，左邊是我們進行微服務拆分之前的狀態，服務對外統一呈現，內部通過部件或者組件高度耦合（所以大家都是藍色的），部件組件之間的信息交互不做規范化定義。結果就是每一次服務的版本發布，所有組件都必須同步發布。這就存在互相牽制的問題，跑得快的組件被跑的慢的組件拖后腿，特性在交付周期不能滿足快速增加的用戶需求。我們這個時期有個高頻詞匯，叫版本火車。顧名思義，火車按站停車，定時開車，計劃性購票，效率比較穩定但是不夠高。之后，我們進行了架構解耦和微服務拆分，右邊這張圖，不都是藍色了，五顏六色，每個解耦出來的微服務都規范化接口定義，自己控制節奏，實現獨立發布，再也沒人攔著了。版本火車不復存在，但是服務快照是可以記錄的。特性的交付周期大大縮短，最快的交付實踐從代碼修改到特性上線只需要1小時。

軟件開發服務是華為云的一個部分。大家知道華為云在國內東北、華北、華東、華南都是有運營區域的。每一個微服務的上線，都是要同步的想全國多個區域發布運行實例，這個過程不可能通過手工來完成，對每一個區域的實例進行升級都是通過部署流水線來實現，實現無業務中斷的版本實例上線過程。統一實現了特性開關機制，向目標用戶推動新功能、新體驗，在得到有效反饋、有效測試結果、有效運營數據支持之后才會逐步的將新特性放開，這樣在保證用戶體驗的同時也保證了運營運維的穩定性。

經過上面所提到的眾多實踐，實現了從最初項目式的持續交付，向服務化的DevOps，以及微服務化條件下的DevOps開發流程的演進，實現了高用戶體驗、高產品質量、高效率交付、高凝聚力團隊建設多個方面的統一。

一個規模化的組織，要想從原有無組織或者弱組織或者簡單組織的開發流程中擺脫出來，投入DevOps的懷抱，總結為八個步驟：

1、迫切感：要看到大趨勢，將危機感和緊迫感植入組織血液；

2、領導力：變革需要高層領導的支持，聯合工作組，高層簽署文件等；

3、愿景：要知道變革帶來的效果，自頂向下制定效率提升的目標；

4、溝通：各級領導自上向下溝通、貫徹，包括如何打破部門墻；

5、授權：各基層組織得到充分授權，What、How、Result；

6、試點：在重點團隊試點能力建設，見效后可以大規模推廣；

7、深入：橫向，組織間互相傳播和交流；縱向：延伸價值鏈覆蓋的范圍；

8、固化：固化核心能力和優秀實踐，形成業務習慣和企業文化。

總體來說，也可以精簡成四點：

第一，要有堅定的意志，從開始變革到有序再到最終融入企業文化，需要一個長期過程，需要很大的投入；

其次，在工具要有所投入，不是說買軟件，是指為了實現價值正向交付和結果反向反饋，需要投入力量去解決自動化和聯調的問題；

第三，要勇于實踐和善于度量，制定有效的優化目標，并不斷深入擴大聯調覆蓋范圍，才能逐漸有所收益；

第四，要樂于分享，企業內部有標桿示范和經驗共享的機制和氛圍，不斷增強企業文化。

軟件開發平臺 DevCloud 軟件開發云 DevOps

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。