運維團隊天天忙著應付各種異常，長久處于高壓狀態下。本文作者將分享這兩年他對一些運維問題的分析和團隊管理的方法。

[[228537]]

大家好，我是來自平安科技數據庫技術部運維團隊的劉書安，從 2014 年開始，配合平安集團的互聯網金融轉型。

我們運維的數據庫從單純的 Oracle 數據庫轉向多種數據庫的運維，當前管理的各類數據庫的實例已經超過了一萬個。在這種情況下，我們連續兩年保持了數據庫零故障的狀態。

事實上在之前，運維團隊也是天天忙著應付各種異常，長久處于高壓狀態下。之后經過我們團隊一系列的優化和改造，目前系統已穩定很多。這期間也確實發生了很多事情。

接下來就跟大家簡單介紹一下我們這兩年對一些運維問題的分析和團隊管理的方法，拋磚引玉一下。

問題解決

首先我們從這張圖說起：

[[228538]]

這個是扁鵲向魏王介紹他們三兄弟的醫術：

• 扁鵲自己是在病人病入膏肓時用虎狼之藥將對方救活。
• 扁鵲的二哥是在別人生小病時將人治愈。
• 扁鵲的大哥則是在病情未發時鏟除病因讓人避免生病。

在扁鵲看來，三個人的醫術排序應該是：大哥>二哥>扁鵲；但在世人眼里卻是：扁鵲>二哥>大哥。

我比較認同扁鵲的觀點，因為我一直都覺得 DB 的運維人員不應該只是背鍋俠，而是應該把自己當成醫生來對待問題，不只是關注問題的解決，更需要多關注如何避免問題的發生。

我們在數據庫異常時去解決問題，別人可能會認為我們是高手，能把問題解決好、事情處理掉。

但實際上這時的運維已經是一個被動式的處理，即便我們用了最快的手段去解決，故障已經發生了，可能還造成了比較嚴重的影響。

如果我們能提前發現這些問題并解決掉，就能避免很多故障和影響的發生。因此在我看來，運維相對高明的手段應該是：在做架構或設計時就把能想到的問題預先解決掉，確保系統的可拓展性和高可用性。

運維也應該多從架構的角度去考慮問題，并將這些問題提前解決好，而非被動地等待問題發生后才去解決。

接下來和大家介紹我們團隊解決的三個案例，以及之后我們通過什么方式避免問題的發生：

案例一

這是我們在 2016 年解決的案例，當時 Oracle 數據庫的版本是 11.2.0.4，這種數據庫使用 SPM 固化 TOP SQL 的執行計劃，確保系統的穩定。

當時異常的問題是，幾乎每次發完大的版本后，已有的功能都會多少受到影響，有一些語句的執行計劃會發生異常。

我們發現，絕大多數語句都和這個語句是類似的，中間有一個 SKIP SCAN（跳躍式掃描），很明顯可以看出它是一個輸入時間（對著用戶的），有一個范圍查詢。

所以我們當時就基本判斷問題出在這里了，使用的解決方案是通過重新固化執行計劃來選擇好的執行計劃。

接著就開始分析問題產生的原因。

對于索引跳躍式掃描而言，在一般情況下，如果運維索引的***個列沒有用到，當它開始使用到第二個列時，就只能用跳躍式的方法去進行一個索引掃描。

而在分析問題原因時，因為類似的語句比較多，我們當時在固化了幾十條后，發現還有源源不斷的類似語句出現，就考慮到問題可能并沒有那么簡單。

所以我們又進行了進一步分析，***發現可能是索引的統計信息有問題。于是我們就重新收集了索引的統計信息，至此，類似的語句問題才算是解決了。

但其實這個問題并沒有徹底結束：

我們在處理完后又重新分析了這個索引的問題，發現索引***列是一個空值，但不知道是誰在空列和輸入時間上建了一個符合索引，導致這個索引有可能會被使用。

發現問題后，我們就查詢了這個索引的訪問方式，看看是否全都是 INDEX SKIP SCAN。

后來發現，基本上訪問這個索引的語句都用的是這種索引跳躍式掃描，所以我們當時就把這個索引設置為不可用，后面把它刪除了。

類似的索引，我們當時處理了有三個，之后這個系統就沒有再出現這樣類似的問題。

SPM 也是一種固化執行計劃的方式，但為什么在這個庫里，SPM 會失效呢？

之后我們分析了它的原因：是因為每次發版本時，有可能會多查一些字段，導致語句發生變化。

