從自動化到智能化運維過渡時，美團 DBA 團隊進行了哪些思考、探索與實踐？

近些年，傳統(tǒng)的數(shù)據(jù)庫運維方式已經(jīng)越來越難于滿足業(yè)務(wù)方對數(shù)據(jù)庫的穩(wěn)定性、可用性、靈活性的要求。

隨著數(shù)據(jù)庫規(guī)模急速擴大，各種 NewSQL 系統(tǒng)上線使用，運維逐漸跟不上業(yè)務(wù)發(fā)展，各種矛盾暴露的更加明顯。

在業(yè)務(wù)的驅(qū)動下，美團 DBA 團隊經(jīng)歷了從“人肉”運維到工具化、產(chǎn)品化、自助化、自動化的轉(zhuǎn)型之旅，也開始了智能運維在數(shù)據(jù)庫領(lǐng)域的思考和實踐。

本文介紹了美團整個數(shù)據(jù)庫平臺的演進歷史，以及當(dāng)前現(xiàn)狀和面臨的一些挑戰(zhàn)，最后分享從自動化到智能化運維過渡時，所進行的思考、探索與實踐。

數(shù)據(jù)庫平臺的演變

我們數(shù)據(jù)庫平臺的演進大概經(jīng)歷了五個大的階段：

• 腳本化
• 工具化
• 產(chǎn)品化
• 自助化
• 自動化 

腳本化階段

這個階段，我們?nèi)松?，集群少，服?wù)流量也比較小，腳本化的模式足以支撐整個服務(wù)。

工具化階段

我們把一些腳本包裝成工具，圍繞 CMDB 管理資產(chǎn)和服務(wù)，并完善了監(jiān)控系統(tǒng)。

這時，我們的工具箱也逐漸豐富起來，包括 DDL 變更工具、SQL Review 工具、慢查詢采集分析工具和備份閃回工具等等。

產(chǎn)品化階段

工具化階段可能還是單個的工具，但是在完成一些復(fù)雜操作時，就需要把這些工具組裝起來形成一個產(chǎn)品。

當(dāng)然，并不是說這個產(chǎn)品一定要做成 Web 系統(tǒng)的形式，而是工具組裝起來形成一套流程之后，就可以保證所有 DBA 的操作行為，對流程的理解以及對線上的影響都是一致的。

我們會在易用性和安全性層面不斷進行打磨。而工具產(chǎn)品化的主要受益者是 DBA，其定位是提升運維服務(wù)的效率，減少事故的發(fā)生，并方便進行快速統(tǒng)一的迭代。

自助化階段（打造私有云平臺）

隨著美團業(yè)務(wù)的高速發(fā)展，僅靠十幾、二十個 DBA 越來越難以滿足業(yè)務(wù)發(fā)展的需要。

所以我們就把某些日常操作開放授權(quán)，讓開發(fā)人員自助去做，將 DBA 從繁瑣的操作中解放出來：

• 當(dāng)時整個平臺每天執(zhí)行 300 多次改表操作。
• 自助查詢超過 1 萬次。
• 自助申請賬號、授權(quán)并調(diào)整監(jiān)控。
• 自助定義敏感數(shù)據(jù)并授權(quán)給業(yè)務(wù)方管理員自助審批和管理。
• 自定義業(yè)務(wù)的高峰和低峰時間段等等。
• 自助下載、查詢?nèi)罩镜鹊取?/li>

自動化階段

對這個階段的理解，其實是“仁者見仁，智者見智”。大多數(shù)人理解的自動化，只是通過 Web 平臺來執(zhí)行某些操作，但我們認為這只是半自動化，所謂的自動化應(yīng)該是完全不需要人參與。

目前，我們很多操作都還處于半自動化階段，下一個階段我們需要從半自動過渡到全自動。

以 MySQL 系統(tǒng)為例，從運維角度看包括主從的高可用、服務(wù)過載的自我保護、容量自動診斷與評估以及集群的自動擴縮容等等。

現(xiàn)狀和面臨的挑戰(zhàn)

下圖是我們平臺的現(xiàn)狀，以關(guān)系數(shù)據(jù)庫 RDS 平臺為例，其中集成了很多管理的功能。

