傳統(tǒng)數(shù)據庫運維人員如何應對分布式轉型?

傳統(tǒng)數(shù)據庫運維人員面對的數(shù)據庫往往是各自獨立的。業(yè)務系統(tǒng)仍然是縱向隔離的狀態(tài),在煙囪式系統(tǒng)架構中,每個業(yè)務系統(tǒng)都有自己獨立的數(shù)據庫,我們在管理這些數(shù)據庫的過程中,往往需要串行化操作。

本文來自twt企業(yè)IT社區(qū),作者/wanglaye。

一、背景

在現(xiàn)今云計算、大數(shù)據等新型技術推動下,業(yè)界主流的應用架構,正由松耦合、集中式的SOA架構向解耦合、分布式的微服務架構發(fā)展,運維人員的工作方式也正在由煙囪式運維、人工運維向自動化、流程化、平臺化、智能化運維轉變。在“去IOE”、“自主可控”的技術和政策雙重背景下,傳統(tǒng)金融行業(yè)的業(yè)務系統(tǒng)所采用的數(shù)據庫,正在從老牌廠商的傳統(tǒng)數(shù)據庫逐漸過渡至開源數(shù)據庫或國產新興的分布式數(shù)據庫。技術路線的變化同時也帶來了工作方式的轉變,傳統(tǒng)數(shù)據庫運維人員在這一輪發(fā)展浪潮中會遇到哪些挑戰(zhàn),以及應該如何應對這些挑戰(zhàn),這些問題成為各位管理員們首先要思考的問題。筆者結合自身工作經歷整理了一些感悟與各位分享。

二、新形勢下的挑戰(zhàn)

1.技術架構發(fā)生改變

和傳統(tǒng)集中式數(shù)據庫相比,分布式數(shù)據庫具備明顯優(yōu)勢,例如帶來了數(shù)據去中心化、負載分攤;能夠按照需求變化進行動態(tài)伸縮,支持橫向與縱向擴展;分布式架構下,服務可用性保障質量更高,不會因為單點失效而中斷,整體容災能力更強;x86服務器組成集群,性價比更高。當然,分布式架構也存在一定的局限性,例如分布式架構帶來的復雜性,比集中式數(shù)據庫運維難度大;X86服務器硬件本身的可靠性有所降低;應用設計的復雜度有所增加,面臨應用的改造。

2.運維輔助工具亟需豐富

作為一家傳統(tǒng)金融行業(yè),業(yè)務系統(tǒng)都有各自獨立的數(shù)據庫,每個數(shù)據庫會被分派給指定的數(shù)據庫管理員運維,這就導致每個人之間存在信息壁壘,無法對全部數(shù)據庫的運行狀況形成全局視圖,缺乏統(tǒng)一的“運維大腦”,無法進行統(tǒng)一的數(shù)據庫分析和輔助決策,出現(xiàn)問題時往往各自為政,大家各自查看自己負責的那些數(shù)據庫,然后靠現(xiàn)場溝通互通有無,運維時效性難以保障。

在集中式運維時代,我們數(shù)據庫管理員有時間、有精力直接敲命令進行運維,例如安裝、巡檢、備份、升級、調參等基本工作,此時是“純人工時代”;隨著數(shù)據庫數(shù)量的增加,再通過手工敲命令方式逐一操作各個數(shù)據庫已經不再現(xiàn)實,因此,我們開始寫腳本,放到服務器上自動執(zhí)行,由操作系統(tǒng)完成腳本執(zhí)行,管理員只需讀取針對各個數(shù)據庫的腳本執(zhí)行結果即可,此時是“腳本時代”;然而,數(shù)據庫數(shù)量日益增長,即使逐一讀取腳本執(zhí)行結果也要消耗相當大的精力,此時管理員們開始借助Ansible這類自動化運維工具批量管理數(shù)據庫,只需讀取一次批量執(zhí)行結果即可,此時是“初級自動化運維時代”。然而,即使到了“初級自動化運維時代”,信息的終點還是“人”,需要由我們管理員做最終判斷,當出現(xiàn)問題時登陸數(shù)據庫讀取各項指標進行人工分析,在當今這個分布式技術蓬勃發(fā)展、數(shù)據海量井噴的時代里,只靠我們這些“人”來判斷處理如此之多的信息流,已經出現(xiàn)力不從心的情況。這種形勢下,必須引入其他運維手段,幫助把我們管理員從繁瑣高壓的工作環(huán)境中解放出來。

