如何落地資料庫智能化運維？

本文根據周亮在2018年5月12日【第九屆中國資料庫技術大會(DTCC)】現場演講內容整理而成。

講師簡介：

周亮，美創科技運維服務中心總監，中國南方Oracle用戶組聯合發起人，ITPUB論壇管理版版主，Oracle ACE/OCM，《Oracle DBA實戰攻略》作者。

文章摘要：

Oracle 18c推出自治資料庫概念之後，將資料庫智能化運維推向了一個新的熱度。本次演講結合多年運維實踐經驗，接地氣地談談資料庫智能化運維常見的誤區是什麼?包含哪些基本要素?如何落地?

正文演講：

首先，我們先來看一下智能化運維的發展趨勢。第一個階段是無序化運維，雖然很多大的甲方公司基本不存在這個問題，但是乙方公司或者是小型甲方公司都有這個問題，運維全靠人，沒有規章制度，也沒有很好的梯隊建設。第二個階段是標準化運維，這個階段除了人員的增加，更重要的是要有工具和文檔的積累。第三個階段是自動化運維，即讓機器干機械的事。什麼是機械的事?就是重複勞動，例如安裝、部署，甚至是某些監控報警和彈性擴容。這裡的彈性擴容指的是當空間和資源不夠了，我們去補充添加，而這些操作都是一些可控的機械化動作。第四個階段是智能化運維，雖然現在關於智能化運維的討論很火，但是客觀來說，目前絕大多數公司還處於理論階段。

以我們公司為例，目前維護的Oracle資料庫大概是5000套左右，而我們的Oracle DBA團隊在五年前是五六十人左右。5年期間，公司業績以每年翻70%左右的速度成長，而公司業績的成長、客戶量的增加勢必會帶來一個問題，那就是需要擴大團隊規模。但是，我們在業績翻番的時候，團隊成員數量也沒有增加。為什麼呢?因為我們的運維工作一路從標準化過渡到自動化再到智能化，人均產值一直在提升。

無序化運維高度依賴工程師價值，所以無論是甲方還是乙方都會碰到一個問題，那就是該崗位的人離職了怎麼辦呢?我經常會碰到這種情況，十幾年前的一個系統沒人敢去動它，因為之前維護的人離職了，該系統就一直跑在那裡，Oracle資料庫甚至還可能是跑在8i階段。

師傅領進門，修行在個人。幾乎沒有任何一個師傅會是他在那兒敲命令，讓你在旁邊看著，再加上沒有文檔、流程等制度化的東西可以給到新人，讓新人只靠個人去成長，速度是很慢的。

人不夠了?招!當公司業績在走上坡路的時候，幾乎每個部門都會面臨缺人的情況，如果每個部門都去找老闆申請，那麼老闆可能會很厭煩。剩餘價值怎麼剝削呢?：)

標準化運維和自動化運維靠的是流程、制度、文檔和工具去落實。例如實時監控、日誌分析、快速部署、彈性擴容、故障處理等都有很多的重複勞動，只靠人來運維的話，可能分身乏術，但如果依靠機器去部署、處理、巡檢，那麼就能解放很多勞動力。

智能化運維，簡單來說就是讓機器幹人的事。以我們公司為背景介紹，很多甲方客戶的資料庫都是可以上雲的，這意味著其網路是可以打通的，所以，為了最大的復用DBA價值，我們推出了遠程DBA。

在網路打通之後，客戶的一些高級信息都會實時推送到我們二線DBA的郵件、微信以及手機客戶端。我們成立了一支二線DBA團隊，專門處理這些事情。因為這些運維日誌來自於五花八門的客戶，包括銀行、公安、醫療、社保等等，所以收集上來之後我們會做一些機器學習，再結合每套系統的業務節奏，我們就可以提前預知哪些資料庫或者哪個業務模塊可能發生問題或者說即將發生問題。

大屏監控是我和我團隊最近一年來一直在琢磨的東西。現在80%的監控都是以結果為導向，比如當空間不足了，監控報警。當CPU資源率達到90%了，再給一個報警。但其實監控不僅僅是給運維人員用的，更是給小白用戶用的，因為他們不精通資料庫，所以才需要去看監控。

但是這裡就又出現了一個問題，既然用戶不太懂資料庫，那麼只告訴他一個結果是沒有用的。所以我們想設計一張簡單易懂的大屏，就算做不到大家都能看懂，至少也要有80%的人能看懂。因此，我們的大屏不是以結果為導向，而是以輸入輸出流程及時間模型的角度聯動展示各項指標。