例如主從的高可用、MGW 的管理、DNS 的變更、備份系統(tǒng)、升級流程、流量分配和切換系統(tǒng)、賬號管理、數(shù)據(jù)歸檔、服務(wù)與資產(chǎn)的流轉(zhuǎn)系統(tǒng)等等。

而且我們按照邏輯對平臺設(shè)計進行了劃分，例如：

• 以用戶維度劃分的 RDS 自助平臺，DBA 管理平臺和測試環(huán)境管理平臺。
• 以功能維度劃分的運維、運營和監(jiān)控。
• 以存儲類型為維度劃分的關(guān)系型數(shù)據(jù)庫 MySQL、分布式 KV 緩存、分布式 KV 存儲，以及正在建設(shè)中的 NewSQL 數(shù)據(jù)庫平臺等等。

未來，我們希望打造成“MySQL+NoSQL+NewSQL，存儲+緩存的一站式服務(wù)平臺”。

挑戰(zhàn)一：RootCause 定位難

即便我們打造了一個很強大的平臺，但還是發(fā)現(xiàn)有很多問題難以搞定。第一個就是故障定位，如果是簡單的故障，我們有類似天網(wǎng)、雷達這樣的系統(tǒng)去發(fā)現(xiàn)和定位。

但是如果故障發(fā)生在數(shù)據(jù)庫內(nèi)部，那就需要專業(yè)的數(shù)據(jù)庫知識，去定位和查明到底是什么原因?qū)е铝斯收稀?/p>

通常來講，故障的軌跡是一個鏈，但也可能是一個“多米諾骨牌”的連環(huán)。

可能因為一些原因?qū)е?SQL 執(zhí)行變慢，引起連接數(shù)的增長，進而導(dǎo)致業(yè)務(wù)超時，而業(yè)務(wù)超時又會引發(fā)業(yè)務(wù)不斷重試，結(jié)果會產(chǎn)生更多的問題。

當(dāng)我們收到一個報警時，可能已經(jīng)過了 30 秒甚至更長時間，DBA 再去查看時，已經(jīng)錯過了最佳的事故處理時機。

所以，我們要在故障發(fā)生之后，制定一些應(yīng)對策略，例如快速切換主庫、自動屏蔽下線問題從庫等等。

除此之外，還有一個比較難的問題，就是如何避免相似的故障再次出現(xiàn)。

挑戰(zhàn)二：人力和發(fā)展困境

第二個挑戰(zhàn)是人力和發(fā)展的困境，當(dāng)服務(wù)流量成倍增長時，其成本并不是以相同的速度對應(yīng)增長的。

當(dāng)業(yè)務(wù)邏輯越來越復(fù)雜時，每增加一塊錢的營收，其后面對應(yīng)的數(shù)據(jù)庫 QPS 可能是 2 倍甚至 5 倍，業(yè)務(wù)邏輯越復(fù)雜，服務(wù)支撐的難度越大。

另外，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫在容量、延時、響應(yīng)時間以及數(shù)據(jù)量等方面很容易達到瓶頸。

這就需要我們不斷拆分集群，同時開發(fā)訴求也多種多樣，當(dāng)我們嘗試使用平臺化的思想去解決問題時，還要充分思考如何滿足研發(fā)人員多樣化的需求。

人力困境這一問題，從 DBA 的角度來說，時間被嚴(yán)重的碎片化，自身的成長就會遇到瓶頸，比如經(jīng)常會做一些枯燥的重復(fù)操作。

另外，業(yè)務(wù)咨詢量暴增，盡管我們已經(jīng)在嘗試平臺化的方法，但是還是跟不上業(yè)務(wù)發(fā)展的速度。

還有一個就是專業(yè)的 DBA 越來越匱乏，越來越貴，關(guān)鍵是根本招聘不到人手。

在這種背景下，我們必須去思考：如何突破困局？如何朝著智能化轉(zhuǎn)型？傳統(tǒng)運維苦在哪里？智能化運維又能解決哪些問題？

總結(jié)有如下五點：

