大家做運維普遍經歷這樣的過程：
首先我們會把操作做一個標准化，這個階段是運維質量的提升的階段。
在標准化實施完以後，由於數目的增加，或者是一些運維場景的增多，我們會逐步的進行一些工具化和自動化，這個階段我們的運維的效率得到提升。
但是眾多的工具以及自動化腳本，會讓我們的管理過程中比較困難，隨著人員的變動或者是一些工具維護過程中的差錯，我們的自動化運維工具的受眾群體不太穩定。
這個時候我們就需要一個平台將我們的運維工具以及運維過程中的一些經驗進行沉澱，借助這個平台實現我們的智能化運維，於是我們從運維人員的需求和體驗出發出發進行了一個運維平台產品化的構建。
銀行卡組織雲運維平台的概況我給大家介紹一下我們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抓取虛擬機的信息，根據上述消息自動生成拓撲。
數據同步可以自定義定時抓數據。
這是一個實際的備份管理的功能，我們可以用我們的這個平台選取相應的服務器，通過平台自助定時、即時備份。
自助化啟動項管理。
自助化定時任務管理。
原文來自：http://os.51cto.com/art/201611/521652.htm
本文地址：http://www.linuxprobe.com/make-cloud-devops.html
http://www.bkjia.com/Linuxjc/1191926.html TechArticle
