DevOps與傳統的融合落地實踐及案例分享

內容來源：2017 年 8 月 26 日，優維科技聯合創始人&COO彭鯉航在「精益運維與DevOps最佳實踐 | 優維科技&又拍雲技術沙龍」進行《DevOps與傳統的融合落地實踐及案例分享》演講分享。IT 大咖說（微信id：itdakashuo）做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：6084 | 16分鐘閱讀

嘉賓演講視頻及PPT回顧： t.cn/RBSNmhJ

摘要

在DevOps日趨成熟的今天，傳統該如何藉助DevOps的能力實現變革與創新？本次主題分享講從具體案例出發，談談企業在落地DevOps中遇到的問題。以及DevOps落地的一些具體方法和技巧。

DevOps體系架構

DevOps的核心思想就是對之前的軟件研發管理過程的進一步延伸，它整合了敏捷管理、持續交付、IT服務管理，關注的是整個業務/應用/服務生命週期的管理和it戰略進行了對齊。

下圖是企業實現DevOps的總結原則：

產品的生產過程包含有三類角色：研發、測試運維，之前這三類角色基本上各自對立，如今DevOps的出現讓他們都被整合到了一塊，共享面向客戶的價值、共享集成目標、共享質量責任。從這一層面來看，其實DevOps存在不一樣實踐，分別是研發方面的實踐、測試方面的實踐、運維方面的實踐，咱們本次主要聚焦在運維方面。

國內互聯網運維的DevOps之路

咱們對騰訊的IT能力發展進行了總結，將其分爲五個階段：事務化管理，流程化管理、自動化管理、可視化管理、智能化管理。

事務化管理只須要完成基本的系統搭建，完成指定任務就夠了。但隨着團隊規模的增大，僅僅是作完是不夠的，還須要作好，這就須要引入流程化管理。再下一個階段對效率上又有了要求，自動化的管理被引入進來。當設備達到10萬臺的時候，想要提升效率就不怎麼簡單了，這時可視化管理就變的很重要。最後就是智能化管理，經過用戶大數據行爲就能夠支撐不少的運維管理的工做。能夠發現業務的迅速發展使機器數量增加迅猛，同時對IT服務管理的要求不斷提升。

運維能力建設的最佳實踐

運維能力的提高核心實際上是實現自動化運維和數據化運維，而想要實現這兩個能力須要經歷三個階段，分別是標準化階段、服務化階段、平臺化階段。

DevOps之標準化實現

在解決運維場景或者生產場景過程當中的問題的時候，實際上存在兩個影響因素，一個是標準化能力，另外一個是自動化能力，他們被用來支撐整個運維管理。當標準化能力較強時，作自動化就會輕鬆些，反之亦然，他們是一個互相 支撐的關係。

運維環境的標準化是一個分層結構，在動手實踐標準化的過程當中要考慮到網絡層的標準化、設備層的標準化、系統資源層的標準化、應用層的標準化和業務層的標準化。

標準化體系建設的方法論

對不少企業來講標準化可能只是意味着一份文檔、一句管理口號或者下發的規章制度，若是推行標準化的方法是這些 ，那麼失敗基本上是註定的。

那麼什麼是真正的標準化？

第一標準化是一種團隊理念，看的是團隊在業務規劃的時候是否有將業務環節作標準的理念。第二標準化是一個生產過程，咱們要判斷標準化生產規定是否嵌入到了交付過程當中，若是在沒有標準化的狀況下業務就沒法上線，那麼標準化就不光是一句空話。第三標準化是變動工具，實際上每一個落地的變動工具在作的就是標準化，只要用工具執行結果就必定是標準的。最後標準化是CMDB。

在推動標椎化的過程當中，核心是打造CMDB能力、流程能力和自動化能力，CMDB用於承載和檢驗標椎化的結果、流程讓標準化融入管理過程、自動化讓標準化融入生產過程。

目前市面上的CMDB方案不少聚焦的是基礎資源層面的管理，包括機房管理、設備管理以及硬件的管理等都被存儲到CMDB中。而在這樣的狀況下數據的使用可能還不如Excel，由於它的數據更新是須要人工錄入的，有可能會出現忘記寫入形成數據不許的狀況。

