《中國人壽數據中心運維經理桂林——自動化運維自主研發之路》要點:
本文介紹了中國人壽數據中心運維經理桂林——自動化運維自主研發之路,希望對您有用。如果有疑問,可以聯系我們。
桂林
中國人壽上海數據中心,服務處經理
帶領團隊獨立自主開發了中國人壽自動化運維平臺,基于開源平臺自開發,建立了自主監控、自主流程、移動運維的一體化智能運維體系.
本文主要講的是中國人壽自主研發自動化運維平臺成功要素.寫了中國人壽自動化運維平臺從無到有這樣的過程,并這有一些關鍵的要點,給大家做一些介紹.
上圖中的照片來自網絡,我曾經是個快樂的碼農,以前是做一些保險業務平臺開發,比如車站碼頭乘客意外險出單系統等,后來開始做運維,真是一入運維深四海,沒有做開發那么痛快,因為有很多苦逼的經歷.
以前我們分公司的機房可能沒有那么規范,我們做光纖布線的時候沒有跳線架,拿一根PP管把光纖插進去,揭開機房地板直接從地板下面把PP水管捅過去,用這種方式來搭光纖連接服務器和存儲,很粗放.
集中到數據中心運維之后,主要的產品線比較多,特別是像我們這種情況,因為我們現在集中主要還是物理集中其沒有邏輯,就是一個系統就是只有36個分公司,一樣的數據庫可能就是36個,所以我們產品線比較多,這個就導致我們應用的實例和數據庫的實例也比較多,我們批作業量也是比較大.
這個前期我們在沒有上線自動化平臺之前,我們是發動了全國分公司的信息部的人力一起干,為此我們還要撥出一部分費用,每一年給他們一點獎勵.
我們的設備是比較繁雜的,大家看這張圖片,很多分公司的機房就是這樣子的,當然總部數據中心要規范多了.
到目前為止實際上我們已經在逐步的去改善這個情況,但是現在我們還是有一部分的大部分核心數據是在小機上面跑.標準比較雜亂,我們剛剛做的時候,標準是比較混亂的,操作系統也是有32位的有64位的,redhat 有5.4的,有5.8的,我們數據庫版本有也有很多種.
這個是一個最大的問題,就是我們的操作,手工操作這個是比如說我們做數據庫轉換的時候,或者是很大的一些數據遷移的時候,我們可能會大量抽調全國做臨時的補充.人手不夠是因為你沒有相應的自動化平臺,平時我們操作的時候也是按照一個操作手冊來做的,而且變更也沒有做一個有序的管理.
這個也是一個很嚴重的問題,基本上節是出了事情我們開始做變更.沒有一個完善的規劃,這個也是一個比較嚴重的問題.一個事件導致一個變更,因為是沒有計劃和組織,沒有經過嚴格的一個計劃安排,所以說往往有可能導致新的事件,被動地變成一系列的變更.
那么怎么辦?這個會導致,我們需要有一個蛻變.從傳統的企業來講,我們其實蛻變的這個程度還是比較痛苦的.
我們的第一個目標就是將大量的開始做X86和U2L轉換,把我們本來是在小機上跑的應用程序轉移到X86平臺上去,進一步轉移到虛擬機的 Linux.
這個應用改造是第一步,我們通過這個改造我們節約了大量的小機.現在我們除了核心的數據庫在這小機上面,我們基本上所有的應用服務器都是基于 Virtual Linux,當然虛擬機也有一部分是 win 的.而且現在除了 vmware 之外我們還有建立了我們一個 OpenStack 集群.
我們做 OpenStack 給我們的研發團隊使用,同時我們還在做我們的一個基于 Docker 的一個 PaaS 平臺的研發.我們通過這些方式為后期的標準化打下基礎.
我們開始做一個標準化,首先是統一一個設備的采購標準,我們統一了一個操作系統、數據庫、中間件版本以及我們很多的開源的平臺我們也是做標準的統一化,就是有統一的規范,以便我們運維有一個統一的管理.
這一塊我們新從新開始做出梳理,先是從有設備來的時候配置資源上線和下線的流程,到把我們這個設備的管理規范起來,然后我們再設立我們計劃變更的流程.
現在我們基本上規定在周三有一個小變更,周五一個大變更,其他時間是不允許做變更的.這樣我們如果說有變更的話,我們都要提前一周做一個變更計劃,通過評審才可以在下周做一個大變更.
我們對于一些影響比較小的,范圍比較小的小系統,或者是特別緊急的系統,我們可以做緊急的變更,我們緊急變更我們也有一個審批流程,這樣就把我們整個的變更的管理讓他有序,讓他形成一個安全可控的一個狀態.
我們同時也建立安全事件的管理流程,以及我們變更的手段,都把它做到有據可依,有據可查,有法可依.
下一步就是要建立我們的工具,我們把標準化做好了以后就要建立我們自己的工具體系,我們的管理工具,這個我們現在還在用
統一的流程管理,通過一些流程觀點的通知,來做到我們的一個所有的流程的統一管理,就是相應流程包括我們這個權限申請的流程,通過這個平臺走.
但是他現在的缺點也很明顯,因為這個整個的架構是比較繁重的,而且系統是比較慢的,因為當初設計的原因,他的操作的界面也是比較復雜的.
然后操作自動化工具是缺失,這個應該是在12年、13年的時候,我受到領導的委托做一些商業的自動化操作軟件的一些POC.
你們看我們考察了很多的商業軟件,我們用了大量的精力來考察這些商業軟件平臺.
然后總的來看,我得出這樣的結論,第一個就是軟件過于龐大,就是這里面很多的功能,有我想要的功能,但是有很多也是不想要的,但是這個東西因為是一個成熟的商業軟件,所以不管怎么樣你都得要.
這個報價預算這個就不具體說了,因為我們目的也是不僅僅想試一試,而是想選擇一個產品線,我們未來兩地三中心整個生產系統,我都想要通過這一個產品線管理起來,所以說因為我們這個預期比較大,他們的胃口也比較大,所以報價是超出我們的預算的.
POC 效果是勉強的,這個很難把個個都測到點,而且很多的功能想做并不是想做就可以做,比如說我當時有一個很簡單的功能需求,云平臺是面向用戶的申請,而我們這里的管理員還有一個需求,就是我把虛擬機配置清單形成 Excel 文件導入進系統,系統就自動幫我把虛擬機全部建好.
但是當時我們跟廠商接觸的反饋就是說,這個功能需要另外開發因為他們的產品是沒有這個功能,需要另外再開發,類似這種定制化開發還有很多,所以這個開發量是很大的.
什么意思呢?比如我們現在人壽的有一個云助理平臺有一個消息推送功能和我們想要引進的商業平臺整合起來,或者是短信整合起來做推送,總之這些都是非常困難的都是需要開發的,每一個點上都錢都是需求都是投入,因為這些種種原因實際上我們這個采購平臺的需求是遲遲得不到領導的批準.所以這是很痛苦的一個事情.
后來我們最后決定做自主開發,因為當時正好是14年九月份的時候,銀監會出了一個文,就是要求實現我們國內金融行業的一個信息系統安全可控的文件,這個文件下來以后,領導態度就變了,領導就是說鼓勵你們做自主研發,我們同時也存在規模瓶頸,大家可以看這是幾個圖.
這個是我們以前在上海集電港的一個機房,隨著規模上面以后,成本是越來越高的.而且我們在這邊我們有很多也還是有大量的技術的沉淀,我們現在就是 OCM 有七個,CCIE 也有五六個,是能夠干一點事的.
其實作為一個沒有這種經驗的一個傳統公司,要來做這些事情是很難的,因為你特別是走出第一步,非常難.因為之前我們都覺得要做這些東西,要自己來做簡直是不可思議的,后來我們也是做了大量的POC驗證,去選擇一個開源的框架做這個事情.
根據我們現有的情況,實際上我們有一部分是開源的東西,這個是我們研發平臺,我們用這個 openstack 來做.還好就是 vmware 的 vsphere API 是全開放的,他每一個版本的SDK都是可以下載的,可以給你做指導,我們基于這個做定制化的工作,我們應用監控是做了大量的日志挖掘.
然后基礎平臺監控我們是基于開源做完全的重新企劃,我們這個是已經達到每天一個億的監控信息采集規模.大概是有十個 zabbix proxy,就可以扛住了.
我們的主界面我們用了比較有意思的框架就是 primefaces,快速的一個 WEB 組件開發的一個框架我們移動端是用的 JQuery.我們在流程方面我們還是用了一個開源的平臺就是 Activiti,自動化我們主要是用 zabbix 的API來實現命令統一推送和配置采集.
實際上自動化我們用了兩塊,一個是通過 rundeck 做批作業,還有一些基于ssh的一個推送,我們還用一個 zabbix 帶有一個告警自動修復功能有一個API,我們利用這個做了一個腳本推送功能.
我們是自主研發整合不同開源和不開源工具,融合現有的生態環境,盡量節省開發人力,現在大概是20萬行代碼,這個寫了一年多寫出來,這個量也不小,有數十個功能模塊.
現在我們基本上目前我們是 zabbix,已經是全面覆蓋掉商業監控軟件的所有的監控點.Activiti 這邊我們的緊急變更,還有資源的上線都來走 Activiti,而不是用原來的商業流程軟件了,我們走逐步的替換的這種方式.
組件我們就是使用了 Primefaces,我們后面的框架主要是基于 JSF 和 spring.我們開發的速度是很快的,功能上線基本上一個新功能一周就可以上去.
這是一個簡單的架構,我們現在這一個平臺是基于 JQuery Mobile 的界面,就是我們這個界面就是自適應的,不管是什么終端訪問都可以自動的適應你的屏幕.
我們前端是 Nginx 做附載均衡,后面是有 Redis 是高速緩存的.幾個組的 Tomcat 是做我們的任務的調度腳本的分發以及虛機的管控,云平臺的管控,這后面是我們的 vsphere API 和 openstack API.下面有 zabbix proxy 這里畫少了,我們現在 proxy 已經有十多個.
這是我們的自己編寫的云平臺的界面,我們內部使用資源幣控制資源消費,你用一個月還是用半年價錢是不一樣的,然后因為通過這個環境管理起來,我們研發環境他們在也不敢浪費了.
都是內部的客戶,其實這個價格也不好我們算,但是我們有這么一個機制以后,研發在使用資源的時候就不會扔在那過了一年兩年還在跑沒人管.
這個是我們做運維分發的工具庫,而且我們每一個推送的腳本都是做了詳細的日志,而且我們通過這些腳本的貢獻者,可以去考核我們每一個系統管理員在我們知識庫里面的貢獻度.
現在我們實現的功能,不只是這些,最高效的是去年我們有一個X86機房都是比較熱,需要關機,這個我們作用發揮了非常大的作用,我們一個按鈕下去200多臺機器就搞定了.
現在看到的這個是我們移動版的功能,這是我們的主機變更的流程,你只需要把你的流程圖在 Activiti 里面畫出來,很少的編程就可以把這個流程跑起來,非常輕量級的這么一個機制.現在我們的緊急變更基本上都是通過手機申請的.
這個是我們項目在2015去年獲得了保險行業協會一個獎——“2015年保險行業信息化杰出項目獎”.
下面講一下未來的考慮,我們做了一些小東西,未來通過這個框架不斷的拓展去自主研發繼續深化,做出一個自主開發的一體化的 DCOS.
我們可以通過執行我們的運維命令,比如說我們在移動端就可以做虛機的一個資源情況的查詢,以及虛機的一些服務器的重啟,擴展我們數據庫的空間,包括我們建立或擴展文件系統,這些標準化的操作都可以做的.
另外我們可以做到智能修復.如果說一些管的不是很規范的地方,覺得這個很簡單,發現了以后修復就可以了,但是不行你必須要留下變更的軌跡,所以我們要通過 zabbix 自動發現了以后,就是把這個自動修復了,然后通過 Activiti 留下一個緊急變更的軌跡,在我們的流程管理里面,以后是有據可查的.
然后我們計劃還是要面向現在這種容器技術做我們云 PaaS 平臺的交互,目前我們新一代 PaaS 平臺是通過調我們自動化運維的 API 來找我們索取虛擬機環境,目前是這樣的接口,未來我們想通過自動化運維平臺來管理我的鏡像和 PaaS 環境.
這是我們的一個設想,用開源代替封閉,用自建代替購買,用整合代替孤立.我們嘗到了一些甜頭但是前面還有很多坑需要我們踏.因為我們 zabbix 可以自動的把這些配置信息推過去,所以我們現在 CMDB 是很準的.
然后我們在剛才的移動版里面,我們又把 CMDB 的查詢做進去了,因為我們希望所有的領導包括系統管理員都可以在手機上面通過 CMDB 查到這個設備的信息.比如位置信息在哪個機房哪個機柜,全部都可以查到.
所以我們 CMDB 實際上一個是源頭是活水.因為從自動化發現里面出來的,消費是頻繁的,因為每一次找服務器都是會用到他.我們以前的封閉的 CMDB 已經完全不用了,下面我們通過 CMDB 把我們現在有的工作流全部結合起來.
未來是什么樣的情況,領導審批以后,系統管理員只需要點一下鼠標 Activiti 就會調我們的自動流標準件完成后續的工作,工作流和自動化完美融合,對外提供云服務菜單,這個就是我們未來的國壽云平臺.
文章來自微信公眾號:高效運維
轉載請注明本頁網址:
http://www.snjht.com/jiaocheng/4255.html