新聞中心
看新型運維技術如何在金融行業成功實踐?
作者:睿至科技集團
北京時間2018年5月15日,由睿至科技集團和IBM共同舉辦的“新型運維技術在金融行業實踐”研討會對目前金融行業的一些痛點以及應對方案做了詳細闡述。

北京時間2018年5月15日 由睿至科技集團和IBM共同舉辦的“新型運維技術在金融行業實踐”研討會在成都希爾頓酒店順利舉行。在本次活動中,來自睿至科技集團和IBM的專家們,分別對目前金融行業的一些痛點以及應對方案做了詳細闡述,此外睿至科技集團也在本次活動中正式發布了有關金融行業的解決方案,詳見《睿至開發測試云 為金融領域注入嶄新動力》


近年來隨著互聯網技術的快速發展,金融領域也逐步重視與互聯網的融合,傳統銀行轉變思想,積極運用互聯網最新技術,探索自己的互聯網金融發展之路,加快推動銀行的經營轉型。由于整個金融行業業務模式的多樣化及移動互聯網用戶的接入需求,整個金融平臺規模呈現出快速增長趨勢,隨之而來的是新業務需求不僅帶來了平臺架構的變革,還對運維模式提出了新的需求。


在本次研討會中,針對這一系列問題,睿至科技集團、IBM和銀行用戶們,分別從AIOPS、DevOpS幾個方面進行了深入的探討。

eeee.jpg

會前討論


越來越多的金融客戶發現數據量越來越大,基礎架構越來越復雜,傳統Power環境、虛擬化技術、云環境、容器環境,SOA架構,微服務架構,技術棧越來越多,學習周期越來越短,基礎架構復雜,需要不同的監控軟件,傳統架構使用Tivoli、BMC、HP的軟件,新型基礎架構用Zabbix、OpenFalcon等監控手段,每次出問題,需要使用到多個軟件定位問題,需要怎么處理?互聯網技術的發展,對應用的上線頻率要求越來越高,運維壓力也越來越大!互聯網化帶來的應用高并發與傳統應用模式的沖突,導致問題定位越來越困難!


在本次研討會中,針對這一系列問題,睿至科技集團、IBM和銀行用戶們,分別從AIOPS、DevOpS幾個方面進行了深入的探討。

微信截圖_20180518155239.png

睿至云基礎架構產品部總監胡敏發表《AIOps助力金融行業運維》主題演講


睿至云基礎架構產品部總監胡敏在《AIOPS助力金融行業運維》的主題演講中提到:“運維已經開始逐步從傳統‘穩’態轉變為新型‘敏’態,而未來的運維也一定是傳統‘穩’態運維+新型‘敏’態運維的雙態智能化運維體系“。

開箱即用.png

睿至科技集團AIOPS平臺特色:開箱即用的分析平臺與場景


在會議中,與會者對于睿至AIOPS平臺特色給予了高度的認可,除開箱即用的分析平臺與場景、視圖定制化能力外,強大的數據采集能力也受到關注。


據悉睿至AIOPS平臺支持任意格式和傳輸協議數據收集、支持輸出到多種存儲上或進行轉發、支持各數據源計量及監控、支持TB級數據傳輸和PB級分析、支持Agent遠程管理、默認支持多種銀行標準格式、支持在線配置,無須二次開發,可視化分析過程管理,秒級數據采集能力支持,全平臺支持(AIX/HPUX/Win/Linux),可定制化開發。


金融行業DevOps和互聯網的DevOps又有什么區別?睿至云解決方案產品總監鄭偉從整個金融行業軟件發布模式進行了深入探討。

微信截圖_20180518154903.png

睿至云解決方案產品總監鄭偉做《DevOps在國有銀行的成功實踐》主題演講


鄭偉表示:長期以來,固定版本排期及項目排期的開發模式,為大型金融企業業務的快速發展提供了強有力的 IT 保障,同時也確保了產品的質量和運行風險。但是,近年來,隨著大量互聯網企業,特別是移動互聯網企業的沖擊,大型金融企業也不得不面臨在業務模式加快創新的同時,需要 IT 團隊加快開發節奏,快速推出滿足業務發展需求的產品。而這種需求正對金融企業現有的 IT 開發模式提出緊迫的挑戰,根據我們的研究,這些挑戰主要體現在如下的三個矛盾中:


  • 為保證產品質量而設定的過長的開發測試流程與快速迭代交付的迫切業務需求之間的矛盾

  • 大量手工操作與金融企業對于產品質量一致性、穩定性嚴苛要求之間的矛盾

  • 開發團隊對于流程簡單性、快速性的現實要求與風險管控之間的矛盾。


因此,適合金融行業自身的DevOps格外重要。


從睿至的角度,幫助金融客戶從規劃到落地,主要分為如下過程:


第一步,消除大量的手工操作,構建一個持續交付的流水線平臺是最基礎也是最迫切的,只有通過流水線平臺的自動化和持續流動,才能保證在不同階段、不同節點上產品發布的一致性和穩定性,同時,也才能消除由于人工操作所引入的人為風險,同時提高效率。


第二步,對現有的開發模式及產品架構做進一步的優化,否則,整個流水線是很難順暢地流動起來的。例如,如果不調整固定版本排期的開發模式,則即使自動化程度再高,緊急需求的上線仍然需要等待整個版本的上線;而對于項目排期的開發模式,在上線前,多個項目代碼或者構建包的手工合并也是必不可少的;在傳統緊耦合的產品架構下,想要做到自動化的增量迭代發布,也是非常困難的,而每次都將整個產品的所有代碼進行發布也是極不現實的,這些其實都是實現整個 DevOps 持續交付過程全自動化的障礙。因此,在構建好持續交付的流水線平臺后,其第二步就是開發模式及產品架構的優化。當然,如果沒有第一步的自動化的持續交付平臺作為基礎,則由開發模式調整所帶來的發布次數增多也是無法完全用手工完成的。


第三步,在通過工具自動化的方式實現產品的持續交付后,由于人工操作的減少,自動化及流水線操作的提高,包括操作過程可追蹤性的實現,快速自動回滾操作的實施等,這個時候,在完整的開發測試交付流程中,有些管控步驟可能就是多余的,是可以優化的。因此最后需要對整體開發測試發布流程進行優化,去掉冗余的人工評審步驟,從而實現企業級的 DevOps 持續交付流水線。

宅男