真正的CMDB關注的不只是如何管理信息，更關鍵的還在於讓數據去支撐應用和業務管理，這纔是CMDB系統的邊界。從這個角度來看，在現今這樣的雲時代實際上基礎資源已經不重要了，更須要關注的是應用層的信息，好比應用的構建、應用包含的信息、應用管理方法、應用維護流程等。這些應用層的信息又依賴於底層的資源，因此在定義CMDB中存儲的數據的時候，咱們視野必定要從應用層往下走。

另外一方面在設計整個CMDB時要考慮到消費場景，要考慮到要存儲的數據價值、數據的具體用途等。

輕量級別的New ITSM vs 傳統的ITSM

從CMDB的維度上能夠發現最終咱們仍是要管理不少的基礎資源信息，要想高效的管理和維護這些信息，靠人工干預確定不行。解決這個問題的方案有兩個，一是構建自動化的能力；二是依靠流程化，好比對於設備的採購會有采購單、入庫單，設備變動的時候會有審批流程和審批單等等，全部的這些信息均可以流轉到CMDB中，再也不須要花費時間維護。

所以咱們最終的目的是將CMDB和ITSM的能力進行整合。但傳統的ITSM更多的是面向管理能力，它強調過程標準規範以及分階段持續完善。所以如今咱們還須要ITSM與運營和持續改善的能力結合，向自動化運營擴展，它重視運營大於建設。

DevOps之服務化實現

服務化的核心是自動化能力。原來運維有不少的業務管理場景，大部分的狀況下都是手工操做，進一步的也僅是自動化的腳本。如今咱們但願將這些須要手工和腳本完成的任務轉化成服務化的能力。

服務化的要求其實很簡單，它有明確的服務輸入定義、職責以及最終交付的標準。從這個角度來看，咱們所須要的是經過做業平臺或者調度引擎的能力去有機的梳理原來運維的各類場景，把它變成服務工具或者服務平臺。這些服務平臺對外又有着明確的交互、接口和要求，它的好處在於對外隱藏了複雜的部分只須要經過接口進行交互延伸。

服務化體系建設的方法論

在創建自動化能力的時候咱們不少時候都會糾結於完美的方案，可是實際上並無完美的方案，只有可用和不可用的方案。只要這個方案可以知足一部分的需求那麼就先用起來，而後再慢慢優化，這就是快速嘗試。

第二是實現閉環，原先在作系統能力建設的時候咱們每每想要向更深更全上去發展，而其實如今所須要的是可以面向完整的應用場景，並經過關聯服務的協同來實現能力閉環。

運維場景很複雜，須要分而治之，每一個服務要儘可能簡單和獨立，同時必定要提供服務接口。

DevOps之平臺化實現

服務化完成後，每一個不一樣的能力和服務化場景都經過服務化能力有效的實現了，至此還須要有一個平臺將這些能力進行整合。

整合平臺的時候核心的考慮點在兩個維度，一是應用管理，二是生命週期管理。

一個應用的構成包含主程序、配置、運行環境描述、管理腳本、日誌清理、容災備份等，全部的這些相關的內容實際上都是應用管理中須要考慮的，在構建面向應用的管理時關注的就是這些內容。

應用的生命週期管理如上圖的閉環，實際上考慮的是從產品的設計、開發、構建、測試、交付、發佈到維護和監控的這樣一個完整閉環能力。

交付能力

DevOps強調的就是快速交付能力，從運維的角度來看有兩層含義，一是資源的交付，二是應用的交付。對於國外的公司來講可能不在須要考慮資源的交付，由於他們的DevOps都構建在雲上，而以國內如今的IT環境很難去實現這一點。

在資源交付方面，咱們如今有不少的平臺，包括私有云、公有云、物理平臺等。針對這些不一樣的平臺所要作的就是構建一個集中的資源管理平臺，經過資源的快速生產、分配能力來加快設備生命週期的循環，經過快速循環來淘汰過期和非標準的資源類型，同時資源的快速交付也意味着更低的成本。