3.運維壓力和成本增加

傳統(tǒng)數(shù)據庫運維人員面對的數(shù)據庫往往是各自獨立的。業(yè)務系統(tǒng)仍然是縱向隔離的狀態(tài),在煙囪式系統(tǒng)架構中,每個業(yè)務系統(tǒng)都有自己獨立的數(shù)據庫,我們在管理這些數(shù)據庫的過程中,往往需要串行化操作。然而,我們的數(shù)據庫運維團隊規(guī)模還比較小,卻已經承擔了上百套數(shù)據庫的運維,隨著業(yè)務系統(tǒng)數(shù)量越來越多、數(shù)據規(guī)模越來越大、交易復雜度不斷提升,如果仍按照傳統(tǒng)的數(shù)據庫單點運維方式,勢必導致運維時間成本和人力成本大幅攀升。

4.技術經驗和人才缺乏

我們在近年也不斷進行分布式數(shù)據庫的轉型實踐。然而,在團隊建設方面,仍然與新技術存在一定的脫節(jié),有的數(shù)據庫管理員已經成為傳統(tǒng)數(shù)據庫領域的專家,可能已經運維了十年甚至二十年之久。面對新型數(shù)據庫技術,傳統(tǒng)技術經驗并不能完全適用,甚至可能是顛覆性的。

三、新形勢下的運維新要求

1.制定規(guī)范和標準,區(qū)分常規(guī)運維和應急場景

作為傳統(tǒng)金融機構,我們有一套完整的運維規(guī)章制度,如運維操作流程、應急處置規(guī)范和預案、完善的變更與回退流程等等,保障各項運維工作有條不紊開展,而這些規(guī)章制度的有效執(zhí)行往往需要依靠各崗位的細化落實,數(shù)據庫運維崗位也不例外。數(shù)據庫運維團隊正在按照這些規(guī)范指引,結合崗位各方面的具體工作,制定出屬于數(shù)據庫管理的規(guī)范和標準。例如把升級、上線、備份、遷數(shù)等工作整理成標準模板文檔,形成運維資產隨時調用;把數(shù)據建模和數(shù)據庫設計、容量規(guī)劃、SQL開發(fā)、高可用架構設計等工作整理成規(guī)范文檔,面向所有數(shù)據庫開發(fā)人員提供咨詢指導;把常見故障問題及解決方案整理成冊,制定面向不同場景的應急處置預案等。通過標準、規(guī)范化的管理,使得數(shù)據庫運維工作有據可依,從而降低運維風險。

2.運維工具向自動化、平臺化、智能化轉變

大數(shù)據背景下運維工作已經不能單純依靠人力來解決,而要借助工具、平臺來完成。目前開源的和商用的運維工具和平臺豐富多樣,很多傳統(tǒng)的手工運維工作都可以交給這些工具或者建設相應平臺來做。常規(guī)序列化操作如安裝、巡檢、升級、備份等,我們已經開始借助自動化運維平臺;以往通過手工更新的數(shù)據庫配置信息表交給ITSM或CMDB來管理;數(shù)據庫的監(jiān)控告警可以利用近幾年大熱的Prometheus+grafana技術進行配置,或者引入商用產品建設數(shù)據庫監(jiān)控平臺或數(shù)據庫性能分析系統(tǒng);等等。作為一名數(shù)據庫管理員一定要經常思考哪些工作可以交給“機器”去做,多多借助運維工具和平臺。

同時,隨著越來越多的運維工具投入使用,運維管理員似乎又“忙”了起來,因為需要在不同的工具和平臺之間進行切換,并在大腦中將各種指標關聯(lián)起來綜合進行判斷,以實現(xiàn)故障分析、關系維護等操作難題,這對于運維人員來說也形成了不小的壓力。深入思考后發(fā)現(xiàn),所有這些運維工具、平臺、系統(tǒng),歸根結底,都在采集“數(shù)據”并向外輸出“信息”。數(shù)據在當代已經成為企業(yè)生存的根本,如果能夠整合這些“信息”并產生更大的“價值”,那么對于運維人員來說必然又多了一項利器。如何實現(xiàn)運維資產數(shù)據有效、精確、精細化管理,利用大數(shù)據技術形成決策中心,運維數(shù)據消費效率,成為目前不得不思考的問題,而數(shù)據中臺、運維數(shù)據中臺、智能運維平臺等技術正是為了解決此類問題應運而生。數(shù)據庫運維員作為智能運維的直接受益者,我們也正在朝這個方向探索。

