1.背景

近幾年 vivo 數(shù)據(jù)庫運(yùn)維規(guī)?？焖僭鲩L，從數(shù)量上看增長了幾倍，達(dá)到了萬級別的規(guī)模，與此同時(shí) DBA 每日需要處理200多條告警。

隨著運(yùn)維規(guī)模越大，線上故障也就越多，DBA 對于每個(gè)故障的處理時(shí)效將會下降，如果沒有強(qiáng)有力的工具能提高故障的排查和修復(fù)效率，那么線上的穩(wěn)定性就得不到保障。因此我們的想法是，我們固然要不斷提供更加豐富的工具，但無論工具再豐富，都需要人去主動使用，因此更重要的是改變以人為主、工具為輔的運(yùn)維模式，引入自動化分析和自愈的手段來提升運(yùn)維效率。

2.實(shí)現(xiàn)思路

2.1 短期和長期目標(biāo)

目標(biāo)確定后，接下來需要確定目標(biāo)的實(shí)現(xiàn)思路。我們調(diào)研了業(yè)界的一些解決方案后，發(fā)現(xiàn)能力的發(fā)展可以總結(jié)為以下三個(gè)階段：

• 平臺化：能夠提供一些數(shù)據(jù)和統(tǒng)計(jì)信息，運(yùn)維人員再基于這些信息來進(jìn)行運(yùn)維；
• 智能化：已經(jīng)能夠提供分析和建議，但是否采納需要運(yùn)維人員自行判斷；
• 自動化：已經(jīng)有部分場景可以實(shí)現(xiàn)自動恢復(fù)，無需人工參與了。

通常平臺的發(fā)展過程如上所述，但是也需要結(jié)合我們自身的情況來決定，因?yàn)槲覀兺度氲娜肆^少，不是成團(tuán)隊(duì)地投入這個(gè)工作，因此不太可能遵循這么一個(gè)發(fā)展策略。因此基于人力投入的情況，我們定下的目標(biāo)是，短期內(nèi)我們要做投入產(chǎn)出比最高的工作，以求達(dá)到立竿見影的效果，但長期來看，圖中成體系的基礎(chǔ)能力還是需要建設(shè)起來。

2.2 尋找切入點(diǎn)

為了短期達(dá)到立竿見影的效果，就需要尋找一個(gè)切入點(diǎn)。如果我們觀察一個(gè)故障的生命周期的話，可以看到故障的生命周期分為故障前、故障中和故障后：

• “故障前”包括故障預(yù)防 ；
• “故障中”包括故障發(fā)現(xiàn)、故障定位和故障恢復(fù)；
• “故障后”包括故障復(fù)盤。

那么從整個(gè)故障的生命周期來看的話，按照我們的經(jīng)驗(yàn)，DBA 大部分時(shí)間都是消耗在故障定位和故障恢復(fù)上的，而因?yàn)槊款惞收暇哂邢嗨频亩ㄎ宦窂?，所以比較容易去定義定位規(guī)則、沉淀專家經(jīng)驗(yàn)。因此我們的想法是將重點(diǎn)放在故障定位和故障恢復(fù)這兩個(gè)階段上，去提高 DBA 的運(yùn)維效率，優(yōu)先找一些投入產(chǎn)出比高的場景去實(shí)現(xiàn)故障自愈。

2.3 結(jié)合實(shí)際情況后的發(fā)展思路

結(jié)合前面提到的短期目標(biāo)和長期目標(biāo)，我們確定下來這么一個(gè)發(fā)展思路。

首先我們會重點(diǎn)去實(shí)現(xiàn)各類故障場景的自動分析和自愈，這些自動分析和自愈行為是由故障消息驅(qū)動的，這也是一個(gè)比較直觀的方式，因?yàn)?DBA 通常也是收到故障消息后，才去進(jìn)行故障定位等操作。然后當(dāng)過程中需要某類基礎(chǔ)能力時(shí)，就去重點(diǎn)發(fā)展該能力。

這樣我們的短期目標(biāo)和長期目標(biāo)就都能兼顧到。

2.4 如何在實(shí)現(xiàn)過程中保證數(shù)據(jù)庫可用性

