?一、概述

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

二、新形勢下的挑戰

1.運維成本大幅提升

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

2.缺乏統一的“運維大腦”

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

3.運維手段亟需豐富

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

4.缺乏新技術運維經驗

在“去 IOE ”、“自主可控”的技術和政策雙重背景下，傳統金融行業的業務系統所采用的數據庫，正在從老牌廠商的 DB2 、 Oracle 等逐漸過渡至開源數據庫或國產新興的分布式數據庫，我們也在進行分布式數據庫的轉型探索。然而，并非所有數據庫管理員都具備新數據庫技術理論和操作能力，有的管理員已經成為傳統數據庫領域的專家，可能已經運維了十年甚至二十年之久。面對新型數據庫技術，傳統技術經驗并不能完全適用，甚至可能是顛覆性的。

三、運維人員如何應對新挑戰

1.制定規范和標準，降低運維風險

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

2.借助運維工具，發展自動化、平臺化運維

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

3.探索智能運維，建設決策中心

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

4.主動擁抱新技術

自主搭建一套測試環境進行學習實踐是轉型的開端。如果已經有 DB2 或者 Oracle 的實踐基礎，可以通過對比的方式來進行新數據庫技術的學習。 MySQL 是當今使用最廣泛的開源數據庫，搭建簡單，網絡上學習教程非常多，如果能夠先把 MySQL原理理清楚，再去對比學習其他分布式數據庫便會簡單許多。目前市面上分布式數據庫技術有兩種實現方式，一類靠 MySQL+ 中間件實現，一類靠研發新型分布式數據庫實現。 Mysql+ 中間件有開源版本，也有諸多數據庫廠商基于中間件做了商業版的分布式增強，而數據庫仍沿用開源 MySQL ；自研分布式數據庫也有很多，比較知名的大廠商和中小公司推出了很多。如果企業已經有了向分布式數據庫轉型的思路，那么數據庫運維人員不妨借此機會開始參與到項目前期調研中，一定會收獲良多。

5.技術，也要懂業務和管理

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

6.引進新技術人才，注入新鮮血液

如果企業有人才招聘計劃，不妨適當引入新型數據庫的技術人才，一方面使得團隊整體對外服務能力得到提升，另一方面也為團隊引入了內部講師有利于全體成員的進步。

7.開展廠商合作，引入專業技術支持

大型金融機構的技術團隊規模可能比不上互聯網技術公司，但更多時候金融機構以甲方的身份出現，有更多的機會與技術公司開展合作。數據庫運維人員可以借助這些合作機會，向專業技術公司學習。

四、總結

以上是筆者結合自身工作經歷整理的些許感悟。在傳統數據庫轉型的過程中，運維人員一定要運用新時代運維理念及時調整自身發展方向，全面提升技術與管理技能，順應新技術潮流，以精細化、自動化、智能化的管理思維勤加思考，在變革的浪潮中砥礪前行。