從單個系統到雲翼一體化支撐，京東雲DevOps推動中的一波三折

做者：王利瑩

採訪嘉賓：京東雲DevOps團隊負責人 鄭永寬

今年，IDC 特別針對中國地區發佈了《IDC MarketScape：中國 DevOps 雲市場 2019，廠商評估》研究報告，IDC 對具備表明性的 7 家 DevOps 雲提供商進行了深度研究。
報告顯示，基於產品現有能力、將來策略與投入、市場表現與客戶滿意度三大指標體系的綜合評估，京東雲 DevOps 躋身」Major Players「（核心廠商）位置。

IDC 認爲，將來 1–2 年市場將高速增加：公有云 DevOps 服務成爲中小企業和部分大型企業快速實踐 DevOps 的優先選擇。雲廠商在不斷吸引和轉化自身雲平臺的用戶使用其 DevOps 服務，同時也在不斷增強對外的宣傳教育工做進行市場培育。預計，將來 1–2 年 DevOps 雲的企業級用戶和我的開發者數量將呈現高速增加。

不只是雲產品與服務，DevOps 涉及的開發運維團隊協做工具與組織內部文化也值得討論，本篇文章咱們來聊聊哪些技術在推進 DevOps 發展，京東雲 DevOps 的內部迭代過程、成果以及將來的路。

什麼在推進 DevOps 的發展？

DevOps 的發展實際上是需求帶動的，互聯網技術浪潮下，隨着業務體量愈來愈大，變動愈來愈多，協做流程愈來愈複雜，必需要有新的技術及工具來支撐。容器技術、微服務、AI和機器學習……新的架構方式在解決問題的時候，天然成爲了 DevOps 的推手，也與 DevOps 最初成型時期被 IT 人員普遍傳播的理念相融。

2009年，在第二屆 Velocity 大會上一個轟動世界的演講，「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」，這個演講提出了 DevOps 的「一箇中心，兩個基本點」——以業務敏捷爲中心，構造適應快速發佈軟件的工具（Tools）和文化（Culture）。而同年「DevOps之父」 Patrick DeBios 在比利時根特市的首屆 DevOpsDays 活動，也讓「DevOps」做爲術語流行起來。

工具、文化都是爲了最終的業務敏捷，也正是容器、微服務等技術所追求和正在推進的。咱們經常看到說「基於容器的 DevOps」，「微服務容器化」，在聊這二者具體的做用前，咱們先來看看問題從何而來。

「軟件吃掉世界」，硅谷投資人馬克安德森曾以一句話撼動了整個業界對 IT 的認知。從傳統瀑布模型，到敏捷開發模型，到 DevOps 開發模型，逐步解決軟件開發的敏捷和運維的敏捷。

雲計算解決了計算、網絡、存儲這幾個方面的彈性問題，可是在應用遷移和應用擴展時，還有未解決的問題。

• 應用遷移涉及到遷移軟件類型、編譯及運行環境、遷移工具，而不一樣的環境下安裝軟件，牽扯到權限問題，配置問題，文件路徑問題等，一旦出錯就會形成安全損失。對於開發和運維團隊來講，每每須要不斷地在不一樣環境安裝軟件，容易出錯。
• 應用擴展涉及到新環境部署，涉及到開發環境服務器、部署方式、測試環境的不一樣等，特定場景下須要更多的服務器來處理大批量需求。

服務器的問題是大問題，如何讓服務器能夠同時處理多方需求呢，大牛們想到了虛擬化技術，什麼是虛擬化？虛擬機是虛擬化技術，容器也是虛擬化技術，虛擬機 (VM) 是物理硬件層抽象，讓一臺服務器變成多臺服務器。而容器可理解爲應用軟件層面的虛擬化，多個容器共享一個操做系統。

虛擬機鏡像太大，拷貝下載都是時間，容器技術跑在雲架構裏就比物理機更如魚得水，讓應用軟件更容易遷移、更容易擴展，從而提高軟件交付的效率。

另外一方面，對於面向互聯網的企業來講，在用戶體量增加時可能會面臨大量問題，若是不用微服務會致使架構到某個階段被迫重構。微服務所倡導的鬆耦合、高內聚與容器的輕量化、可移植性、快速集成的特色相輔相成，在實際應用中，容器+微服務，組合拳的力量不容忽視。

兵來將擋水來土掩，雲與 DevOps 其實自然相依，讓 DevOps 的工做由大模塊拆分紅小模塊再更好地重組，其實就是 DevOps 理念所講的工具讓業務更敏捷，實現持續集成與持續發佈。

而另一個「工具」——人工智能，機器學習算法、算力、海量數據將讓 DevOps 走向更高的山峯——AIOps，這也是咱們常聽到的詞，其實就是讓更多的機器學習工具來輔助或者主導整合開發運維交付過程，讓原有的系統更有彈性，更加敏捷。特別是對於大廠來講，技術實力、經濟實力、複雜變態的業務場景及運維場景，主動逼着 Ops 走向智能也許更加容易。