監控大屏以過程為導向，例如CPU資源使用率達到100%時，那麼大屏顯示出問題的環節，如在SQL執行的生命周期中，明確指出SQL哪個環節出現了問題，甚至可以聯動的顯示出受影響的各個環節。當然並不是所有的問題都會在大屏里顯示出來，大概會涵蓋80%以上的常見資料庫故障。

五大健康指數是最醒目的一個環節。第一個是可用性，這張大屏主要是針對Oracle，不過SQL Sever、MySQL除了一些技術實現細節，概念方面是通用的，如服務、監聽、實例、表空間等。

第二個是性能，性能指標沒有一千也有八百，如何選擇一個指標去反映數據的性能好壞呢?我們思考了很久!一般情況下，我們讀取數據都有個過程，如從磁碟上讀上來，再讀到內存裡面，從內存裡面讀數據塊的過程就叫邏輯讀。資料庫本質上就是一個存數據和讀數據的過程，存數據之前要先把數據塊讀上來，這對Oracle來講就是一個邏輯讀。衡量邏輯讀也有兩個細化指標，一是邏輯讀的時間，正常情況下單個邏輯讀的時間是幾納秒，如果出現了幾十倍的上升，那麼一定是出現問題了。二是邏輯讀次數，如果邏輯讀次數急劇上升，那麼也肯定是出現問題了，應用發生了變化或者是SQL的執行計劃發生了劇烈變化。

第三個是錯誤，相信在所有的告警里，大家最關心的就是錯誤，我們會推送資料庫運行過程中的錯誤到大屏。

第四個是變化，資料庫發生問題了肯定是來自於變化。所以我們在監控里將變化作為一個重要因素放入其中。資料庫中的對象有沒有變多，許可權有沒有變更，空間使用有沒有變高等等，一旦這個庫發生變化，我們就會把它投到大屏里。

最後是可靠性，也就是備份，因為一般的生產庫肯定是有備份或者災備的，所以我們也會選擇最重要的幾個指標放到大屏上。

SQL生命周期監控，SQL生命周期可分為登陸、解析、執行、提交四個階段，所以我們把整個庫的性能也剖析成四個環節，每個環節分別進行機器學習。因為每套系統的業務結構都不一樣，而個人經驗又很有限，盲目判斷很容易出問題，所以需要機器學習去動態學習每個業務系統的節奏。

以執行環節為例，需要用執行次數和每次執行的時間去衡量這個環節是不是有問題。如果通過多個業務周期的學習，執行次數和時間是相對固定的，那我就認為這是個正常值。如果突然在某個業務中某個指標超出這個正常值的範圍，那我就認為這是出問題了或者是即將出問題。

通過變化和比較，能夠直觀凸顯性能瓶頸。

資源關聯分析，主要是查看我的資料庫資源是不是快要不足了?做資料庫DBA的都知道資料庫資源包括processes、session、DB files和jobs，而我們經常碰到的資料庫性能三大資源鎖是Mutex、Latch和Lock，主機四大資源是CPU、內存、存儲和網路。

這是大屏的細化圖，除了上文提到的機器學習部分，整個模型過程中都需要去強化訓練。例如在執行階段的執行數和執行時間，也有很多其它環節需要去學習。

機器學習有什麼用處?風險異常預測是老生常談了，這裡就不再展開講了，我們談談另一個用戶為決策提供依據。在不改變業務的情況下，DBA可以知道下個時刻，庫空間有多大?按照這個趨勢發展什麼時候資源會不足?什麼時候需要準備擴容?

因為我們的客戶量比較大，所以涉及到庫的類型也比較多。不過，資料庫版本雖多，但是萬變不離其宗，它們肯定是運行在小機上或者X86上，採用的硬體都差不多。在我們的數據積累過程中，發現很多廠商的硬碟故障率並沒有他們標榜的那麼好。從上圖中，我們可以看到，機器剛剛運過來時，可能因為路上有顛簸或者其他原因，故障率是最高的，而一個月之後故障率就會下降，當到了一定生命壽命周期之後，就又上升了。

得到了這種趨勢，我們就可以指導用戶存儲上線的時間。如在第一個月最好是進行跑批等測試，當測試沒問題了之後，再上線。這樣的話上線之後會穩定很多，這就是一個經驗+數據指導用戶決策的很好例子。

