背景介紹
本期分享内容為《平台化 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