在實(shí)現(xiàn)方案前，需要先思考一個(gè)問題，即我們?nèi)绾卧趯?shí)現(xiàn)過程中保證數(shù)據(jù)庫的可用性？

之所以把數(shù)據(jù)庫可用性單獨(dú)提出來，是因?yàn)楣收献杂亲詣佑|發(fā)、自動執(zhí)行的，而且過程中通常需要去觸達(dá)數(shù)據(jù)庫，比如查詢數(shù)據(jù)庫的狀態(tài)或執(zhí)行操作，那么這種自動的操作本身會帶來比較大風(fēng)險(xiǎn)，因此更加需要考慮實(shí)現(xiàn)過程中，如何避免對數(shù)據(jù)庫造成的可用性影響。那么如何避免可用性影響呢？我們的答案是將每個(gè)故障自愈方案上線的流程標(biāo)準(zhǔn)化。

3.具體實(shí)現(xiàn)

3.1 故障自愈方案上線流程

下圖是我們以可用性為第一考量的前提下，確定下來的故障自愈方案上線流程。

①確定方案：當(dāng)有一個(gè)新的故障自愈場景需要實(shí)現(xiàn)時(shí)，首先需要把自愈方案確定下來，即確定在這個(gè)故障場景中，需要“做什么、怎么去做”。這里有兩種確定方案的方式，可以和 DBA 進(jìn)行咨詢交流確定方案，也可以通過分析線上案例來確定方案

②開發(fā)測試：方案確定后進(jìn)行程序的開發(fā)測試，此處不必贅述

③線上灰度：開發(fā)測試完成后，需進(jìn)行線上灰度，這里我們支持針對具體對象進(jìn)行灰度，比如某個(gè)集群經(jīng)常發(fā)生該類故障，那么可以指定灰度該集 群。如果沒有具體對象，也可以設(shè)置百分比隨機(jī)灰度。當(dāng)然如果某些故障場景發(fā)生的頻率很低，我們一開始也會進(jìn)行線上演練，通過在線上模擬故障的方式來進(jìn)行驗(yàn)證

④全網(wǎng)生效：灰度完成后，開放全網(wǎng)生效

⑤演進(jìn)方案：每個(gè)故障自愈方案不是上線后就是最終形態(tài)，還需要我們結(jié)合用戶反饋以及后續(xù)案例來不斷進(jìn)行迭代優(yōu)化

上述流程的五個(gè)步驟中，“確定方案”和“演進(jìn)方案”是重點(diǎn)，因此下文展開介紹。

3.1.1 確定方案

在實(shí)踐中，我們通過和 DBA 咨詢交流以及分析線上案例的方式來確定故障自愈的方案。

• 咨詢交流

這里介紹下發(fā)生磁盤告警時(shí)自動清理 MySQL Binlog 的方案，通過和 DBA 咨詢交流的方式，我們確定了該方案。具體方案流程如下圖所示，其實(shí)整個(gè)方案就重點(diǎn)關(guān)注了兩個(gè)問題：

第一個(gè)問題，如何確定哪些 Binlog 是不可以清理的？答案是未備份的 Binlog 不能清理，因?yàn)闀绊懺隽總浞?；備庫未同步?Binlog 也不能清理，因?yàn)闀绊憦?fù)制同步。

第二個(gè)問題，如何保證刪除過程中的系統(tǒng)可用性？這里我們采用分批刪除、每次刪除睡眠一秒的方式來平滑刪除帶來的 IO 壓力。

• 案例分析

有時(shí)不是所有方案都能夠通過咨詢交流的方式確定下來，對于根因分析的場景，因?yàn)槊總€(gè)運(yùn)維人員的運(yùn)維經(jīng)歷有所差別，如果要把所有可能的情況枚舉出 來，那么會導(dǎo)致方案十分冗長，因此一種更好的方法是通過分析線上真實(shí)案例來確定方案，這樣產(chǎn)出的方案是最貼合線上情況的，后續(xù)也可以不斷結(jié)合案例做迭代優(yōu)化。

這里介紹下我們?nèi)绾未_定 SQL 類告警根因 SQL 分析方案。為了確定這個(gè)方案，我們分析了50個(gè)線上案例：首先找出哪些案例是能明顯看出有根因 SQL 的， 再對有根因 SQL 的類別進(jìn)行細(xì)化，最后得到根因 SQL 的判斷步驟。

