1. <legend id="jwpzh"></legend>

    2. <optgroup id="jwpzh"></optgroup>

      <optgroup id="jwpzh"></optgroup>
      1. 回到主頁

        干貨 | 以CMDB為基礎打造的DevOps平臺

        Jerry Huang

        · 操作指南

        背景

        6月29日,DevOps國際峰會暨DevOps金融峰會(DOIS)在北京終于開幕。作為國內首個國內唯一的國際性 DevOps 技術峰會,DOIS (DevOps 國際峰會)由 OSCAR 聯盟指導、DevOps 時代社區與高效運維社區聯合主辦,共邀全球80余名頂級專家暢談 DevOps 體系與方法、過程與實踐、工具與技術。

        在會上,優維科技資深解決方案架構師Jerry Huang對傳統行業DevOps落地方案中的《以CMDB為基礎打造的DevOps平臺》做了分享。

        *Jerry是國內較早的EXIN DevOps Master之一,現任優維科技高級解決方案架構師。有豐富運維研發經驗,負責多年中國移動運維架構以及敏捷轉型工作,曾在電力、通信、金融行業Devops項目建設實踐方面有豐富經驗。

        以下是Jerry Huang的演講內容,經編輯整理刪改:

        今天主要的主題是我們要打造現在的DevOps平臺為什么以CMDB基礎來打造。在這個過程中主要分四各環節:(1)DEVOPS平臺需要強CMDB(2)CMDB模型如何構建(3)CMDB平臺如何建設(4)招商銀行CMDB落地經驗分享,前面主要講DevOps平臺,最后的環節是講招商銀行總部的CMDB分享,互相借鑒參考一些經驗,希望可以跟大家討論一下。

        上面的四大塊是我們平常工作中就涉及相關的比較多的,比如說我們前端的服務構建平臺,服務構建平臺包括我們的一些研發、研發過程、需求管理的過程,以及我們代碼庫,服務交互過程可能是我們持續交互的平臺建設。后面是我們的服務運行平臺,我們運維部門涉及更多的比如我們的一些監控或者巡檢、維護還有告警事件。服務運營平臺,就是所謂的一些運營分析,比如我們的APM,比如我們的一些分布式鏈路監控,比如我們的一些統計分析平臺。

        ?

        這個CMDB它不再像以前我們的所謂的ITIL提出來的資產管理的概念,我們現在互聯網轉型的過程,我們的CMDB建設的核心是圍繞著一個應用的CMDB交付的過程,圍繞著應用CMDB交付的過程圍繞兩層部分,第一是基層平臺,第二是下面的黃色這一塊,就是我們的IAAS的資源池,有計算、存儲、網絡、公有云的服務。上面這一塊,這是我們基于下面的服務來建立一些類似CMP資源池管理。我們叫服務支撐平臺,圍繞著這所有的服務支撐平臺,是為了上層四大塊來提供一些實質性的、有效性的數據,做整個自動化的過程。

        持續交付平臺我把它劃為三塊,一塊以應用可視化自動化部署為核心,所謂的CD,就是我們所謂的自動化部署。自動化部署包括一些容器等等。第二以應用場景化變更管理為核心的,比如一些日志分析、日志監控還有頁面分析。第三是以應用流水線能力和持續改進為核心,這就是我們先做CD,我們再往上做一些OPS的持續反饋。再往前申到研發那一端,很多傳統企業大部分是外包廠商,很難控制到我們的研發那一端。所以我為什么把CI放在最后面,這也是傳統企業里面的很難的一步。

        DevOps里面,我們CMDB它起到一個承上啟下的過程,它往下就是我們的基礎資源、基礎設備層自動創建的能力,往上走就是我們運維平臺的所謂的PaaS服務。運維的價值在于交付能力。要把自動化的能力最終可以形成按鈕、平臺直接可以交付給研發端的東西。

        CMDB的釋義是IT資源管理,我們是圍繞著以應用為中心的價值交付,為什么以應用為中心?它有些什么樣的能力?比如我這個應用它布在OS上面,操作系統是什么,還有系統配置是什么,它屬于哪個業務,這一層互聯網可能叫做服務樹。服務樹上面比如說這個應用屬于哪個系統,這個系統屬于哪個大業務架構。再往下拓,這個集群以及這臺機器,它到底消費了哪些,比如它存儲、數據庫,往下到一些網絡。

        為什么要圍繞以應用為中心呢?因為這樣會產生非常多場景可以做,比如持續交付、自動化作業變更、版本上線,只要運維人員做了變更,數據狀態就能實時反饋到CMDB, 比如說我現在加了一臺機器,那我加的這臺機器按以前的路線可能只有用戶才知道?,F在很多互聯網化架構里面的業務,有部分企業做到一些灰色發布。做到這些發布的能力過程中,你要明確地知道哪些IP上面布了新版本,哪些IP還沒有更新。這塊是誰來做呢?CMDB,只有監控變更才做得到。所以我們為什么說是一個IT資源管理,就是面向應用的IT資源管理,它是全生命周期的管理。

        CMDB里面CI維護主要分為兩層,一層是最早的基礎層,一層是應用層,這個角度是我們需要新建的。目前來說,各個平臺現在大家都是獨立的,我們要通過什么樣的方式去影響呢?比如說我故障影響分析,我現在已經監控到了我有故障了,那現在大家的做法是發一個告警郵件,發給相關的負責人,他看到郵件之后人工去做定位,定位完了人工在變更平臺中去做修復動作。

        為什么一些簡單的動作不能做到自愈呢?比如我的監控平臺監控到表空間使用不足了。變更平臺里是不是有自動擴表空間腳本呢?這里完全可以通過CMDB關聯起來做自愈動作的,相關負責人知道這個被修復了就可以了。DevOps建設要有對象關系的維護,而且是非常準的前提,你才能支撐上層的自動化的能力。

        平常的一些場景包括上線、下線、故障自愈、持續部署等等都是需要強CMDB的過程,這里面很強調了我們CMDB里面都是以對象為基礎來去支撐的,比如說我們是面向一個應用為對象的,或者我面向一個設備為對象,那么我針對這個對象或者針對這個應用,我要對它上層能夠散發出什么樣的自動化的能力。

        下面來說一下,IP應用的生命周期為什么是靠CMDB能力來支撐的。比如上一個新的業務系統:從流程開始去申請一個資源變更的單,領導申請通過后線上管理人員能夠接收到工單。通知系統部署的能力。系統部署的能力,我們現在大部分做到了虛擬化,比如CMP的一些接口,完全可以做到自動化創建的能力。往下走,帶外監控機器是否創建成功。到自動化運維平臺,從CMDB里面拉取這個新OS需要部署什么中間件以及依賴包等的一鍵安裝。IT變更中心再往下走是應用構建與測試環境,我們在構建的過程中,這個環境準備好了,要去布包了,這個包是現機編譯的還是什么直接發布制品包?我們有2條線,在發布過程中啟動發布流程,發布流程會自動去CMDB拉取我們維護的這套數據,具體到拉取哪個包哪個版本,以及這個包的維護腳本是什么,推到我們的系統上部署成功之后,去跑我們的自動化回歸測試案例。再往下走這個業務驗證通過之后,CMDB獲取到這個狀態,那我監控平臺可以往上做監控Agent部署了。這是我們非常標準的上線流程,完全可以做到一鍵自動化,比如一鍵擴容,容災切換等場景。

        最后說一下再招行的CMDB建設過程,現在在招行建的首先是建設一個應用的CMDB,然后在CMDB基礎上建設流水線的能力。這里面關鍵點的原則,這個原則其實是當初分析非常多的時間才總結出來的。

        1)應用CMDB必須提供統一的應用元數據管理能力,和應用類型無關

        2)應用CMDB建設的核心訴求是應用生命周期管理

        3)應用CMDB必須以應用為中心,而非以基礎資源為中心

        4)應用CMDB必須要從應用的角度構建起與IT資源的彈性關系

        5)應用CMDB是為應用資源、動作、狀態的統一管理提供支撐

        6)應用CMDB要有統一的基礎資源層CMDB作為基礎

        7)應用CMDB的核心場景就是持續交付

        本次演講內容分享就到這里結束,若是想下載PPT,可以在“優維科技EasyOps”公眾號回復關鍵字“DOISPPT”即可獲得。

        所有文章
        ×

        還剩一步!

        確認郵件已發至你的郵箱。?請點擊郵件中的確認鏈接,完成訂閱。

        好的

        美女一级牲交视频