*轉載源：“OceanBase資料庫星球”服務號*

***“DBA100人”專訪計劃是OceanBase圍繞資深DBA進行的人物專訪活動，旨在透過人物故事、職業發展經歷以及日常工作中遇到的技術難題和實踐案例，未來對技術趨勢的想法，希望他們的成長之道能夠給到各行業DBA一些建議和思考。***

------

> #### **編者按**
>
> **DBA如何快速定位故障？如何做好效能最佳化？如何做好技術選型與技術體系建設？**
>
> **今天《DBA 100人》第1期帶你瞭解一位擁有十多年職場經驗的資深資料庫專家&運維人——雲南某銀行資訊科技部運維中心經理，他曾負責主機、中介軟體、資料庫的維護；參與銀行核心系統、支付系統的開發；領導運維體系、應急容災體系、監控體系的建設，希望他的經驗能給你帶來參考價值。**

2001年，這個問題對於正在報考大學志願的李建明而言，一無所知。和許多因為“喜歡玩電腦”和覺得“程式設計有趣”的人不同，李建明高中時都不曾接觸計算機，只因那時計算機還未在全國校園普及，他只曾聽人說起，學計算機能在畢業後找到一份不錯的工作。

就這樣，李建明成為中國第一批學習資訊保安技術的本科生，在校期間還兼職開發了辦公軟體、論壇、部落格等，第一次感受到了程式設計的樂趣：“我很享受這種從無到有，一步一步把產品做出來的過程”。由於資訊保安技術的知識比較寬泛，對於想在計算機領域穩紮穩打的李建明而言必須深入工程，打好編碼的底層基礎。因此，他在報考研究生時選擇了系統分析與整合專業。對於專業的選擇，李建明認為一個重要的判斷因素是“未來這條路是寬還是窄，通俗地說就是未來擇業時，你所選方向的市場需求量是大還是小？還可以結合自己的興趣考慮，在自己感興趣的領域或許會更加順利。”

這次選擇，為李建明進入資料庫領域，成為一名DBA埋下了伏筆。

## 成長中的DBA：快速定位故障，清楚系統執行機制

2008年，研究生畢業的李建明入職正值電子化改革高速發展期的某信用社，參與核心系統和支付系統的維護與開發工作。早在2004年，國務院要求深化農村信用社改革，某信用社響應國家號召，在2005年成立了科技結算中心，建設了資訊系統，此舉也為客戶帶來了更方便、快捷的金融服務。但不斷上漲的交易量給系統帶來了挑戰，系統穩定性的保障難度不斷加碼。

### “快”是一大挑戰

信用社資訊系統的搭建正是由李建明所在的科技結算中心負責，因此，從入職起他就一邊負責系統的維護，一邊最佳化系統，工作之餘還自學DBA相關的知識。作為系統維護人員，李建明需要在系統出錯時，及時定位故障並快速修復。而要做到“快”，對於初入職的“技術小白”而言卻很有挑戰。

李建明的辦法是搞清楚系統執行機制、執行流程。當系統報錯時就可以很快地查詢到哪些賬務是錯誤的，以及這種錯誤會在什麼情況下出現。

一般來說，運維人員會覺得應用系統永遠都是缺文件的。開發人員可能不會將文件寫得全面。因此，運維人員在維護系統時就需要多鑽研。比如，瞭解系統架構與業務架構及其技術實現路徑，瞭解系統表結構就能基本掌握業務結構，瞭解作業系統的命令就能掌握系統的結構。此外，還要進一步學習系統元件，如鑽研資料庫的表結構。

透過不斷地深入瞭解系統各個層面以及不斷向上層探索，逐漸清楚系統的執行機制與執行流程，並在一次又一次的假設問題與驗證答案中掌握真理。當“實驗”做得足夠多時，自然就能掌握快速定位故障並修復故障的能力。除此以外，李建明花了七八個月的時間通讀系統主要的原始碼。這段時間的鑽研與自學，不僅使李建明可以在系統出錯時快速找到問題，也讓他的技術能力與程式碼質量都得到了迅速提升。

2010年，李建明也因為兩年的優秀表現，正式成為了一名系統管理員兼資料庫管理員（DBA），負責系統的穩定與高效執行，並管理和維護資料庫、作業系統、應用軟體、中介軟體等。“當時有兩個系統管理員，只要出現技術故障，我們都需要介入處理”。而他在這兩年對系統的鑽研與探索，使他對系統基本瞭如指掌，對新的工作任務得心應手。

### 摸索、踩坑、學習

這些問題對於一個成熟的DBA而言都不算難。但對於成長中的DBA而言，需要不斷在實踐中摸索、踩坑、學習。