應用的持續交付是DevOps所涉及的部分，它從git或svn的源碼庫開始直接作快速的構建，而後生成UT測試、生成鏡像、發佈的測試環境測試、冒煙測試系統測試。目前構建這種能力業界用的比較多的是Jenkins持續集成平臺，它能夠幫咱們把前端的源碼庫對接和構建自動化能力銜接起來，可是在交付的運維層面上流水線的能力主要仍是依賴腳本管理。

上圖是運營管理平臺的總體架構，它的底層是各類硬件資源平臺的整合，往上是CMDB，用來銜接資源層和服務能力層。再往上是各個不一樣的能力域，裏面的模塊就是各個服務能力，每個服務化的模塊都有一個接口，服務之間的協同經過統一的API網關實現，API網關會匯聚下方的各個服務能力提供的接口將服務進行整合對上層暴露，而後由服務編排系統將這些接口組織成不一樣的邏輯場景，最後呈現給用戶的是運維服務目錄、研發者服務目錄、我的任務中心以及業務的狀態中心。

EASYOPS及企業實踐

物流客戶的EASYOPS建設方案

咱們曾服務過一家物流企業，他們有本身的監控系統、日誌的分析平臺也有一些工具，可是總體來看能力仍是比較弱。他們所遇到的最大的問題是發佈成本很高，每一次發佈都須要停機，時間大概是二、3個小時，最終在業務部署接入EasyOps後發佈時時間被減小到10分鐘。

項目建設的三個階段

項目建設的三個階段分別是標準化、服務化、平臺化。原先的發佈之因此須要2個小時，核心的問題在於程序的耦合性太強，而標準化中有一個很關鍵的應用程序解耦，它拆開了一些沒必要要的模塊，使得發佈效率得以提升。服務化中應用程序的改造與標準化中的解耦有關，要想對非強制依賴的部分進行解耦，就須要向改造原先的程序。

挑戰和機會

上圖是這個過程當中遇到的挑戰和機會。

這裏簡要說下挑戰。一是沒有標準化積累，不少東西都是亂的，好比不一樣網段採用同樣的IP，很難管理。二是內網環境管理嚴格，它內部分爲生產網和辦公網，咋看起來很安全，但有一個致命的問題——內部出故障時沒法判斷是網絡仍是應用問題，同時因爲內網審覈時間很長，即便判斷出問題所在也不能立刻變動。三是沒有CMDB，所擁有的1000臺以上的物理機都是經過excel維護，四是沒有IT流程，基本上依靠的是郵件和電子流而且和IT維護脫節。

交付平臺

咱們交付了兩套環境，分別是測試環境和生產環境。測試環境主要用來作功能上線前的演示，每次的BUG修復或者新版本驗證的時候都會事先在測試環境試運行。

集中仍是離散

在應用的快速交付過程當中之前不少公司的作法相似上圖這樣的流程。

某個程序發佈以前都會在本地備份原先的程序，而後纔將這個程序放進去。爲了防止程序丟失在備份完成後，還要有一臺專用的備份服務器存儲備份。這種方案在集羣足夠大的狀況下，可能沒什麼問題，可是在集羣較小或者單機的狀況下，一旦機器掛掉程序就可能丟失。這時候就須要在程序源碼庫中找尋原先的版本，爲了保證必定能在源碼庫中獲取到程序版本，不少公司都會在新版本發佈到業務服務器後，再從服務器拷貝一份該版本到源碼中。

上圖是咱們採起的解決方案。

這裏有一個製品庫的概念，研發的源碼有着版本管理，發佈的製品也應該要有版本管理，而這個版本管理就被放在製品庫中。所以在發佈的時候就再也不須要在本地進行備份，由於製品庫會集中管理每次交付的版本，要進行回滾的時候直接能夠從製品庫拿取須要的版本。

雙製品倉庫解決網路隔離問題

