數據庫智能運維探索與實踐

從自動化到智能化運維過渡時，美團DBA團隊進行了哪些思考、探索與實踐？本文根據趙應鋼在「第九屆中國數據庫技術大會」上的演講內容整理而成，部份內容有更新。

背景

近些年，傳統的數據庫運維方式已經愈來愈難於知足業務方對數據庫的穩定性、可用性、靈活性的要求。隨着數據庫規模急速擴大，各類NewSQL系統上線使用，運維逐漸跟不上業務發展，各類矛盾暴露的更加明顯。在業務的驅動下，美團點評DBA團隊經歷了從「人肉」運維到工具化、產品化、自助化、自動化的轉型之旅，也開始了智能運維在數據庫領域的思考和實踐。

本文將介紹美團點評整個數據庫平臺的演進歷史，以及咱們當前的狀況和麪臨的一些挑戰，最後分享一下咱們從自動化到智能化運維過渡時，所進行的思考、探索與實踐。

數據庫平臺的演變

咱們數據庫平臺的演進大概經歷了五個大的階段：

第一個是腳本化階段，這個階段，咱們人少，集羣少，服務流量也比較小，腳本化的模式足以支撐整個服務。

第二個是工具化階段，咱們把一些腳本包裝成工具，圍繞CMDB管理資產和服務，並完善了監控系統。這時，咱們的工具箱也逐漸豐富起來，包括DDL變動工具、SQL Review工具、慢查詢採集分析工具和備份閃回工具等等。

第三個是產品化階段，工具化階段可能仍是單個的工具，可是在完成一些複雜操做時，就須要把這些工具組裝起來造成一個產品。固然，並非說這個產品必定要作成Web系統的形式，而是工具組裝起來造成一套流程以後，就能夠保證全部DBA的操做行爲，對流程的理解以及對線上的影響都是一致的。咱們會在易用性和安全性層面不斷進行打磨。而工具產品化的主要受益者是DBA，其定位是提高運維服務的效率，減小事故的發生，並方便進行快速統一的迭代。

第四個是打造私有云平臺階段，隨着美團點評業務的高速發展，僅靠十幾、二十個DBA愈來愈難以知足業務發展的須要。因此咱們就把某些平常操做開放受權，讓開發人員自助去作，將DBA從繁瑣的操做中解放出來。當時整個平臺天天執行300屢次改表操做；自助查詢超過1萬次；自助申請帳號、受權並調整監控；自助定義敏感數據並受權給業務方管理員自助審批和管理；自定義業務的高峯和低峯時間段等等；自助下載、查詢日誌等等。

第五個是自動化階段，對這個階段的理解，實際上是「仁者見仁，智者見智」。大多數人理解的自動化，只是經過Web平臺來執行某些操做，但咱們認爲這只是半自動化，所謂的自動化應該是徹底不須要人蔘與。目前，咱們不少操做都還處於半自動化階段，下一個階段咱們須要從半自動過渡到全自動。以MySQL系統爲例，從運維角度看包括主從的高可用、服務過載的自我保護、容量自動診斷與評估以及集羣的自動擴縮容等等。

現狀和麪臨的挑戰

下圖是咱們平臺的現狀，以關係數據庫RDS平臺爲例，其中集成了不少管理的功能，例如主從的高可用、MGW的管理、DNS的變動、備份系統、升級流程、流量分配和切換系統、帳號管理、數據歸檔、服務與資產的流轉系統等等。

並且咱們按照邏輯對平臺設計進行了劃分，例如以用戶維度劃分的RDS自助平臺，DBA管理平臺和測試環境管理平臺；以功能維度劃分的運維、運營和監控；以存儲類型爲維度劃分的關係型數據庫MySQL、分佈式KV緩存、分佈式KV存儲，以及正在建設中的NewSQL數據庫平臺等等。將來，咱們但願打形成「MySQL+NoSQL+NewSQL，存儲+緩存的一站式服務平臺」。

挑戰一：RootCause定位難

即使咱們打造了一個很強大的平臺，但仍是發現有不少問題難以搞定。第一個就是故障定位，若是是簡單的故障，咱們有相似天網、雷達這樣的系統去發現和定位。可是若是故障發生在數據庫內部，那就須要專業的數據庫知識，去定位和查明究竟是什麼緣由致使了故障。

