企業(yè)應用運維定義
我們把企業(yè)內的IT團隊做一個初步職責和邊界劃分：
運維的起始點是拿到開發(fā)的代碼包開始，然后進行資源環(huán)境準備、環(huán)境搭建、應用發(fā)布，以及一些列的運維支撐保障工作；而從運維團隊內部來看，大致從技術棧層面分為幾類：
IDC運維：負責操作系統(tǒng)及以下的運維支撐工作，主要提供穩(wěn)定的網(wǎng)絡、存儲和服務器。
SA：系統(tǒng)管理員，負責操作系統(tǒng)以上，代碼以下的運維管理工作，不過有的公司，由于中間件的運維支撐與應用關聯(lián)緊密，很多時候SA只負責操作系統(tǒng)和數(shù)據(jù)庫兩個內容。
應用運維：核心職能是確保進程和服務可用，同時響應研發(fā)、運營人員的訴求，維護新版本的穩(wěn)定運行，以及提供數(shù)據(jù)和服務給到運營人員。
應用運維在各個行業(yè)里面都非常重要，其發(fā)揮的價值深度，對于公司業(yè)務支撐保障和與優(yōu)化輔助，都起著至關重要的作用，但面臨的困境也很多。
應用架構多樣性、異構化程度大；無論是多年前無法重構的單體架構，SOA架構的應用，微服務架構應用，基于業(yè)務中臺的架構，還是近幾年號召的云原生架構，越大的企業(yè)，應用的多樣與異構化程度就越大，對于應用運維人員的技術棧要求高，管理復雜度大。
安全和質量級別要求高；無論是新版本發(fā)布，災備切換與演練，應用故障處理還是其他維護場景，都直接影響應用服務的可用性，更不要說因為操作權限很高，可能出現(xiàn)誤操作或破壞性行為的風險。
效率要求高；快速發(fā)現(xiàn)問題，定位問題和觸發(fā)預案處置，每一個節(jié)點的速度都影響了SLA，因而應用運維主動和被動響應的要求都越來越高，沒有自動化手段已經無法解決現(xiàn)有的局面。
無法提供數(shù)據(jù)分析的增值服務；應用運維擁有核心的日志、配置、監(jiān)控數(shù)據(jù)，這些數(shù)據(jù)往往能通過一些技術手段分析后，提供給運營人員，給他們帶來增值服務，而日常繁雜的工作，和缺乏有效的數(shù)據(jù)分析手段，導致價值沒有得到充分發(fā)揮。
應用運維自動化設計前提
在應用運維自動化設計前，我們需要有兩個基本的共同認知，這樣才能保障整體的設計規(guī)劃是有效的。
應用的異構化是一個長期存在的狀態(tài)。
應用運維自動化平臺具備適應靈活場景的能力，具備很強的擴展性。
為什么需要有這兩個約束，最核心的原因是如果企業(yè)的業(yè)務標準化程度足夠高，甚至全部能云原生化，這個時候業(yè)務API也是服務、函數(shù)也是服務。而云自身能提供足夠高的可用性和保障功能，其實對于體系化的自動化運維平臺需求并沒那么強烈了，因為在這種理想化的情況下，場景足夠單一了，并不需要適配各種異構化的場景。但是我們都知道，目前實際情況來看，多種架構和類型的應用共存，是一個可能很長期的狀態(tài)。因而，從設計原則看：
平臺化架構：
把應用運維需要的通用能力沉淀下來，然后場景可以保留持續(xù)擴展構建的能力，只有這樣，才能適配應用運維過程中，各種靈活和自定義的運維場景。
原子化：
豐富應用運維的最小操作單元，然后基于平臺可以快速迭代出各類場景，例如有了分發(fā)文件、執(zhí)行腳本的原子，就可以編排出一個簡單的應用發(fā)布自動化場景。
要覆蓋企業(yè)應用運維全生命周期：
從應用的上線、運行，到后續(xù)一系列運維場景和過程來規(guī)劃所需的功能和工具；
標準性：
從輸入、輸出、操作規(guī)范、安全控制等方面對運維操作組件進行規(guī)范性約束。
基于應用生命周期設計應用運維自動化
我們從應用運維的生命周期來看，大致分為如下幾個部分：
應用上線：應用上線前的標準化資源與運行環(huán)境準備，以及應用上線過程中的發(fā)布與更新操作。
應用上線的資源準備實現(xiàn)資源交付標準化：包括基礎資源準備，數(shù)據(jù)庫、中間件、組件資源準備，而且保持標準化的環(huán)境部署，如程序路徑、組件配置等。
應用上線包括新的版本發(fā)布與版本更新：實現(xiàn)批量發(fā)布、回滾、發(fā)布依賴的自動化。
應用運行：應用上線后，運行過程SLA保障運維服務。
應用巡檢：包括OS、DB、組件、進程、模塊的功能性、規(guī)范性、安全性、性能巡檢，從基礎組件服務狀態(tài)、日志關鍵字來反饋應用整體運行狀態(tài)。
應用監(jiān)控：監(jiān)控應用的可用性、功能模塊的可用性、調用鏈監(jiān)控和性能監(jiān)控（APM），整合統(tǒng)一的告警中心服務，實現(xiàn)故障的預警與告警。
應用配置管理：包括應用的配置模型，對象、屬性、關聯(lián)關系，和應用配置文件的版本、配置下發(fā)、程序包綁定的管理。
運維流程協(xié)同：運維流程基本管理，事件、問題、變更、知識庫管理，以及相應協(xié)同部門的服務請求，包括運營用戶服務目錄等。
故障處理：應用運行過程中的故障分析和處理環(huán)節(jié)，快速恢復應用可用性。
日志分析：實現(xiàn)統(tǒng)一的日志搜集、存儲與分析平臺，輔助排障人員快速獲取到關聯(lián)日志。
故障定位：基于CMDB的關聯(lián)關系，確定影響范圍，細化故障點；并逐步演進到AIOps智能監(jiān)控領域，通過多個指標異常檢測、知識圖譜、故障鏈傳播，實現(xiàn)智能化的快速故障點定位。
故障自愈：基于自動化編排引擎，實現(xiàn)常用的故障自動化處理，包括日志清理、服務重啟、參數(shù)調整等操作編排；未來可擴展引入AIOps，與知識庫關聯(lián)，實現(xiàn)智能預案推薦。
生產操作：應用運維過程中，需要主動性的完成很多變更或周期性的運維操作。
災備切換自動化：實現(xiàn)企業(yè)應用容災管理的自動化、可視化，讓災備切換與演練成為常態(tài)，檢驗應用災備架構，和實現(xiàn)災難的快速恢復。
擴縮容自動化：根據(jù)業(yè)務類型，實現(xiàn)應用架構、底層資源的容量管理，包括容量分析模型、容量預測、自動擴縮容操作編排。
服務啟停：日常運維過程中需要對服務進行批量啟停，以及服務依賴編排的啟停管理。
其他可以提升運維效率和安全性的工具系統(tǒng)，包括報表、作業(yè)、安全加固等場景化的操作管理。
增值服務：指基于運維大數(shù)據(jù)服務的能力，面向運營人員，提供數(shù)據(jù)分析服務或工具輔助服務。
數(shù)據(jù)分析與提?。簩痈鱾€業(yè)務系統(tǒng)數(shù)據(jù)、日志數(shù)據(jù)、指標數(shù)據(jù)、事件或告警數(shù)據(jù)，面向運營人員提供數(shù)據(jù)計算結果服務，輔助運營人員決策、分析和判斷。
運營輔助工具：面向運營人員個性化需求，封裝底層工具系統(tǒng)和數(shù)據(jù)服務，提供輔助工具，如用戶體驗管理、智能擴容建議等。
我們挑幾個重點模塊，結合基于藍鯨客戶化落地場景，進行闡述說明。
1.應用的配置管理如何建設？
應用的配置管理是應用實現(xiàn)自動化運維的基石，應用的配置管理建設應該涵蓋兩個方面的內容，一方面是基于業(yè)務和應用維度建立CMDB配置管理模型，且配置管理模型是屬于企業(yè)整體CMDB的一部分，并實現(xiàn)數(shù)據(jù)導入或自動采集；另外一方面是與CMDB中具體應用模塊關聯(lián)的配置文件管理。
利用藍鯨CMDB模塊，則很便捷的實現(xiàn)應用模型管理，包括應用層級和模型自定義。
基于藍鯨平臺構建應用管理SaaS，實現(xiàn)配置文件管理，并把配置文件管理與應用的模塊、主機、資源（軟件包等）、程序包進行整體關聯(lián)，實現(xiàn)配置文件版本管理、批量配置下發(fā)、參數(shù)提取等管理行為。
2.應用發(fā)布如何設計？
企業(yè)的應用發(fā)布設計需要考慮幾個關鍵要素：應該基于CMDB消費發(fā)布過程中的配置信息、配置文件與程序包的管理是為應用發(fā)布提供資源服務的、需要依賴比較強大和靈活的自動化編排引擎。
基于藍鯨平臺的工具構建能力，和藍鯨自動化編排引擎一級saas標準運維，實現(xiàn)企業(yè)級靈活的發(fā)布場景。把發(fā)布過程中的操作原子化，然后封裝成相對固化的場景；把發(fā)布需要的配置和資源信息，提前基于CMDB和應用管理封裝好。
3.應用災備切換設計？
企業(yè)應用災備切換自動化設計主要考慮幾個關鍵要素：需要原子化對接災備過程中的各個對象，前端路由切換、數(shù)據(jù)庫、虛擬化、網(wǎng)絡等；依然需要強大的編排引擎；災備演練和切換要做到可視化。
4.數(shù)據(jù)分析服務如何設計？
運維中產生的數(shù)據(jù)很多，運維數(shù)據(jù)的異構化和數(shù)據(jù)類型特別復雜，包括指標、事件、告警、日志、CMDB等數(shù)據(jù)，覆蓋mysql、InfluxDB、MongoDB、文本文件等多個數(shù)據(jù)類型，且分散在各個系統(tǒng)中，平臺要求具備很強的適配性和靈活性，通過單一Agent和數(shù)據(jù)管道解決異構化數(shù)據(jù)接入和適配的問題。
因而運維大數(shù)據(jù)服務平臺應該和業(yè)務大數(shù)據(jù)服務平臺單獨考慮，運維大數(shù)據(jù)平臺建設需要考慮幾個關鍵因素：數(shù)據(jù)采集、低門檻的數(shù)據(jù)開發(fā)、數(shù)據(jù)開發(fā)結果可消費。
應用運維自動化設計架構
我們圍繞應用運維自動化的生命周期，可以分層來看所需要的能力，包括所有場景都需要的平臺能力、對應環(huán)節(jié)需要的功能模塊、其他組合場景模塊。
整體架構描述：
從層次上來看：PaaS平臺提供工具所需的公共模塊能力，例如CMDB、Agent、作業(yè)執(zhí)行等；應用自動化工具鏈，提供滿足企業(yè)應用自動化運維生命周期的工具鏈，并基于平臺整體能力實現(xiàn)融合；場景組合SaaS，少量代碼拼裝出各類靈活的場景，例如節(jié)假日值班、應急中心等。
場景是靈活且個性化的，因而需要PaaS化的平臺支撐。
iPaaS層：API GateWay（統(tǒng)一接入模塊），將配置管理（CMDB）平臺、作業(yè)平臺、數(shù)據(jù)平臺、挖掘平臺等原子平臺統(tǒng)一接入、集成、驅動和調度，供上層運維場景APP驅動和調用。
aPaaS開發(fā)者中心（提供前后端開發(fā)框架）：開發(fā)者中心提供完整的前后端開發(fā)框架，當企業(yè)在未來出現(xiàn)新的運維需求的時候，企業(yè)可以快速利用開發(fā)者中心完成相應的運維系統(tǒng)開發(fā)，并一鍵部署。
總結
互聯(lián)網(wǎng)+的時代，各種應用賦能企業(yè)業(yè)務普遍，從研發(fā)、運維至運營測都面臨到應用異構、響應業(yè)務的效能要求、安全與質量把控、數(shù)字化助力業(yè)務的挑戰(zhàn)。我們在文章中基于應用生命周期設計應用運維自動化，并利用PaaS平臺給予所有場景所需的能力。整體設計解決了幾個關鍵問題，異構化的應用如何不侵入做運維、如何做到可持續(xù)性建設或足夠的擴展性、架構分層帶來場景的靈活性、生命周期的工具鏈滿足整體保障與效能提升場景。
