難點一：自動化運維項目，如何進行技術路線的選擇？

1、基于開源工具自研

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

2、基于開源平臺自研

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

3、基于閉源自研

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

4、第三方現有產品客戶化定制

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

難點二：自動化運維項目，如何進行底層工具產品選型？

1、自動化運維底層工具產品是選用開源產品還是閉源產品

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

2、通用的底層工具產品包括哪些部分

（1）自動化底層運維工具：CMDB及配置自動化發現工具；腳本及作業管理中心；Agent及管控中心，用來執行命令獲取數據；自動化編排引擎；集成中心，API集成和訪問權限管理；

（2）在此之上構建的專業領域運維工具：網絡自動化工具；防火墻自動化工具；操作系統運維工具；中間件運維工具；云資源管理工具；應用發布工具；

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

難點三：自動化運維項目，如何合理規劃工程實施步驟？

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

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

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

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

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

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

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

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

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

7、自動化運維外部接口開發和測試

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

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

難點四：如何從整體上和“平臺”角度規劃自動化運維平臺？

1、整體上

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

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

2、平臺角度

是一個具備集成能力，具備服務開放性，具備很好的功能擴展的一個平臺。

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

難點五：自動化運維平臺如何融入整體運維體系，劃分功能邊界？

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