「DevOps 轉型與實踐」沙龍回顧第二講

背景介紹

本期分享內容爲《平臺化 DevOps—雲計算與雲原生模式下 DevOps 的建設實踐》。目前，DevOps 愈來愈成爲你們當前建設的熱點，伴隨着基礎設施的轉型和應用框架的轉型，更多的業務偏向雲端和 C 端的場景，促進了 DevOps 的發展。在本次沙龍上，騰訊雲 CODING DevOps 資深架構師餘朋飛爲你們介紹了在雲計算和雲原生兩種模式下，如何推動 DevOps 的建設和實踐。

企業 IT 架構演變歷程

在 2007 年以前，企業還未產生 DevOps 的概念，大多仍是基於物理機的模式。2012-2014 年是第一波上雲的熱潮，企業紛紛將傳統的物理硬件轉換到虛擬機的結構上。以後，容器的發展推進了應用的轉型，微服務愈來愈被你們所說起，對應 DevOps 這個概念也愈來愈被你們所推崇。因此第二波上雲是業務從底層遷移到雲上。第三波是雲原生，整個 IT 基礎設施，不管是從硬件端、中間件以及所依賴的數據庫等資源所有可以在雲上提供服務。 基於這個模式，更應該被關注的是整個軟件開發自己業務需求的梳理，到整個業務的運營，這個階段從開發態，從運營態和服務調度的模式都有新的改善。

DevOps 一直致力於怎麼更好地維護應用的生命週期。在 DevOps 1.0 時代，這個時代是將基礎資源作標準化，更多的是針對應用架構採起單體或服務總線的架構，對應的模式仍是以虛擬化爲主。 然而在整個業務發展過程當中，更應該面向的是 DevOps 2.0 服務管理，整個應用架構和基礎設施的架構隨之也會變化。接下來就具體看一看在這兩種不一樣的管理模式下，整個 DevOps 的建設究竟是什麼樣的方式去推進和落地它的。

雲計算模式下的 DevOps

業務上雲給你們帶來了什麼？咱們須要解決哪些問題？如下總結了幾方面目前業界比較關心的點。首先由於基礎設施的爆炸式增加，致使環境配置管理和維護愈發困難，持續部署層面須要發佈的節點愈來愈複雜；在業務推向虛擬化基礎設施的時代下，業務架構變得更加複雜，對應部署成功率，相應的系統穩定性也會降低；另外因爲底層雲資源帶來的便利，在流量衝擊的狀況下須要作好資源和應用的彈性；最後，隨着業務對 IT 的訴求愈來愈頻繁，須要更快速反饋整個業務的訴求。

所以， DevOps 的建設迫在眉睫，從需求到最終上線運營的全生命週期裏須要進行全方位改進——好比須要更好更標準的需求管理工具，須要經過自動化手段快速管理對應的環境，可以經過自動化測試把質量創建起來，最後可以更好地處理在運營階段的事故。在這個階段，你們更聚焦的核心是自動化，怎麼經過 DevOps 的手段來強化自動化流程。在自動化效果基礎上伴隨的是標準化和版本化，在自動化的同時也要作好相應的質量內建以及 DevOps 過程度量，由於只有將過程度量好以後才能評估 DevOps 建設的效果，質量內建也是保證 DevOps 建設過程當中軟件的質量可以獲得很好的控制。

從這幾個目標來看，核心指標包括生產效率、軟件研發效率，生產控制中的產品質量，對應的成本節省。在軟件研發過程當中，經過可靠、可重複的流水線能夠幫助咱們更快速、更高效地生產 IT 軟件或對應的服務。

CODING DevOps 流水線實踐

下圖爲當前 CODING 面向客戶所推的 DevOps 流水線實踐。

基於 CODING 平臺，從代碼拉取開始，基於內置的代碼靜態掃描模塊來保證代碼靜態檢查，包含代碼規範、缺陷、重複率等不一樣的維度，另外，雲端的構建環境可以保證各類不一樣的構建編譯，結合基礎設施的管理可以將自動化部署到對應的測試環境，幫助在整個流水線過程當中作到測試質量管理，讓質量在整個流水線過程當中有比較好的保障。最後，單一的製品來源可以保證獨立存儲製品。到了生產階段，咱們更多關注基於業務運營的過程怎麼作灰度和 A/B Test 的部署模式。

研發規範

在創建流水線時，須要遵循一系列的研發規範。

流水線建設過程當中須要將這些規範囊括起來，流水線並不僅是打包工具，不是經過流水線將代碼構建成製品就結束了，而是可以在流水線過程當中標準化整個研發過程。

瞭解了這些規範，實際應該怎麼去落地？在建設 DevOps 的過程當中經常遇到許多使人痛苦的問題。好比，針對金融行業大量已有系統，研發管理模式不盡相同，規範過多該如何管理？新老系統和業務如何兼容？隨着時間增加、流程緊急、業務壓力增長，如何保證團隊的熱忱和規範的持久運轉？規範須要對應的人員去支撐，工做場景每每至關複雜，如何作好規範的標準化工做？CODING 基於以前的經驗，針對這些痛點研發了一款研發規範產品 TCMS，定義不一樣的研發團隊所對應的研發管理流程，可以約束對應的需求、代碼、流水線管理，作標準化的約束來提高整個團隊的協做效率。

