自動化運維專案前期規劃五大難點

導讀	目前來看，無論是開源還是閉源都可以滿足銀行的運維需求，選用開源產品無非就是銀行自身的技術實力允許，有一定的開發實力，或者和第三方外包一起結合熱點開源產品進行二次開發。

基於社群活躍度高、口碑好、功能強大的開源自動化工具，進行二次開發，實現自身需求的完全定製化，該技術路線有兩個理解層次，第一個層次只是開源工具的使用上，對該工具的所有模組的運用都非常嫻熟，二次開發也是工具的呼叫、整合、介面定製方面；第二個層次是開源工具的程式碼定製上，深入開原始碼，進行重新最佳化和定製，嵌入自身的內容，並在第一個層次上去呼叫和整合。能夠實現自研路線的銀行科技力量都比較強大，有專門的自動化運維開發團隊，對開源社群研究的比較深入，有強大的開發和運維實力。

除了開源工具的自研之外，還有一種是開源平臺的自研，在開源工具之上，往上發展，基於統一的研發平臺，實現從底層工具到自動化運維“平臺”的自研，開源平臺提供了一些開發框架、介面標準、技術工具供開發人員使用，加速開源工具和“平臺”的研發效率和進度。

這條技術路線和前面兩種技術路線類似，都屬於自研類，區別是，前者是站在開源工具/平臺的肩膀之上，進行的二次開發，而後者是完全從底層工具、代理、平臺、介面、介面等方方面面都是自研，難度也是最大的，國內大行研發實力強的，都基本是這條技術路線，需要大量的運維工具開發和維護團隊，耗費大量時間和精力。但受益也是很不錯的，其他各運維條線的工作效率大幅提升，自主化高，迭代能力強。

這條技術路線是目前選擇最多的，也是中小銀行絕大多數的選擇，開發團隊一般都用來做業務軟體開發了，很少中小銀行會將自研自動化運維繫統和平臺。目前自動化運維產品提供廠商也非常多，而且相當一部分廠商都能提供一整套解決方案，包括DevOps、自動化運維、集中監控等。這種技術路線，銀行企業需要仔細甄別，不僅僅是甄別自動化運維產品本身，更重要的是甄別其擴充性和平臺的能力，同時銀行企業，也要在多個系統引入過程中，站在整體視角，嚴格劃分好功能邊界，運維體系比較大，廠商的各類解決方案，都是大而全的方案，在引入過程中，難免各家廠商的功能邊界會出現混淆和不清晰的地方，需要仔細區分。

目前來看，無論是開源還是閉源都可以滿足銀行的運維需求，選用開源產品無非就是銀行自身的技術實力允許，有一定的開發實力，或者和第三方外包一起結合熱點開源產品進行二次開發。當然對開源產品的選型要慎重，如果是銀行自己採用開源產品，建議選擇無代理模式的自動化運維工具，對系統無侵入還是比較重要的，否則的話，就應該深入介入瞭解開源代理的底層程式碼。如果是和有技術實力和案例的第三方外包一起進行開源的二次開發的話，那麼無代理和有代理都是可以選擇的，因為可以透過外包轉嫁開源風險。選擇閉源產品目前也是很多，基本是透過有代理的模式進行的，有代理模式的效率要比無代理更高，而且客戶端無需和服務端建立互信關係，弱化服務端的使用者許可權，但是客戶端的代理基本是透過ROOT賬戶執行，可能會有後門。

（1）自動化底層運維工具：CMDB及配置自動化發現工具； 及作業管理中心；Agent及管控中心，用來執行 獲取資料；自動化編排引擎；整合中心，API整合和訪問許可權管理；

（2）在此之上構建的專業領域運維工具：網路自動化工具；防火牆自動化工具；作業系統運維工具；中介軟體運維工具；雲資源管理工具；應用釋出工具；

（3）基於各種運維場景構建的運維工具：巡檢工具；補丁及基線管理工具；軟體安裝配置工具；日誌自助查詢工具；抽數工具等等。

大致的步驟有以下幾個方面：

1、規劃自動化運維場景、模組和整體架構

2、自動化運維管理節點和模組軟硬體資源部署

3、在節點上安裝自動化運維服務端軟體，並進行相關配置