日常智能巡檢，很多用戶都會去做，但我們不同的地方是加入了機器學習的成分。大家都知道腳本是死的，一套腳本跑遍所有庫，給出來的建議肯定是有問題的。而且資料庫數量很多的情況下，人工寫巡檢報告也是很大的工作量。

所以，我們的巡檢結合了某些指標進行動態的採樣、動態的分析、動態的調整，甚至還可以自動書寫巡檢報告出來。巡檢報告並不是巡檢結果的一個簡單展示，還需要做一些智能化的建議。自動巡檢報告完成之後，DBA再進行人工審核，並給出自己的建議，形成最終完整的巡檢報告。

上圖是我們巡檢平台的截圖。

智能性能解析也是提供給小白DBA使用的，這個功能的靈感來源於醫院體檢。醫學專業術語很多，也很複雜，但是體檢報告大家都看得懂。為什麼呢?因為體檢報告會在各項數值之後都會標明正常、過高或過低。

同樣，我們也可以把它應用在我們的AWR報告中。一般來說，AWR報告都會有幾十頁，如果SQL很多的話可能會達到上百頁。如果是一個新手DBA去看這個報告，可能無從下手。但如果我們開發這樣一個功能，它把AWR報告上傳之後，我們把每個環節都幫他解析掉，並反饋給他一份新的報告。這份新報告中包含了所有的問題，甚至是哪些SQL是什麼問題。而且如果平台能連到你的資料庫，我還可以給出建議這條SQL如何改。

這對小白用戶來說簡直是大喜訊，不僅把長篇大論的幾十頁AWR報告濃縮成幾頁的新報告，而且還可以簡單明了的看到問題出在哪裡，甚至可以根據建議修正錯誤。

故障處理，我們已經能自動解決空間之內的容量故障。但是 Oracle報一個600錯誤或是其它稀奇古怪的錯誤，想要依靠機器或者軟體把它解決掉或者分析出原因，難度實在很大。而且Oracle是一個商業化軟體，版本更迭是難以避免的，而這對我們來說就意味著要始終追著Oracle的屁股跑，很明顯，我們沒有那麼大的精力投入其中。

在摸索階段我碰到了幾個問題，第一個是雖然我可以通過一定的趨勢去預測故障，但是可能有些故障並沒有納入到故障列表中，那機器還是解決不了;第二個是不同因素之間的干擾，不止是Oracle，其它資料庫也一樣都是並發性很強的資料庫，一個因素可能會影響到其它因素，導致一個故障像滾雪球一樣引發大面積的癱瘓。不同因素的干擾是一件非常痛苦的事情，不同因素有不同的因子，反映在機器學習里就有不同的變數，而且這些變數的權重還不一樣。

當前我們能做到的是什麼呢?首先是解決容量不足類故障。當空間、主機等資源不足了，可以自動去擴容。其次是保留故障現場。還有就是快速止損，很多客戶都有考核標準，例如在30分鐘內處理掉故障，那麼就不需要上報領導或者上級機構。所以，即使是一個在DBA看來很嚴重的問題，只要你能及時恢復，那麼對客戶來說就是小問題。

如何快速止損呢?通常的手段是重啟資料庫或者殺會話。但是這又帶來一個問題，資料庫重啟了，會話殺掉了，事後怎麼分析?現場破壞了之後，人為就很難進一步分析了。所以在引入快速止損時要先保留故障現場，也就是說在重啟資料庫之前，要把那個時刻的主機資源、空間資源、內存、進程等等資料都保存下來。而且保留故障現場必須要工具化，否則靠人工敲命令，時間很快就流逝了。

總之，快速止損和保留故障現場是必須用起來的一套組合拳。

快速止損是當前資料庫智能化運維領域中最易實現的，那麼現在有哪些快速止損的手段呢?不同的故障對應不同的止損手段。假設是監聽出問題了，那麼就要重啟監聽，但這個問題的關鍵是如何判斷監聽出問題了以及如何在監聽之前把這些狀態保留下來?這個話題有點廣，下次再說：)

其餘的常見快速止損手段還包括實例重啟、Kill進程、Kill鎖、空間擴容、主機資源擴容、固化執行計劃、閥值告警以及現場保存。其中，經過長期的實踐發現，資料庫自動化程度越高，執行計劃突變的概率越大，而執行計劃一旦發生變異的話，機器學習就要立即響應，通過調用調用響應時間正常值的執行計劃，把它固化掉，讓系統性能恢復正常。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！