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

從自動化到智能化運維過渡時，美團DBA團隊進行了哪些思考、探索與實踐？本文根據(jù)趙應(yīng)鋼在“第九屆中國數(shù)據(jù)庫技術(shù)大會”上的演講內(nèi)容整理而成，部分內(nèi)容有更新。

近些年，傳統(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)前的情況和面臨的一些挑戰(zhàn)，最后分享一下我們從自動化到智能化運維過渡時，所進行的思考、探索與實踐。

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

第一個是腳本化階段，這個階段，我們?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)罩镜鹊取?/p>

第五個是自動化階段，對這個階段的理解，其實是“仁者見仁，智者見智”。大多數(shù)人理解的自動化，只是通過Web平臺來執(zhí)行某些操作，但我們認(rèn)為這只是半自動化，所謂的自動化應(yīng)該是完全不需要人參與。目前，我們很多操作都還處于半自動化階段，下一個階段我們需要從半自動過渡到全自動。以MySQL系統(tǒng)為例，從運維角度看包括主從的高可用、服務(wù)過載的自我保護、容量自動診斷與評估以及集群的自動擴縮容等等。

下圖是我們平臺的現(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ù)平臺”。

即便我們打造了一個很強大的平臺，但還是發(fā)現(xiàn)有很多問題難以搞定。第一個就是故障定位，如果是簡單的故障，我們有類似天網(wǎng)、雷達(dá)這樣的系統(tǒng)去發(fā)現(xiàn)和定位。但是如果故障發(fā)生在數(shù)據(jù)庫內(nèi)部，那就需要專業(yè)的數(shù)據(jù)庫知識，去定位和查明到底是什么原因?qū)е铝斯收稀?/p>

通常來講，故障的軌跡是一個鏈，但也可能是一個“多米諾骨牌”的連環(huán)。可能因為一些原因?qū)е耂QL執(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ā)展的困境，當(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ù)量等方面很容易達(dá)到瓶頸，這就需要我們不斷拆分集群，同時開發(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)運維苦在哪里？智能化運維又能解決哪些問題？

首先從故障產(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ù)。而站在公司的角度，就是在有限的資源下，提升效率，降低成本，盡可能長遠(yuǎn)地解決問題。

上圖是傳統(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)和處理的智能化。就像我們既有步槍，也有手槍和刺刀，能遠(yuǎ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è)來看，包含集群拓?fù)湔{(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)新和落地。