本文來自twt企業(yè)IT社區(qū)，作者/wanglaye。
一、背景
在現(xiàn)今云計算、大數(shù)據(jù)等新型技術推動下，業(yè)界主流的應用架構，正由松耦合、集中式的SOA架構向解耦合、分布式的微服務架構發(fā)展，運維人員的工作方式也正在由煙囪式運維、人工運維向自動化、流程化、平臺化、智能化運維轉變。在“去IOE”、“自主可控”的技術和政策雙重背景下，傳統(tǒng)金融行業(yè)的業(yè)務系統(tǒng)所采用的數(shù)據(jù)庫，正在從老牌廠商的傳統(tǒng)數(shù)據(jù)庫逐漸過渡至開源數(shù)據(jù)庫或國產新興的分布式數(shù)據(jù)庫。技術路線的變化同時也帶來了工作方式的轉變，傳統(tǒng)數(shù)據(jù)庫運維人員在這一輪發(fā)展浪潮中會遇到哪些挑戰(zhàn)，以及應該如何應對這些挑戰(zhàn)，這些問題成為各位管理員們首先要思考的問題。筆者結合自身工作經歷整理了一些感悟與各位分享。
二、新形勢下的挑戰(zhàn)
1.技術架構發(fā)生改變
和傳統(tǒng)集中式數(shù)據(jù)庫相比，分布式數(shù)據(jù)庫具備明顯優(yōu)勢，例如帶來了數(shù)據(jù)去中心化、負載分攤；能夠按照需求變化進行動態(tài)伸縮，支持橫向與縱向擴展；分布式架構下，服務可用性保障質量更高，不會因為單點失效而中斷，整體容災能力更強；x86服務器組成集群，性價比更高。當然，分布式架構也存在一定的局限性，例如分布式架構帶來的復雜性，比集中式數(shù)據(jù)庫運維難度大；X86服務器硬件本身的可靠性有所降低；應用設計的復雜度有所增加，面臨應用的改造。
2.運維輔助工具亟需豐富
作為一家傳統(tǒng)金融行業(yè)，業(yè)務系統(tǒng)都有各自獨立的數(shù)據(jù)庫，每個數(shù)據(jù)庫會被分派給指定的數(shù)據(jù)庫管理員運維，這就導致每個人之間存在信息壁壘，無法對全部數(shù)據(jù)庫的運行狀況形成全局視圖，缺乏統(tǒng)一的“運維大腦”，無法進行統(tǒng)一的數(shù)據(jù)庫分析和輔助決策，出現(xiàn)問題時往往各自為政，大家各自查看自己負責的那些數(shù)據(jù)庫，然后靠現(xiàn)場溝通互通有無，運維時效性難以保障。
在集中式運維時代，我們數(shù)據(jù)庫管理員有時間、有精力直接敲命令進行運維，例如安裝、巡檢、備份、升級、調參等基本工作，此時是“純人工時代”；隨著數(shù)據(jù)庫數(shù)量的增加，再通過手工敲命令方式逐一操作各個數(shù)據(jù)庫已經不再現(xiàn)實，因此，我們開始寫腳本，放到服務器上自動執(zhí)行，由操作系統(tǒng)完成腳本執(zhí)行，管理員只需讀取針對各個數(shù)據(jù)庫的腳本執(zhí)行結果即可，此時是“腳本時代”；然而，數(shù)據(jù)庫數(shù)量日益增長，即使逐一讀取腳本執(zhí)行結果也要消耗相當大的精力，此時管理員們開始借助Ansible這類自動化運維工具批量管理數(shù)據(jù)庫，只需讀取一次批量執(zhí)行結果即可，此時是“初級自動化運維時代”。然而，即使到了“初級自動化運維時代”，信息的終點還是“人”，需要由我們管理員做最終判斷，當出現(xiàn)問題時登陸數(shù)據(jù)庫讀取各項指標進行人工分析，在當今這個分布式技術蓬勃發(fā)展、數(shù)據(jù)海量井噴的時代里，只靠我們這些“人”來判斷處理如此之多的信息流，已經出現(xiàn)力不從心的情況。這種形勢下，必須引入其他運維手段，幫助把我們管理員從繁瑣高壓的工作環(huán)境中解放出來。
3.運維壓力和成本增加
傳統(tǒng)數(shù)據(jù)庫運維人員面對的數(shù)據(jù)庫往往是各自獨立的。業(yè)務系統(tǒng)仍然是縱向隔離的狀態(tài)，在煙囪式系統(tǒng)架構中，每個業(yè)務系統(tǒng)都有自己獨立的數(shù)據(jù)庫，我們在管理這些數(shù)據(jù)庫的過程中，往往需要串行化操作。然而，我們的數(shù)據(jù)庫運維團隊規(guī)模還比較小，卻已經承擔了上百套數(shù)據(jù)庫的運維，隨著業(yè)務系統(tǒng)數(shù)量越來越多、數(shù)據(jù)規(guī)模越來越大、交易復雜度不斷提升，如果仍按照傳統(tǒng)的數(shù)據(jù)庫單點運維方式，勢必導致運維時間成本和人力成本大幅攀升。
4.技術經驗和人才缺乏
我們在近年也不斷進行分布式數(shù)據(jù)庫的轉型實踐。然而，在團隊建設方面，仍然與新技術存在一定的脫節(jié)，有的數(shù)據(jù)庫管理員已經成為傳統(tǒng)數(shù)據(jù)庫領域的專家，可能已經運維了十年甚至二十年之久。面對新型數(shù)據(jù)庫技術，傳統(tǒng)技術經驗并不能完全適用，甚至可能是顛覆性的。
三、新形勢下的運維新要求
1.制定規(guī)范和標準，區(qū)分常規(guī)運維和應急場景
作為傳統(tǒng)金融機構，我們有一套完整的運維規(guī)章制度，如運維操作流程、應急處置規(guī)范和預案、完善的變更與回退流程等等，保障各項運維工作有條不紊開展，而這些規(guī)章制度的有效執(zhí)行往往需要依靠各崗位的細化落實，數(shù)據(jù)庫運維崗位也不例外。數(shù)據(jù)庫運維團隊正在按照這些規(guī)范指引，結合崗位各方面的具體工作，制定出屬于數(shù)據(jù)庫管理的規(guī)范和標準。例如把升級、上線、備份、遷數(shù)等工作整理成標準模板文檔，形成運維資產隨時調用；把數(shù)據(jù)建模和數(shù)據(jù)庫設計、容量規(guī)劃、SQL開發(fā)、高可用架構設計等工作整理成規(guī)范文檔，面向所有數(shù)據(jù)庫開發(fā)人員提供咨詢指導；把常見故障問題及解決方案整理成冊，制定面向不同場景的應急處置預案等。通過標準、規(guī)范化的管理，使得數(shù)據(jù)庫運維工作有據(jù)可依，從而降低運維風險。
2.運維工具向自動化、平臺化、智能化轉變
大數(shù)據(jù)背景下運維工作已經不能單純依靠人力來解決，而要借助工具、平臺來完成。目前開源的和商用的運維工具和平臺豐富多樣，很多傳統(tǒng)的手工運維工作都可以交給這些工具或者建設相應平臺來做。常規(guī)序列化操作如安裝、巡檢、升級、備份等，我們已經開始借助自動化運維平臺；以往通過手工更新的數(shù)據(jù)庫配置信息表交給ITSM或CMDB來管理；數(shù)據(jù)庫的監(jiān)控告警可以利用近幾年大熱的Prometheus+grafana技術進行配置，或者引入商用產品建設數(shù)據(jù)庫監(jiān)控平臺或數(shù)據(jù)庫性能分析系統(tǒng)；等等。作為一名數(shù)據(jù)庫管理員一定要經常思考哪些工作可以交給“機器”去做，多多借助運維工具和平臺。
同時，隨著越來越多的運維工具投入使用，運維管理員似乎又“忙”了起來，因為需要在不同的工具和平臺之間進行切換，并在大腦中將各種指標關聯(lián)起來綜合進行判斷，以實現(xiàn)故障分析、關系維護等操作難題，這對于運維人員來說也形成了不小的壓力。深入思考后發(fā)現(xiàn)，所有這些運維工具、平臺、系統(tǒng)，歸根結底，都在采集“數(shù)據(jù)”并向外輸出“信息”。數(shù)據(jù)在當代已經成為企業(yè)生存的根本，如果能夠整合這些“信息”并產生更大的“價值”，那么對于運維人員來說必然又多了一項利器。如何實現(xiàn)運維資產數(shù)據(jù)有效、精確、精細化管理，利用大數(shù)據(jù)技術形成決策中心，運維數(shù)據(jù)消費效率，成為目前不得不思考的問題，而數(shù)據(jù)中臺、運維數(shù)據(jù)中臺、智能運維平臺等技術正是為了解決此類問題應運而生。數(shù)據(jù)庫運維員作為智能運維的直接受益者，我們也正在朝這個方向探索。
3.知其然與所以然，實踐出真知
分布式數(shù)據(jù)庫經過了多年的發(fā)展，在用戶體驗方面和可視化操作層面其實已經做的很好了，有時候管理頁面點擊幾下就可以把數(shù)據(jù)庫操作完成，但是，作為數(shù)據(jù)庫管理員，仍然需要謹記：系統(tǒng)做得越優(yōu)化、越簡單，里面隱藏的技術、原理反而越多。因為所有個性化的功能都是做了包裝的，如果一直停留在表面去使用，那可能在出問題的時候無法解決。所以我們在使用分布式數(shù)據(jù)庫這種架構復雜、經過封裝的軟件產品時，還是要花更多的時間去了解其原理。
分布式數(shù)據(jù)庫技能的提升一定要放到真實環(huán)境中去，這個真實環(huán)境選擇不影響業(yè)務的。自主搭建一套測試環(huán)境進行學習實踐是轉型的開端。如果已經有DB2或者Oracle的實踐基礎，可以通過對比的方式來進行新數(shù)據(jù)庫技術的學習。MySQL是當今使用最廣泛的開源數(shù)據(jù)庫，搭建簡單，網絡上學習教程非常多，如果能夠先把MySQL原理理清楚，再去對比學習其他分布式數(shù)據(jù)庫便會簡單許多。目前市面上分布式數(shù)據(jù)庫技術有兩種實現(xiàn)方式，一類靠MySQL+中間件實現(xiàn)，一類靠研發(fā)新型分布式數(shù)據(jù)庫實現(xiàn)。MySQL+中間件有開源版本，也有諸多數(shù)據(jù)庫廠商基于中間件做了商業(yè)版的分布式增強，而數(shù)據(jù)庫仍沿用開源Mysql；自研分布式數(shù)據(jù)庫也有很多。如果企業(yè)已經有了向分布式數(shù)據(jù)庫轉型的思路，那么數(shù)據(jù)庫運維人員不妨借此機會開始參與到項目前期調研中，一定會收獲良多。
4.技術和管理兩手抓
大型金融機構內部的分工往往比較細，很多情況下技術人員、項目管理人員是不同的團隊，然而對于個人發(fā)展來說，還是應該把重點從技術領域擴展到復合型領域。正如前文所說，如果企業(yè)已經有了向分布式數(shù)據(jù)庫轉型的思路，那么數(shù)據(jù)庫運維人員一定要從項目前期調研就開始參與，因為項目前期所進行的調研、需求、poc測試是了解新技術的第一步，可以最快速地了解市場主流技術和應用現(xiàn)狀。到了項目建設期，就更需要技術和管理的復合型人才了，數(shù)據(jù)庫運維人員自身已經有了技術實力，更能方便地把業(yè)務需求與實踐相結合，利于項目成功落地。項目建成后進行新技術推廣時，技術人員的優(yōu)勢又能進一步凸顯，因為無論是何種新技術的推廣實施，一定要先制定完善的技術升級規(guī)范，提前做好測試，獲取遷移改造量和改造難度，制定出切實可行的切換計劃，在這一點上技術人員可謂具有得天獨厚的優(yōu)勢。
5.適當引入技術支持
技術支持分內部和外部。先說外部，大型金融機構的技術團隊規(guī)?？赡鼙炔簧匣ヂ?lián)網技術公司，但更多時候金融機構以甲方的身份出現(xiàn)，有更多的機會與技術公司開展合作。數(shù)據(jù)庫運維人員可以借助這些合作機會，向專業(yè)技術公司學習，例如以培訓、證書、定制課程的方式。對于內部，如果企業(yè)有人才招聘計劃，不妨適當引入新型數(shù)據(jù)庫的技術人才，一方面使得團隊整體對外服務能力得到提升，另一方面也為團隊引入了內部講師有利于全體成員的進步。
四、總結
以上是筆者結合自身工作經歷整理的些許感悟。在傳統(tǒng)數(shù)據(jù)庫轉型的過程中，運維人員一定要運用新時代運維理念及時調整自身發(fā)展方向，提升技術與管理技能，順應新技術潮流，以精細化、自動化、智能化的管理思維持續(xù)成長。