3.知其然與所以然,實踐出真知

分布式數(shù)據庫經過了多年的發(fā)展,在用戶體驗方面和可視化操作層面其實已經做的很好了,有時候管理頁面點擊幾下就可以把數(shù)據庫操作完成,但是,作為數(shù)據庫管理員,仍然需要謹記:系統(tǒng)做得越優(yōu)化、越簡單,里面隱藏的技術、原理反而越多。因為所有個性化的功能都是做了包裝的,如果一直停留在表面去使用,那可能在出問題的時候無法解決。所以我們在使用分布式數(shù)據庫這種架構復雜、經過封裝的軟件產品時,還是要花更多的時間去了解其原理。

分布式數(shù)據庫技能的提升一定要放到真實環(huán)境中去,這個真實環(huán)境選擇不影響業(yè)務的。自主搭建一套測試環(huán)境進行學習實踐是轉型的開端。如果已經有DB2或者Oracle的實踐基礎,可以通過對比的方式來進行新數(shù)據庫技術的學習。MySQL是當今使用最廣泛的開源數(shù)據庫,搭建簡單,網絡上學習教程非常多,如果能夠先把MySQL原理理清楚,再去對比學習其他分布式數(shù)據庫便會簡單許多。目前市面上分布式數(shù)據庫技術有兩種實現(xiàn)方式,一類靠MySQL+中間件實現(xiàn),一類靠研發(fā)新型分布式數(shù)據庫實現(xiàn)。MySQL+中間件有開源版本,也有諸多數(shù)據庫廠商基于中間件做了商業(yè)版的分布式增強,而數(shù)據庫仍沿用開源Mysql;自研分布式數(shù)據庫也有很多。如果企業(yè)已經有了向分布式數(shù)據庫轉型的思路,那么數(shù)據庫運維人員不妨借此機會開始參與到項目前期調研中,一定會收獲良多。

4.技術和管理兩手抓

大型金融機構內部的分工往往比較細,很多情況下技術人員、項目管理人員是不同的團隊,然而對于個人發(fā)展來說,還是應該把重點從技術領域擴展到復合型領域。正如前文所說,如果企業(yè)已經有了向分布式數(shù)據庫轉型的思路,那么數(shù)據庫運維人員一定要從項目前期調研就開始參與,因為項目前期所進行的調研、需求、poc測試是了解新技術的第一步,可以最快速地了解市場主流技術和應用現(xiàn)狀。到了項目建設期,就更需要技術和管理的復合型人才了,數(shù)據庫運維人員自身已經有了技術實力,更能方便地把業(yè)務需求與實踐相結合,利于項目成功落地。項目建成后進行新技術推廣時,技術人員的優(yōu)勢又能進一步凸顯,因為無論是何種新技術的推廣實施,一定要先制定完善的技術升級規(guī)范,提前做好測試,獲取遷移改造量和改造難度,制定出切實可行的切換計劃,在這一點上技術人員可謂具有得天獨厚的優(yōu)勢。

5.適當引入技術支持

技術支持分內部和外部。先說外部,大型金融機構的技術團隊規(guī)??赡鼙炔簧匣ヂ?lián)網技術公司,但更多時候金融機構以甲方的身份出現(xiàn),有更多的機會與技術公司開展合作。數(shù)據庫運維人員可以借助這些合作機會,向專業(yè)技術公司學習,例如以培訓、證書、定制課程的方式。對于內部,如果企業(yè)有人才招聘計劃,不妨適當引入新型數(shù)據庫的技術人才,一方面使得團隊整體對外服務能力得到提升,另一方面也為團隊引入了內部講師有利于全體成員的進步。

四、總結

以上是筆者結合自身工作經歷整理的些許感悟。在傳統(tǒng)數(shù)據庫轉型的過程中,運維人員一定要運用新時代運維理念及時調整自身發(fā)展方向,提升技術與管理技能,順應新技術潮流,以精細化、自動化、智能化的管理思維持續(xù)成長。

THEEND

最新評論(評論僅代表用戶觀點)

更多
暫無評論