企業(yè)應用級自動化運維建設方案

1、 企業(yè)應用級自動化運維建設方案 目 錄 TOC o 1-3 h z u HYPERLINK l _Toc66547111 企業(yè)應用級自動化運維建設方案 PAGEREF _Toc66547111 h 1 HYPERLINK l _Toc66547112 1.前言 PAGEREF _Toc66547112 h 3 HYPERLINK l _Toc66547113 2.概述 PAGEREF _Toc66547113 h 4 HYPERLINK l _Toc66547114 2.1 相關名詞 PAGEREF _Toc66547114 h 4 HYPERLINK l _Toc66547115 2.2 相

2、互關系 PAGEREF _Toc66547115 h 4 HYPERLINK l _Toc66547116 3.應用運維的模型研究 PAGEREF _Toc66547116 h 6 HYPERLINK l _Toc66547117 3.1 應用的運行工作要點 PAGEREF _Toc66547117 h 7 HYPERLINK l _Toc66547118 3.2 應用的維護工作要點 PAGEREF _Toc66547118 h 8 HYPERLINK l _Toc66547119 3.3 發(fā)版流程控制: PAGEREF _Toc66547119 h 9 HYPERLINK l _Toc665

3、47120 3.4 應用運維與系統(tǒng)運維的區(qū)別 PAGEREF _Toc66547120 h 10 HYPERLINK l _Toc66547121 4.自動化運維平臺的開發(fā)設計 PAGEREF _Toc66547121 h 10 HYPERLINK l _Toc66547122 4.1 體系架構(gòu) PAGEREF _Toc66547122 h 11 HYPERLINK l _Toc66547123 4.2 代理選型和接口的設計 PAGEREF _Toc66547123 h 11 HYPERLINK l _Toc66547124 4.3 應用運維的擴展 PAGEREF _Toc66547124 h

4、 12 HYPERLINK l _Toc66547125 4.4 巡檢監(jiān)控的擴展-指標監(jiān)控分析 PAGEREF _Toc66547125 h 13 HYPERLINK l _Toc66547126 4.5 日常維護 PAGEREF _Toc66547126 h 13 HYPERLINK l _Toc66547127 4.6 查看監(jiān)視 PAGEREF _Toc66547127 h 14 HYPERLINK l _Toc66547128 5.總結(jié) PAGEREF _Toc66547128 h 14【摘要】本文試圖從應用層面探討自動化運維的實現(xiàn)思路，并分享某銀行的落地實踐經(jīng)驗，既是作者對以往工作的總

5、結(jié)，也嘗試從理論上做更深入全面的研究，供自動化運維平臺建設和開發(fā)的專家及廣大同仁們參考。1.前言銀行等信息化程度高的行業(yè)，隨著業(yè)務的持續(xù)發(fā)展和不斷創(chuàng)新，IT系統(tǒng)不斷壯大，IT運維已經(jīng)成為IT服務內(nèi)涵中重要的組成部分。面對越來越復雜的業(yè)務，面對越來越多樣化的用戶需求，數(shù)據(jù)中心基礎設施規(guī)模隨之不斷擴大，服務器、存儲、數(shù)據(jù)庫、網(wǎng)絡資源等需求愈加旺盛，系統(tǒng)架構(gòu)日趨復雜；在互聯(lián)網(wǎng)和智慧化建設背景下，包括智能營銷和精準獲客在內(nèi)的新需求大量涌現(xiàn)，促使應用架構(gòu)呈現(xiàn)多元化發(fā)展趨勢；監(jiān)管要求日趨嚴格，現(xiàn)場監(jiān)管和非現(xiàn)場監(jiān)管、內(nèi)部審計和外部審計相結(jié)合的方式，對運維標準化、規(guī)范化、合規(guī)性提出了更高的要求。不斷擴展的IT