3.1.2 演進(jìn)方案

針對某個(gè)故障場景的方案通常不是一步到位、直接擁有自動恢復(fù)故障的能力的，而是在實(shí)踐中不斷演進(jìn)。我們把方案演進(jìn)的過程分為下圖三個(gè)階段：

那么為什么要分階段去演進(jìn)方案呢？

從效率的角度看，能夠先快速上線比較簡單的方案，可以快速地提高運(yùn)維效率；

從可用性的角度看，前一階段是后一階段的基礎(chǔ)，只有前一階段驗(yàn)證成熟了，再去不斷演進(jìn)是比較安全的做法。

以 SQL 故障場景為例來演示方案的演進(jìn)過程。我們的 SQL 故障場景方案一開始只是提供數(shù)據(jù)和統(tǒng)計(jì)，然后進(jìn)一步地通過案例分析的方式，使其可以根據(jù)規(guī)則嘗試找出導(dǎo)致告警的根因 SQL，目前正在實(shí)現(xiàn)對根因 SQL 的自動優(yōu)化建議，最終目標(biāo)是可以具備對問題 SQL 自動優(yōu)化、自動限流的能力。

3.2 故障自愈流程

基于上述的思路，我們實(shí)現(xiàn)了一個(gè)故障消息驅(qū)動、基于規(guī)則的故障自愈流程。

首先我們監(jiān)聽了故障消息，當(dāng)自愈系統(tǒng)接收到故障消息時(shí)，會根據(jù)這個(gè)消息類型去規(guī)則庫中查找對應(yīng)的自愈流程，再通過流程編排引擎運(yùn)行起來。流程中會去調(diào)用相關(guān)基礎(chǔ)能力，最后生成一個(gè)處理結(jié)果通知，發(fā)送到我們的工作溝通軟件。同時(shí)也會將這次流程的運(yùn)行信息保存到分析中心，用戶后續(xù)可以在分析中心看到詳細(xì)的現(xiàn)場快照、分析結(jié)果，還能對這次分析進(jìn)行評價(jià)標(biāo)注。

下面對流程中的重點(diǎn)組件進(jìn)行介紹。

3.2.1 故障消息

首先是故障消息，在一開始設(shè)計(jì)時(shí)，我們期望是可以支持接入各種故障消息，比如告警事件、巡檢事件等，但是在實(shí)踐中，我們還是優(yōu)先針對 TOP 告警場景進(jìn)行開發(fā)，因?yàn)楣收舷⒅校^大部分都是告警。而且據(jù)我們統(tǒng)計(jì)，TOP 5 的告警差不多占了所有告警的一半，優(yōu)先針對 TOP 告警短期內(nèi)能取得不錯(cuò)的效果。

3.2.2 規(guī)則庫

規(guī)則庫保存了故障消息類型和自愈流程的綁定關(guān)系，自愈系統(tǒng)收到故障消息后，會根據(jù)這個(gè)消息類型去規(guī)則庫中查找對應(yīng)的自愈流程。這里我們實(shí)現(xiàn)了一個(gè)簡單的流程編排功能，我們的想法是，先實(shí)現(xiàn)一些原子操作，再去將這些操作組合成一個(gè)流程，這樣可以讓操作具有的復(fù)用性，也更容易實(shí)現(xiàn)新的流程。

比如針對 CPU 告警，我們將 TOP 分析和 SQL 根因分析獨(dú)立成兩個(gè)原子操作，這樣這兩個(gè)操作也能復(fù)用在其他流程中。

3.2.3 分析中心

在分析中心，用戶可以看到監(jiān)控告警詳情、現(xiàn)場快照、分析的結(jié)果，還可以通過這里向我們反饋這個(gè)告警的原因、如何排查等信息，幫忙我們?nèi)ミM(jìn)行迭代優(yōu)化。這樣自愈流程就不是一個(gè)黑盒了，也方便運(yùn)維人員之間進(jìn)行協(xié)作。

3.3 數(shù)據(jù)采集和計(jì)算

3.3.1 數(shù)據(jù)采集

故障自愈需要大量的數(shù)據(jù)支持，我們將數(shù)據(jù)分為三種類型。

