1. 程式人生 > >中國人壽資料中心運維經理桂林——自動化運維自主研發之路

中國人壽資料中心運維經理桂林——自動化運維自主研發之路

作者簡介

桂林

中國人壽上海資料中心,服務處經理

帶領團隊獨立自主開發了中國人壽自動化運維平臺,基於開源平臺自開發,建立了自主監控、自主流程、移動運維的一體化智慧運維體系。

前言

本文主要講的是中國人壽自主研發自動化運維平臺成功要素。寫了中國人壽自動化運維平臺從無到有這樣的過程,並這有一些關鍵的要點,給大家做一些介紹。

上圖中的照片來自網路,我曾經是個快樂的碼農,以前是做一些保險業務平臺開發,比如車站碼頭乘客意外險出單系統等,後來開始做運維,真是一入運維深四海,沒有做開發那麼痛快,因為有很多苦逼的經歷。

1、運維之疼

疼點一:系統繁多

以前我們分公司的機房可能沒有那麼規範,我們做光纖佈線的時候沒有跳線架,拿一根PP管把光纖插進去,揭開機房地板直接從地板下面把PP水管捅過去,用這種方式來搭光纖連線伺服器和儲存,很粗放。

系統繁多

集中到資料中心運維之後,主要的產品線比較多,特別是像我們這種情況,因為我們現在集中主要還是物理集中其沒有邏輯,就是一個系統就是隻有36個分公司,一樣的資料庫可能就是36個,所以我們產品線比較多,這個就導致我們應用的例項和資料庫的例項也比較多,我們批作業量也是比較大。

這個前期我們在沒有上線自動化平臺之前,我們是發動了全國分公司的資訊部的人力一起幹,為此我們還要撥出一部分費用,每一年給他們一點獎勵。

疼點二:裝置繁雜

裝置繁雜

我們的裝置是比較繁雜的,大家看這張圖片,很多分公司的機房就是這樣子的,當然總部資料中心要規範多了。

疼點三:標準雜亂

到目前為止實際上我們已經在逐步的去改善這個情況,但是現在我們還是有一部分的大部分核心資料是在小機上面跑。標準比較雜亂,我們剛剛做的時候,標準是比較混亂的,作業系統也是有32位的有64位的,redhat 有5.4的,有5.8的,我們資料庫版本有也有很多種。

疼點四:操作無序

標準雜亂

這個是一個最大的問題,就是我們的操作,手工操作這個是比如說我們做資料庫轉換的時候,或者是很大的一些資料遷移的時候,我們可能會大量抽調全國做臨時的補充。人手不夠是因為你沒有相應的自動化平臺,平時我們操作的時候也是按照一個操作手冊來做的,而且變更也沒有做一個有序的管理。

這個也是一個很嚴重的問題,基本上節是出了事情我們開始做變更。沒有一個完善的規劃,這個也是一個比較嚴重的問題。一個事件導致一個變更,因為是沒有計劃和組織,沒有經過嚴格的一個計劃安排,所以說往往有可能導致新的事件,被動地變成一系列的變更。

那麼怎麼辦?這個會導致,我們需要有一個蛻變。從傳統的企業來講,我們其實蛻變的這個程度還是比較痛苦的。

2、化繭成蝶

蛻變一:標準化

我們的第一個目標就是將大量的開始做X86和U2L轉換,把我們本來是在小機上跑的應用程式轉移到X86平臺上去,進一步轉移到虛擬機器的 Linux。

應用改造

這個應用改造是第一步,我們通過這個改造我們節約了大量的小機。現在我們除了核心的資料庫在這小機上面,我們基本上所有的應用伺服器都是基於 Virtual Linux,當然虛擬機器也有一部分是 win 的。而且現在除了 vmware 之外我們還有建立了我們一個 OpenStack 叢集。

平臺標準化

我們做 OpenStack 給我們的研發團隊使用,同時我們還在做我們的一個基於 Docker 的一個 PaaS 平臺的研發。我們通過這些方式為後期的標準化打下基礎。

  • 基礎平臺標準化架構標準化

我們開始做一個標準化,首先是統一一個裝置的採購標準,我們統一了一個作業系統、資料庫、中介軟體版本以及我們很多的開源的平臺我們也是做標準的統一化,就是有統一的規範,以便我們運維有一個統一的管理。

  • 應用架構標準化這個是我們根據以往的教訓對研發上線的應用系統我們做出了一些架構上的規避,比如說我們對非叢集的系統我們不允許上線,或者說你這個是單點的,你沒有采用叢集架構我們是不允許上線的。你用什麼手段保證你的資料庫實現一個熱切換,可以有一個更快的恢復,規定我們一個抽取的標準,你資料怎麼抽取也要有一個規範。我們和研發就達成了一個君子協定相應對於你推過來的版本不符合規範我們是不允許上線的。我們應用架構標準化這一塊是就是推動到研發當中去發揮出我們的影響力。
    • 運維流程的標準化

