背景
近些年，傳統(tǒng)的數(shù)據(jù)庫運(yùn)維方式已經(jīng)越來越難于滿足業(yè)務(wù)方對數(shù)據(jù)庫的穩(wěn)定性、可用性、靈活性的要求。隨著數(shù)據(jù)庫規(guī)模急速擴(kuò)大，各種NewSQL系統(tǒng)上線使用，運(yùn)維逐漸跟不上業(yè)務(wù)發(fā)展，各種矛盾暴露的更加明顯。在業(yè)務(wù)的驅(qū)動(dòng)下，美團(tuán)點(diǎn)評DBA團(tuán)隊(duì)經(jīng)歷了從“人肉”運(yùn)維到工具化、產(chǎn)品化、自助化、自動(dòng)化的轉(zhuǎn)型之旅，也開始了智能運(yùn)維在數(shù)據(jù)庫領(lǐng)域的思考和實(shí)踐。
本文將介紹美團(tuán)點(diǎn)評整個(gè)數(shù)據(jù)庫平臺(tái)的演進(jìn)歷史，以及我們當(dāng)前的情況和面臨的一些挑戰(zhàn)，最后分享一下我們從自動(dòng)化到智能化運(yùn)維過渡時(shí)，所進(jìn)行的思考、探索與實(shí)踐。
數(shù)據(jù)庫平臺(tái)的演變
我們數(shù)據(jù)庫平臺(tái)的演進(jìn)大概經(jīng)歷了五個(gè)大的階段：
第一個(gè)是腳本化階段，這個(gè)階段，我們?nèi)松?，集群少，服?wù)流量也比較小，腳本化的模式足以支撐整個(gè)服務(wù)。
第二個(gè)是工具化階段，我們把一些腳本包裝成工具，圍繞CMDB管理資產(chǎn)和服務(wù)，并完善了監(jiān)控系統(tǒng)。這時(shí)，我們的工具箱也逐漸豐富起來，包括DDL變更工具、SQL Review工具、慢查詢采集分析工具和備份閃回工具等等。
第三個(gè)是產(chǎn)品化階段，工具化階段可能還是單個(gè)的工具，但是在完成一些復(fù)雜操作時(shí)，就需要把這些工具組裝起來形成一個(gè)產(chǎn)品。當(dāng)然，并不是說這個(gè)產(chǎn)品一定要做成Web系統(tǒng)的形式，而是工具組裝起來形成一套流程之后，就可以保證所有DBA的操作行為，對流程的理解以及對線上的影響都是一致的。我們會(huì)在易用性和安全性層面不斷進(jìn)行打磨。而工具產(chǎn)品化的主要受益者是DBA，其定位是提升運(yùn)維服務(wù)的效率，減少事故的發(fā)生，并方便進(jìn)行快速統(tǒng)一的迭代。
第四個(gè)是打造私有云平臺(tái)階段，隨著美團(tuán)點(diǎn)評業(yè)務(wù)的高速發(fā)展，僅靠十幾、二十個(gè)DBA越來越難以滿足業(yè)務(wù)發(fā)展的需要。所以我們就把某些日常操作開放授權(quán)，讓開發(fā)人員自助去做，將DBA從繁瑣的操作中解放出來。當(dāng)時(shí)整個(gè)平臺(tái)每天執(zhí)行300多次改表操作;自助查詢超過1萬次;自助申請賬號(hào)、授權(quán)并調(diào)整監(jiān)控;自助定義敏感數(shù)據(jù)并授權(quán)給業(yè)務(wù)方管理員自助審批和管理;自定義業(yè)務(wù)的高峰和低峰時(shí)間段等等;自助下載、查詢?nèi)罩镜鹊取?/p>
第五個(gè)是自動(dòng)化階段，對這個(gè)階段的理解，其實(shí)是“仁者見仁，智者見智”。大多數(shù)人理解的自動(dòng)化，只是通過Web平臺(tái)來執(zhí)行某些操作，但我們認(rèn)為這只是半自動(dòng)化，所謂的自動(dòng)化應(yīng)該是完全不需要人參與。目前，我們很多操作都還處于半自動(dòng)化階段，下一個(gè)階段我們需要從半自動(dòng)過渡到全自動(dòng)。以MySQL系統(tǒng)為例，從運(yùn)維角度看包括主從的高可用、服務(wù)過載的自我保護(hù)、容量自動(dòng)診斷與評估以及集群的自動(dòng)擴(kuò)縮容等等。
現(xiàn)狀和面臨的挑戰(zhàn)
下圖是我們平臺(tái)的現(xiàn)狀，以關(guān)系數(shù)據(jù)庫RDS平臺(tái)為例，其中集成了很多管理的功能，例如主從的高可用、MGW的管理、DNS的變更、備份系統(tǒng)、升級流程、流量分配和切換系統(tǒng)、賬號(hào)管理、數(shù)據(jù)歸檔、服務(wù)與資產(chǎn)的流轉(zhuǎn)系統(tǒng)等等。
而且我們按照邏輯對平臺(tái)設(shè)計(jì)進(jìn)行了劃分，例如以用戶維度劃分的RDS自助平臺(tái)，DBA管理平臺(tái)和測試環(huán)境管理平臺(tái);以功能維度劃分的運(yùn)維、運(yùn)營和監(jiān)控;以存儲(chǔ)類型為維度劃分的關(guān)系型數(shù)據(jù)庫MySQL、分布式KV緩存、分布式KV存儲(chǔ)，以及正在建設(shè)中的NewSQL數(shù)據(jù)庫平臺(tái)等等。未來，我們希望打造成“MySQL+NoSQL+NewSQL，存儲(chǔ)+緩存的一站式服務(wù)平臺(tái)”。
挑戰(zhàn)一：RootCause定位難
即便我們打造了一個(gè)很強(qiáng)大的平臺(tái)，但還是發(fā)現(xiàn)有很多問題難以搞定。第一個(gè)就是故障定位，如果是簡單的故障，我們有類似天網(wǎng)、雷達(dá)這樣的系統(tǒng)去發(fā)現(xiàn)和定位。但是如果故障發(fā)生在數(shù)據(jù)庫內(nèi)部，那就需要專業(yè)的數(shù)據(jù)庫知識(shí)，去定位和查明到底是什么原因?qū)е铝斯收稀?/p>
通常來講，故障的軌跡是一個(gè)鏈，但也可能是一個(gè)“多米諾骨牌”的連環(huán)。可能因?yàn)橐恍┰驅(qū)е耂QL執(zhí)行變慢，引起連接數(shù)的增長，進(jìn)而導(dǎo)致業(yè)務(wù)超時(shí)，而業(yè)務(wù)超時(shí)又會(huì)引發(fā)業(yè)務(wù)不斷重試，結(jié)果會(huì)產(chǎn)生更多的問題。當(dāng)我們收到一個(gè)報(bào)警時(shí)，可能已經(jīng)過了30秒甚至更長時(shí)間，DBA再去查看時(shí)，已經(jīng)錯(cuò)過了最佳的事故處理時(shí)機(jī)。所以，我們要在故障發(fā)生之后，制定一些應(yīng)對策略，例如快速切換主庫、自動(dòng)屏蔽下線問題從庫等等。除此之外，還有一個(gè)比較難的問題，就是如何避免相似的故障再次出現(xiàn)。
挑戰(zhàn)二：人力和發(fā)展困境
第二個(gè)挑戰(zhàn)是人力和發(fā)展的困境，當(dāng)服務(wù)流量成倍增長時(shí)，其成本并不是以相同的速度對應(yīng)增長的。當(dāng)業(yè)務(wù)邏輯越來越復(fù)雜時(shí)，每增加一塊錢的營收，其后面對應(yīng)的數(shù)據(jù)庫QPS可能是2倍甚至5倍，業(yè)務(wù)邏輯越復(fù)雜，服務(wù)支撐的難度越大。另外，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫在容量、延時(shí)、響應(yīng)時(shí)間以及數(shù)據(jù)量等方面很容易達(dá)到瓶頸，這就需要我們不斷拆分集群，同時(shí)開發(fā)訴求也多種多樣，當(dāng)我們嘗試使用平臺(tái)化的思想去解決問題時(shí)，還要充分思考如何滿足研發(fā)人員多樣化的需求。
人力困境這一問題，從DBA的角度來說，時(shí)間被嚴(yán)重的碎片化，自身的成長就會(huì)遇到瓶頸，比如經(jīng)常會(huì)做一些枯燥的重復(fù)操作;另外，業(yè)務(wù)咨詢量暴增，盡管我們已經(jīng)在嘗試平臺(tái)化的方法，但是還是跟不上業(yè)務(wù)發(fā)展的速度。還有一個(gè)就是專業(yè)的DBA越來越匱乏，越來越貴，關(guān)鍵是根本招聘不到人手。
在這種背景下，我們必須去思考：如何突破困局?如何朝著智能化轉(zhuǎn)型?傳統(tǒng)運(yùn)維苦在哪里?智能化運(yùn)維又能解決哪些問題?
首先從故障產(chǎn)生的原因來說，傳統(tǒng)運(yùn)維是故障觸發(fā)，而智能運(yùn)維是隱患驅(qū)動(dòng)。換句話來說，智能運(yùn)維不用報(bào)警，通過看報(bào)表就能知道可能要出事了，能夠把故障消滅在“萌芽”階段;第二，傳統(tǒng)運(yùn)維是被動(dòng)接受，而智能運(yùn)維是主動(dòng)出擊。但主動(dòng)出擊不一定是通過DBA去做，可能是系統(tǒng)或者機(jī)器人操作;第三，傳統(tǒng)運(yùn)維是由DBA發(fā)起和解決的，而智能運(yùn)維是系統(tǒng)發(fā)起、RD自助;第四，傳統(tǒng)運(yùn)維屬于“人肉救火”，而智能運(yùn)維屬于“智能決策執(zhí)行”;最后一點(diǎn)，傳統(tǒng)運(yùn)維需要DBA親臨事故現(xiàn)場，而智能運(yùn)維DBA只需要“隱身幕后”。
從自動(dòng)化到智能化
那么，如何從半自動(dòng)化過渡到自動(dòng)化，進(jìn)而發(fā)展到智能化運(yùn)維呢?在這個(gè)過程中，我們會(huì)面臨哪些痛點(diǎn)呢?
我們的目標(biāo)是為整個(gè)公司的業(yè)務(wù)系統(tǒng)提供高效、穩(wěn)定、快速的存儲(chǔ)服務(wù)，這也是DBA存在的價(jià)值。業(yè)務(wù)并不關(guān)心后面是MySQL還是NoSQL，只關(guān)心數(shù)據(jù)是否沒丟，服務(wù)是否可用，出了問題之后多長時(shí)間能夠恢復(fù)等等。所以我們盡可能做到把這些東西對開發(fā)人員透明化，提供穩(wěn)定高效快速的服務(wù)。而站在公司的角度，就是在有限的資源下，提升效率，降低成本，盡可能長遠(yuǎn)地解決問題。
上圖是傳統(tǒng)運(yùn)維和智能運(yùn)維的特點(diǎn)分析，左邊屬于傳統(tǒng)運(yùn)維，右邊屬于智能運(yùn)維。傳統(tǒng)運(yùn)維在采集這一塊做的不夠，所以它沒有太多的數(shù)據(jù)可供參考，其分析和預(yù)警能力是比較弱的。而智能運(yùn)維剛好是反過來，重采集，很多功夫都在平時(shí)做了，包括分析、預(yù)警和執(zhí)行，智能分析并推送關(guān)鍵報(bào)表。
而我們的目標(biāo)，是讓智能運(yùn)維中的“報(bào)警+分析+執(zhí)行”的比重占據(jù)的越來越少。
決策執(zhí)行如何去做呢?我們都知道，預(yù)警重要但不緊急，但報(bào)警是緊急且重要的，如果你不能夠及時(shí)去處理的話，事態(tài)可能會(huì)擴(kuò)大，甚至?xí)o公司帶來直接的經(jīng)濟(jì)損失。
預(yù)警通常代表我們已經(jīng)定位了一個(gè)問題，它的決策思路是非常清晰的，可以使用基于規(guī)則或AI的方式去解決，相對難度更小一些。而報(bào)警依賴于現(xiàn)場的鏈路分析，變量多、路徑長，所以決策難，間接導(dǎo)致任何決策的風(fēng)險(xiǎn)可能都變大。所以說我們的策略就是全面的采集數(shù)據(jù)，然后增多預(yù)警，率先實(shí)現(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)時(shí)間95線、99線、錯(cuò)誤日志和吞吐量;從系統(tǒng)層面，支持秒級采樣、操作系統(tǒng)各項(xiàng)指標(biāo);從變更側(cè)來看，包含集群拓?fù)湔{(diào)整、在線DDL、DML變更、DB平臺(tái)操作日志和應(yīng)用端發(fā)布記錄等等。
數(shù)據(jù)分析，首先是圍繞集群分析，接著是實(shí)例、庫，最后是表，其中每個(gè)對象都可以在多項(xiàng)指標(biāo)上同比和環(huán)比，具體對比項(xiàng)可參考上圖。
通過上面的步驟，我們基本可以獲得數(shù)據(jù)庫的畫像，并且?guī)椭覀儚恼w上做資源規(guī)劃和服務(wù)治理。例如，有些集群實(shí)例數(shù)特別多且有繼續(xù)增加的趨勢，那么服務(wù)器需要scale up;讀增加迅猛，讀寫比變大，那么應(yīng)考慮存儲(chǔ)KV化;利用率和分布情況會(huì)影響到服務(wù)器采購和預(yù)算制定;哪幾類報(bào)警最多，就專項(xiàng)治理，各個(gè)擊破。
從局部來說，我們根據(jù)分析到的一些數(shù)據(jù)，可以做一個(gè)集群的健康體檢，例如數(shù)據(jù)庫的某些指標(biāo)是否超標(biāo)、如何做調(diào)整等等。
數(shù)據(jù)庫預(yù)警，通過分析去發(fā)現(xiàn)隱患，把報(bào)警轉(zhuǎn)化為預(yù)警。上圖是我們實(shí)際情況下的報(bào)警統(tǒng)計(jì)分析結(jié)果，其中主從延遲占比最大。假設(shè)load.1minPerCPU比較高，我們怎么去解決?那么，可能需要采購CPU單核性能更高的機(jī)器，而不是采用更多的核心。再比如說磁盤空間，當(dāng)我們發(fā)現(xiàn)3T的磁盤空間普遍不夠時(shí)，我們下次可以采購6T或更大空間的磁盤。
針對空間預(yù)警問題，什么時(shí)候需要拆分集群?MySQL數(shù)據(jù)庫里，拆分或遷移數(shù)據(jù)庫，花費(fèi)的時(shí)間可能會(huì)很久。所以需要評估當(dāng)前集群，按目前的增長速度還能支撐多長時(shí)間，進(jìn)而反推何時(shí)要開始拆分、擴(kuò)容等操作。
針對慢查詢的預(yù)警問題，我們會(huì)統(tǒng)計(jì)紅黑榜，上圖是統(tǒng)計(jì)數(shù)據(jù)，也有利用率和出軌率的數(shù)據(jù)。假設(shè)這是一個(gè)金融事業(yè)群的數(shù)據(jù)庫，假設(shè)有業(yè)務(wù)需要訪問且是直連，那么這時(shí)就會(huì)產(chǎn)生幾個(gè)問題：第一個(gè)，有沒有數(shù)據(jù)所有者的授權(quán);第二個(gè)，如果不通過服務(wù)化方式或者接口，發(fā)生故障時(shí)，它可能會(huì)導(dǎo)致整個(gè)金融的數(shù)據(jù)庫掛，如何進(jìn)行降級?所以，我們會(huì)去統(tǒng)計(jì)出軌率跟慢查詢，如果某數(shù)據(jù)庫正被以一種非法的方式訪問，那么我們就會(huì)掃描出來，再去進(jìn)行服務(wù)治理。
從運(yùn)維的層面來說，我們做了故障快速轉(zhuǎn)移，包括自動(dòng)生成配置文件，自動(dòng)判斷是否啟用監(jiān)控，切換后自動(dòng)重寫配置，以及從庫可自動(dòng)恢復(fù)上線等等。
報(bào)警自動(dòng)處理，目前來說大部分的處理工作還是基于規(guī)則，在大背景下擬定規(guī)則，觸發(fā)之后，按照滿足的前提條件觸發(fā)動(dòng)作，隨著庫的規(guī)則定義的逐漸完善和豐富，可以逐步解決很多簡單的問題，這部分就不再需要人的參與。
展望
未來我們還會(huì)做一個(gè)故障診斷平臺(tái)，類似于“扁鵲”，實(shí)現(xiàn)日志的采集、入庫和分析，同時(shí)提供接口，供全鏈路的故障定位和分析、服務(wù)化治理。
展望智能運(yùn)維，應(yīng)該是在自動(dòng)化和智能化上交疊演進(jìn)，在ABC(AI、Big Data、Cloud Computing)三個(gè)方向上深入融合。在數(shù)據(jù)庫領(lǐng)域，NoSQL和SQL界限正變得模糊，軟硬結(jié)合、存儲(chǔ)計(jì)算分離架構(gòu)也被越來越多的應(yīng)用，智能運(yùn)維正當(dāng)其時(shí)，我們也面臨更多新的挑戰(zhàn)。我們的目標(biāo)是，希望通過DB平臺(tái)的不斷建設(shè)加固，平臺(tái)能自己發(fā)現(xiàn)問題，自動(dòng)定位問題，并智能的解決問題。
作者簡介
應(yīng)鋼，美團(tuán)點(diǎn)評研究員，數(shù)據(jù)庫專家。曾就職于百度、新浪、去哪兒網(wǎng)等，10年數(shù)據(jù)庫自動(dòng)化運(yùn)維開發(fā)、數(shù)據(jù)庫性能優(yōu)化、大規(guī)模數(shù)據(jù)庫集群技術(shù)保障和架構(gòu)優(yōu)化經(jīng)驗(yàn)。精通主流的SQL與NoSQL系統(tǒng)，現(xiàn)專注于公司業(yè)務(wù)在NewSQL領(lǐng)域的創(chuàng)新和落地。