SPM 這類的固化執行計劃的方式都和語句有強關聯，只要語句上有一個小小的改動，都會導致固化的方式失效。這也是每次更新版本語句都會發生異常的原因之一。

之后我們繼續分析，為什么這個時間索引有這種類似問題？

這是我們之前整理的一個案例分析的原因：我們在做索引的范圍查詢時，它的選擇率公式如下 ：

但是在不同情況下，比如這種右側索引，比如創建時間、更新時間、輸入時間，我們寫入數據都是用 sysdate 寫入的，那么它永遠都在索引列的右側，類似這種方式是往里面插入數據的。

然而我們統計信息的收集又不是一個實時收集的，主要是對一些大表，比如一個一千萬的表可能要到 10%，也就是 100 萬的 DMR 量；更大的表的DMR量會更大。

這就會導致我們的統計信息和當前的值永遠是過時的，就會產生下面的問題。

對于這三個查詢來說：***個查詢發生在有效范圍內，所以它可以反映出一個比較真實的數據；第二個查詢也可以反映一部分。

但第三個查詢就相當于完成一個超范圍的查詢，計算出一個很低的值，這樣就會導致我們的語句偏異常。

更坑的是在 OLPP 系統里，新數據查詢的幾率永遠比老數據的大，越新的數據被訪問的幾率越高，這也導致我們的語句每次都會出現異常的情況。

發現這些問題后，我們立即展開了一個行動，就是把數據庫里所有與時間索引相關的字段都提取一下。

然后定期修改索引字段上面的 HIGH VALUE，統計信息里面的 HIGH VALUE，就能避免出現這種問題。

如上圖所示，是一個范圍查詢的情況，即在一個索引前導列的區別，類似于我們在創建時間和 OWNER 之間建索引。

如果把創建時間放在前面，把 OWNER 放在后面就是***種情況；如果把 OWNER 放在前面，把 CREATED 放在后面就是第二種情況。

現在來分析這兩個不同索引的區別：

當我們把創建時間放在前面時，有一個很大的問題，我們通過時間字段去查詢時很難做到等值查詢，即不可能去發現每分每秒插入的值。

對于這種查詢，我們一般都使用范圍查詢，比如查一個月或一天、一周的數據。

所以大家可以看到，如果我在這個語句內查這一分鐘、這一天 DBMGR 創建的情況，在***個索引里它整個范圍都會涉及到，隨后取相關聯的三個值。

但是在第二個索引里，三個值是連在一起的，因為 DBMGR 是有序的，時間也是有序的，它們就可以完成只涉及到自己相關值的值。

這里面還有一些細小的區別：如果我先進行范圍查詢，后做等值查詢，對于這樣的索引，Filter 時就會多做一個 Filter 步驟。

但如果把這個順序調整一下，就不會有這種情況。所以我們在做這種符合索引創建的時候，就一定要盡量把等值查詢的放在前面。

之前有一個說法：在選擇符合索引的前導列時，要把選擇率比較低的值放在前導列。

但我們覺得這個說法是不完善的：比如對于一個時間字段而言，一天有 86400 秒，100 天就可能有 800 多萬的不同值，一年會有更多不同值。

可如果把這個作為前導列，有時候是不適合的，因為對它來說，有可能我們是需要查詢一天或一個月的數據，而一年有 365 天，或者說十二個月。因此更準確的說法應該是把查詢條件中選擇率低的列做為復合索引的前導列。

所以通過這個案例，我們就把運維問題的解決分成了三個步驟：

• 快速解決問題，確保應用恢復。對于運維人員來說，恢復應用是***位的。
• 看問題是不是重復性發生的。比如前面說的案例一，如果我們當時的處理方案僅是固化執行計劃，或是收集統計信息，你沒有辦法保證它以后不會再出現類似的情況。

如果我們使用的是收集統計信息的方式，可能再過一個月或兩個月，這種情況又會再次發生，所以根本的解決方案是找到這個問題發生的原因，確保這次問題解決后不會再復發。

• 避免問題，看這個問題是否屬于共性問題、其他庫里有沒有類似問題。如果有類似問題，就要形成一種規范，去避免這種問題的發生。

尤其是對于一些新的應用來說，只有當你制定規范、讓開發遵守后，后續才會減少類似問題的發生，不然就會演變成我們一邊解決問題，新問題又源源不斷發生的情況，***我們只能不斷地去解決這種重復發生的問題。

我記得之前有一個案例就是共性問題：當時是在一個實際的庫里，我們分析發現它存在內存泄漏的問題，但并沒有馬上開始處理，結果第二天另一個庫也發生內存泄漏，于是我們不得不緊急重啟。

