我們在數(shù)據(jù)可視化方面，我們通過采集器采集信息，通過同步器同步其它平臺信息，存儲在核心數(shù)據(jù)庫，通過閾值庫產(chǎn)生進行對比告警，通過分析函數(shù)庫進行性能分析，并產(chǎn)生一些我們運維需要的報表進行可視化管理。

　　作者簡介

　　魯逸丁 中國銀行卡組織運維架構師

　　長期從事金融信息系統(tǒng)運維工作，專注于運維體系建設，對金融企業(yè)云計算運維具有深刻理解，銀行卡組織云運維平臺負責人。

　　前言

　　大家做運維普遍經(jīng)歷這樣的過程：

　　首先我們會把操作做一個標準化，這個階段是運維質(zhì)量的提升的階段。

　　在標準化實施完以后，由于數(shù)目的增加，或者是一些運維場景的增多，我們會逐步的進行一些工具化和自動化，這個階段我們的運維的效率得到提升。

　　但是眾多的工具以及自動化腳本，會讓我們的管理過程中比較困難，隨著人員的變動或者是一些工具維護過程中的差錯，我們的自動化運維工具的受眾群體不太穩(wěn)定。

　　這個時候我們就需要一個平臺將我們的運維工具以及運維過程中的一些經(jīng)驗進行沉淀，借助這個平臺實現(xiàn)我們的智能化運維，于是我們從運維人員的需求和體驗出發(fā)出發(fā)進行了一個運維平臺產(chǎn)品化的構建。

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

　　我給大家介紹一下我們IT體系建設的情況，差不多十年前我們以ITIL為基礎構建了流程平臺，變更、事件、問題、服務等流程通過這個平臺進行流轉。

　　在五年前我們從開放平臺轉化為云運維平臺，在這個過程中，我也建立了IaaS虛擬化資源平臺，同時我們也跟業(yè)界一樣構建了CMDB，用于同意管理運維數(shù)據(jù)。

　　但是在運轉下來以后，我們發(fā)現(xiàn)還有很多需求需要實現(xiàn)，主要三個方面：

　　軟硬件節(jié)點數(shù)目不斷增加，日常運維迫切需要一個適應各種運維場景的高效自動化平臺，減少重復勞動。

　　需求是將運維人員的經(jīng)驗需要在一個平臺沉淀，形成一個智能化場景庫，將運維服務或能力的復用，從而提高整體運維質(zhì)量和運維效率。

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

　　所以基于這三方面需要，我們建設了一個云計算環(huán)境下面向規(guī)�；�運維的平臺。

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

　　互聯(lián)網(wǎng)業(yè)務在我所在的公司開展特別快，還會有一些營銷活動，這樣就需要運維有一個快速的響應。

　　我們的硬件數(shù)目有了一個幾何級的增長。

　　最近幾年頻繁的使用一些開源架構新興技術，對運維技術增加了要求。

　　運維工具散亂，缺乏同同一管理。

　　我們運維數(shù)據(jù)沒有一個同一的的展示

　　第六個是我們的人力增長目前比較緩慢，我們在審計過程中會有一些人工安全性方面的問題。

　　出于這些方面考慮，我們運維平臺的愿景，是運維的質(zhì)量以及可運維設備的數(shù)量不因我們的運維人員的數(shù)量或者是技能的變化改變，從而實現(xiàn)我們的運維的數(shù)量和質(zhì)量都達到一個可控的。

　　銀行卡組織的云運維平臺是個怎樣的產(chǎn)品

　　接下來給大家介紹一下我們運維平臺這個產(chǎn)品，主要四個方面：

　　第一是資源統(tǒng)一調(diào)度，我們可以將資源整合，我們通過資源平臺提供的API包括，包括Openstack、數(shù)據(jù)庫管理平臺、容器管理平臺、分布式存儲管理平臺、網(wǎng)絡管理平臺、安全管理平臺，將我們所常用的運維操作，都整合在我們這個運維平臺中，將我們的運維流程盡量的簡化，實現(xiàn)自助化運維。

　　第二，我們希望借助我們運維平臺盡量實現(xiàn)自動化管理，減少我們手工操作，實現(xiàn)自動的數(shù)據(jù)收集、自動應用安裝、自動配置和更新、自動數(shù)據(jù)分析、自動擴展、自動備份恢復、自動鼓掌處理等。

　　第三是多維為可視化，讓各個角色有一個在平臺上都有一個獨立的視角，以角色重定義運維。如網(wǎng)絡管理視圖，系統(tǒng)管理視圖、監(jiān)控視圖、報表視圖等。統(tǒng)一報表系統(tǒng)，統(tǒng)一全局數(shù)據(jù)并提供可自定義多維報表。

　　最后一個就是實現(xiàn)高性能，我們希望我們這個運維平臺可以滿足萬級節(jié)點的并發(fā)收集、執(zhí)行。

　　云運維平臺建設場景

　　這個是我們運維平臺的場景規(guī)劃圖，下面是我們一個核心的調(diào)動模塊。包括執(zhí)行、采集以及和其他流程的對接，中間是我們這個運維平臺主要要做的事情，我們把這個叫做運維OS，圖表管理實現(xiàn)自動化拓撲和自定義報表，全生命周期管理是實現(xiàn)應用系統(tǒng)從上線到下線通過我們這個平臺實現(xiàn)一個自動化的實施。

　　運行環(huán)境管理和運維工具給實際的運維人員提供一個比較便利的一個操作環(huán)境，包括備份比對，作業(yè)編排以及參數(shù)管理等，容量管理我們是希望通過我們這個平臺將監(jiān)控的數(shù)據(jù)進行一個匯總，實現(xiàn)對容量的管控。