一般來說，故障的軌跡是一個鏈，但也多是一個「多米諾骨牌」的連環。可能由於一些緣由致使SQL執行變慢，引發鏈接數的增加，進而致使業務超時，而業務超時又會引起業務不斷重試，結果會產生更多的問題。當咱們收到一個報警時，可能已通過了30秒甚至更長時間，DBA再去查看時，已經錯過了最佳的事故處理時機。因此，咱們要在故障發生以後，制定一些應對策略，例如快速切換主庫、自動屏蔽下線問題從庫等等。除此以外，還有一個比較難的問題，就是如何避免類似的故障再次出現。

挑戰二：人力和發展困境

第二個挑戰是人力和發展的困境，當服務流量成倍增加時，其成本並非以相同的速度對應增加的。當業務邏輯愈來愈複雜時，每增長一塊錢的營收，其後面對應的數據庫QPS多是2倍甚至5倍，業務邏輯越複雜，服務支撐的難度越大。另外，傳統的關係型數據庫在容量、延時、響應時間以及數據量等方面很容易達到瓶頸，這就須要咱們不斷拆分集羣，同時開發訴求也多種多樣，當咱們嘗試使用平臺化的思想去解決問題時，還要充分思考如何知足研發人員多樣化的需求。

人力困境這一問題，從DBA的角度來講，時間被嚴重的碎片化，自身的成長就會遇到瓶頸，好比常常會作一些枯燥的重複操做；另外，業務諮詢量暴增，儘管咱們已經在嘗試平臺化的方法，可是仍是跟不上業務發展的速度。還有一個就是專業的DBA愈來愈匱乏，愈來愈貴，關鍵是根本招聘不到人手。

在這種背景下，咱們必須去思考：如何突破困局？如何朝着智能化轉型？傳統運維苦在哪裏？智能化運維又能解決哪些問題？

首先從故障產生的緣由來講，傳統運維是故障觸發，而智能運維是隱患驅動。換句話來講，智能運維不用報警，經過看報表就能知道可能要出事了，可以把故障消滅在「萌芽」階段；第二，傳統運維是被動接受，而智能運維是主動出擊。但主動出擊不必定是經過DBA去作，多是系統或者機器人操做；第三，傳統運維是由DBA發起和解決的，而智能運維是系統發起、RD自助；第四，傳統運維屬於「人肉救火」，而智能運維屬於「智能決策執行」；最後一點，傳統運維須要DBA親臨事故現場，而智能運維DBA只須要「隱身幕後」。

從自動化到智能化

那麼，如何從半自動化過渡到自動化，進而發展到智能化運維呢？在這個過程當中，咱們會面臨哪些痛點呢?

咱們的目標是爲整個公司的業務系統提供高效、穩定、快速的存儲服務，這也是DBA存在的價值。業務並不關心後面是MySQL仍是NoSQL，只關心數據是否沒丟，服務是否可用，出了問題以後多長時間可以恢復等等。因此咱們儘量作到把這些東西對開發人員透明化，提供穩定高效快速的服務。而站在公司的角度，就是在有限的資源下，提高效率，下降成本，儘量長遠地解決問題。

上圖是傳統運維和智能運維的特色分析，左邊屬於傳統運維，右邊屬於智能運維。傳統運維在採集這一塊作的不夠，因此它沒有太多的數據可供參考，其分析和預警能力是比較弱的。而智能運維恰好是反過來，重採集，不少功夫都在平時作了，包括分析、預警和執行，智能分析並推送關鍵報表。

而咱們的目標，是讓智能運維中的「報警+分析+執行」的比重佔據的愈來愈少。

決策執行如何去作呢？咱們都知道，預警重要但不緊急，但報警是緊急且重要的，若是你不可以及時去處理的話，事態可能會擴大，甚至會給公司帶來直接的經濟損失。

預警一般表明咱們已經定位了一個問題，它的決策思路是很是清晰的，可使用基於規則或AI的方式去解決，相對難度更小一些。而報警依賴於現場的鏈路分析，變量多、路徑長，因此決策難，間接致使任何決策的風險可能都變大。因此說咱們的策略就是全面的採集數據，而後增多預警，率先實現預警發現和處理的智能化。就像咱們既有步槍，也有手槍和刺刀，能遠距離解決敵人的，就儘可能不要短兵相接、肉搏上陣。