當時我們分析出問題是由某一個 Bug 導致后，就搜索那個 Bug 相關的信息，發現早在兩三年前（2014 年）已經有同事解決了這個問題。

只不過在另一個庫里還打了相應的 PATCH 來解決問題，但就是因為沒有把這個問題推廣到所有系統里，排查是否其他庫也存在這個問題而引起的。

從那之后我們就特別注意這種共性問題，如果每個系統、每個問題都要發生一次，代價實在是太大了。

所以我們盡可能在發現共性問題后就解決掉，盡量排除其他庫也發生類似問題的情況。

案例二

第二個案例是一個版本為 12.1.0.2 的 Oracle 數據庫，每到晚上總會不定時地主機 CPU 持續到 100%，應用同時會創建大量的數據到數據庫中。

當時我們的應急方案是把這種相關的等待時間全部批量 Kill 掉，因為這些系統是在比較核心的庫里，基本上每個系統被 Kill 掉的進程有幾千個，代價還是比較大的。

后來這個問題發生兩次后，我們開始著手重點分析問題，通過 ASH 分析發現，出現這個異常等待是因為一個很簡單的語句—— SELECT USER FROM SYS.DUAL。

之后我們就通過這個語句來一步步關聯， 看到底是哪個地方調用的，結果發現是在一個應用用戶的登錄 TRIGGER 中的用戶判斷步驟。

這個 USER 是 Oracle 的內部函數，但就是這么簡單的一個語句，就讓整個庫都 Hang 住了。

然后我們開始分析原因，我們通過 ASH 發現該語句在我們恢復應用前有重新加載的過程。

當時我們懷疑是硬件導致的，就通過這種方式去分析，結果發現是在晚上 10 點時被 Oracle 的自動任務做了一個統計信息的自動收集。

收集完后，又因為它是一個登錄的 Trigger，用戶在不斷登錄，在做登錄解析時這個語句就沒辦法解析，所以才導致用戶源源不斷地卡在那里。

而應用是需要新建連接的，新建的連接又無法進到庫里面，就會導致連接數越來越多，全都卡在那里。***我們通過鎖定 dual 表統計信息的收集來從根本上解決這個問題。

案例三

第三個案例有兩個問題，但后來我們發現這兩個問題是由相同的原因引起的。

我們有一個數據庫是從 10.2.0.5.X 升級到 10.2.0.5.18 版本，升級后會不定時出現 cursor:pin 相關的一些等待。

其實出現 cursor:pin 是很正常的，因為這個數據庫的負載比較高，變化也較高，但問題是它是在升級之后出現的。運營認為這是升級之后出現的異常，我們就開始著手分析問題的原因。

第二個問題是我們在應急時發現的，有時異常出現時，某個庫里有些語句的執行次數會特別高，甚至 15min 能達到上億次，這對于一個正常的業務系統來說，出現這么高的執行頻率是不正常的。

之后我們就去分析這些問題，發現這兩個問題有相同的一些點：比如語句中間出現了個函數調用；比如說這個情況下，A 表如果訪問的數據量較大時，這些函數就有可能被調用很多次。

我們發現，有一個語句，它執行一次可能會出現十幾萬次的函數調用。如果在調用的過程中，關聯的那張表的執行計劃發生了變化，比如說A表走了一個全程掃描，那可能會出現幾千萬次的函數調用。

當時我們也總結了一些關于通過什么樣的方法去快速定位、是否是函數調用導致的看法。

在 Oracle 10g 之前確實沒有什么好的辦法，因為它里面沒有一個顯示的關聯，就可能通過代碼去掃描，去找對應的語句。

在 Oracle 11g 后會比較簡單一些，通過 AS 值相關的 TOP LEVEL SQL ID 就可以直接關聯到是哪個語句調的函數導致的問題。

這里還有一個問題是函數調用。因為它調用的函數可能都是特別快的，但次數又會比較高，性能波動可能帶來比較大的影響。

之前我們有一個案例就發生在月底高峰，我們當時發現某個數據庫中會出現很多 CBC 的等待，后來又發現有一個小表被頻繁訪問，那個小表就 100 多行數據，但可能它相關的語句每隔 15min 就調用了上千萬次。

其實這么高的并發下，出現這種 CBC 的等待是很正常的。不過因為它只有 100 多行數據，且都集中在一個數據塊里，所以才導致這個數據塊特別熱，就會一直出現這種 CBC 的等待。

于是我們就找辦法解決這個熱塊的問題，但又因為不能在月底沖業績時停運來做修改。