這一塊我們新從新開始做出梳理,先是從有裝置來的時候配置資源上線和下線的流程,到把我們這個裝置的管理規範起來,然後我們再設立我們計劃變更的流程。

現在我們基本上規定在週三有一個小變更,週五一個大變更,其他時間是不允許做變更的。這樣我們如果說有變更的話,我們都要提前一週做一個變更計劃,通過評審才可以在下週做一個大變更。

我們對於一些影響比較小的,範圍比較小的小系統,或者是特別緊急的系統,我們可以做緊急的變更,我們緊急變更我們也有一個審批流程,這樣就把我們整個的變更的管理讓他有序,讓他形成一個安全可控的一個狀態。

我們同時也建立安全事件的管理流程,以及我們變更的手段,都把它做到有據可依,有據可查,有法可依。

  • 操作流程規範化操作規範的標準化,這個也是我們做標準梳理的一個重要的動作,我們把我們的知識建立了一個文件庫,我們把操作手冊集中起來,首先要做的是文件管理,所以文件版本要統一。統一以後我們的變更的時間建立在週三到週五的八點鐘以後,做到定期維護。

    蛻變二:工具化

    下一步就是要建立我們的工具,我們把標準化做好了以後就要建立我們自己的工具體系,我們的管理工具,這個我們現在還在用

    • 流程管理工具

    統一的流程管理,通過一些流程觀點的通知,來做到我們的一個所有的流程的統一管理,就是相應流程包括我們這個許可權申請的流程,通過這個平臺走。


    但是他現在的缺點也很明顯,因為這個整個的架構是比較繁重的,而且系統是比較慢的,因為當初設計的原因,他的操作的介面也是比較複雜的。

    • 配置管理工具這個老產品就是依賴手工更新 CMDB 配置項的,嵌入到我們一個變更管理流程裡面去,這個需要手工的更新這個資訊,通過績效考核考察你這個 CMDB 的完整性。這個實際上也是比較坑爹的。
      • 監控的工具我們用的監控工具也是基於一款商業軟體,能夠解決大多數的基礎平臺狀態監控問題,而應用監控這一塊是比較薄弱的也都有一個共同的通電在裡面,因為你是依賴廠商,新的需求就一定要定製化開發。

        蛻變三:自主化

        然後操作自動化工具是缺失,這個應該是在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年保險行業資訊化傑出專案獎”。

        3、未來方向:自主開發一體化DCOS

        下面講一下未來的考慮,我們做了一些小東西,未來通過這個框架不斷的拓展去自主研發繼續深化,做出一個自主開發的一體化的 DCOS。

        我們可以通過執行我們的運維命令,比如說我們在移動端就可以做虛機的一個資源情況的查詢,以及虛機的一些伺服器的重啟,擴充套件我們資料庫的空間,包括我們建立或擴充套件檔案系統,這些標準化的操作都可以做的。

        另外我們可以做到智慧修復。如果說一些管的不是很規範的地方,覺得這個很簡單,發現了以後修復就可以了,但是不行你必須要留下變更的軌跡,所以我們要通過 zabbix 自動發現了以後,就是把這個自動修復了,然後通過 Activiti 留下一個緊急變更的軌跡,在我們的流程管理裡面,以後是有據可查的。

        容器技術然後我們計劃還是要面向現在這種容器技術做我們雲 PaaS 平臺的互動,目前我們新一代 PaaS 平臺是通過調我們自動化運維的 API 來找我們索取虛擬機器環境,目前是這樣的介面,未來我們想通過自動化運維平臺來管理我的映象和 PaaS 環境。

        這是我們的一個設想,用開源代替封閉,用自建代替購買,用整合代替孤立。我們嚐到了一些甜頭但是前面還有很多坑需要我們踏。因為我們 zabbix 可以自動的把這些配置資訊推過去,所以我們現在 CMDB 是很準的。

        然後我們在剛才的移動版裡面,我們又把 CMDB 的查詢做進去了,因為我們希望所有的領導包括系統管理員都可以在手機上面通過 CMDB 查到這個裝置的資訊。比如位置資訊在哪個機房哪個機櫃,全部都可以查到。

        所以我們 CMDB 實際上一個是源頭是活水。因為從自動化發現裡面出來的,消費是頻繁的,因為每一次找伺服器都是會用到他。我們以前的封閉的 CMDB 已經完全不用了,下面我們通過 CMDB 把我們現在有的工作流全部結合起來。

        未來是什麼樣的情況,領導審批以後,系統管理員只需要點一下滑鼠 Activiti 就會調我們的自動流標準件完成後續的工作,工作流和自動化完美融合,對外提供雲服務選單,這個就是我們未來的國壽雲平臺。

        文章來自微信公眾號:高效運維