> 小 T 導讀：作為薪水較為可觀的 IT 職業之一，DBA 貌似是一個門檻低、活還少的技術崗位，只要接受過相應的系統性訓練，應該就可以成功入門。但想要真正勝任這個崗位，實際卻並不容易。DBA 的工作到底是怎樣的？它的前景如何？想做好 DBA 又需要具備哪些能力？我們採訪了兩位有豐富工作經驗的 DBA 和運維工程師，下面一起看一看他們的感悟吧。

**DBA 的一天是怎樣的？**

> 分享人：濤思資料交付工程師 董延瓊
（注：本章節 DBA 特指運維 DBA）

本人不僅是一個在 IT 行業摸爬滾打~~（混吃等死）~~、兢兢業業~~（得過且過）~~十多年的從業者，也是一個有著近十年豐富工作經驗的 DBA~~（老油條）~~。在剛進職場的五年裡，我在一家中字頭下面的三產做運維，主機、資料庫都有接觸，後來被朋友“坑”去創業公司玩了三年 MySQL，再後來繼續給國字頭做了三年資料庫（Oracle）運維，現在的職場身份是時序資料庫（Time Series Database）TDengine 團隊的交付工程師。

鄭重宣告：那種一杯茶一包煙，一張表導一天的快樂日子，我根本就沒經歷過。

關於運維 DBA 的工作，其實和中醫治病的理念有點像，在此引用一下魏文侯問扁鵲三兄弟醫術的故事，很有意思。對話是這樣的：

> 魏文候問扁鵲：“你們兄弟三人，哪一位醫術最精呢？”

> 扁鵲回答說：“大哥醫術最精，二哥次之，我最差。”

> 魏文候又問：“那為什麼我沒有聽說過他們呢？”

> 扁鵲解釋說：“大哥於病視神，在疾病還未形成時就將其除掉了，大家都沒怎麼見過他治病，所以他的名聲傳不出家門；二哥治病，是在疾病剛剛萌芽時就治癒它了，大家都只見到他治一些不嚴重的小病，所以他的名聲也不出於鄰里之間；而我通常是等病發展到一定程度才發現，透過針刺血脈、投湯藥、割皮解肌來治病。大家都認為我擅長治療各種疑難雜症，因此聞名於諸侯之間。”

現在估計很多 DBA 都會有類似的想法。理想的工作就是每天處理一下小問題，調調優，防患於未然，爭取將大問題都掐死在搖籃裡，剩餘時間就是看看資料，提升一下自己，平平淡淡地“混過”每一天。但很不幸的是，如果真的抱著這樣的想法，那麼你離被裁也就不遠了，因為你在老闆眼裡就是個無所事事，混跡在職場中打醬油的“老油條”。

其實我們換位思考一下也就能理解了，如果你是老闆，一個員工整天沒啥正事，除了聊天打屁，就是上網看書，系統一年也沒有出現過啥大問題，身為老闆的你是不是也感覺這人力成本花的有點冤。

而與之相反的另一種情況是，你的員工每天忙忙碌碌，加班處理問題，好幾次重大問題都及時有效地解決了，避免造成更重大的損失。你是不是感覺這招人的錢花的還比較值，甚至年終還想發點錢鼓勵他再接再厲。

**轉到價值觀積極的一面，如果你是個積極上進~~（年少無知）~~的 DBA，每天應該怎麼安排自己的工作呢？**

其實和運維相關的工作，性質都差不多，不管是運維 DBA、主機工程師或網路管理員。說到運維，就一定要說一下墨菲定律（Murphy’s Law），放在運維領域簡直太有用了。

墨菲定律主要包括以下四方面：

- 任何事都沒有表面看起來那麼簡單
- 所有的事都會比你預計的時間長
- 會出錯的事總會出錯
- 如果你擔心某種情況發生，那麼它就更有可能發生

對應到運維領域就是：

- 簡單的小問題，可能是某個喪心病狂的程式設計師的大 Bug，一旦忽視，就可能把你盡心維護的資料庫搞崩；
- 備份恢復的時間，永遠都超過你所估計的時間；
- 高危操作通常都會出事（普通操作一樣有風險）；
- 如果你擔心庫掛了沒有備份恢復，那麼備份大機率不能用。

相應的應對措施則是：

- 刨根求底，每個小問題都搞清楚，不放棄任何隱患；
- 把計劃時間乘以 10，能多長就多長（把泡茶、抽菸、上廁所也算在內）；
- 提前做好預案的預案，提前為某個操作失敗想辦法；
- 每天檢查備份，條件執行多備幾份，反正儲存不花自己的錢。

**將以上四點貫徹到底，你就擁有了無比充實~~（累死累活）~~的運維 DBA 的一天。**當然事情也不是絕對，以上大部分內容都是在討論傳統的關係型資料庫，如 Oracle、MySQL、PostgreSQL 等，對於其它的諸如 InfluxDB、TDengine、TiDB 等新興資料庫就又另當別論了。

以 TDengine 為例（當然這種安裝包不到 100 MB 的 Database 通常是不配擁有專屬 DBA 的）：

