如何打造一個高逼格的雲運維平臺？

前言

你們作運維廣泛經歷這樣的過程：

首先咱們會把操做作一個標準化，這個階段是運維質量的提高的階段。

在標準化實施完之後，因爲數目的增長，或者是一些運維場景的增多，咱們會逐步的進行一些工具化和自動化，這個階段咱們的運維的效率獲得提高。

可是衆多的工具以及自動化腳本，會讓咱們的管理過程當中比較困難，隨着人員的變更或者是一些工具維護過程當中的差錯，咱們的自動化運維工具的受衆羣體不太穩定。

這個時候咱們就須要一個平臺將咱們的運維工具以及運維過程當中的一些經驗進行沉澱，藉助這個平臺實現咱們的智能化運維，因而咱們從運維人員的需求和體驗出發出發進行了一個運維平臺產品化的構建。

銀行卡組織雲運維平臺的概況

我給你們介紹一下咱們IT體系建設的狀況，差很少十年前咱們以ITIL爲基礎構建了流程平臺，變動、事件、問題、服務等流程經過這個平臺進行流轉。

在五年前咱們從開放平臺轉化爲雲運維平臺，在這個過程當中，我也創建了IaaS虛擬化資源平臺，同時咱們也跟業界同樣構建了CMDB，用於贊成管理運維數據。

可是在運轉下來之後，咱們發現還有不少需求須要實現，主要三個方面：

軟硬件節點數目不斷增長，平常運維迫切須要一個適應各類運維場景的高效自動化平臺，減小重複勞動。

需求是將運維人員的經驗須要在一個平臺沉澱，造成一個智能化場景庫，將運維服務或能力的複用，從而提升總體運維質量和運維效率。

第三個需求是在傳統的流程化運維的基礎上，注入智能化場景，將運維工做從依靠人工判斷、流程決策，逐步轉爲依靠機器智能分析判斷。

因此基於這三方面須要，咱們建設了一個雲計算環境下面向規模化運維的平臺。

雲運維平臺主要解決的是如下幾個痛點:

• 互聯網業務在我所在的公司開展特別快，還會有一些營銷活動，這樣就須要運維有一個快速的響應。
• 咱們的硬件數目有了一個幾何級的增加。
• 最近幾年頻繁的使用一些開源架構新興技術，對運維技術增長了要求。
• 運維工具散亂，缺少同同一管理。
• 咱們運維數據沒有一個同一的的展現
• 第六個是咱們的人力增加目前比較緩慢，咱們在審計過程當中會有一些人工安全性方面的問題。

出於這些方面考慮，咱們運維平臺的願景，是運維的質量以及可運維設備的數量不因咱們的運維人員的數量或者是技能的變化改變，從而實現咱們的運維的數量和質量都達到一個可控的。

銀行卡組織的雲運維平臺是個怎樣的產品

接下來給你們介紹一下咱們運維平臺這個產品，主要四個方面：

第一是資源統一調度，咱們能夠將資源整合，咱們經過資源平臺提供的API包括，包括Openstack、數據庫管理平臺、容器管理平臺、分佈式存儲管理平臺、網絡管理平臺、安全管理平臺，將咱們所經常使用的運維操做，都整合在咱們這個運維平臺中，將咱們的運維流程儘可能的簡化，實現自助化運維。

第二，咱們但願藉助咱們運維平臺儘可能實現自動化管理，減小咱們手工操做，實現自動的數據收集、自動應用安裝、自動配置和更新、自動數據分析、自動擴展、自動備份恢復、自動鼓掌處理等。

第三是多維爲可視化，讓各個角色有一個在平臺上都有一個獨立的視角，以角色重定義運維。如網絡管理視圖，系統管理視圖、監控視圖、報表視圖等。統一報表系統，統一全局數據並提供可自定義多維報表。

最後一個就是實現高性能，咱們但願咱們這個運維平臺能夠知足萬級節點的併發收集、執行。

雲運維平臺建設場景

這個是咱們運維平臺的場景規劃圖，下面是咱們一個核心的調動模塊。包括執行、採集以及和其餘流程的對接，中間是咱們這個運維平臺主要要作的事情，咱們把這個叫作運維OS，圖表管理實現自動化拓撲和自定義報表，全生命週期管理是實現應用系統從上線到下線經過咱們這個平臺實現一個自動化的實施。

運行環境管理和運維工具給實際的運維人員提供一個比較便利的一個操做環境，包括備份比對，做業編排以及參數管理等，容量管理咱們是但願經過咱們這個平臺將監控的數據進行一個彙總，實現對容量的管控。

高可用管理對咱們各個應用系統，各個層面的組件的可用性進行一個統一的管理，可用性監控，自動化可用性演練。

重點場景一：生命週期管理

第一個是生命週期管理，咱們周圍在之前的一個部署過程當中，一般是這樣的，開發人員寫一個是需求文檔經過內部流程給運維接口人，他會協調各資源管理員分配資源，造成部署方案，最後將這個部署方案經過人工構建變動的方式實施。

這裏面有兩個問題，一是傳遞過程當中可能誤差，第是週期比較長，咱們但願藉助咱們的雲運維平臺實現參數級別的電子化傳遞，以及自動化的部署。也就是用戶在咱們平臺上面選擇須要的組件，以及資源需求，由咱們的管理員分配、確認實際的部署資源。