　　高可用管理對我們各個應用系統(tǒng)，各個層面的組件的可用性進行一個統(tǒng)一的管理，可用性監(jiān)控，自動化可用性演練。

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

　　第一個是生命周期管理，我們周圍在以前的一個部署過程中，通常是這樣的，開發(fā)人員寫一個是需求文檔通過內(nèi)部流程給運維接口人，他會協(xié)調(diào)各資源管理員分配資源，形成部署方案，最后將這個部署方案通過人工構建變更的方式實施。

　　這里面有兩個問題，一是傳遞過程中可能偏差，第是周期比較長，我們希望借助我們的云運維平臺實現(xiàn)參數(shù)級別的電子化傳遞，以及自動化的部署。也就是用戶在我們平臺上面選擇需要的組件，以及資源需求，由我們的管理員分配、確認實際的部署資源。

　　最后由平臺進行一個自動化的部署，并在部署過程中自動進行各項規(guī)范標準的實施。

　　重要場景二：運行環(huán)境管理

　　第二個場景是我們的運行環(huán)境管理，包括資源類的CPU、內(nèi)存、IP、端口、訪問關系等，以及我們運維人員關注的，定時任務、備份策略、自啟動項目等。我們通過云運維平臺對運行環(huán)境進行管理，替代原有excel表格，并進行自動化設置。

　　重要場景三：持續(xù)部署管理

　　第三個場景是持續(xù)部署管理，傳統(tǒng)部署方式我們會遇到一些問題，包括：應用版本通過版本服務器多次人工傳遞，各應用的配置、維護腳本沒有統(tǒng)一標準;通過表格人工維護各環(huán)境的參數(shù)差異，不同環(huán)境人工修改參數(shù);應用的安裝過程視變更人員經(jīng)驗，異常告警沒有統(tǒng)一標準，回退方式不統(tǒng)一等。

　　為此，我們做了一個持續(xù)發(fā)布的標準，而且將這些標準借助這個平臺可以實施，包括：統(tǒng)一版本傳遞路線，版本標準化;構建生產(chǎn)、測試、研發(fā)環(huán)境配置差異庫，平臺根據(jù)所在環(huán)境自動生存對應參數(shù);標準化應用部署過程，多節(jié)點安裝順序自由編排，按照編排順序進行安裝;標準異常告警;故障時按照編排順序逆向回退。

　　重要場景四：運行環(huán)境維護

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

　　重要場景五：畫像場景

　　第五個場景是我們應用為維度的應用畫像，通常我們一個應用可能有很多的元素，大家想知道這些元素會比較困難，例如這個應用的架構是什么樣的，可能只有在一些應用的開發(fā)設計人員，或者是一些骨干的心中才能知道，也不一定特別的準確。

　　應用的參數(shù)可能有很多要到服務器查。應用版本、參數(shù)變遷、維護記錄需要翻變更，應用各個層面的容量情況需要找各專業(yè)室查。應用的情況普遍說不清，要廢很大的力氣才知道是什么樣。

　　我們在云運維平臺里面，借助我們之前提到的各種產(chǎn)品管理工具，容量管理和高可用管理，我們放在一個視圖的畫像里面，根據(jù)變遷維護歷史以及應用的容量、高可用信息，還可以計算出這個應用他的運維方面的成熟度。

　　云運維平臺技術方案

　　在硬件資產(chǎn)層面我們通過一些snmp等工具獲取狀態(tài)及操作，虛擬資源層面我們目前借助openstack及其它管理平臺提供的接口進行管理，操作系統(tǒng)之上我們通過自主開發(fā)的核心調(diào)度系統(tǒng)對linux及應用進行管理。

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

　　業(yè)務流技術

　　上圖是我們具體的一個業(yè)務流程，左邊是我們這個云運維平臺的界面，一個運維請求會被封裝為一個消息會放到消息隊列里面，schedule模塊接收到消息后按照調(diào)度算法，自動分配給ansible節(jié)點，ansible節(jié)點通過ssh到服務器上執(zhí)行，并將執(zhí)行結果異步返回給消息隊列。

　　schedule的調(diào)度算法與Ansible分布式架構

　　schedule的調(diào)度算法，是我們考慮到我們生產(chǎn)環(huán)境有很多的分區(qū)，我們會根據(jù)他的IP自動生成一個所屬區(qū)域的tag，schedule在發(fā)現(xiàn)這些消息以后，他會針對你tag以及目標機器數(shù)據(jù)進行拆分，我們把這個詳細拆分幾個消息，ansible去訂閱處理自己的消息。

　　我們在ansible上進行一個改造，所有任務均有唯一的id，處理完成后返回消息，從而實現(xiàn)多任務的并發(fā)異步執(zhí)行。

　　數(shù)據(jù)可視化

　　我們在數(shù)據(jù)可視化方面，我們通過采集器采集信息，通過同步器同步其它平臺信息，存儲在核心數(shù)據(jù)庫，通過閾值庫產(chǎn)生進行對比告警，通過分析函數(shù)庫進行性能分析，并產(chǎn)生一些我們運維需要的報表進行可視化管理。

　　銀行卡組織云運維平臺成果展示

　　我們平臺的建設結果，我們這個平臺上面已經(jīng)完全建設的一些部分，另外有一些功能我們在開發(fā)，這個是我們在實際中已經(jīng)上線的平臺，大概有幾千太的虛擬服務器，我們首先看到這個信息中心里面有一個機房，我們看到一些機柜，并且配置好每一個機柜里面對應的哪些服務器。

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

　　數(shù)據(jù)同步可以自定義定時抓數(shù)據(jù)。

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

　　自助化啟動項管理。

　　自助化定時任務管理。