• 從故障產(chǎn)生的原因來說，傳統(tǒng)運維是故障觸發(fā)，而智能運維是隱患驅(qū)動。換句話來說，智能運維不用報警，通過看報表就能知道可能要出事了，能夠把故障消滅在“萌芽”階段。
• 傳統(tǒng)運維是被動接受，而智能運維是主動出擊。但主動出擊不一定是通過 DBA 去做，可能是系統(tǒng)或者機器人操作。
• 傳統(tǒng)運維是由 DBA 發(fā)起和解決的，而智能運維是系統(tǒng)發(fā)起、RD 自助。
• 傳統(tǒng)運維屬于“人肉救火”，而智能運維屬于“智能決策執(zhí)行”。
• 傳統(tǒng)運維需要 DBA 親臨事故現(xiàn)場，而智能運維 DBA 只需要“隱身幕后”。

從自動化到智能化

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

我們的目標(biāo)是為整個公司的業(yè)務(wù)系統(tǒng)提供高效、穩(wěn)定、快速的存儲服務(wù)，這也是 DBA 存在的價值。

業(yè)務(wù)并不關(guān)心后面是 MySQL 還是 NoSQL，只關(guān)心數(shù)據(jù)是否沒丟，服務(wù)是否可用，出了問題之后多長時間能夠恢復(fù)等等。

所以我們盡可能做到把這些東西對開發(fā)人員透明化，提供穩(wěn)定高效快速的服務(wù)。

而站在公司的角度，就是在有限的資源下，提升效率，降低成本，盡可能長遠地解決問題。

上圖是傳統(tǒng)運維和智能運維的特點分析，左邊屬于傳統(tǒng)運維，右邊屬于智能運維。

傳統(tǒng)運維在采集這一塊做的不夠，所以它沒有太多的數(shù)據(jù)可供參考，其分析和預(yù)警能力是比較弱的。

而智能運維剛好是反過來，重采集，很多功夫都在平時做了，包括分析、預(yù)警和執(zhí)行，智能分析并推送關(guān)鍵報表。

而我們的目標(biāo)，是讓智能運維中的“報警+分析+執(zhí)行”的比重占據(jù)的越來越少。

決策執(zhí)行如何去做呢？我們都知道，預(yù)警重要但不緊急，但報警是緊急且重要的，如果你不能夠及時去處理的話，事態(tài)可能會擴大，甚至?xí)o公司帶來直接的經(jīng)濟損失。

預(yù)警通常代表我們已經(jīng)定位了一個問題，它的決策思路是非常清晰的，可以使用基于規(guī)則或 AI 的方式去解決，相對難度更小一些。

而報警依賴于現(xiàn)場的鏈路分析，變量多、路徑長，所以決策難，間接導(dǎo)致任何決策的風(fēng)險可能都變大。

所以說我們的策略就是全面的采集數(shù)據(jù)，然后增多預(yù)警，率先實現(xiàn)預(yù)警發(fā)現(xiàn)和處理的智能化。

就像我們既有步槍，也有手槍和刺刀，能遠距離解決敵人的，就盡量不要短兵相接、肉搏上陣。

數(shù)據(jù)采集，從數(shù)據(jù)庫角度來說，我們產(chǎn)生的數(shù)據(jù)分成四塊：

• Global Status、Variable
• Processlist、InnoDB Status
• Slow、Error、General Log
• Binlog

從應(yīng)用側(cè)來說，包含端到端成功率、響應(yīng)時間 95 線、99 線、錯誤日志和吞吐量；從系統(tǒng)層面，支持秒級采樣、操作系統(tǒng)各項指標(biāo)。

從變更側(cè)來看，包含集群拓撲調(diào)整、在線 DDL、DML 變更、DB 平臺操作日志和應(yīng)用端發(fā)布記錄等等。

數(shù)據(jù)分析，首先是圍繞集群分析，接著是實例、庫，最后是表，其中每個對象都可以在多項指標(biāo)上同比和環(huán)比，具體對比項可參考上圖。

通過上面的步驟，我們基本可以獲得數(shù)據(jù)庫的畫像，并且?guī)椭覀儚恼w上做資源規(guī)劃和服務(wù)治理。

例如，有些集群實例數(shù)特別多且有繼續(xù)增加的趨勢，那么服務(wù)器需要 scale up；讀增加迅猛，讀寫比變大，那么應(yīng)考慮存儲 KV 化。

