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