- 安裝步驟不到三步
- 運維命令不超過 50 個
- 引數不到 100 個

DBA 除了升級、重啟，貌似就沒啥工作可幹了。

**DBA 的發展已經沒前途了嗎？**

> 分享人：濤思資料交付工程師 董延瓊

如果篤定地說資料庫 DBA 沒有前途，那可能有些武斷了。但某些 DBA 的前途確實渺茫了，比如 DB2 和 Sybase 的 DBA 們。可能有的小夥伴不太瞭解這兩個產品，要知道，DB2 當年的風頭還在 Oracle 之上。不禁要緬懷一句，“舞榭歌臺，風流總被，雨打風吹去”。

至於資料庫 DBA 這個新興的小鮮肉，說不定哪天也會被掃進歷史的垃圾堆。但還不是現在。

我們隨便開啟一個招聘網站，輸入 DBA 就可以看到招聘的職位，薪資範圍在 15~60K 之間，看起來還是蠻誘人的。

![](http://img.blog.itpub.net/blog/2022/08/09/a283d07e93e7a2f2.jpeg?x-oss-process=style/bb)

從涉及的資料庫產品來看，主要以 Oracle、MySQL、PostgreSQL 為主。僅從招聘資訊來看，資料庫 DBA 的“錢途”還是有的。但在這個“盛世”下，有人還在擔心資料庫 DBA 的未來發展，不過也是有跡可循的。

2018 年，Oracle 推出了全球首款，也是唯一一款自治資料倉儲——Oracle Autonomous Database Warehouse ，它可以用更低的成本為客戶提供更高的效能、可用性和安全性，帶來現代化的雲端體驗，為全面迎接自治時代成功奠基。

“自治（Autonomous）”是雲技術的一個跨越，它不僅可以在無需人工干預的情況下，對業務執行的設施進行自動更新、調整和修復，還能幫助企業節約管理成本、快速部署專案並顯著降低風險，為企業客戶帶來全新的上雲體驗。**這意味著 Oracle 已經開始搶它自己 DBA 的飯碗了。**

**不止是 Oracle 這種老牌資料庫廠商，新的資料庫廠商其實也在進行運維革命了。**新興的時序資料庫 TDengine 在其官網首頁中描述產品的特性時，提到了零管理：安裝、叢集幾秒搞定，無任何依賴，不用分庫分表，系統執行狀態監測能與 Grafana 或其他運維工具無縫整合。不論技術上如何實現，至少在理論上，已經致力於盡力減少運維工作了。

![](http://img.blog.itpub.net/blog/2022/08/09/d518135092e40181.png?x-oss-process=style/bb)

我記得之前上 MBA 時，老師組織過一場討論，論題是 AI 會不會取代大部分人類工作。我當時的觀點很明確，會的，因為這就是我們研究 AI 的目的。

最開始入職 IT 行業時，搞定一個系統上線是個非常複雜的工作，需要先將伺服器上架，再安裝相應的作業系統，還要配置網路、連線儲存，隨便搞搞就要一週的時間。發展到現在，阿里雲從下單到開通不到十分鐘，整個過程中的主機工程師、網路工程師、儲存工程師等古早職業都消失了。

要知道，阿里雲不止有云主機，還有云資料庫，你不需要再關心底層架構，只有付錢就可以了，甚至不需要進行維護，最多關心一下磁碟是否夠用，DBA 的工作就這樣被極大地簡化了。**如果從這個角度來看，資料庫 DBA 的前途確實堪憂了。**

**那麼已經是 DBA 的同學，或是剛成為 DBA 的同學應該怎麼辦呢？**不論任何職業，只要不想被淘汰，那就必須讓自己做的工作成為不可取代的那部分。

**那 DBA 有哪些工作是很難取代的呢？我們先來梳理一下 DBA 的工作內容：**

1. 業務建模：根據業務場景，設計庫和表結構
2. SQL 最佳化：對業務 SQL 進行最佳化，提升效率
3. 安裝部署：部署資料庫產品
4. 系統調優：調整資料庫引數，最佳化效能
5. 應急處理：處理緊急問題，如資料庫故障、資料誤刪除
6. 備份恢復：不需解釋

對於以上工作內容，第 3、4 項在雲環境裡已經沒什麼意義了；而第 2 項，對於擁有高階解析器的資料庫產品，如 Oracle 來說，也沒什麼必要了；第 6 項完全看實際需要，簡單的備份恢復自動化就可以完成，更定製化的則需要人工干預。

那麼現在來看，就只剩下了第 1、5 項工作必須要人工來完成了。每個系統所對應的業務場景都是獨一無二的，並不存在一個“包打天下”的統一的建模方式，**從這個角度來說，快速熟悉業務場景是 DBA 至關重要的能力。**

**只要是 IT 系統，不管設計的多麼智慧，都可能會出現 Bug。能夠深入瞭解產品、快速應對意外情況、及時提出解決方案的 DBA ，在此時就是最稀缺的。**

綜上所述，雖然目前資料庫 DBA 的前途和“錢途”都還是有的，但也不能盲目樂觀，還要不斷提升自己才不會被淘汰掉，追趕我們的不止是技術，還有“後浪”。

**想做好時序資料庫 DBA，需要具備哪些能力？**

> 分享人：濤思資料交付工程師 肖波

想勝任 DBA 這個職業，應該具備哪些必備能力？大家討論的比較多的大都是關係型資料庫的 DBA ，下面我會從時序資料庫角度來談下個人觀點。

- 持續學習的能力

時序資料庫是一個新的方向，它採用的技術架構普遍與關係庫不同。例如，在資料索引結構的選擇上，關係型資料庫大多采用 B+ 樹，時序資料庫則多采用 LSM 樹；而且結合時序資料的特點，時序資料庫多采用列式儲存方式。

以 TDengine 為例，它採用就是 LSM 樹，加上列式儲存、一個裝置一張表的設計，在應對物聯網時序資料的場景時就會很有優勢。如果你還停留在 B+ 樹的語境裡，那將很難理解這種設計的優勢和特點，高效運維自然無從談起。這種技術架構的差異導致技術實現也會有很大不同，DBA 只有不斷學習，才能掌握關鍵點，做好本職工作。

- 對計算機系統深入理解

目前資料庫系統大多執行於 Linux 系統上，一個合格的 DBA 不能只滿足於對計算機系統的一般性認識，還需要深入瞭解系統的工作原理，對記憶體分配回收、程式排程、網路管理等都要有深刻的理解，對如何分析、定位作業系統問題也要有深刻認識。只有做到這些，才能迅速定性、定位實際工作中遇到的問題。

- 深入瞭解儲存系統

目前的時序資料庫大多采用分散式架構，在分散式架構下如何保證資料的一致性、特別是海量資料的一致性是一個特別大的挑戰。傳統大資料平臺有利用 HBase 作為儲存系統的，新一代的時序資料庫有自研儲存系統的，也有采用開源的分散式儲存系統作為儲存方案的。作為一個 DBA，確保資料安全是最重要的工作，這就要求你必須深入瞭解所使用的資料庫的儲存架構，才能制訂出合理的資料備份、恢復、災備方案。

- 熟悉主流高階語言的資料庫介面及框架

時序資料庫的寫入吞吐一般比關係型資料庫要高若干個數量級，一般後者每秒寫入數百條記錄就算不少了，但時序資料庫每秒寫入經常要達到幾十萬，甚至數百萬條記錄。聚焦寫入問題上，除了資料庫本身的效能調優，還涉及到各語言聯結器、框架的使用方法是否正確。要想成為合格的時序資料庫 DBA，你需要對聯結器、框架非常瞭解。

當然，除了寫入，查詢是另一個重點。調優時序資料庫的查詢效能，除最佳化本身引數外，對主流語言框架如何構造查詢語句也要有深入瞭解，這會大大縮短很多複雜查詢問題的定位時間。

- 對數量級的敏感

隨著各行業的不斷髮展，海量的資料寫入、讀出帶來的問題和挑戰比起從前更加頻發，定性問題的關鍵是需要 DBA 對數量級有超過一般人的敏感度。除了 CPU 負荷外，磁碟吞吐量、IOPS、網路吞吐、PPS、佇列長度深度、各類耗時等都需要 DBA 反覆不停地比較、計算，直到找到問題的主要原因。對數量級的高敏感度可以大大減少問題定性、分析時間。

除了上述的能力加持外，DBA 最重要也最基礎的能力其實是——基礎知識牢固、邏輯分析能力強、思維清晰。很多人認為有 Oracle 的認證、微軟的認證很重要，我覺得那隻能證明他曾經具有一定的學習能力。一個 DBA 的能力強弱，具體體現在他定位、解決一個問題的速度，這裡面除了經驗以外，紮實的基礎知識、良好的訓練、科學的分析方法論才是可靠的“屠龍刀”。

**寫在最後**
如果你有志於成為一名時序資料庫 DBA，那你一定不能錯過 8 月 13 日我們在北京·昆泰嘉瑞文化中心舉辦的「TDengine 開發者大會」，本次會議上不僅會有多位基礎軟體領域知名大咖貢獻精彩演講與趨勢解讀，還會有金融、車聯網等行業知名企業分享資料架構升級經驗。此外，TDengine 3.0 版本也將重磅釋出，核心研發人員將首次對外分享創新思路，進一步加深你對時序資料庫技術實現和架構創新的思考。

------------

想了解更多 TDengine Database的具體細節，歡迎大家在[GitHub]( https://github.com/taosdata/grafanaplugin"GitHub")上檢視相關原始碼。
[![](http://img.blog.itpub.net/blog/2022/05/11/0fd59db1207fc97f.jpeg?x-oss-process=style/bb)](https://www.taosdata.com/?zh "![](http://img.blog.itpub.net/blog/2022/05/11/0fd59db1207fc97f.jpeg?x-oss-process=style/bb)")

DBA的一天是怎樣的？運維工程師告訴你答案

相關文章