資料庫智慧運維探索與實踐

摘要： 從自動化到智慧化運維過渡時，美團DBA團隊進行了哪些思考、探索與實踐？本文根據趙應鋼在“第九屆中國資料庫技術大會”上的演講內容整理而成，部分內容有更新。 背景 近些年，傳統的資料庫運維方式已經越來越難於滿足業務方對資料庫的穩定性、可用性、靈活性的要求。隨著資料庫規模急速擴大，各種New...

從自動化到智慧化運維過渡時，美團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領域的創新和落地。