例如，資料庫連線池出現故障時，經驗較少的DBA可能會認為是連線數量不夠，於是不斷建立更多的連線，當連線池佔滿時也沒能解決問題。因為連線池滿只是一種現象，解決根本問題還需從現象看本質。在一些情況下，確實存在業務量過大的原因，但在大多數情況下，業務量不會突然增大，連線池滿的原因可能是新業務不高效，導致連線池堵塞或者連線池沒有及時釋放。這時，一味地加連線只是延緩系統堵塞，並不能從本質解決問題。

再例如，發生長事務問題導致業務中斷時，對原理不熟悉的DBA只會傻傻地等待事務回滾。但積累一定經驗後，就會知道，其實可以透過不斷增加事務日誌檔案，來保證業務正常執行的過程中將事務回滾完成。

“系統管理員的工作，讓我對軟體系統有了更深入的瞭解。從理論到實踐，積累了豐富的故障處理及效能最佳化經驗，提升了技術自信心”，李建明如是說。同時，他總結了保障系統穩定性及定位故障、最佳化效能的經驗。

**作為DBA，保障系統穩定性是重中之重，李建明認為需要做好三項工作。**

第一，預防，即關注網路、儲存、計算資源，以及作業系統等基礎架構的規劃。確保基礎框架保持相對的統一。

第二，在系統正常執行時，注重從業務視角觀察系統執行是否有異常，是否處於亞健康狀態，做好預警、應急等方面的可觀測性建設，完善容災體系和標準化操作管理。

第三，應急，即透過系統架構定位故障，再結合監控系統輔助分析問題。**對於故障定位與效能最佳化，可從三方面開展：**

1）確認系統架構和業務架構，站在全域性的角度排查問題；2）關注各種指標，如常見的CPU記憶體、I/O、負載、業務量，業務的成功率、響應時間等；3）在壓力場景下，從前到後排除每個模組的效能表現，或者是一些活動的概要資訊和詳細資訊，包括當前系統正在做的一些操作。比如呼叫了什麼函式，執行了什麼SQL，以及每一個執行緒正在執行什麼函式，甚至關注網路傳輸包的響應效率和網路延遲等問題。

此外，為了避免各模組負責人之間推卸責任，需要有一個技術融合的團隊，在應急時每個人都能統管全域性，快速上手處理問題。

## 經驗豐富的DBA：資料庫選型不求最貴，只求最好

在某信用社的十年，李建明從懵懵懂懂的應屆生成為了經驗老到的系統管理員與高階工程師，該信用社的電子系統也從支撐上百萬賬務交易量發展為支撐上千萬賬務交易量。如果說信用社是李建明職業生涯的基石，是培養他職業技能的搖籃，那麼銀行就是他十年職業技能與經驗的高階試煉場。

自2018年李建明加入雲南某銀行，負責運維團隊的管理與運維體系、應急容災體系、監控體系的建設。另外，在2021年參與了一項看似離DBA很遙遠的工作：資料庫選型。

不以業務為基礎的選型就是耍流氓，想做好技術選型，**首先要對市場中哪些資料庫可以作為備選有一定的瞭解。** 李建明認為，一款優秀的資料庫產品應該像Informix一樣穩定、簡潔，同時又能像Oracle一樣擁有豐富的內建系統表，且具備高效能特性。還應該達到ACID（Atomicity、Consistency、Isolation、Durability，即或稱不可分割性）、原子性、一致性、隔離性、永續性）的要求，另外，保證應用的透明性是不可或缺的能力。資料庫還應該給予DBA足夠的掌控感，讓DBA看到他和資料庫互動的過程中使用了什麼工具、消耗了多少CPU、用了多長時間，以及做過哪些操作。

**其次，針對業務特性，選擇“最優解”。** 以李建明當前所在的銀行行業更換資料庫時的技術選型為例。

大部分銀行都會使用較為成熟的Oracle資料庫，使用Oracle的好處在於其文件、書籍等資料較全，工具豐富且生態成熟，遇到問題時能複用他人的解決方案或比較快速地找到懂Oracle的開發者。但隨著銀行資料量的日益龐大，Oracle的資料處理能力顯得捉襟見肘，在做異地多活的時候也顯現出了短板，Oracle的全域性快取機制會使A客戶的資料跑在A中心，B客戶的資料跑在B中心，如果交叉跑會導致效能極大地衰減。另外，硬體投入成本、軟體使用成本都在不斷增加。可替換資料庫談何容易，李建明所在的銀行在資料庫選型上陷入兩難境地。

**其實銀行真正需要的是一個效能更好且成本更低的資料庫，能夠靈活地擴容、縮容，在業務量較低時減少節點，在應對交易峰值時增加節點。將對於傳統的集中式資料庫Oracle，分散式資料庫似乎是新的選擇方向。**