6、應用需要越來越合理的模式來保障IT服務能靈活便捷、安全穩(wěn)定地持續(xù)保障，這種模式中的保障因素之一就是IT運維。從初期的幾臺服務器發(fā)展到龐大的數(shù)據(jù)中心，單靠人工已經(jīng)無法滿足在技術、業(yè)務、管理等方面的要求，那么標準化、自動化、架構(gòu)優(yōu)化、過程優(yōu)化等降低IT服務成本的因素越來越被人們所重視。其中，自動化最開始作為代替人工操作為出發(fā)點的訴求被廣泛研究和應用。所謂自動化運維是指通過將日常IT運維中大量的重復性工作（小到簡單的日常檢查、配置變更和軟件安裝，大到整個變更流程的組織調(diào)度）由過去的手工執(zhí)行轉(zhuǎn)為標準化、流程化和自動化操作。自動化運維通過制定IT運維工作的規(guī)范規(guī)則，輔助技術手段，促進IT運維工作尤其是應

7、用運維的規(guī)范化、流程化和自動化, 提高工作效率，降低運行風險。宏觀能通過圖表流程等直觀友好方式向普通運維人員和管理人員展示運維進程和運維成果, 微觀能給后臺技術人員提供盡量詳細實時的運行情況和事后分析記錄。目前，自動化運維基本上都是以計算機主機、操作系統(tǒng)為對象的系統(tǒng)層面的操作，我稱為基于系統(tǒng)層面的自動化運維。本文試圖從應用層面探討自動化運維的實現(xiàn)思路，系統(tǒng)運維實質(zhì)性是對操作系統(tǒng)本身運行維護的一種特殊應用運維，業(yè)務作為一種或者多種應用系統(tǒng)的功能，通過業(yè)務-應用關聯(lián)實現(xiàn)業(yè)務的應用遍歷查詢，通過與流程審批管理、服務管理等系統(tǒng)對接實現(xiàn)業(yè)務維護的自動化， 從而實現(xiàn)全方位多角度的自動化運維平臺。應用層面的

8、自動化運維已在某銀行做了很多落地實踐，效果很理想。由于是探索式開發(fā)，有些方面還有待完善，本文既是對以往工作的總結(jié)，也想從理論上做更深入全面的研究，供自動化運維平臺建設和開發(fā)的專家們參考。2.概述2.1 相關名詞業(yè)務:指各行業(yè)中需要處理的事務，但是通常偏向指銷售的事務。在IT中，指按某一共同的目標，通過信息交換實現(xiàn)的一系列過程。在銀行IT系統(tǒng)中，業(yè)務大多不是獨立的系統(tǒng)，或多或少在有多個應用系統(tǒng)中交流。IT運維的最終目的為各式各樣的業(yè)務服務，很多IT運維事件也是源于業(yè)務問題。業(yè)務問題實質(zhì)上是應用系統(tǒng)功能不完善或者程序?qū)崿F(xiàn)缺陷，業(yè)務問題的運維操作實質(zhì)上是對應用系統(tǒng)的功能修補或者是一種特殊的業(yè)務交易，

9、原則上都可通過應用系統(tǒng)的優(yōu)化升級根除該類操作。系統(tǒng)軟件：指控制和協(xié)調(diào)計算機及其外部設備，支持應用軟件開發(fā)和運行的系統(tǒng)，是無需要用戶干預的各種程序的集合。我們一般指操作系統(tǒng)、數(shù)據(jù)庫以及中間件等輔助的成熟的軟件。應用系統(tǒng)：指專門為滿足不同領域、不同問題的應用需求而編制的軟件, 分為應用軟件包和用戶程序。譬如：銀行的核心系統(tǒng)、前置系統(tǒng)、中間業(yè)務系統(tǒng)、財務系統(tǒng)等等。運維：運維是一個非常廣泛的定義，在不同的公司不同的階段有著不同的職責與定位，最基本的職責是保證業(yè)務穩(wěn)定運行。大型的公司對于運維工作要求越來越高，分工也越來越細，從大的方向可分為網(wǎng)站運維、系統(tǒng)運維、應用運維、網(wǎng)絡運維、數(shù)據(jù)庫運維、安全運維等等

