本文作者：林曉斌，網(wǎng)名丁奇，騰訊云數(shù)據(jù)庫負責人。林曉斌，網(wǎng)名丁奇，騰訊云數(shù)據(jù)庫負責人

今天給大家分享上周在 Techo 開發(fā)者大會上做的一個演講主題：數(shù)據(jù)庫智能時代和DBA的職責演進，既然把現(xiàn)在稱為一個新的時代，我們要順便把以前的時期也分一下，當然這個僅代表個人觀點。

在我看來，數(shù)據(jù)庫運維經(jīng)歷了四個大的階段，前面三個我分別稱為石器時代、工具時代、專家時代。

在大約2008年及之前，還少有公司有專門的DBA團隊，那時候都統(tǒng)一在OP范疇。我記得那時候寫應用，如果涉及到需要數(shù)據(jù)庫， 我的發(fā)布步驟里面，還要包含數(shù)據(jù)庫的安裝步驟。然后op同學就按照安裝命令一行行執(zhí)行。

數(shù)據(jù)庫很多時候被當做應用程序的本地存儲，用來替換更早之前，程序員需要自己維護的本地文件存儲。研發(fā)要自己確定整個機器的內(nèi)存分配，當然也是因為那時候單機的內(nèi)存很小。我記得我要在3G的可用內(nèi)存里，分配好應用進程和MySQL分別占多少內(nèi)存。數(shù)據(jù)庫也被當做一個本地進程一個監(jiān)控，跟應用服務器上的應用進程、agent等統(tǒng)一對待。所以什么線程監(jiān)控、死鎖監(jiān)控，還都沒有。慢慢地數(shù)據(jù)庫的服務開始轉給OP，那時候的工作甚至還包括搬機器。

所以我們說，這是石器時代，當DBA特別需要體力。不止是上服務器，查問題也是，一個個進程看過去，那時候故障排查的資料也不多，很多現(xiàn)象最后陷入到數(shù)據(jù)庫內(nèi)核原理那一步，就變成無頭公案。

后來，數(shù)據(jù)庫越用越多，維護數(shù)據(jù)庫的工作就給了專門的團隊，DBA團隊才開始慢慢成為中型公司的標配。懶惰促使技術進步。每次安裝數(shù)據(jù)庫、遷移、升級都要一點點執(zhí)行，可受不了，于是自動化腳本、工具、crontab就開始。當然由于DBA團隊多是從op出身，操作還是很規(guī)范的，雖然腳本、工具多，卻也不會亂。但是每次操作都要登到服務器上，很多窗口都是黑色背景。

在我印象里，這個工具時代的主要特征，就是黑屏。要看個線程狀態(tài)，上主機執(zhí)行show processlist；要重啟實例，上主機mysql_admin ；MySQL進程crash了，上主機，gdb掛core文件，那個時候其實已經(jīng)開始凸顯專家的專業(yè)性，但是為了看不同的信息，要到主機上執(zhí)行大量的命令，每個專家的查問題的習慣思路也都還不一樣。

現(xiàn)在大家流行說devops，其實反過來，在很早之前，op和DBA就先實現(xiàn)了opsdev，也就是運維研發(fā)。他們是第三個時代的締造者。

從基本的實例生命周期管理開始，再到實例監(jiān)控，再到實例集群監(jiān)控、大盤監(jiān)控，這個時代的特征之一是:agent林立，要采集各種信息，從主機信息、到進程信息，cpu、io、load這些算是通用監(jiān)控了，對于每個不同的數(shù)據(jù)庫，又有數(shù)據(jù)庫內(nèi)的監(jiān)控，比如MySQL總是要監(jiān)控增刪改查命令數(shù)，讀寫io次數(shù)等，而redis更關心mget這類吃cpu的大操作的次數(shù)。同時數(shù)據(jù)可視化技術直接造福DBA。監(jiān)控數(shù)據(jù)幾乎直接跳過原始數(shù)據(jù)階段，進入可視化狀態(tài)。為了收集數(shù)據(jù)并快速展示，消息隊列也成了運維系統(tǒng)的標準組件之一。這些數(shù)據(jù)被從agent采樣，通過消息隊列發(fā)到存儲服務器，然后再可視化展現(xiàn)出來，到web頁面上，背景往往是白色的，因此這個時代的特征之一，就是白屏化。

當一個公司的DBA團隊有了一個統(tǒng)一的白屏系統(tǒng)后，問題診斷的模式開始固定。