利用率和分布情況會影響到服務(wù)器采購和預(yù)算制定；哪幾類報警最多，就專項治理，各個擊破。

從局部來說，我們根據(jù)分析到的一些數(shù)據(jù)，可以做一個集群的健康體檢，例如數(shù)據(jù)庫的某些指標(biāo)是否超標(biāo)、如何做調(diào)整等等。

數(shù)據(jù)庫預(yù)警，通過分析去發(fā)現(xiàn)隱患，把報警轉(zhuǎn)化為預(yù)警。上圖是我們實際情況下的報警統(tǒng)計分析結(jié)果，其中主從延遲占比最大。

假設(shè) load.1minPerCPU 比較高，我們怎么去解決？那么，可能需要采購 CPU 單核性能更高的機器，而不是采用更多的核心。

再比如說磁盤空間，當(dāng)我們發(fā)現(xiàn) 3T 的磁盤空間普遍不夠時，我們下次可以采購 6T 或更大空間的磁盤。

針對空間預(yù)警問題，什么時候需要拆分集群？MySQL 數(shù)據(jù)庫里，拆分或遷移數(shù)據(jù)庫，花費的時間可能會很久。

所以需要評估當(dāng)前集群，按目前的增長速度還能支撐多長時間，進而反推何時要開始拆分、擴容等操作。

針對慢查詢的預(yù)警問題，我們會統(tǒng)計紅黑榜，上圖是統(tǒng)計數(shù)據(jù)，也有利用率和出軌率的數(shù)據(jù)。

假設(shè)這是一個金融事業(yè)群的數(shù)據(jù)庫，假設(shè)有業(yè)務(wù)需要訪問且是直連，那么這時就會產(chǎn)生幾個問題：

• 有沒有數(shù)據(jù)所有者的授權(quán)？
• 如果不通過服務(wù)化方式或者接口，發(fā)生故障時，它可能會導(dǎo)致整個金融的數(shù)據(jù)庫掛掉，如何進行降級？

所以，我們會去統(tǒng)計出軌率跟慢查詢，如果某數(shù)據(jù)庫正被以一種非法的方式訪問，那么我們就會掃描出來，再去進行服務(wù)治理。

從運維的層面來說，我們做了故障快速轉(zhuǎn)移，包括自動生成配置文件，自動判斷是否啟用監(jiān)控，切換后自動重寫配置，以及從庫可自動恢復(fù)上線等等。

報警自動處理，目前來說大部分的處理工作還是基于規(guī)則，在大背景下擬定規(guī)則。

觸發(fā)之后，按照滿足的前提條件觸發(fā)動作，隨著庫的規(guī)則定義的逐漸完善和豐富，可以逐步解決很多簡單的問題，這部分就不再需要人的參與。

展望

未來我們還會做一個故障診斷平臺，類似于“扁鵲”，實現(xiàn)日志的采集、入庫和分析，同時提供接口，供全鏈路的故障定位和分析、服務(wù)化治理。

展望智能運維，應(yīng)該是在自動化和智能化上交疊演進，在 ABC（AI、Big Data、Cloud Computing）三個方向上深入融合。

在數(shù)據(jù)庫領(lǐng)域，NoSQL 和 SQL 界限正變得模糊，軟硬結(jié)合、存儲計算分離架構(gòu)也被越來越多的應(yīng)用，智能運維正當(dāng)其時，我們也面臨更多新的挑戰(zhàn)。

我們的目標(biāo)是，希望通過 DB 平臺的不斷建設(shè)加固，平臺能自己發(fā)現(xiàn)問題，自動定位問題，并智能的解決問題。

作者：趙應(yīng)鋼

簡介：美團研究員，數(shù)據(jù)庫專家。曾就職于百度、新浪、去哪兒網(wǎng)等，10 年數(shù)據(jù)庫自動化運維開發(fā)、數(shù)據(jù)庫性能優(yōu)化、大規(guī)模數(shù)據(jù)庫集群技術(shù)保障和架構(gòu)優(yōu)化經(jīng)驗。精通主流的 SQL 與 NoSQL 系統(tǒng)，現(xiàn)專注于公司業(yè)務(wù)在 NewSQL 領(lǐng)域的創(chuàng)新和落地。