10、。CMDB：CMDBConfiguration Management Database 配置管理數(shù)據(jù)庫。CMDB存儲與管理企業(yè)IT架構(gòu)中設備的各種配置信息，它與所有服務支持和服務交付流程都緊密相聯(lián)，支持這些流程的運轉(zhuǎn)、發(fā)揮配置信息的價值，同時依賴于相關流程保證數(shù)據(jù)的準確性。2.2 相互關系業(yè)務、應用、系統(tǒng)、數(shù)據(jù)、運維等之間從定義和目標方面是各有側(cè)重點又緊密聯(lián)系的，大致關系如下圖：從上圖中分析，業(yè)務、應用、服務器之間都存在一對多的關系, 自動化運維控制的基本單位是應用系統(tǒng)所需的各服務器。服務器及其網(wǎng)絡等系統(tǒng)運維方面的管理要素相對統(tǒng)一簡單，因此自動化運維基于服務器資源的系統(tǒng)運維是比較成熟廣泛的。應

11、用層面處于整個運維環(huán)節(jié)的中心位置，與業(yè)務和資源關系最密切，因此，基于應用層面建設自動化運維將大大擴展自動化運維的使用范圍和使用效果。CMDB，幾乎是每個運維人都繞不過去的字眼，但又是很多運維人的痛，因為CMDB很少有成功的，因此我也把它稱之為運維人的恥辱。其中失敗原因大都可歸結(jié)到CMDB很難做到與實際工作同步變更，造成信息的過時或錯誤，最終失去使用價值。如果從應用層面建設自動化運維系統(tǒng)，再豐富服務器網(wǎng)絡等底層資源信息和管理控制，豐富業(yè)務層次的關聯(lián)信息，這些實際上已極大地滿足了CMDB的信息要求，只要增加同步CMDB數(shù)據(jù)庫機制，或者按照CMDB數(shù)據(jù)規(guī)范直接查找自動化運維數(shù)據(jù)庫展示各種配置信息，就

12、可以同步建設好CMDB。面向應用的運維能力才是真正直接作用于用戶的。面向用戶的價值流梳理對應的就是應用交付流的識別。里面有幾個核心的場景：應用上線場景、應用維護升級場景、應用遷移場景、應用下線場景等等，貫穿了整個應用交付的生命周期管理。3.應用運維的模型研究應用系統(tǒng)規(guī)模大小不一，支撐的基礎軟件與硬件也不定相同，隨著互聯(lián)網(wǎng)與通信技術的發(fā)展，單純的前后臺一體的應用系統(tǒng)很少，大都是基于前臺瀏覽器或微信等手機app的瘦客戶端，控制管理和數(shù)據(jù)都在后臺服務器。本文研究系統(tǒng)也都默認是后臺系統(tǒng)。應用系統(tǒng)總的拓撲架構(gòu)如下:應用指一個應用系統(tǒng)，主要記錄其管理屬性，譬如分類碼、開發(fā)公司、負責人、維護AB角等。子應用

13、指應用系統(tǒng)中相對獨立的有其共同操作屬性的子系統(tǒng)，主要記錄其操作屬性，譬如: 部署的操作系統(tǒng)用戶名、主工作目錄等。一個應用可能包括多個子應用，每個子應用可能部署在多臺服務器中，多個應用或者子應用也可能部署在同一個服務器中。為了模型的統(tǒng)一，我們將沒有明顯的多個子應用也規(guī)定一個子應用，對于復雜的多子應用的劃分，尤其是使用廣泛的unix類后臺應用，我們原則上以應用部署的操作系統(tǒng)用戶作為劃分子應用的標準。建議應用系統(tǒng)不要以操作系統(tǒng)的超級用戶部署，將超級用戶留給系統(tǒng)運維。我們在實際工作中發(fā)現(xiàn)少數(shù)以超級用戶部署的應用系統(tǒng),實際并不需要這么高的權(quán)限。有些(子)應用存在雙機或多機負載均衡或備機情況，這就是一個子

14、應用對應多服務器情況。我們也可將不同維護人不同系統(tǒng)類型的系統(tǒng)運維以子應用方式將多服務器歸屬管理維護。我們在服務器中記錄其包括地點等資源屬性。運維即運行維護，包括運行和維護兩個方面。軟件工程的理論和各種論壇文章大都是站在開發(fā)角度的開發(fā)維護論述。實際中作為運維主角的甲方，不一定能很好掌握應用的開發(fā)文檔和代碼。下面我將從甲方角度詳述運行和維護的相關內(nèi)容，即使不懂開發(fā)，我們也能較好地做應用運維，管控所需應用軟件，當然懂開發(fā)我們就能做得更好，甚至能比只懂開發(fā)的開發(fā)人員更好。3.1 應用的運行工作要點這里的應用實際上是上述的關注操作屬性的子應用。我們將應用系統(tǒng)的各種開發(fā)特性剔除，當作一個黑盒，根據(jù)我多年的