所以我們就想了一個方案：建一個 PCT FREE 99 的索引，把表所有列的數據都包含進去，確保每個索引塊里面只保留了一行數據，變相地把這 100 多行數據分到 100 多個塊里。

做了這個操作后，CBC 相關的問題被解決了，也順利地撐過了業務高峰期，但是第二天月初的報表發現又掉坑里了。

因為我們在每個月月初需要上報給監管的一個報表，這種報表是屬于一個長事務。

但是它在那個報表里面也是調了之前優化的那個索引，優化后的語句雖然降低高峰期 CBC 的等待，但因為它是要訪問 100 多個數據塊，單次訪問從 0.25 毫秒變成了 1 毫秒，相當于效率降低了 4 倍。

由于報表是一種長事務的處理，相當于那個進程比原來多花了一倍多的時間也沒跑完。

所以之后我們發現這個問題后，又不得不把那個索引給干掉了，讓它恢復原來那種狀態。

尤其是現在對 IT 的要求越來越高，時限的要求也越來越高，很多系統基本都是用這種敏捷的開發方式盡快地上線。

新系統上線有一個很大的問題就是剛上線時壓力都不會很大、負載也不高，但其實很多問題在開始階段被隱藏了。

等到真正發生問題時，負載高了或者壓力大了再去解決問題，難度就會比較大一點。

尤其對于數據庫來說，數據庫量小的時候，比如說 300、500M 的數據，這個表格怎么整改都很簡單，但等到這個表漲到 300、500G 甚至 1、2T 時再想去做這個表數據類的整改，難度就會大很多。

比如說，我們之前做分期表整改時會用這種在線重定義的方式，但對于一些比較大的表，幾百 G 甚至上 T 的表，再用這種在線重定義的方式，就會遇到各種各樣的 Bug。

后來坑踩多了，我們現在對于大表的分表改造就是先同步歷史數據級改造，后做一個數據增量，方法會復雜很多。

但其實如果在開始階段，我們對于這種大表就已經設計好它的分區，尤其在時間索引上，基于時間去做一個分區，可以避免很多問題。

為什么我們的歷史庫里有那么多時間索引？

很大的一個原因是有很多報表是基于時間去查詢的，比如說要查這一個月或者這一天新增的一些數據的情況，都需要通過時間的字段去訪問。

我之前就見過很多關于時間的索引，但***卻因為時間索引的特性，導致系統源源不斷地出現各種各樣的問題。

如果在設計階段把這些大表提前就設計成分區表，完全可以避免這些不必要的問題。

運維管理

因為各個公司具體情況不同，我接下來就簡單介紹一下我司關于運維管理的一些做法，給大家做個參考。

變更管理

相對來說，我們公司的變更管理比較嚴格，后續可能會更加嚴格。

變更管控

對于變更管控，比如在白天嚴禁做任何變更，工作時間內任何變更都不能做，即便是一些緊急或故障的修復，也是需要通過部門負責人確認、領導同意后才可以做的，確保風險可控。

變更流程

可能每個公司都有變更流程，但我們公司有一個比較特殊的地方。因為一些兼容數據庫的要求可能會高一些，流程管控的每個部分都要確保到位。

變更方案

我們的變更方案是每個人要提前去做評審和驗證，包括制定方案的同事和實施操作的同事，就需要變更實施人員提前在一個環境下做完整的驗證，確保每個步驟都是驗證通過的。

規范管理

架構規范

我自己之前在做架構師時，制定各種各樣的規范是一項重點的工作。可能是養成習慣了，現在也和大家一起制定各式各樣的運維規范。

但我自己感受最深的是：規范一定要有統一的標準，如果做不到統一就有可能會在后續產生問題。

比如我們之前有些開發測試環境不是那么規范，現在想改造做自動化時，發現根本就做不起來，因為每個庫的情況不一樣，自動化的腳本不可能適應所有情況來做這種標準化的改造。

把它弄成不標準是很簡單的，但要想把不標準的改成標準的，難度就大了，尤其是在我們已經形成習慣之后。

運維規范

在 2014 年前，我們做的是純 Oracle 數據庫的運維，因為之前建立的是一個傳統的金融企業，運維的都是 Oracle 數據庫，但 2014 年后我們逐步轉向了互聯網金融。

因此我們陸續研究了 MySQL、PG、Redis、MongDB、SQL Server、HBase 等 7、8 種數據庫，在運維過程中遇的坑就會比較多。