4、兩種方式建立自動化運維關係：

（1）建立服務端和客戶端的互信，客戶端安裝必要的依賴軟體，如Python

（2）客戶端安裝相應代理和依賴包

5、驗證服務端和客戶端的自動化運維關係

6、進行自動化運維場景和功能模組分類開發和測試

7、自動化運維外部介面開發和測試

8、自動化運維統一門戶搭建，並對接不同場景和功能模組

9、自動化運維繫統正式上線

考慮監、管、控、及充分結合其他運維繫統，而不僅僅是一個自動化的工具。

自動化運維作為運維技術體系中的一員，其目的就是為了減輕運維成本、提升運維效率、規範運維任務、透過自動化自愈提升業務連續性等等，其重要意義不言而喻。這點從國內各類大行、股份制銀行等的運維人員招聘的技術要求中，也可以略知一二，經常是需要一些既懂運維技術的，又懂運維開發的人員。但這些各自為政的自動化運維開發都為自己提供便利，往往沒有站在全域性的角度去思考問題，造成開發工作重複，邊界不清晰，甚至功能衝突的情況，這是自動化運維需要規避的地方，從一開始介入這個領域，就應該從整體的角度，清晰的劃分不同運維團隊的自動化運維邊界，真正實現運維端到端的自動化服務，為實現這些服務，需要理清哪些地方要有哪些自動化工具支撐，哪些工具能夠共用合併，最後再從整合的角度，如何統一管控和對外提供服務等。

是一個具備整合能力，具備服務開放性，具備很好的功能擴充套件的一個平臺。

“平臺”在我們的理解中應該是一個整合者和統一管控者，這有別於“系統”，系統是一個功能和處理個體，就好比銀行系統架構中的前置-中臺-後臺的概念，系統屬於後臺的概念，而“平臺”屬於中臺的概念。後臺所有對外的服務都需要透過中臺來流轉，中臺有一個，而後臺可以有多個，是1對多的關係。因此，從自動化運維平臺的角度來看這個問題，這個平臺不需要有多強大的功能，不需要完成例如批次排程、自動化投產、自動化巡檢、自動化操作、自動化軟硬體配置等具體操作，更重要的是將底層的自動化運維技術實現抽象化，服務化，同時對整個自動化技術實現統一管理，包括自動化服務註冊、自動化服務模板、自動化服務整合、自動化服務許可權管理等等。至於具體技術實現，則交由底層的各類自動化運維工具去實現，或者獨立的“系統”去實現。另外，“平臺”也可以是一個多“系統”和工具的排程者，單一工具無法實現的自動化任務，可以透過多工具任務編排實現，形成大平臺，小系統的格局，突破傳統的小系統過於臃腫，每個系統都想做全，爭老大，造成功能邊界模糊的問題。

自動化運維平臺需要很好的融入整體運維體系，清晰的劃分功能邊界，包括雲管平臺、流程平臺、監控平臺、配置管理平臺、智慧運維平臺等。統一CMDB為所有系統和平臺提供統一的配置基準資料，提升聯動的資料質量和效果；自動化運維平臺自動採集和發現價值資料和資料關聯，供其他系統和平臺使用，和各項資源建立自動化關聯關係，提供不同自動化運維場景呼叫API，供其他系統和平臺呼叫；集中監控平臺對接所有監控系統和平臺，實時收集所有事件和告警，結合CMDB配置資料，第一時間匹配和豐富事件告警內容，以豐富的通知手段和詳盡真實的告警詳情告知相關負責人；運維大資料透過多樣化、不同通道的方式，整合各系統和平臺的實時或歷史的結構化、非結構化資料，並進行過濾、清洗、加工、整合、分析、輸出和資料持久化；IT架構視覺化系統透過業務系統部署架構圖、業務邏輯架構圖、業務網路拓撲圖三類架構圖的方式，結合運維大資料中，不同資料來源的資料，包括智慧運維產出的建議，進行實時的展示，讓資料和圖聯動，更為直觀的展示業務系統整體執行狀況。運維以IT架構視覺化為主，智慧運維為輔，強調人在運維中不可替代性。可以參考以下規劃圖：

原文來自：