15、開發(fā)維護經(jīng)驗，應用系統(tǒng)實際上有著很多一致的運行關注要點，并開發(fā)了一些相應的通用運維操作程序，豐富和簡化了日常運維，也能輕易地使用到應用層面的自動化運維中。資源狀況: 包括CPU、內(nèi)存、存儲空間、數(shù)據(jù)空間等常規(guī)資源狀態(tài)。這也是很多系統(tǒng)層面自動化運維的主要內(nèi)容，這方面很容易通用化。但應用層面可做得更精準些。服務進程: 每個應用或子應用都有一個或多個服務進程和子進程，該進程應與其部署的操作系統(tǒng)用戶相關。常見的機房監(jiān)控系統(tǒng)很多也可監(jiān)控各服務器中進程，但大都未考慮用戶與應用的相關問題，對于服務器存在多個應用的相似進程名不能區(qū)分，導致漏報或誤報。文件清理:應用的長久運行，為了開發(fā)維護的追蹤查找，必然產(chǎn)生大

16、量日志和臨時文件，如果長期不清理，必然會導致磁盤空間緊張，運行緩慢甚至失敗。因在開發(fā)測試基本不存在該問題，導致文件清理常常被開發(fā)忽視或者清理不徹底。文件清理可分為兩種模式:第一種:備份后清理; 第二種: 直接清理。運維人員要根據(jù)文件的保存必要性加以區(qū)別，最好做成定時任務自動定時清理,防患于未然，也是主動運維的核心所在。數(shù)據(jù)清理: 數(shù)據(jù)即數(shù)據(jù)庫記錄表也存在與上述的文件同樣的問題。數(shù)據(jù)清理可分二種方式:第一種:當前表轉(zhuǎn)移至歷史表; 第二種:當前表或歷史表導出備份后清理。通信狀態(tài):通信狀態(tài)包括本應用的服務端口、外聯(lián)的IP地址和端口，出于安全運行考慮很多外聯(lián)IP只能在本應用部署的服務器才能訪問，有些甚

17、至未開放ping只開放了指定端口。這些情況，常規(guī)的集中式的數(shù)據(jù)中心監(jiān)控是不能做的，通過面向應用的自動化運維讓該應用狀態(tài)的監(jiān)控成為現(xiàn)實。服務啟停等常用維護操作:該操作也是很多自動化運維提到的操作，這對于應用層面的自動化運維是很自然的操作。服務日志: 應用日志在銀行等單位的很多應用系統(tǒng)中很豐富和龐大，尤其是一些交易量大的交易服務日志。采用打包在自動化運維平臺中下載查看是不現(xiàn)實的，這就需要采用實時的遠程部分查閱模式或者專門的日志管理分析系統(tǒng)。對賬情況: 對賬只針對部分應用系統(tǒng)，一般用于與第三方等其它應用系統(tǒng)聯(lián)網(wǎng)交易日終處理場景。有些系統(tǒng)有專用的對賬平臺或?qū)~交易，但原理上應該都可用腳本查詢到，并通過

18、較通用模式展示。服務交易情況: 交易情況分為統(tǒng)計情況和明細情況，統(tǒng)計情況可用圖示展示。服務交易查詢大致有以下幾種方式:數(shù)據(jù)庫流水表記錄型:通過交易流水數(shù)據(jù)庫記錄查詢統(tǒng)計，優(yōu)點是查詢統(tǒng)計方便靈活;缺點是因為不是關鍵交易無相應流水表或數(shù)據(jù)庫事務機制等原因?qū)е驴赡苡胁糠纸灰孜磳懹涗浕驅(qū)懭胧〉挠涗洝?監(jiān)控記錄文件型: 部分功能較完善的應用系統(tǒng)可能存在該類文件，文件記錄可解決無相應流水表或事務失敗回滾的記錄問題，能更全面地記錄各類交易狀態(tài)。缺點是很難直接進行較復雜靈活的查詢統(tǒng)計。日志信息抽取型: 分析日志信息生成各類交易記錄。該類型適用于日志較豐富但無交易數(shù)據(jù)記錄或交易監(jiān)控文件記錄情況，可更全面地記錄