最初有很多標準，但沒有一個是***的實踐，很多也是根據業界、自己的經驗制定出來的；還有各種不同的數據庫里，不同的團隊制定了不同標準，***就有各種各樣的標準了。

所以我們在運維中會發現各種各樣的問題，***要強制去做這方面的規范整改。

而且，之前的標準大部分都沒有經過大規模使用和大規模負載的驗證，很多標準并不那么統一、規范和有效。

因此，我們在運維過程中對于這種規范，還是在不斷地去優化和改進，畢竟很多情況在沒有遇到時，你真的是沒有辦法去解決這個問題。

規范優化

舉個例子，最初我們并沒有規定 Redis 一定要和應用放在同一個網絡區域，但隨著 Redis 的負載增加，我們發現防火墻已經承受不了。

當時平安的 WiFi 剛上線不久，但關于 Redis 的訪問，幾個實例每秒都有高達上萬次調用，整個防火墻都撐不住了，還差點導致一個比較嚴重的故障。

在解決這個問題后，我們就制定了一條強制的規范：Redis 這種高并發訪問的數據庫，一定要和應用放在一起，不能有出現跨墻訪問的情況。

所以這個規范也是不斷去優化的，包括我們運維的一些標準。因為在最初創建標準時，我們可能會因為使用時間不長而考慮不到一些問題。

我印象比較深刻的是 MySQL 剛引入時的一個問題，對于軟件的版本沒有明確到小版本。

后來甚至出現有 MySQL 停庫時是 5.6.22 的版本，在維護完成后就被啟動成 5.6.16 的版本。

***是通過不斷地優化來確保我們的規范和實際是相結合的，避免這種問題的發生。

人員發展

團隊意識

關于團隊這塊，需要提升每個人在團隊中的作用，需要確保團隊里的每個人都是有備份的。如果發展成離開誰都不行，那對團隊的整體發展來說是不正常的。

所以我們在安排工作時，對于比較重要的工作，我會盡量不讓熟悉的同事重復去做，而是盡量讓一些不熟悉的同事參與去做。

之前每走一個資深成員，都會明顯感覺到團隊的整體技能或知識少了一塊。為了避免類似問題的發生，從 2017 年開始我們就制定了一些策略，讓大家做知識技能的分享，每周抽取兩個下午，每個下午抽取一到兩個小時做分享。

另一個策略是技能的積累，即把我們在工作中遇到和解決的一些問題都錄入問題管理系統。

這樣做有兩個好處：

• 可以把重復的問題記錄下來，因為我們想要去分析哪些問題是重復發生的、哪些是有共性的，就需要有一個這樣的系統去拉對應的問題清單，***去解決問題。
• 即便人員流失了，他們之前解決的一些問題和技能也能讓團隊其他人發現，不至于每走一個人就留下一個坑。

所以我們是通過這種手段來盡量避免人員流失或變動給團隊帶來的一些問題。

但說到底，這種事這是沒辦法完全避免的，因為數據庫運維有一定的復雜度，需要依靠不斷地發生故障、解決故障，包括一些人為失誤來提升。

權責分明

我們的輪班人員是 7×24 小時，即上三班的方式來輪班的。之前團隊有一個比較嚴重的問題，當一件事情發生了，輪班人員有可能將問題交接給下一班次；或是升級給其他人后，就覺得與自己沒有關系了。

還有就是風險意識不強，有一些操作沒有評估過影響就開始在生產庫里操作。

當時我們也發生了不少問題，后來在內部重點提升兩點意識：責任人意識和風險意識。

首先你需要在生產做措施前，確保要做的操作會有什么影響、導致什么后果，不能在做完后才去想這個問題：比如說我們現在每天變更，都需要提前把腳本和手冊做好，讓值班人員熟悉。

操作會有什么后果？后續有什么異常會發生？應對方法又是什么？……這些都是需要提前評估好的。

技能提升

關于技能提升，雖然必要的培訓是必不可少的，但我們認為關鍵還是要靠自己的學習、理解和在實踐中的積累，并沒有什么好的捷徑去實現，大多時候還是要通過不斷地解決問題、發現問題甚至包括犯錯的代價來提升的。

[[228539]]

 

劉書安，平安科技數據庫技術部運維團隊經理，當前任職于平安科技數據庫技術部運維團隊，有十余年的數據庫管理經驗，有多年數據庫架構設計和運維管理經驗，熟悉性能調優和故障處理。目前主要負責平安科技數據庫運維的管理工作，團隊負責運維的數據庫種類包括 Oracle、PostgreSQL、MySQL、Redis、MongoDB 等多數數據庫的運維管理工作。