本文總結(jié)了銀行自動化運(yùn)維項目建設(shè)的難點(diǎn)問題并解析，希望能夠幫助運(yùn)維同仁們在項目前期規(guī)劃及建設(shè)過程中，有的放矢，消除疑慮。分享者：來自金融行業(yè)的鄧毓、he7yong、michael1983
難點(diǎn)一：自動化運(yùn)維項目，如何進(jìn)行技術(shù)路線的選擇？
就筆者所了解的，自動化運(yùn)維項目有以下四條技術(shù)路線供大家參考
1、基于開源工具自研
基于社區(qū)活躍度高、口碑好、功能強(qiáng)大的開源自動化工具，進(jìn)行二次開發(fā)，實(shí)現(xiàn)自身需求的完全定制化，該技術(shù)路線有兩個理解層次，第一個層次只是開源工具的使用上，對該工具的所有模塊的運(yùn)用都非常嫻熟，二次開發(fā)也是工具的調(diào)用、整合、界面定制方面；第二個層次是開源工具的代碼定制上，深入開源代碼，進(jìn)行重新優(yōu)化和定制，嵌入自身的內(nèi)容，并在第一個層次上去調(diào)用和整合。能夠?qū)崿F(xiàn)自研路線的銀行科技力量都比較強(qiáng)大，有專門的自動化運(yùn)維開發(fā)團(tuán)隊，對開源社區(qū)研究的比較深入，有強(qiáng)大的開發(fā)和運(yùn)維實(shí)力。
2、基于開源平臺自研
除了開源工具的自研之外，還有一種是開源平臺的自研，在開源工具之上，往上發(fā)展，基于統(tǒng)一的研發(fā)平臺，實(shí)現(xiàn)從底層工具到自動化運(yùn)維“平臺”的自研，開源平臺提供了一些開發(fā)框架、接口標(biāo)準(zhǔn)、技術(shù)工具供開發(fā)人員使用，加速開源工具和“平臺”的研發(fā)效率和進(jìn)度。
3、基于閉源自研
這條技術(shù)路線和前面兩種技術(shù)路線類似，都屬于自研類，區(qū)別是，前者是站在開源工具/平臺的肩膀之上，進(jìn)行的二次開發(fā)，而后者是完全從底層工具、代理、平臺、界面、接口等方方面面都是自研，難度也是最大的，國內(nèi)大行研發(fā)實(shí)力強(qiáng)的，都基本是這條技術(shù)路線，需要大量的運(yùn)維工具開發(fā)和維護(hù)團(tuán)隊，耗費(fèi)大量時間和精力。但受益也是很不錯的，其他各運(yùn)維條線的工作效率大幅提升，自主化高，迭代能力強(qiáng)。
4、第三方現(xiàn)有產(chǎn)品客戶化定制
這條技術(shù)路線是目前選擇最多的，也是中小銀行絕大多數(shù)的選擇，開發(fā)團(tuán)隊一般都用來做業(yè)務(wù)軟件開發(fā)了，很少中小銀行會將自研自動化運(yùn)維系統(tǒng)和平臺。目前自動化運(yùn)維產(chǎn)品提供廠商也非常多，而且相當(dāng)一部分廠商都能提供一整套解決方案，包括DevOps、自動化運(yùn)維、集中監(jiān)控等。這種技術(shù)路線，銀行企業(yè)需要仔細(xì)甄別，不僅僅是甄別自動化運(yùn)維產(chǎn)品本身，更重要的是甄別其拓展性和平臺的能力，同時銀行企業(yè)，也要在多個系統(tǒng)引入過程中，站在整體視角，嚴(yán)格劃分好功能邊界，運(yùn)維體系比較大，廠商的各類解決方案，都是大而全的方案，在引入過程中，難免各家廠商的功能邊界會出現(xiàn)混淆和不清晰的地方，需要仔細(xì)區(qū)分。
難點(diǎn)二：自動化運(yùn)維項目，如何進(jìn)行底層工具產(chǎn)品選型？
1、自動化運(yùn)維底層工具產(chǎn)品是選用開源產(chǎn)品還是閉源產(chǎn)品
目前來看，無論是開源還是閉源都可以滿足銀行的運(yùn)維需求，選用開源產(chǎn)品無非就是銀行自身的技術(shù)實(shí)力允許，有一定的開發(fā)實(shí)力，或者和第三方外包一起結(jié)合熱點(diǎn)開源產(chǎn)品進(jìn)行二次開發(fā)。當(dāng)然對開源產(chǎn)品的選型要慎重，如果是銀行自己采用開源產(chǎn)品，建議選擇無代理模式的自動化運(yùn)維工具，對系統(tǒng)無侵入還是比較重要的，否則的話，就應(yīng)該深入介入了解開源代理的底層代碼。如果是和有技術(shù)實(shí)力和案例的第三方外包一起進(jìn)行開源的二次開發(fā)的話，那么無代理和有代理都是可以選擇的，因為可以通過外包轉(zhuǎn)嫁開源風(fēng)險。選擇閉源產(chǎn)品目前也是很多，基本是通過有代理的模式進(jìn)行的，有代理模式的效率要比無代理更高，而且客戶端無需和服務(wù)端建立互信關(guān)系，弱化服務(wù)端的用戶權(quán)限，但是客戶端的代理基本是通過ROOT賬戶運(yùn)行，可能會有后門。
2、通用的底層工具產(chǎn)品包括哪些部分
（1）自動化底層運(yùn)維工具：CMDB及配置自動化發(fā)現(xiàn)工具；腳本及作業(yè)管理中心；Agent及管控中心，用來執(zhí)行命令獲取數(shù)據(jù)；自動化編排引擎；集成中心，API集成和訪問權(quán)限管理；
（2）在此之上構(gòu)建的專業(yè)領(lǐng)域運(yùn)維工具：網(wǎng)絡(luò)自動化工具；防火墻自動化工具；操作系統(tǒng)運(yùn)維工具；中間件運(yùn)維工具；云資源管理工具；應(yīng)用發(fā)布工具；
（3）基于各種運(yùn)維場景構(gòu)建的運(yùn)維工具：巡檢工具；補(bǔ)丁及基線管理工具；軟件安裝配置工具；日志自助查詢工具；抽數(shù)工具等等。
難點(diǎn)三：自動化運(yùn)維項目，如何合理規(guī)劃工程實(shí)施步驟？
大致的步驟有以下幾個方面：
1、規(guī)劃自動化運(yùn)維場景、模塊和整體架構(gòu)
2、自動化運(yùn)維管理節(jié)點(diǎn)和模塊軟硬件資源部署
3、在節(jié)點(diǎn)上安裝自動化運(yùn)維服務(wù)端軟件，并進(jìn)行相關(guān)配置
4、兩種方式建立自動化運(yùn)維關(guān)系：
（1）建立服務(wù)端和客戶端的互信，客戶端安裝必要的依賴軟件，如Python
（2）客戶端安裝相應(yīng)代理和依賴包
5、驗證服務(wù)端和客戶端的自動化運(yùn)維關(guān)系
6、進(jìn)行自動化運(yùn)維場景和功能模塊分類開發(fā)和測試
7、自動化運(yùn)維外部接口開發(fā)和測試
8、自動化運(yùn)維統(tǒng)一門戶搭建，并對接不同場景和功能模塊
9、自動化運(yùn)維系統(tǒng)正式上線
難點(diǎn)四：如何從整體上和“平臺”角度規(guī)劃自動化運(yùn)維平臺？
1、整體上
考慮監(jiān)、管、控、及充分結(jié)合其他運(yùn)維系統(tǒng)，而不僅僅是一個自動化的工具。
自動化運(yùn)維作為運(yùn)維技術(shù)體系中的一員，其目的就是為了減輕運(yùn)維成本、提升運(yùn)維效率、規(guī)范運(yùn)維任務(wù)、通過自動化自愈提升業(yè)務(wù)連續(xù)性等等，其重要意義不言而喻。這點(diǎn)從國內(nèi)各類大行、股份制銀行等的運(yùn)維人員招聘的技術(shù)要求中，也可以略知一二，經(jīng)常是需要一些既懂運(yùn)維技術(shù)的，又懂運(yùn)維開發(fā)的人員。但這些各自為政的自動化運(yùn)維開發(fā)都為自己提供便利，往往沒有站在全局的角度去思考問題，造成開發(fā)工作重復(fù)，邊界不清晰，甚至功能沖突的情況，這是自動化運(yùn)維需要規(guī)避的地方，從一開始介入這個領(lǐng)域，就應(yīng)該從整體的角度，清晰的劃分不同運(yùn)維團(tuán)隊的自動化運(yùn)維邊界，真正實(shí)現(xiàn)運(yùn)維端到端的自動化服務(wù)，為實(shí)現(xiàn)這些服務(wù)，需要理清哪些地方要有哪些自動化工具支撐，哪些工具能夠共用合并，最后再從集成的角度，如何統(tǒng)一管控和對外提供服務(wù)等。
2、平臺角度
是一個具備集成能力，具備服務(wù)開放性，具備很好的功能擴(kuò)展的一個平臺。
“平臺”在我們的理解中應(yīng)該是一個集成者和統(tǒng)一管控者，這有別于“系統(tǒng)”，系統(tǒng)是一個功能和處理個體，就好比銀行系統(tǒng)架構(gòu)中的前置-中臺-后臺的概念，系統(tǒng)屬于后臺的概念，而“平臺”屬于中臺的概念。后臺所有對外的服務(wù)都需要通過中臺來流轉(zhuǎn)，中臺有一個，而后臺可以有多個，是1對多的關(guān)系。因此，從自動化運(yùn)維平臺的角度來看這個問題，這個平臺不需要有多強(qiáng)大的功能，不需要完成例如批量調(diào)度、自動化投產(chǎn)、自動化巡檢、自動化操作、自動化軟硬件配置等具體操作，更重要的是將底層的自動化運(yùn)維技術(shù)實(shí)現(xiàn)抽象化，服務(wù)化，同時對整個自動化技術(shù)實(shí)現(xiàn)統(tǒng)一管理，包括自動化服務(wù)注冊、自動化服務(wù)模板、自動化服務(wù)集成、自動化服務(wù)權(quán)限管理等等。至于具體技術(shù)實(shí)現(xiàn)，則交由底層的各類自動化運(yùn)維工具去實(shí)現(xiàn)，或者獨(dú)立的“系統(tǒng)”去實(shí)現(xiàn)。另外，“平臺”也可以是一個多“系統(tǒng)”和工具的調(diào)度者，單一工具無法實(shí)現(xiàn)的自動化任務(wù)，可以通過多工具任務(wù)編排實(shí)現(xiàn)，形成大平臺，小系統(tǒng)的格局，突破傳統(tǒng)的小系統(tǒng)過于臃腫，每個系統(tǒng)都想做全，爭老大，造成功能邊界模糊的問題。
難點(diǎn)五：自動化運(yùn)維平臺如何融入整體運(yùn)維體系，劃分功能邊界？
自動化運(yùn)維平臺需要很好的融入整體運(yùn)維體系，清晰的劃分功能邊界，包括云管平臺、流程平臺、監(jiān)控平臺、配置管理平臺、智能運(yùn)維平臺等。統(tǒng)一CMDB為所有系統(tǒng)和平臺提供統(tǒng)一的配置基準(zhǔn)數(shù)據(jù)，提升聯(lián)動的數(shù)據(jù)質(zhì)量和效果；自動化運(yùn)維平臺自動采集和發(fā)現(xiàn)價值數(shù)據(jù)和數(shù)據(jù)關(guān)聯(lián)，供其他系統(tǒng)和平臺使用，和各項資源建立自動化關(guān)聯(lián)關(guān)系，提供不同自動化運(yùn)維場景調(diào)用API，供其他系統(tǒng)和平臺調(diào)用；集中監(jiān)控平臺對接所有監(jiān)控系統(tǒng)和平臺，實(shí)時收集所有事件和告警，結(jié)合CMDB配置數(shù)據(jù)，第一時間匹配和豐富事件告警內(nèi)容，以豐富的通知手段和詳盡真實(shí)的告警詳情告知相關(guān)負(fù)責(zé)人；運(yùn)維大數(shù)據(jù)通過多樣化、不同通道的方式，集成各系統(tǒng)和平臺的實(shí)時或歷史的結(jié)構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù)，并進(jìn)行過濾、清洗、加工、整合、分析、輸出和數(shù)據(jù)持久化；IT架構(gòu)可視化系統(tǒng)通過業(yè)務(wù)系統(tǒng)部署架構(gòu)圖、業(yè)務(wù)邏輯架構(gòu)圖、業(yè)務(wù)網(wǎng)絡(luò)拓?fù)鋱D三類架構(gòu)圖的方式，結(jié)合運(yùn)維大數(shù)據(jù)中，不同數(shù)據(jù)源的數(shù)據(jù)，包括智能運(yùn)維產(chǎn)出的建議，進(jìn)行實(shí)時的展示，讓數(shù)據(jù)和圖聯(lián)動，更為直觀的展示業(yè)務(wù)系統(tǒng)整體運(yùn)行狀況。運(yùn)維以IT架構(gòu)可視化為主，智能運(yùn)維為輔，強(qiáng)調(diào)人在運(yùn)維中不可替代性。可以參考以下規(guī)劃圖：
難點(diǎn)六：通過開源工具自主開發(fā)自動化運(yùn)維系統(tǒng)，最大的難點(diǎn)主要體現(xiàn)在哪些方面？
最主要的還是開發(fā)上和架構(gòu)集成上的難點(diǎn)：
1、首先是要結(jié)合企業(yè)自身的需求，量身設(shè)計不同的自動化運(yùn)維場景，這點(diǎn)與直接采用第三方的產(chǎn)品有所不同，第三方是基于他們的理念，設(shè)計出的通用性的產(chǎn)品，適當(dāng)進(jìn)行定制化開發(fā)。而我們要做的是，直接將實(shí)際的問題場景化，更貼切實(shí)際需求，沒有冗余的內(nèi)容。這點(diǎn)有好處也有弊端，弊端就是場景需求可能會變化，量身定做不一定今后就適用，所以既要量身開發(fā)，又要有通用性的思維，場景設(shè)計盡量參數(shù)化、模塊化。再往深一點(diǎn)的話，就是需要對開源工具源碼比較熟悉，復(fù)雜場景都可能面臨要動開源產(chǎn)品的底層代碼；
2、其次是本身系統(tǒng)的架構(gòu)設(shè)計和如何和其他運(yùn)維系統(tǒng)做集成的問題，一方面需要具備比較強(qiáng)大的架構(gòu)能力，開源產(chǎn)品通常都是解決特定問題，這些工具如何集成，需要架構(gòu)師的規(guī)劃；另一方面需要和其他運(yùn)維系統(tǒng)集成，運(yùn)維的其他系統(tǒng)不可能都是開源的，尤其是銀行而言，還是以商用產(chǎn)品為主，集成是最大的麻煩，需要廠商的支持，如果沒有廠商的支持，那就需要對這個商用產(chǎn)品有非常的了解，才能很好的對接。
難點(diǎn)七：自動化運(yùn)維對接的CMDB里主要存放哪些數(shù)據(jù)，顆粒度如何定義，如何維護(hù)準(zhǔn)確性？
1、 CMDB應(yīng)該是存放對象的元數(shù)據(jù)
2、CMDB的顆粒度如何定義
CMDB顆粒度取決于維護(hù)CMDB的人數(shù)量，維護(hù)能力越強(qiáng)，人數(shù)越多，可以將顆粒度提高，數(shù)據(jù)間關(guān)系可以做得越復(fù)雜。如果維護(hù)能力不足，人數(shù)不多，顆粒度盡量精簡。因此，建議遵循最小化的原則，理清ITSM和自動化運(yùn)維工具到底可能會消費(fèi)什么數(shù)據(jù)，才管理什么數(shù)據(jù)。CMDB工具本身可以支持CI屬性的靈活擴(kuò)展即可；
3、準(zhǔn)確性如何維護(hù)
要看你的業(yè)務(wù)需求，如果僅僅給到ITSM用，準(zhǔn)確性不用要求太高，CMDB是臺賬而已，如果和監(jiān)控，自動化聯(lián)動，CMDB要求要很高。準(zhǔn)確性要通過自動發(fā)現(xiàn)、管理流程、數(shù)據(jù)消費(fèi)（消費(fèi)發(fā)現(xiàn)數(shù)據(jù)不準(zhǔn)確，及時更新）等來管控這些數(shù)據(jù)，模型搭建好，盡量減少人的作用和直接參與，人更多體現(xiàn)在流程的審核和管理上，讓流程來驅(qū)動CMDB數(shù)據(jù)（如交付資源自動注冊到CMDB中）落地，讓自動發(fā)現(xiàn)來審核落地數(shù)據(jù)的準(zhǔn)確性，互相牽扯。
難點(diǎn)八：開源工具建設(shè)自動化運(yùn)維系統(tǒng)的瓶頸問題如何解決，其處理效率如何滿足日常運(yùn)維工作？
1、性能瓶頸方面：
開源工具或者第三方閉源與瓶頸不是必然的關(guān)系，無論是開源還是閉源，大規(guī)模環(huán)境下，軟件或多或少都會有瓶頸。合理的部署架構(gòu)可以解決大規(guī)模環(huán)境下，自動化運(yùn)維的瓶頸，可以采用分布式自動化運(yùn)維管理節(jié)點(diǎn)部署，每個管理節(jié)點(diǎn)管一片或者一類運(yùn)維節(jié)點(diǎn)，通過統(tǒng)一的管理平臺進(jìn)行對接。
2、運(yùn)維工作處理效率提升方面：
如果我們不僅僅滿足日常運(yùn)維工作，還需要讓運(yùn)維工作自助化，服務(wù)化，這就需要自動化運(yùn)維系統(tǒng)具備比較強(qiáng)大的集成和編排能力，能夠?qū)⒌讓佣鄠€自動化運(yùn)維工具按照編排的順序調(diào)度，滿足用戶端到端運(yùn)維自動化的任務(wù)。
