「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 敏捷也是為了讓大家的工作效率協同模式得到更好的保障。隨著對於應用質量的管控，將質量管理做到流水線過程中，能夠讓問題發現的環節更加前置，花更小的成本去修復問題。