摘要：聽華為雲DevCloud首席技術布道師徐毅講述雲原生下的DevOps實踐。
本文分享自華為雲社群《靈活開發專家一席談：雲原生技術下的華為雲DevOps實踐之路》，作者：華為雲社群精選 。
DevOps最早在2009年被人提出，願景非常美好，但真正實施起來困難重重。
随着近幾年微服務、容器等技術的興起，使得企業對DevOps的需求更加迫切，實施變得更加容易，DevOps越來越被接受和重視。
同樣，為了應對業務的靈活釋出，應用平台的彈性訴求，商業環境的變化，雲原生時代已到來，雲原生技術已經應用到企業核心業務。
雲原生與DevOps是什麼關系？其技術優勢如何與DevOps結合，才能更加高效便捷的實施呢？雲原生時代下，DevOps的落地會遇到哪些困難？華為雲是否有一些實踐方案去應對？
華為雲社群邀請到了華為雲DevCloud首席技術布道師徐毅，聽他講述雲原生技術下的DevOps實踐，深入了解集華為30年研發經驗的華為雲DevCloud是如何踐行DevOps理念的。
衆所周知，很多變革都始于技術。技術經由積累産生勢能，這些新的技術釋放出很強大的生産力并帶來創新，滿足使用者和客戶新需求的爆發，進而需求驅動技術的迅速普及和優化，最終帶來商業的繁榮。
雲原生應該是雲化的延伸。在雲的發展初期，并非所有的産品技術都是雲原生的，随着雲計算技術的不斷發展，雲原生的應用和系統能夠更好的滿足需求側在功能和非功能各方面的訴求。從雲到雲原生這個過程來看，在當下創新加速的VUCA時代，也帶來了一系列的變化：
需求變化快，但方向暫不清楚，這就需要IT資訊化支撐業務創造的過程更靈活、反應更快速；
在業務闆塊創造出來之後，會面臨着業務使用的強度和頻率是不固定的，是以就需要支撐業務供給的靈活性和快速響應的速度；
當下的使用者需求和業務的顆粒度，随着市場發展越來越小，是以能夠迅速把握市場動态、完成業務創造、提供業務這個全過程周期的速度也變得非常重要，還需要能夠拉通整個組織。但不同職能組織都有自己的不同目标，無法做到說改變就改變。
雲原生技術的發展，使得各個職能組織去支援、去改變的難度越來越低、投入越來越小，大家更願意拉通和協作，進而在商業側能夠給企業帶來更大的競争優勢。
首先要掌握架構解耦、雲端彈性等相關技術，具備研發能力，這是第一要素。
第二，把技術能力運用起來在平衡中去解決業務問題，不能太過于完美主義。例如面對一個遺留系統，是一步到位解耦完畢還是循序漸進呢？分析業務現狀的問題并針對性地應用雲原生技術能力去解決，去創造價值，是第二個關鍵要素。
第三是團隊通力協作的能力。作為團隊的基礎，團隊的每個成員都具備充分的技術能力，這樣團隊的能力可以等同于團隊成員的合力。團隊成員之間通過協作能夠産生的化學效應，不隻是1+1=2的效果，它将會帶來乘數甚至指數級的效應。
第四是組織變革能力。新組織可以直接招募具備雲原生技術的成員組建團隊，這樣帶來的好處就是大家沒有遺留系統，了解業務即可。如果是一個現成的組織，那麼團隊成員既要邊學習和掌握新技能，邊繼續發展業務，就如同“給行駛中的汽車換輪子”。這時就需要一種軟實力來打消大家的顧慮，推動往雲原生的傳遞模式轉變。
按照CNCF的說法，容器、微服務等被認作是雲原生技術。DevOps主要是指一種工作方式或模式，它幫助拉通整個價值創造過程中各環節的人群組織，通力協作縮短價值創造的周期時間。在這個過程中，就需要從人、工具和流程方法三個次元去改變。
如何區分普通DevOps和雲原生DevOps，主要看一個組織在應用DevOps的過程中，是否使用雲原生技術開發應用或者系統。 舉例來講，DevOps開發一個傳統的單機應用，不需要開發人員掌握容器或微服務等技術，對部署和釋出的自動化要求也不高，或許也不需要灰階釋出、應用監控等功能，往往隻需應用幾個DevOps工具就能夠滿足需求。
當然，它是被定義為DevOps，是以代碼送出之後的編譯建構、測試、打包、安裝啟動等，都要能夠以全自動化的方式完成，無需人工幹預，那這個應用的研發過程就是一個普通的DevOps。
雲原生模式嚴格意義上來說，是整個應用的生産過程都在雲上， 需求在雲端的系統上管理，代碼存放和評審、測試用例都在雲上進行，甚至日常交流、開會等方面也都在雲上進行，這就是比較徹底的雲原生DevOps。這時就需要一個可以拉通各個環節的雲原生DevOps工具的平台，我們稱之為一站式雲原生DevOps平台。
應該說是未來的趨勢。個人開發者可以利用雲廠商提供的便利，以極低的成本，去學習和實踐雲原生DevOps開發的全過程，掌握運用各種雲原生技術，去創造價值。同時，開發者要從自身的長遠發展出發，自己的未來自己做主，不要僅僅依賴于工作中實踐，可以考慮去主動的投資學習。畢竟自身能力的提升是帶來更大回報的最常見手段，其他手段都依賴于能力的提升。
在雲原生2.0的趨勢下，越來越成熟的雲原生技術化解了開發者的諸多難題，開發者突破個人職業瓶頸的核心關鍵是掌握1+N關鍵能力，就是1個DevOps平台加上N套技術棧，再配合雲原生提供的開發能力，開啟第二曲線。想了解更多，可以直擊文章《雲原生開發者須具備的1+N技能，開啟第二曲線》中做了詳細的解讀。
要說DevOps如何解決實際開發運維中遇到的問題，首先我們應該先分析當下開發運維會遇到哪些問題，簡單列舉幾個點：
第一個問題：現在市場需求變化很快，産品要快速響應，頻繁的進行版本更疊。
當下很多項目都在使用微服務架構，其中一個好處是可以減少變更影響的範圍，但微服務其實對運維的要求相對變高了，因為之前你隻負責一個單體服務的釋出，現在你要負責多個微服務的釋出，傳統組織結構以及運維方式很難滿足，這其實也是促使DevOps誕生的一個主要因素。DevOps是可以通過一系列的自動化工具，将很多以前需要手工操作的流程變成自動化的。比如釋出包的建構、部署任務參數配置等等，然後對各個服務按照不同場景，做出不同的釋出政策，進行自動化的釋出，加速産品新特性的上線。
第二個問題：産品上線後，資料營運和分析。
這點容易被忽略，很多人認為DevOps就是自動化工具鍊，其實資料分析、營運也是DevOps中很重要的一部分。 DevOps文化中，度量是很重要的一環，這個度量不是說向老闆彙報用的，而是通過資料去了解各個服務的運作情況、使用者的使用情況等，然後根據分析結果對産品進行優化改進。傳統的運維模式很難建立這種回報機制，不搞清楚市場或者使用者群體感受的開發，很容易閉門造車，而DevOps則是提倡在營運環節建立回報機制來解決這個問題。
其他方面問題：比如基礎設施、網絡、場地等方面的投入，相當于把資源托管，讓開發者更多的聚焦于新特性的傳遞。以上這些其實都是DevOps解決實際生産中的問題的例子。
測試階段遇到延遲的問題是說很多時候安全測試在整個軟體生命周期中做的比較晚，導緻很多漏洞之類的沒有測出來。這個問題其實很好解決，首先可以從單元測試入手，在新特性開發之前，根據驗收标準寫好單元測試，等到功能開發完成直接進行單元測試，這樣就會減少測試的延遲。
DevOps也主張将測試環節盡可能地嵌入到流水線中，華為雲DevCloud提供了代碼檢查功能，檢查代碼的漏洞。還有就是現在很多項目都在用微服務架構，微服務架構中服務與服務之間是通過API進行互動的，那我們也可以将接口測試作為一個主要安全管控手段，将他納入到持續傳遞流水線中，每次執行流水線時，自動進行接口測試。
華為雲積極地參與業界相關标準和能力模型的共建共創，作為重要參考來建構DevOps相關産品。業界主流是根據DevOps的自動化程度将它劃分成三個階段：
1、保證代碼時刻可以進行建構的持續內建；
2、将代碼自動化部署到類生産環境進行測試的持續傳遞；
3、将最新的代碼直接自動化部署至生産環境的持續部署；
其中，持續內建自動化程度相對會低一些，持續部署自動化程度是最高的。但更多的時候需要結合業務場景去選擇是持續內建、持續傳遞或是持續部署，并不是所有的場景都必須做到持續部署。如果條件允許的話，一定是自動化程度越高，就意味傳遞頻率越快。
華為雲提供的雲原生DevOps體系架構叫做HE2E，即華為端到端（End to End）DevOps架構。是結合了華為30年研發經驗并集合了業界先進的實踐所形成的一套可操作可落地的靈活開發方法論。HE2E圍繞一個名為鳳凰商城的電商平台項目，按照DevOps方式完成從送出代碼到流水線部署上線的全過程，項目使用了微服務、容器等多種雲原生技術，其中DevOps部分依托于華為雲DevCloud。
在這個實踐中，開發者可以通過華為雲DevCloud的項目管理功能進行靈活項目管理。項目的示例代碼也是通過華為雲DevCloud的代碼倉庫codehub，項目使用微服務架構，前後端分離，并且可以通過華為雲DevCloud進行雲端建構實作持續內建，将前後端打成Docker鏡像放到雲端鏡像倉庫，供部署使用。
從內建到部署，還可以通過DevCloud的流水線功能串聯起來，在流水線中配置建構、部署任務實作雲原生的DevOps，這個流程和現在很多企業的實際開發場景也吻合。
最後，對于開發者來說，DevOps是神秘的，自己可能沒有精力或資源搭建DevOps工具鍊，其實這部分可以通過H2E2——相當于是用華為雲搭好的一套架子，直接使用華為雲DevCloud體驗雲原生的DevOps。
點選關注，第一時間了解華為雲新鮮技術~