舉個例子，當然，這些都是示意圖。如果你看主從延遲的監(jiān)控曲線，看到這種圖形，就是在某個時間點后，延遲曲線變成一個45度的線段，然后過一段時間又幾乎垂直地恢復，那就是從庫應用線程被堵住了。這往往是因為從庫上有查詢堵住了主從同步線程的更新。

再舉個例子，如果你看到一個主庫的多個從庫的主從延遲，都以類似的曲線上升，這往往表示的是主庫的更新特別多了。這時候有經(jīng)驗的DBA會去看主庫的各種更新類監(jiān)控項。比如這個例子，主庫的InnoDB_rows_updated出現(xiàn)類似的突增，那基本就確認結論了。

再看下一個，slave1的延遲增大， 同主庫的其他slave的沒有明顯異常。這就說明不是主庫的原因了。而且這個曲線也不是45度直線，表示不是事務堵住。這種情況一般就是slave1上的資源消耗過大。

這樣下一步我們就是去看cpu占用，果然有增大，然后再看cpu消耗相關的指標，比如這個例子里，讀數(shù)據(jù)行數(shù)增加很多，那就是查詢變多，或者慢查詢多，也能很快得到結論。這些是在黑屏的時候很難直觀的看出來的，也就很難很快得到答案。

也就是說，白屏化帶來了三個方向的改變，催熟了專家時代。

首先，解放后端。

很多操作只需要按一下按鈕就完成，這完全可以由業(yè)務使用方自己來做。比如申請實例、升級實例、SQL審核等等。這樣就把DBA從日常的操作中解放出來。工具時代工具即使再方便，也不會允許研發(fā)直接上數(shù)據(jù)庫服務器上去執(zhí)行工具。

其次，形成定式。

在固定的圖形界面下，這些查找問題的經(jīng)驗，開始被定式化。那些“一目了然”的分析和解決問題的方法，開始被當做套路使用，而且成功率還挺高。定式化的方法，特別適合積累和傳承。

第三，反饋迭代。

白屏能提供給專家數(shù)據(jù)的，能夠快速定位問題；白屏不能提供的，就會頗費周章。于是作為跟DBA同一個團隊，甚至于是同一撥人的運維開發(fā)，開始對監(jiān)控系統(tǒng)快速升級迭代，這個過程是正向循環(huán)，在一個團隊里飛快地積累解決問題的經(jīng)驗。

因此這個時代的特點是：

• DBA的數(shù)據(jù)庫經(jīng)驗和運維經(jīng)驗，得到快速積累，

• 數(shù)據(jù)庫專家經(jīng)驗跟業(yè)務研發(fā)經(jīng)驗分離，DBA的經(jīng)驗在解決數(shù)據(jù)庫問題時成為稀有資源，個人價值被具象化到跟業(yè)務掛鉤；

• 經(jīng)驗易于積累和傳承，DBA團隊成長很快。

• 一個快速積累處理問題能力的團隊，很容易形成口碑。這對團隊也是一個正向的反饋。

雖然這個過程也經(jīng)常會碰到一些無奈的情況。比如偶爾會被問到一些很簡單的問題，比如在白屏化掩蓋了一些細節(jié)情況下，還是需要直接登錄到服務器上去看更詳細的數(shù)據(jù)，再做分析。因此這個過程偶爾挺累，但是總體都在把控之中，又有技術的稀缺性，而白屏化加分析討論又能快速定位和解決一些簡單的問題。總體來說，過得還是比較舒適的。

專家經(jīng)驗持續(xù)輸出，當然問題也越來越復雜。尤其是公有云數(shù)據(jù)庫場景下，用戶的使用場景更加不可控。在公司內(nèi)部服務的時候，DBA專家，是可以限定業(yè)務研發(fā)使用數(shù)據(jù)庫的方式的。比如存儲過程不能用、觸發(fā)器不能用、join不能太復雜、DDL等操作必須后端統(tǒng)一處理等等，而在這種限定使用模式下，首先就不太容易出問題，其次就算出了問題，查明和解決問題的方法，也在專家團隊的固定模式，也就是套路中。

但是在云服務就不是這樣了。數(shù)據(jù)庫的用戶是客戶的研發(fā)團隊。一個云MySQL或者云redis的用戶，總會按照他們自己的習慣，來使用數(shù)據(jù)庫服務。而用戶反饋問題的時候，往往現(xiàn)場很快就結束了。這時候傳統(tǒng)的方法是開始碰到問題。由于沒有現(xiàn)場，查問題非常麻煩。另一方面，客戶的應用端到云數(shù)據(jù)庫服務端，網(wǎng)絡很多跳，鏈路復雜，追查問題很難定位。