19、各類服務交易。缺點是依賴于日志記錄的豐富，且分析抽取困難并可能不準確。3.2 應用的維護工作要點維護可分開發(fā)方維護和使用方維護。下面主要論述使用方維護工作技術要點，不討論維護工作的合規(guī)性等管理要求。相關文擋資料: 我們要盡量掌握了解應用的設計架構(gòu)、數(shù)據(jù)庫結(jié)構(gòu)、維護手冊等維護文檔，如能進一步了解源代碼會更好。這無疑是最快最好地進行維護的方式，但現(xiàn)實是很多應用這方面文檔不全甚至沒有，即使有，也不易全部深入掌握。相關目錄結(jié)構(gòu): 主要目錄包括啟停腳本或服務命令的可執(zhí)行程序目錄、日志目錄、配置信息目錄和臨時文件目錄等。相關日志結(jié)構(gòu): 運行中出現(xiàn)的問題，我們往往需要在相關日志中查找問題點，然后據(jù)此分析找到

20、優(yōu)化修正方法。相關表索引: 索引使用不當，能顯著地影響執(zhí)行效率，是導致很多交易超時的主要因素之一，這方面因開發(fā)測試數(shù)據(jù)量不多，不容易發(fā)現(xiàn)，往往運行數(shù)月甚至數(shù)年后才能呈現(xiàn)。查看常用表尤其是記錄數(shù)多的表是否有主鍵、索引，有關日期的流水記錄類表是否有以日期為首關鍵字的索引或主鍵，最好還能了解分析數(shù)據(jù)庫運行記錄或開發(fā)代碼中的相關大表查詢條件是否有效地使用了索引。多年的維護工作中發(fā)現(xiàn): 大表沒索引、索引關鍵字順序不當、索引過多存在重復性的無效索引等問題是很常見的。應用層面自動化運維也可以在這方面作一些記錄和管理分析工作。3.3 發(fā)版流程控制:系統(tǒng)層面的自動化運維中大都只有靜默方式的軟件安裝升級功能，這適

21、應于需要大批量更新較單純軟件或者應用，如互聯(lián)網(wǎng)應用的多服務負載均衡部署。對于很多單機或者少量機運行的應用系統(tǒng), 安裝升級過程不完善又需要經(jīng)常版本發(fā)布并不適用。因此，我們將軟件一步式的靜默安裝升級方式，通過規(guī)范引導，設計成多步的發(fā)版流程，以便實時監(jiān)控發(fā)版進程和運行日志。規(guī)范化流程化發(fā)版已在我行推廣至二十多個應用系統(tǒng)，取得了很好的效果。該模式也能根據(jù)需要改為靜默大批量軟件安裝升級模式。通用的發(fā)版流程如下：發(fā)版大屏監(jiān)視：3.4 應用運維與系統(tǒng)運維的區(qū)別4.自動化運維平臺的開發(fā)設計自動化運維平臺作為管理眾多應用系統(tǒng)和服務器等的數(shù)據(jù)中心的主要的運維管理平臺，我認為要優(yōu)先致力于各類運維規(guī)范標準的建設、根據(jù)

22、規(guī)范標準建設完善平臺自身功能和標準的推廣應用。平臺要讓要應用運維人員或者普遍服務臺人員操作,除了平臺本身權(quán)限控制外，還要在服務器的操作系統(tǒng)用戶層面針對不同的功能作操作安全權(quán)限控制，總之操作記錄跟蹤和安全權(quán)限要作為建設重點，以便控制風險并有據(jù)可查，滿足嚴格的監(jiān)管要求。制造自動化、辦公自動化除了技術升級改造外還有關鍵的規(guī)范化標準化工序或元件，要實現(xiàn)自動化運維也同樣離不開運維操作和流程的規(guī)范化標準化，自動化運維平臺建設必須與運維規(guī)范標準化相輔相成。4.1 體系架構(gòu)應用層面的自動化運維功能首選操作對象是應用，然后通過應用自動選擇其最終操作的服務器和對應的基本操作設定, 從而達到應用層面的運維目的。4.