監(jiān)控?cái)?shù)據(jù)：我們這邊的數(shù)據(jù)庫種類比較多，每種數(shù)據(jù)庫都有自己監(jiān)控采集方式；

日志數(shù)據(jù)：采集流程中 Agent 先會向 Manager 查詢自己需要采集哪些日志，然后以類似 tail 的方式一行一行地采集，再上報(bào)給 Manager，最后由 Manager 根據(jù)配置的正則表達(dá)式解析成結(jié)構(gòu)化數(shù)據(jù)，寫入 Kafka。這些日志包括慢日志、運(yùn)行日志、全量日志等；

事件數(shù)據(jù)：我們開發(fā)了一個(gè)事件系統(tǒng)的 SDK，由各個(gè)服務(wù)使用這個(gè) SDK，將自己服務(wù)的事件上報(bào)到事件系統(tǒng)。

3.3.2 數(shù)據(jù)計(jì)算

數(shù)據(jù)采集后，一些數(shù)據(jù)需要做計(jì)算處理。我們現(xiàn)在對數(shù)據(jù)做實(shí)時(shí)計(jì)算的場景比較少，下圖是近期的全量 SQL 需求。

首先由 Agent 采集 SQL LOG 文件，進(jìn)行批量上報(bào)，為了降低 Kafka 的帶寬壓力，上報(bào)的時(shí)候需要進(jìn)行壓縮。上報(bào)時(shí)指定實(shí)例地址作為 Kafka 分區(qū) Key， 以保證同一個(gè)實(shí)例的數(shù)據(jù)能寫到同一個(gè) Kafka 分區(qū)，因此也就能保證在實(shí)時(shí)計(jì)算端，同一個(gè)實(shí)例的數(shù)據(jù)會落在同一個(gè)處理線程上，這樣就能在接收到數(shù)據(jù)后，做一個(gè)預(yù)聚合，降低發(fā)往下游的網(wǎng)絡(luò)流量。然后通過逐層聚合的方式，先聚合出每分鐘每個(gè) SQL_ID 的平均執(zhí)行次數(shù)、平均響應(yīng)時(shí)間等指標(biāo)，再根據(jù)SQL_ID 的聚合數(shù)據(jù)，聚合出每分鐘每個(gè) Table 的平均訪問次數(shù)指標(biāo)。最后這份數(shù)據(jù)將用以支撐 SQL 趨勢、表流量統(tǒng)計(jì)、SQL 過載保護(hù)等功能。

4.成果和案例

4.1 成果

10+種故障場景分析和自愈能力：

使用6人月覆蓋線上70%以上告警：

4.2 案例

這里介紹一個(gè)案例：長時(shí)間執(zhí)行的 SQL 數(shù)量達(dá)到閾值后，產(chǎn)生了告警，根據(jù) SQL 根因分析得出，這是因?yàn)橛幸粭l長時(shí)間運(yùn)行的 SQL 阻塞了其他 SQL，并把分析結(jié)果推送到故障處理群。從分析詳情可以看出，這是一個(gè) MDL 鎖等待的經(jīng)典場景，因?yàn)槟硹l SQL 長時(shí)間運(yùn)行，備份進(jìn)程執(zhí)行 FLUSH 時(shí)請求 MDL 被阻塞，繼而引發(fā)后續(xù) SQL 請求 MDL 阻塞。

5.未來展望

展望未來，仍有許多事項(xiàng)需要逐步建設(shè)完善：

建立可觀測、可跟蹤的效果度量機(jī)制。目前可觀測的指標(biāo)只有告警覆蓋率，而對于每次分析的有效性和正確率，現(xiàn)在還無法度量，因此需要建立一套效果度量機(jī)制；

仍有許多基礎(chǔ)能力需要逐步建設(shè)完善，比如 SQL 優(yōu)化建議、SQL 限流等功能；

基于規(guī)則的故障自愈方案容易碰到投入產(chǎn)出比降低、系統(tǒng)能力瓶頸等問題，因此需要借鑒業(yè)界方案，逐步使用 AI 技術(shù)，在各個(gè)功能場景進(jìn)行嘗試。

作者介紹

林鋒英，vivo互聯(lián)網(wǎng)高級數(shù)據(jù)庫研發(fā)工程師。