企業應用運維自動化應該如何設計？

企業應用運維定義

咱們把企業內的IT團隊作一個初步職責和邊界劃分：

運維的起始點是拿到開發的代碼包開始，而後進行資源環境準備、環境搭建、應用發佈，以及一些列的運維支撐保障工做；而從運維團隊內部來看，大體從技術棧層面分爲幾類：

IDC運維：負責操做系統及如下的運維支撐工做，主要提供穩定的網絡、存儲和服務器。

SA：系統管理員，負責操做系統以上，代碼如下的運維管理工做，不過有的公司，因爲中間件的運維支撐與應用關聯緊密，不少時候SA只負責操做系統和數據庫兩個內容。

應用運維：核心職能是確保進程和服務可用，同時響應研發、運營人員的訴求，維護新版本的穩定運行，以及提供數據和服務給到運營人員。

應用運維在各個行業裏面都很是重要，其發揮的價值深度，對於公司業務支撐保障和與優化輔助，都起着相當重要的做用，但面臨的困境也不少。

應用架構多樣性、異構化程度大；不管是多年前沒法重構的單體架構，SOA架構的應用，微服務架構應用，基於業務中臺的架構，仍是近幾年號召的雲原生架構，越大的企業，應用的多樣與異構化程度就越大，對於應用運維人員的技術棧要求高，管理複雜度大。

安全和質量級別要求高；不管是新版本發佈，災備切換與演練，應用故障處理仍是其餘維護場景，都直接影響應用服務的可用性，更不要說由於操做權限很高，可能出現誤操做或破壞性行爲的風險。

效率要求高；快速發現問題，定位問題和觸發預案處置，每個節點的速度都影響了SLA，於是應用運維主動和被動響應的要求都愈來愈高，沒有自動化手段已經沒法解決現有的局面。

沒法提供數據分析的增值服務；應用運維擁有核心的日誌、配置、監控數據，這些數據每每能經過一些技術手段分析後，提供給運營人員，給他們帶來增值服務，而平常繁雜的工做，和缺少有效的數據分析手段，致使價值沒有獲得充分發揮。

應用運維自動化設計前提

在應用運維自動化設計前，咱們須要有兩個基本的共同認知，這樣才能保障總體的設計規劃是有效的。

1. 應用的異構化是一個長期存在的狀態。

2. 應用運維自動化平臺具有適應靈活場景的能力，具有很強的擴展性。

爲何須要有這兩個約束，最核心的緣由是若是企業的業務標準化程度足夠高，甚至所有能雲原生化，這個時候業務API也是服務、函數也是服務。而云自身能提供足夠高的可用性和保障功能，其實對於體系化的自動化運維平臺需求並沒那麼強烈了，由於在這種理想化的狀況下，場景足夠單一了，並不須要適配各類異構化的場景。可是咱們都知道，目前實際狀況來看，多種架構和類型的應用共存，是一個可能很長期的狀態。於是，從設計原則看：

平臺化架構：

把應用運維須要的通用能力沉澱下來，而後場景能夠保留持續擴展構建的能力，只有這樣，才能適配應用運維過程當中，各類靈活和自定義的運維場景。

原子化：

豐富應用運維的最小操做單元，而後基於平臺能夠快速迭代出各種場景，例若有了分發文件、執行腳本的原子，就能夠編排出一個簡單的應用發佈自動化場景。

要覆蓋企業應用運維全生命週期：

從應用的上線、運行，到後續一系列運維場景和過程來規劃所需的功能和工具；

標準性：

從輸入、輸出、操做規範、安全控制等方面對運維操做組件進行規範性約束。

基於應用生命週期設計應用運維自動化

咱們從應用運維的生命週期來看，大體分爲以下幾個部分：

應用上線：應用上線前的標準化資源與運行環境準備，以及應用上線過程當中的發佈與更新操做。

應用上線的資源準備實現資源交付標準化：包括基礎資源準備，數據庫、中間件、組件資源準備，並且保持標準化的環境部署，如程序路徑、組件配置等。

應用上線包括新的版本發佈與版本更新：實現批量發佈、回滾、發佈依賴的自動化。

應用運行：應用上線後，運行過程SLA保障運維服務。

應用巡檢：包括OS、DB、組件、進程、模塊的功能性、規範性、安全性、性能巡檢，從基礎組件服務狀態、日誌關鍵字來反饋應用總體運行狀態。

應用監控：監控應用的可用性、調用鏈監控和性能監控（APM）功能模塊的可用性，整合統一的告警中心服務，實現故障的預警與告警。

應用配置管理：包括應用的配置模型，對象、屬性、關聯關係，和應用配置文件的版本、配置下發、程序包綁定的管理。

運維流程協同：運維流程基本管理，事件、問題、變動、知識庫管理，以及相應協同部門的服務請求，包括運營用戶服務目錄等。

故障處理：應用運行過程當中的故障分析和處理環節，快速恢復應用可用性。

日誌分析：實現統一的日誌蒐集、存儲與分析平臺，輔助排障人員快速獲取到關聯日誌。

故障定位：基於CMDB的關聯關係，肯定影響範圍，細化故障點；並逐步演進到AIOps智能監控領域，經過多個指標異常檢測、知識圖譜、故障鏈傳播，實現智能化的快速故障點定位。

故障自愈：基於自動化編排引擎，實現經常使用的故障自動化處理，包括日誌清理、服務重啓、參數調整等操做編排；將來可擴展引入AIOps，與知識庫關聯，實現智能預案推薦。