前面提到過不少企業會有研發網和生產網的隔離，爲了解決製品庫的發佈被專線隔離的問題，就須要選擇是搭建一套平臺仍是兩套平臺。對此咱們的建議是搭建一套平臺，由於若是搭建了兩臺平臺，全部的CMDB的信息就是離散的，須要人工從新匯聚信息。另外一方面代碼是從製品庫拉出來傳到服務器上，中間因爲有着專線隔離存在帶寬上的問題，若是研發網的製品庫要鏈接生產網傳輸效率就很低，對此的應對方案是每次上傳製品的時候進行數據同步。

設計配置項的管理和維護過程

爲了使用CMDB的收集的大量信息，咱們設計了不少流程，好比網絡設備上架，網絡設備採購及下架、應用的上線及下線，這些流程會和整個流程平臺結合。

上圖是流程平臺，在這裏填寫的有用信息會流轉到CMDB中去，而自動化平臺中所作的任何變動也會和流程平臺進行交互，因此最後的信息都會落入到CMDB中。

測試

原先瀑布流的軟件管理測試作的很是完整，可是現今互聯網都在追求敏捷，使得不少有需求的測試都被省略。現今大多數公司單單隻聚焦在功能性測試上，性能和可靠性測試會有一部分，安全性、可維護性、可運行性測試則徹底沒有。

測試的過程通常都是這樣的：單元測試、功能測試、預發佈測試、生成灰度、生產全量。

整個過程當中咱們發現不少客戶沒有預發佈測試環境，功能測試完後直接在生產環境中作灰度和全量。功能測試的交付製品中包含程序和配置，且在研發環境和生產環境中配置不一樣，因此在沒有預發佈測試的狀況下每每沒法驗證交付製品。

灰度

上圖是個關於灰度測試的例子。A和B都是集羣化部署，A功能依賴B功能，這時若是對A、B分別灰度，那麼A就有可能會調度不一樣的B。另外一方面升級的時候A能夠灰度一臺，B則須要所有升級，這種狀況下灰度就沒法進行下去。

針對以上問題的一種解決方案是藍綠部署，經過藍綠部署將A、B配置的設置徹底區分開，這時對其中一個集羣作升級的時候，老的集羣能夠繼續保留。這種方案的灰度只有一半，也就是按藍綠的灰度。

更好的解決方案是調度網關，當B要升級的時候，有幾個核心理念：一是B`須要兼容舊版本的A的請求，二是經過調度網關識別請求，而後調度到合適的目標中去。

從文件交付到程序包交付

之前的交付是將文件和腳本放到機器上，而後人工運行腳本對文件進行發佈以及相關操做。這種方案存在一些問題，首先是沒有完整的運行環境，其次機器若是出現故障，要想擴容一臺機器的時候，就須要到原來的機器中將程序、環境變量以及腳本都拷貝出來。

最後咱們提出了程序包的概念。全部的應用都有獨立的程序包，包含程序、配置、管理方法，而且有本身的運行環境，能夠自我監控自我管理，咱們須要作的只是將程序包發到機器上運行就夠了。這個時候作擴容就很是簡單了，只須要從製品庫中將所要的包發到新的機器上就。

上圖所列出的就是程序包中具體所包含的東西。

工具和平臺都是爲人服務的

咱們不少時候都會思考如何將AI或者大數據應用到運維的場景中來。

爲了便於理解這裏先來對比下Deep Blue和AlphaGO，這二者實際上是徹底不一樣的解決方案。

前者將國際象棋的整個算法抽象成25條規則，用來判斷每一步棋的好壞，這裏的難點在於如何定義那25條規則。

因爲圍棋的下法太多很難根據一些簡單的規則定義每一步棋的好壞，因此AlphaGo使用的是深度學習的方案。深度學習有兩個核心的概念，一是對原始的數據集進行抽象提取有價值的數據，二是對這些有價值的數據分類最終得出想要的結論。

時至今日當咱們想要實現智能化運維的時候，就會發現其實咱們連最基本的數據歸類都沒作到。因此說當下更重要的是經過流程平臺、CMDB以及持續反饋的能力將有價值的數據承載起來，將來基於這種數據，即便不用AlphaGo的深度學習算法，也能夠採用Deep Blue的那種簡單決策模型找尋到有價值的信息。