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

京東科技開發者發表於2019-12-19
dev

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

作者：王利瑩
採訪嘉賓：京東雲DevOps團隊負責人 鄭永寬
今年，IDC 特別針對中國地區釋出了《IDC MarketScape：中國 DevOps 雲市場 2019，廠商評估》研究報告，IDC 對具有代表性的 7 家 DevOps 雲提供商進行了深度研究。 報告顯示，基於產品現有能力、未來策略與投入、市場表現與客戶滿意度三大指標體系的綜合評估，京東雲 DevOps 躋身”Major Players“（核心廠商）位置。

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

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推進中的一波三折

京東雲 DevOps 產品圖覽


在整個軟體交付過程中，對於開發和運維來說，程式碼的版本化管理至關重要，程式碼提交的效率和程式碼的安全也非常重要，京東雲構建了自己的程式碼託管平臺 Code Commit，版本庫多地部署，保證程式碼在京東雲的安全性和可靠性。同時它可以無縫對接京東雲的雲編譯產品，實現從編寫原始碼到輸出構建結果的一站式服務，保證持續交付全流程。

整個產品層面，京東雲 DevOps 提供了程式碼託管、雲編譯、雲部署、流水線、日誌服務、雲監控、雲撥測、效能測試、測試管理、雲翼 DevOps 平臺等能力，京東雲透過自身產品的能力進行整合，也形成了部署、測試、日誌、監控方向的技術解決方案。
在軟體交付效率和軟體交付質量提升上，京東雲 DevOps 提供了從程式碼、構建、部署一條流水線式的方式來實施交付，同時提供測試管理、效能測試等測試方向的管理工具，來保證企業的軟體交付效率與質量。
我們在瞭解或使用一項技術一款產品的時候，總會問為什麼值得，它好在哪裡？對於京東雲來說，DevOps 最大的優勢是源於京東自身業務實踐，京東雲 DevOps 目前提供的多重產品以及解決方案都是經過驗證的成熟的產品。經受多次 6.18、11.11 電商大促的嚴峻考驗，保證了高效高質的交付和對流量壓力的靈活應對。同時不僅可以實現工具鏈產品與平臺化產品的結合，提供 DevOps 工具鏈產品與平臺化產品兩種形態，幫助不同的客戶需求靈活定製方案，助力企業數字化轉型與產業網際網路發展。
此外，基於電商網際網路的基因，京東雲 DevOps 相對於競品，在 Ops 部分投入了更多的精力，更具備可以滿足各種複雜場景的自動化運維能力，具體表現在：
  • 與京東雲深度整合，提供統一的運維入口，一站式解決業務生命週期內服務管理閉環，可以滿足各種複雜運維場景一鍵式作業，實現真正的自動化研發運維；
  • 運維管理可以與企業組織結構匹配，基於角色的許可權管理，滿足企業層次化運維管理；
  • 智慧監控提供基礎-存活-效能-業務全鏈路監控，確保監控覆蓋，提供豐富異常檢測手段和報警策略，降低故障 MTTR；
  • 統一的後設資料管理平臺，統一運維入口，有效提升運維效率和降低運維複雜度，進一步降低穩定性風險；
  • 從保障使用者業務穩定性的角度，DevOps 服務可自動為當機伺服器上執行的容器（雲主機）重新遷移並生成新的例項，保障業務不掉線，高可靠執行。系統自動監控服務健康狀態，動態調整叢集，實時排程相關預案，實現故障自愈。
而其實在去年，“2018 GOLF金牌運維峰會”上，京東雲翼 DevOps 就榮獲“運維行業2018年度明星產品”。

京東雲在 DevOps 上的未來規劃

針對未來的規劃，京東雲有三個方向的策略：
1完善標準化產品+解決方案
京東雲作為行業內極具產業屬性的雲智慧廠商，會在標準產品能力基礎上，結合京東集團在零售、物流、數字科技等方面的組合生態優勢，在助力業務自身實現持續迭代、發展的同時，立足產業特點與京東集團深厚行業經驗，將 DevOps 產品結合其他雲產品服務以解決方案形式落地輸出。
2依託京東雲開發者社群，進一步推廣 DevOps 產品
面對大眾開發者、重點開發者與合作伙伴群體，從內容支援，佈道師技術支援，到程式碼、資料級交流提供持續服務，為京東雲客戶提供更好的上雲體驗。
3完善核心生態體系
有關渠道擴充，京東雲將在充分發揮自身銷售能力、品牌輸出的同時，進一步利用渠道打造開放環境，構建產業生態圈、吸引更多的開發者和合作夥伴，完整建立起圍繞京東雲公有云、私有云雲平臺的核心生態體系。
京東雲一直在致力於產品的研發和完善，產品也比較少對外發聲，後續在推廣上將會加大力度，讓更多的企業及開發者瞭解其能力。包括舉辦 DevOps 專項活動（如：京東雲 DevOps 自動化運維技術實踐·上海站），開發者社群的佈道，與外部諮詢機構合作，透過專業客觀的評估，來向外傳達京東雲 DevOps 的相關能力。

結語

“故事的開頭總是這樣，適逢其會，猝不及防。故事的結局總是這樣，花開兩朵，天各一方。“，用戀愛關係打個比方，對於發展 DevOps 來說，開發和運維同學們，也別天各一方了，還是並蒂雙開吧。
點選“ 閱讀 ”瞭解更多關於京東雲翼
歡迎點選“ 京東雲 ”瞭解更多精彩內容

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

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


來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69912185/viewspace-2669481/，如需轉載，請註明出處，否則將追究法律責任。

相關文章