除了工具，在文化因素層面，企業內部 DevOps 文化更可能是從上而下，領導或團隊負責人如何培育團隊文化，由點到面，由工具鏈平臺到協做文化，但其實文化講起來容易作起來難。

信通院雲計算開源產業聯盟今年發佈《中國 DevOps 現狀調查報告（2019年）》，在 1549 份有效問卷及專家訪談支持下，分析提到：多因素形成企業難以推行 DevOps，其中各部門之間目標的不一樣是企業首選的主要緣由。近半數企業認爲各部門之間目標的不一樣是致使 DevOps 推行失敗的主要緣由。近 3 成企業認爲我的優先效忠於本身的部門其次纔是組織。

歸根結底，今天 IT 行業的業務需求推進是首要緣由，要讓用戶體驗好，不被時代拋棄，技術人在探索這些新的技術、工具、協做方法、文化，DevOps 被普遍討論及實踐其實也說明了它的前沿性和正確性。

京東云爲何要作 DevOps

回到京東雲，2016 年京東雲正式商用，在國內其實算起步較晚，可是讓雲更好地服務自身及客戶是使命，整個雲計算的基礎生態建設是必需要作的，而作雲計算的基礎生態建設離不開 DevOps。

咱們也能夠這樣說京東雲在作而且能作，離不開自身的「超級電商」場景，離不開大量的人才資金投入，咱們都愛關注和參加大促活動，大大小小活動也幾乎天天都有，爲了響應業務需求，勢必要求開發敏捷，而伴隨電商業務的海量數據、豐富的運營策略，要求開發團隊在短期內快速迭代，持續時間甚至不超過兩週，同時也要求運維敏捷實踐，因而 DevOps 必需要作。

在早期的京東，是採用「HumanOps」的方式去發佈產品，隨着京東業務的不斷擴展，線上環境也愈來愈複雜，這就要求京東的發佈系統、監控系統、日誌系統等基礎設施的建設可以知足業務增加的場景，因而京東開始逐步構建 DevOps 平臺，經過不斷的迭代，在 2016 年京東雲正式商用，也同時把自身業務的實踐經驗，造成了京東雲 DevOps 方案正式發佈。

京東雲推動 DevOps 的決心

「京東雲 DevOps 平臺在內部經歷過幾回迭代，才發展到今天這樣一套平臺，爲你們提供能力。」

最先期的時候，京東雲內部分別構建了部署、監控、日誌的系統能力，但發現各個系統雖然能支撐京東雲業務的研發運維的需求，可是沒法作到很好的一體化支撐。

所以京東雲構建了最基礎的 CMDB，CMDB 的建設能夠說決定了京東雲 DevOps 平臺的最基礎的底座，早期 CMDB 會有一些模型上的問題，以及數據準確性的問題，致使了 DevOps 平臺能力有各類數據不一致的問題，或者模型不匹配的問題。

由此京東雲構建了「以 APP 爲中心，向上構建業務模型，向下構建資源模型」的 CMDB 模型，京東雲內部稱爲服務樹，以服務樹爲基礎進行研發運維能力建設。服務樹打通了各個系統之間的元數據，解決了信息孤島問題，但這時分散的運維繫統致使了監控、部署、日誌等操做的分散，各類研發角色之間很難緊密協同，不利於 DevOps 的實施。

然後京東雲在服務樹基礎之上進一步構建了 DevOps 平臺——雲翼，從而統一了操做入口，提高了用戶體驗和操做效率。現在的雲翼 DevOps 平臺有四大優點：

• 跨平臺混合雲管理——私有云、公有云和各類虛擬化平臺。如VMware、OpenStack、物理機資源的統一接入；
• 服務容錯，永不掉線——自動爲宕機服務器上運行的容器（雲主機）從新遷移並生成新的實例，保障業務不掉線；
• 全鏈路監控服務——縮短異常 MTTR，保障業務正常運行
• DevOps 提高企業交付能力——統一操做平臺，打破開發和運維團隊之間的障礙。

系統構建完成後如何更好地被內部接受，推廣的形式十分重要，怒吼發展 DevOps 文化是正確的，須要在組織文化上進行變革，在企業內部實施過程當中把文化和技術的方法論結合。固然也不能空談文化，要有工具的結合，工具鏈平臺也很重要。

「畢竟在企業內部，文化的轉變，難度之大超乎想象，所以 DevOps 的落地推進，更應該是經過工具鏈去引導文化， DevOps 應該像流水線同樣，把各個角色的人員鏈接在一塊兒。推進在內部跨團隊跨角色的落地實施。」鄭永寬提到。

談到京東雲在 DevOps 的研發投入與研發團隊狀況，鄭永寬說：「京東是一家重視技術的企業，在今年的 JDD 大會上，京東宣佈開啓京東技術服務元年，咱們會把技術做爲咱們的核心能力，咱們 DevOps 研發團隊大部分都曾服務過 BAT 一線互聯網企業，都擁有很是紮實的研發能力，近期咱們也在不斷引入行業內最優秀的 DevOps 專家。」