數據採集，從數據庫角度來講，咱們產生的數據分紅四塊，Global Status、Variable，Processlist、InnoDB Status，Slow、Error、General Log和Binlog；從應用側來講，包含端到端成功率、響應時間95線、99線、錯誤日誌和吞吐量；從系統層面，支持秒級採樣、操做系統各項指標；從變動側來看，包含集羣拓撲調整、在線DDL、DML變動、DB平臺操做日誌和應用端發佈記錄等等。

數據分析，首先是圍繞集羣分析，接着是實例、庫，最後是表，其中每一個對象均可以在多項指標上同比和環比，具體對比項可參考上圖。

經過上面的步驟，咱們基本能夠得到數據庫的畫像，而且幫助咱們從總體上作資源規劃和服務治理。例如，有些集羣實例數特別多且有繼續增長的趨勢，那麼服務器須要scale up；讀增長迅猛，讀寫比變大，那麼應考慮存儲KV化；利用率和分佈狀況會影響到服務器採購和預算制定；哪幾類報警最多，就專項治理，各個擊破。

從局部來講，咱們根據分析到的一些數據，能夠作一個集羣的健康體檢，例如數據庫的某些指標是否超標、如何作調整等等。

數據庫預警，經過分析去發現隱患，把報警轉化爲預警。上圖是咱們實際狀況下的報警統計分析結果，其中主從延遲佔比最大。假設load.1minPerCPU比較高，咱們怎麼去解決？那麼，可能須要採購CPU單核性能更高的機器，而不是採用更多的核心。再好比說磁盤空間，當咱們發現3T的磁盤空間廣泛不夠時，咱們下次能夠採購6T或更大空間的磁盤。

針對空間預警問題，何時須要拆分集羣？MySQL數據庫裏，拆分或遷移數據庫，花費的時間可能會好久。因此須要評估當前集羣，按目前的增加速度還能支撐多長時間，進而反推什麼時候要開始拆分、擴容等操做。

針對慢查詢的預警問題，咱們會統計紅黑榜，上圖是統計數據，也有利用率和出軌率的數據。假設這是一個金融事業羣的數據庫，假設有業務須要訪問且是直連，那麼這時就會產生幾個問題：第一個，有沒有數據全部者的受權；第二個，若是不經過服務化方式或者接口，發生故障時，它可能會致使整個金融的數據庫掛，如何進行降級？因此，咱們會去統計出軌率跟慢查詢，若是某數據庫正被以一種非法的方式訪問，那麼咱們就會掃描出來，再去進行服務治理。

從運維的層面來講，咱們作了故障快速轉移，包括自動生成配置文件，自動判斷是否啓用監控，切換後自動重寫配置，以及從庫可自動恢復上線等等。

報警自動處理，目前來講大部分的處理工做仍是基於規則，在大背景下擬定規則，觸發以後，按照知足的前提條件觸發動做，隨着庫的規則定義的逐漸完善和豐富，能夠逐步解決不少簡單的問題，這部分就再也不須要人的參與。

展望

將來咱們還會作一個故障診斷平臺，相似於「扁鵲」，實現日誌的採集、入庫和分析，同時提供接口，供全鏈路的故障定位和分析、服務化治理。

展望智能運維，應該是在自動化和智能化上交疊演進，在ABC（AI、Big Data、Cloud Computing）三個方向上深刻融合。在數據庫領域，NoSQL和SQL界限正變得模糊，軟硬結合、存儲計算分離架構也被愈來愈多的應用，智能運維正當其時，咱們也面臨更多新的挑戰。咱們的目標是，但願經過DB平臺的不斷建設加固，平臺能本身發現問題，自動定位問題，並智能的解決問題。

做者簡介

應鋼，美團點評研究員，數據庫專家。曾就任於百度、新浪、去哪兒網等，10年數據庫自動化運維開發、數據庫性能優化、大規模數據庫集羣技術保障和架構優化經驗。精通主流的SQL與NoSQL系統，現專一於公司業務在NewSQL領域的創新和落地。