生產操做：應用運維過程當中，須要主動性的完成不少變動或週期性的運維操做。

災備切換自動化：實現企業應用容災管理的自動化、可視化，讓災備切換與演練成爲常態，檢驗應用災備架構，和實現災難的快速恢復。

擴縮容自動化：根據業務類型，實現應用架構、底層資源的容量管理，包括容量分析模型、容量預測、自動擴縮容操做編排。

服務啓停：平常運維過程當中須要對服務進行批量啓停，以及服務依賴編排的啓停管理。

其餘能夠提高運維效率和安全性的工具系統，包括報表、做業、安全加固等場景化的操做管理。

增值服務：指基於運維大數據服務的能力，面向運營人員，提供數據分析服務或工具輔助服務。

數據分析與提取：對接各個業務系統數據、日誌數據、指標數據、事件或告警數據，面向運營人員提供數據計算結果服務，輔助運營人員決策、分析和判斷。

運營輔助工具：面向運營人員個性化需求，封裝底層工具系統和數據服務，提供輔助工具，如用戶體驗管理、智能擴容建議等。

咱們挑幾個重點模塊，結合基於客戶化落地場景，進行闡述說明。

1.應用的配置管理如何建設？

應用的配置管理是應用實現自動化運維的基石，應用的配置管理建設應該涵蓋兩個方面的內容，一方面是基於業務和應用維度創建CMDB配置管理模型，且配置管理模型是屬於企業總體CMDB的一部分，並實現數據導入或自動採集；另一方面是與CMDB中具體應用模塊關聯的配置文件管理。

利用CMDB模塊，則很便捷的實現應用模型管理，包括應用層級和模型自定義。

基於平臺構建應用管理SaaS，實現配置文件管理，並把配置文件管理與應用的模塊、主機、資源（軟件包等）、程序包進行總體關聯，實現配置文件版本管理、批量配置下發、參數提取等管理行爲。

2.應用發佈如何設計？

企業的應用發佈設計須要考慮幾個關鍵要素：應該基於CMDB消費發佈過程當中的配置信息、配置文件與程序包的管理是爲應用發佈提供資源服務的、須要依賴比較強大和靈活的自動化編排引擎。

基於平臺的工具構建能力，和自動化編排引擎一級saas標準運維，實現企業級靈活的發佈場景。把發佈過程當中的操做原子化，而後封裝成相對固化的場景；把發佈須要的配置和資源信息，提早基於CMDB和應用管理封裝好。

3.應用災備切換設計？

企業應用災備切換自動化設計主要考慮幾個關鍵要素：須要原子化對接災備過程當中的各個對象，前端路由切換、數據庫、虛擬化、網絡等；依然須要強大的編排引擎；災備演練和切換要作到可視化。

4.數據分析服務如何設計？

運維中產生的數據不少，運維數據的異構化和數據類型特別複雜，包括指標、事件、告警、日誌、CMDB等數據，覆蓋mysql、InfluxDB、MongoDB、文本文件等多個數據類型，且分散在各個系統中，平臺要求具有很強的適配性和靈活性，經過單一Agent和數據管道解決異構化數據接入和適配的問題。

於是運維大數據服務平臺應該和業務大數據服務平臺單獨考慮，運維大數據平臺建設須要考慮幾個關鍵因素：數據採集、低門檻的數據開發、數據開發結果可消費。

應用運維自動化設計架構

咱們圍繞應用運維自動化的生命週期，能夠分層來看所須要的能力，包括全部場景都須要的平臺能力、對應環節須要的功能模塊、其餘組合場景模塊。

總體架構描述：

從層次上來看：PaaS平臺提供工具所需的公共模塊能力，例如CMDB、Agent、做業執行等；應用自動化工具鏈，提供知足企業應用自動化運維生命週期的工具鏈，並基於平臺總體能力實現融合；場景組合SaaS，少許代碼拼裝出各種靈活的場景，例如節假日值班、應急中心等。

場景是靈活且個性化的，於是須要PaaS化的平臺支撐。

iPaaS層： API GateWay（統一接入模塊），將配置管理（CMDB）平臺、做業平臺、數據平臺、挖掘平臺等原子平臺統一接入、集成、驅動和調度，供上層運維場景APP驅動和調用。

aPaaS開發者中心（提供先後端開發框架）：開發者中心提供完整的先後端開發框架，當企業在將來出現新的運維需求的時候，企業能夠快速利用開發者中心完成相應的運維繫統開發，並一鍵部署。

總結

互聯網+的時代，各類應用賦能企業業務廣泛，從研發、運維至運營測都面臨到應用異構、響應業務的效能要求、安全與質量把控、數字化助力業務的挑戰。咱們在文章中基於應用生命週期設計應用運維自動化，並利用PaaS平臺給予全部場景所需的能力。總體設計解決了幾個關鍵問題，異構化的應用如何不侵入作運維、如何作到可持續性建設或足夠的擴展性、架構分層帶來場景的靈活性、生命週期的工具鏈知足總體保障與效能提高場景。

做者：張敏

優質文章

域內計算機本地管理員密碼管理

騰訊PaaS平臺 | 主機名設置錯誤怎麼辦？

Redis持久化介紹

4大步驟節省30%浪費，優化企業上雲成本從瞭解雲開始！

運維思考 | 你知道CMDB與監控是什麼關係嗎？