而京東雲不只僅在研發上投入資源，另外針對大客戶使用 DevOps 的狀況，還提供了專門的服務團隊，包括客服、技術中臺以及大客戶專屬架構師服務團隊，目前服務團隊大概規模近百人。

京東雲 DevOps 成果與優點

京東雲 DevOps 產品圖覽

在整個軟件交付過程當中，對於開發和運維來講，代碼的版本化管理相當重要，代碼提交的效率和代碼的安全也很是重要，京東雲構建了本身的代碼託管平臺 Code Commit，版本庫多地部署，保證代碼在京東雲的安全性和可靠性。同時它能夠無縫對接京東雲的雲編譯產品，實現從編寫源代碼到輸出構建結果的一站式服務，保證持續交付全流程。

整個產品層面，京東雲 DevOps 提供了代碼託管、雲編譯、雲部署、流水線、日誌服務、雲監控、雲撥測、性能測試、測試管理、雲翼 DevOps 平臺等能力，京東雲經過自身產品的能力進行整合，也造成了部署、測試、日誌、監控方向的技術解決方案。

在軟件交付效率和軟件交付質量提高上，京東雲 DevOps 提供了從代碼、構建、部署一條流水線式的方式來實施交付，同時提供測試管理、性能測試等測試方向的管理工具，來保證企業的軟件交付效率與質量。

咱們在瞭解或使用一項技術一款產品的時候，總會問爲何值得，它好在哪裏？對於京東雲來講，DevOps 最大的優點是源於京東自身業務實踐，京東雲 DevOps 目前提供的多重產品以及解決方案都是通過驗證的成熟的產品。經受屢次 6.1八、11.11 電商大促的嚴峻考驗，保證了高效高質的交付和對流量壓力的靈活應對。同時不只能夠實現工具鏈產品與平臺化產品的結合，提供 DevOps 工具鏈產品與平臺化產品兩種形態，幫助不一樣的客戶需求靈活定製方案，助力企業數字化轉型與產業互聯網發展。

此外，基於電商互聯網的基因，京東雲 DevOps 相對於競品，在 Ops 部分投入了更多的精力，更具有能夠知足各類複雜場景的自動化運維能力，具體表如今：

• 與京東雲深度集成，提供統一的運維入口，一站式解決業務生命週期內服務管理閉環，能夠知足各類複雜運維場景一鍵式做業，實現真正的自動化研發運維；
• 運維管理能夠與企業組織結構匹配，基於角色的權限管理，知足企業層次化運維管理；
• 智能監控提供基礎-存活-性能-業務全鏈路監控，確保監控覆蓋，提供豐富異常檢測手段和報警策略，下降故障 MTTR；
• 統一的元數據管理平臺，統一運維入口，有效提高運維效率和下降運維複雜度，進一步下降穩定性風險；
• 從保障用戶業務穩定性的角度，DevOps 服務可自動爲宕機服務器上運行的容器（雲主機）從新遷移並生成新的實例，保障業務不掉線，高可靠運行。系統自動監控服務健康狀態，動態調整集羣，實時調度相關預案，實現故障自愈。

而其實在去年，「2018 GOLF金牌運維峯會」上，京東雲翼 DevOps 就榮獲「運維行業2018年度明星產品」。

京東雲在 DevOps 上的將來規劃

針對將來的規劃，京東雲有三個方向的策略：

1完善標準化產品+解決方案

京東雲做爲行業內極具產業屬性的雲智能廠商，會在標準產品能力基礎上，結合京東集團在零售、物流、數字科技等方面的組合生態優點，在助力業務自身實現持續迭代、發展的同時，立足產業特色與京東集團深厚行業經驗，將 DevOps 產品結合其餘雲產品服務以解決方案形式落地輸出。

2依託京東雲開發者社區，進一步推廣 DevOps 產品

面對大衆開發者、重點開發者與合做夥伴羣體，從內容支持，佈道師技術支持，到代碼、數據級交流提供持續服務，爲京東雲客戶提供更好的上雲體驗。

3完善核心生態體系

有關渠道拓展，京東雲將在充分發揮自身銷售能力、品牌輸出的同時，進一步利用渠道打造開放環境，構建產業生態圈、吸引更多的開發者和合做夥伴，完整創建起圍繞京東雲公有云、私有云雲平臺的核心生態體系。

京東雲一直在致力於產品的研發和完善，產品也比較少對外發聲，後續在推廣上將會加大力度，讓更多的企業及開發者瞭解其能力。包括舉辦 DevOps 專項活動（如：京東雲 DevOps 自動化運維技術實踐·上海站），開發者社區的佈道，與外部諮詢機構合做，經過專業客觀的評估，來向外傳達京東雲 DevOps 的相關能力。

結語

「故事的開頭老是這樣，適逢其會，猝不及防。故事的結局老是這樣，花開兩朵，天各一方。「，用戀愛關係打個比方，對於發展 DevOps 來講，開發和運維同窗們，也別天各一方了，仍是並蒂雙開吧。

點擊「閱讀」瞭解更多關於京東雲翼

歡迎點擊「京東雲」瞭解更多精彩內容