23、2 代理選型和接口的設計自動化運維的實現(xiàn)原理是通過自動化運維服務器控制數(shù)據(jù)中心的其它服務器等應用系統(tǒng)資源設備。要控制服務器有2種模式：代理模式和非代理模式。非代理模式如果不遠程登錄則只能做測試通信等有限的功能，如登錄，則需要記錄用戶密碼，在修改用戶密碼后需要同步，或者使用ssh的互信免密設置(ssh實際也類似于代理程序)，同時登錄也會耗時影響效率。因此，目前基本都是采用代理模式。代理一旦選定推廣，不易修改。代理的選型網(wǎng)上有很多文章，這里不加闡述。但是我們應該可以通過編寫接口函數(shù)隱藏代理細節(jié)，實現(xiàn)更靈活的可自由選型的自動化運維。綜觀了一些代理的介紹和我們應用過的Puppet+mcollectiv

24、e和Control-M等自動化代理軟件。雖然代理工具有很多輔助的控制調(diào)用功能，但是真正能廣泛使用的只是常用的幾種調(diào)用，可能基于自動化等考慮，代理軟件都屏蔽了標準輸入，不能實時標準輸出必須等命令執(zhí)行完畢才能將得到整個標準輸出，這就意味著我們與應用連最簡單的交互都不能直接做，對運行長久的命令不能及時了解執(zhí)行進展。這對于一些運維場景不是很合適或者需要做一些技術處理。原理上自動化運維平臺可做數(shù)據(jù)中心的全面監(jiān)控，但是基于代理軟件的資源開銷比較大，而監(jiān)控尤其是基礎設備監(jiān)控往往頻繁又要求實時，建議安裝輕量級的監(jiān)控專用代理,只使用自動化運維平臺中的基本關系數(shù)據(jù)。4.3 應用運維的擴展根據(jù)應用運維的模型設計，應

25、用運維如同一個功能容器，我們可以根據(jù)不同類型的用戶在上面作不同的功能整合，擴展為系統(tǒng)運維、數(shù)據(jù)庫運維、網(wǎng)絡運維和安全運維等專家職能運維。數(shù)據(jù)庫運維主要指數(shù)據(jù)庫管理員職能操作，我們可在數(shù)據(jù)庫服務器上建立專屬的數(shù)據(jù)庫應用，將常用功能在專屬的應用容器封裝。網(wǎng)絡運維指對路由器等網(wǎng)絡設備的運維，通常我們都是通過可訪問的電腦聯(lián)網(wǎng)訪問維護，我們可在專用服務器安裝自動化代理建立專屬的網(wǎng)絡應用，或者直接在自動化平臺服務器中虛擬一個專屬的網(wǎng)絡應用，將常用功能在專屬的應用容器中封裝。應用層面的自動化運維，因與業(yè)務層面關系密切，可較容易地與面向業(yè)務或管理方向的ITIL類系統(tǒng)對接，實現(xiàn)業(yè)務層面的自動化運維。詳見下文的日常維護。4.4 巡檢監(jiān)控的擴展-指標監(jiān)控分析通常監(jiān)控平臺都是將采集和分析顯示包攬起來，完成納管服務器等設備的所有工作。這就造成了監(jiān)控功能的局限性，同時讓監(jiān)控管理人員疲于應付。我們可以轉(zhuǎn)換思路，將采集數(shù)據(jù)做成開放式的，監(jiān)控平臺主做分析顯示的功能。開放的監(jiān)控數(shù)據(jù)我稱為指標，定義各類指標規(guī)范，讓各應用系統(tǒng)各服務器運維人員將想監(jiān)控的指標按規(guī)范發(fā)送監(jiān)控服務器集中分析顯示。如此，充分體現(xiàn)讓專業(yè)人做專業(yè)事以及主動運維的思想。指標監(jiān)控能輕易地實現(xiàn)網(wǎng)絡監(jiān)控、應用監(jiān)控、業(yè)務監(jiān)控等。譬如：定義數(shù)據(jù)模型: 指標編碼, 類別, 時間, 筆數(shù), 數(shù)值, 狀態(tài)(成功,