從系統角度而言，對比目前市面上優秀的分散式資料庫，李建明認為，資料庫的架構應該由其本身決定，而不是由上層應用和DBA總關注它的資料分佈機制，就這一點，便能夠排除一些資料庫選項，OceanBase資料庫由於其一體化的架構佔據了優勢。從擴、縮容角度而言，有資料庫級、表級、行級的彈性，資料庫級別的擴、縮容不夠細緻，而行級的擴、縮容對於當前業務交易量而言還用不到，因此，表級擴、縮容的OceanBase便是不錯的選擇，且OceanBase的三地五中心能夠做到不丟失資料。從效能角度和成熟案例這兩方面來看，經歷過大型活動考驗的資料庫產品，OceanBase較為出眾，已經穩定支撐了十年的“雙11”活動，並經過支付寶、網商銀行等的驗證。而且在效能測試時，達到了8000 TPS（每秒事務處理量）。

**由於雲南某銀行是在傳統的核心繫統基礎上使用分散式資料庫。因此在綜合考慮後，認為OceanBase是更適合的選擇。** 參與了此次資料庫選型的李建明總結了四點經驗：

第一，國產資料庫當前的產品和技術實力也在逐步提升，可以作為選型考慮的一部分。

第二，面對日益龐大的資料量，分散式資料庫是較好的選擇。

第三，選擇分散式資料庫時，考慮資料庫的ACID。

第四，考慮對應用的改造程度及相容度。考慮資料庫的效能、體量以及對硬體的相容度。

## 給 DBA 的七個成長建議

在採訪的最後，談及一名優秀的DBA應該具備哪些素質或能力時，李建明根據自己十多年的職場經驗，分享了他的看法並給出了七個建議：

1. **具備紮實的資料庫理論功底。** 比如資料庫系統的概論、資料庫的核心概念、分散式資料庫原理等，理論能為工作中的實踐提供宏觀指導。

2. **熟悉軟體開發基礎知識和技術架構。** DBA或許不需要寫好程式碼。但如果他不熟悉程式碼，比如不知道程式碼怎麼寫出來的、怎麼做負載均衡，怎麼連線資料庫，以及不清楚常見的框架，那麼他可能在排查問題時只會說“我覺得資料庫沒有問題”，更不能站在全域性角度保障系統的穩定性。

3. **熟悉作業系統的操作及效能調優。** 資料庫最終還是要跑在作業系統上。對於作業系統的操作熟練度可以透過日常工作積累，而對於效能調優，可以透過閱讀官方文件中的說明來掌握，比如瞭解引數的意義和修改引數會帶來的影響，並在日常工作中多動手。

4. **熟練的資料庫運維操作。** 尤其要經過高併發、大資料量的洗禮。操作的熟練度更多是靠量的積累。至於能不能碰到高併發場景，由所在企業的業務決定。比如支撐小的業務量的Oracle資料庫，很多時候按照預設引數就可以執行得很好。DBA不會遇到較大挑戰，頂多是擴充套件儲存空間。因此難以積累這方面的經驗。

5. **越是難懂的理論，越應該努力掌握。** 對於眾多的技術知識，先做到學會其中一個知識點並達到一定深度後再橫向發展，如果你熟悉多項技能，且每項技能只停留在表層，那麼你在技術領域很難到達高層次。

6. **保持對知識的好奇心，堅持終身學習。** 對於技術人而言，想學習IT理論可以閱讀技術書籍；有針對性地學習系統的實操經驗可以用極客時間；學習專業領域的技術知識，可以閱讀廠商的官方文件；遇到“疑難雜症”時可以瀏覽CSDN；對於學科類與常識性的內容，就用得到App；研究強理論、學術型的知識可以翻看論文。

7. **培養自己的逆向思維和結構化思考能力。** 打破思維慣性想象多種可能性，尤其是向兩個極端方向去思考。不斷問問題，推翻自己的假設並驗證新的假設。

如果能給年輕時的自己一些建議，李建明表示**“吾生有涯而知無涯，要捨得放棄，找到自己最感興趣或者最擅長的方向，下笨功夫、練就必殺技。還要多學一些跨學科的基本原理，拓寬自我的知識面，提升多維思考能力，並且要勤于思考、有計劃的多動手。”** 與眾多資料庫從業者共勉。

------

### **關於作者**
**李建明**

目前在雲南某銀行擔任資訊科技部運維中心經理。擁有系統分析師、Elasticsearch認證工程師、Kubernetes認證管理員、DevOps Master、Oracle認證專家、OceanBase認證專家等資質。

【DBA100人】李建明：一名普通DBA的14年技術之路與成長智慧

相關文章