最後由平臺進行一個自動化的部署，並在部署過程當中自動進行各項規範標準的實施。

重要場景二：運行環境管理

第二個場景是咱們的運行環境管理，包括資源類的CPU、內存、IP、端口、訪問關係等，以及咱們運維人員關注的，定時任務、備份策略、自啓動項目等。咱們經過雲運維平臺對運行環境進行管理，替代原有excel表格，並進行自動化設置。

重要場景三：持續部署管理

第三個場景是持續部署管理，傳統部署方式咱們會遇到一些問題，包括：應用版本經過版本服務器屢次人工傳遞，各應用的配置、維護腳本沒有統一標準;經過表格人工維護各環境的參數差別，不一樣環境人工修改參數;應用的安裝過程視變動人員經驗，異常告警沒有統一標準，回退方式不統一等。

爲此，咱們作了一個持續發佈的標準，並且將這些標準藉助這個平臺能夠實施，包括：統一版本傳遞路線，版本標準化;構建生產、測試、研發環境配置差別庫，平臺根據所在環境自動生存對應參數;標準化應用部署過程，多節點安裝順序自由編排，按照編排順序進行安裝;標準異常告警;故障時按照編排順序逆向回退。

重要場景四：運行環境維護

第四個場景是是經常使用運維工具集成，包括咱們經常使用的應用重啓、健康檢查、隔離、恢復工具，服務器的一些物理測試，以及自動裝機後自動接入OpenStack或者是其它資源管理平臺的自動對接，網絡設備的健康檢查，還有一些按期的安全檢查，咱們把這些工具集成在咱們的雲運維平臺上。

重要場景五：畫像場景

第五個場景是咱們應用爲維度的應用畫像，一般咱們一個應用可能有不少的元素，你們想知道這些元素會比較困難，例如這個應用的架構是什麼樣的，可能只有在一些應用的開發設計人員，或者是一些骨幹的心中才能知道，也不必定特別的準確。

應用的參數可能有不少要到服務器查。應用版本、參數變遷、維護記錄須要翻變動，應用各個層面的容量狀況須要找各專業室查。應用的狀況廣泛說不清，要廢很大的力氣才知道是什麼樣。

咱們在雲運維平臺裏面，藉助咱們以前提到的各類產品管理工具，容量管理和高可用管理，咱們放在一個視圖的畫像裏面，根據變遷維護歷史以及應用的容量、高可用信息，還能夠計算出這個應用他的運維方面的成熟度。

雲運維平臺技術方案

在硬件資產層面咱們經過一些snmp等工具獲取狀態及操做，虛擬資源層面咱們目前藉助openstack及其它管理平臺提供的接口進行管理，操做系統之上咱們經過自主開發的核心調度系統對linux及應用進行管理。

咱們整個平臺是使用權的一個部署，除了下面的緩存和MySQL其餘全部的組件都是全容器的部署，前端使用apache、haproxy、keepalived;後端使用jboss、rabbitmq、ansible、zookeeper;數據存儲採用mysql、redis、ceph等;另外咱們還有一個安全服務模塊，檢查是否會有一些高危操做。

業務流技術

上圖是咱們具體的一個業務流程，左邊是咱們這個雲運維平臺的界面，一個運維請求會被封裝爲一個消息會放到消息隊列裏面，schedule模塊接收到消息後按照調度算法，自動分配給ansible節點，ansible節點經過ssh到服務器上執行，並將執行結果異步返回給消息隊列。

schedule的調度算法與Ansible分佈式架構

schedule的調度算法，是咱們考慮到咱們生產環境有不少的分區，咱們會根據他的IP自動生成一個所屬區域的tag，schedule在發現這些消息之後，他會針對你tag以及目標機器數據進行拆分，咱們把這個詳細拆分幾個消息，ansible去訂閱處理本身的消息。

咱們在ansible上進行一個改造，全部任務均有惟一的id，處理完成後返回消息，從而實現多任務的併發異步執行。

數據可視化

咱們在數據可視化方面，咱們經過採集器採集信息，經過同步器同步其它平臺信息，存儲在覈心數據庫，經過閾值庫產生進行對比告警，經過分析函數庫進行性能分析，併產生一些咱們運維須要的報表進行可視化管理。

銀行卡組織雲運維平臺成果展現

咱們平臺的建設結果，咱們這個平臺上面已經徹底建設的一些部分，另外有一些功能咱們在開發，這個是咱們在實際中已經上線的平臺，大概有幾千太的虛擬服務器，咱們首先看到這個信息中內心面有一個機房，咱們看到一些機櫃，而且配置好每個機櫃裏面對應的哪些服務器。

這個交換機/F5-物理服務器-虛擬服務器自動拓撲的頁面，是咱們根據snmp抓取交換機、F5信息，經過anbible抓取物理機的信息，經過openstack抓取虛擬機的信息，根據上述消息自動生成拓撲。

數據同步能夠自定義定時抓數據。

這是一個實際的備份管理的功能，咱們能夠用咱們的這個平臺選取相應的服務器，經過平臺自助定時、即時備份。

自助化啓動項管理。

自助化定時任務管理。

免費提供最新Linux技術教程書籍，爲開源技術愛好者努力作得更多更好：http://www.linuxprobe.com/