在這種情況下，全日志和全鏈路監(jiān)控，就應運而生。全日志也成為審計日志，是把數(shù)據(jù)庫上所有的操作都記錄起來，包括增刪改查，登錄行為等等。這樣理論上可以復現(xiàn)任何時刻的現(xiàn)場。當然由于這種粒度的數(shù)據(jù)量很大，所以往往只能保存一段時間的日志。審計日志可以用來快速定位數(shù)據(jù)庫內(nèi)的問題。

數(shù)據(jù)庫外的呢？

由于鏈路更復雜，鏈路上每一個環(huán)節(jié)出點問題，導致連接失敗、查詢變慢等等，客戶都會認為是數(shù)據(jù)庫出問題了。這類問題首先是特別難查。作為DBA，客戶反饋查詢語句慢了，第一時間就會去看sql寫法對不對、表索引是否合理等等。需要排除掉很多可能，才會最終懷疑到網(wǎng)絡上。這就影響了排查問題的時間。而網(wǎng)絡由于有多跳，容易最終查不到確切結論。全鏈路監(jiān)控就在這樣的場景下出現(xiàn)。不論是保存日志里所有日志，還是鏈路上所有狀態(tài)，都需要一個大規(guī)模、壓縮率要很高、寫入速度足夠快的存儲系統(tǒng)。數(shù)據(jù)量大以后，就可以在數(shù)據(jù)上做各種預分析操作。

自然的，這個系統(tǒng)就會進化為下面的狀態(tài)。

• 簡單的問題能夠自動處理；

• 復雜的問題提供建議；

• 疑難問題定位線索，提供給專家準確的信息；

騰訊云數(shù)據(jù)庫團隊研發(fā)的DBbrain，就是面向這樣的能力構建的系統(tǒng)。這些能力具備以后，就有了更進一步的能力，提前發(fā)現(xiàn)潛在問題：我們知道很多業(yè)務，尤其是電商類的業(yè)務，在節(jié)假日、運營活動前都會封網(wǎng)一周或更久，也就是說，其實真的會導致高峰期出問題的哪些慢查詢、哪些不合理的表結構，是在高峰之前一周，就已經(jīng)在線上的了，只不過處于潛伏狀態(tài)。

因為壓力不大，這些潛在的危險查詢，并沒有造成影響，甚至連慢查詢都不算。這個潛伏期，其實也是發(fā)現(xiàn)問題的緩沖區(qū)。DBbrain可以在這個緩沖時間內(nèi)，發(fā)現(xiàn)潛在的性能和使用問題，通過給出建議的方式，提示客戶的DBA和研發(fā)做優(yōu)化，起到治未病的作用。

當然一旦操作簡單以后，將監(jiān)控、建議和操作集中在移動端，就更容易了。運維同學不用在婚禮的時候還掏出筆記本，登錄vpn解決了，一些簡單的操作，可以在手機端直接完成。這也是DBbrain結合微信的優(yōu)勢，會提供給運維的便利。

那么，到了智能時代，云數(shù)據(jù)庫+智能診斷系統(tǒng)，會搶了DBA的飯碗嗎？

今天我們分析了數(shù)據(jù)庫運維發(fā)展過程，大家可以看到，在前面的幾個階段，隨著工具越來越成熟，解放了一部分低價值的工作量，DBA的價值一直在提升。那從專家時代的白屏化，到智能時代，其實本質上，也是工具成熟，減少低價值工作，跟之前是沒有區(qū)別的。

從拼體力到做工具，通過更快的滿足業(yè)務需求，去掉的是搬機器的工作，去掉的是一行行敲命令的工作，聚焦于更高的效率；從工具化到成為專家，通過更快地定位問題，去掉的是登錄機器，執(zhí)行和工具的動作，聚焦于專家經(jīng)驗積累；到了智能時代，去掉了基本的性能優(yōu)化、問題發(fā)現(xiàn)工作，聚焦于復雜的數(shù)據(jù)庫問題，聚焦于業(yè)務架構，優(yōu)化架構設計，這個是更高的業(yè)務價值。因此我認為數(shù)據(jù)庫運維智能時代的關鍵詞是業(yè)務價值。

其實業(yè)務價值是貫穿于各個時代的，所有的工作都最終是服務于業(yè)務的。只是在智能時代，DBA對業(yè)務價值的貢獻，因為云數(shù)據(jù)庫和智能診斷工具，會凸顯得更加純粹。

公眾號后臺回復：techo，可以得到完整版 PPT 。

總結

以上是生活随笔為你收集整理的Techo 大会：AI 会替代 DBA 么？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。