背景介紹
本期分享內容為《平臺化 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
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/164809.html
標籤：其他