研發管理包括幾個部分。首先定義研發工做流，須要定義代碼能拉出哪幾個分支，容許哪些對應的合併策略，而且每次合併必需要有對應的規範和理由；第二，不一樣的合併規則意味着不一樣流水線的執行，在合開發分支的時候，開發人員作了一次本地提交可能只須要運轉開發流水線，只須要對代碼的質量和單元測試作一些約束便可，一旦涉及到 release 分支或 MR 的合併，這時候意味着功能合流了，基於合流規則來關聯流水線，在流水線過程當中去約束這個合流所對應的業務規則；第三，自動化工具輔助分支管理，若是定義了一個分支只能拉出來一週，一週以內必須合併進去的話也會作一些約束；第四，將對應的分支和需求管理關聯起來，分支在合流的時候可以很清晰地從需求管理追溯到代碼開發，從代碼開發再追溯到整個業務合併，全生命週期管理是可控制和便於查閱的。

下圖爲 CODING 的標準化流水線：

雲原生帶來的改變

從 CODING 當前服務的客戶，一塊是移動端的業務，當前移動端 APP 已經愈來愈多的企業重視雲原生，針對移動端也是可以基於雲讓開發速度獲得更好的保障另外一塊是從金融行業，有些營銷類業務更多適應雲原生的場景。不管是營銷類也好，仍是 APP 類也好，核心挑戰是 C 端用戶過多的狀況下業務會受到較大制約，好比收集更多的用戶數據，更快速地對用戶訴求獲得反饋。單單經過流水線建設是沒法達到這個效果的，流水線只能幫助咱們更快地實現代碼到構建到部署這一段的效率，可是以後怎麼基於部署的應用來提高業務價值，就涉及到價值交付的過程。在當前的 DevOps 2.0 裏面，運營過程和業務分析過程被歸入到 DevOps 體系裏面去實現相應的價值交付。

那麼怎麼作價值交付？CODING 第一步會作自動化，第二步會作敏捷。至於爲何把敏捷放在 DevOps、自動化以後去建設，CODING 發現，在國內、尤爲是大型機構和金融企業裏面，敏捷沒有推得像你們想象的那麼好。自動化設備沒有作到必定程度的時候是不足以支撐過於短平快的迭代的。因此 CODING 首先經過可靠可重複的流水線創建自動化的應用交付體系，幫助代碼可以更快上線；而後基於敏捷的思惟和實踐對業務需求作拆分和管理，經過迭代作增量式開發。另外隨着對迭代的要求愈來愈高， CODING 天天都會進行發佈，敏捷已經不足以支撐業務需求的增加，所以 CODING 團隊更加貼合互聯網模式去作微服務改造，應用架構變化以後，應用更小更細，就能更快地實現迭代。最後，業務上線以後運營過程也能夠歸入到對應的 DevOps 體系裏面來。

下圖爲 CODING 在價值交付體系下的組織結構轉型：

在價值交付體系裏面，CODING 從組織、流程、能效和工具四個層面作梳理。基於對應的 DevOps 指標可以評估團隊對應的 DevOps 能效如何，怎麼基於這些指標進行提高。

經過 DevOps 的建設，企業可以經過容器化構建和開發環境管理，下降資源利用率和節省成本。CODING 提供了構建的資源池，你們在作開發的時候不須要本身管理服務器；另外，經過 CODING 流水線建設作到對應的持續交付的效果；基於 CODING 的實施也能更好地建設符合 DevOps 文化的度量體系；標準化製品管理可以管理製品模板、流轉和進階的過程；最後，基於研發規範的約束可以讓整個團隊在落地 DevOps 的時候更加無感，你們自覺遵照約束以提升開發標準化。這是 CODING 的願景——讓開發更簡單。

Q & A

Q：落地 DevOps 必然會面臨團隊成熟度的問題，包括團隊技術水平，敏捷意識和能力，如何保證標準化的產品在每一個團隊作更靈活的適配？
A：從 CODING 的角度來看，規範有兩個不一樣的角色，規範的制定者和使用規範的人。只有對業務有深入瞭解的人可以制定規範。一些經驗不足的同窗，只須要基於當前制定的規範使用這個產品就能夠了。

Q：在小公司裏面，如何在成本控制和 DevOps 的落地之間取得平衡？
A：DevOps 從某種程度上是下降成本的。CODING 可以提供虛擬化的空間資源池讓開發資源獲得更好的利用。推進 DevOps 敏捷也是爲了讓你們的工做效率協同模式獲得更好的保障。隨着對於應用質量的管控，將質量管理作到流水線過程當中，可以讓問題發現的環節更加前置，花更小的成本去修復問題。

點擊觀看課程錄播並下載 PPT