首先，vivo自研了數(shù)據(jù)庫運(yùn)維平臺DaaS來支撐數(shù)據(jù)庫運(yùn)維工作。在規(guī)模覆蓋、效率提升、故障告警處理等層面均衡發(fā)力，保障了數(shù)據(jù)的穩(wěn)定性，以工單自助，故障自愈為核心，實(shí)現(xiàn)了數(shù)據(jù)庫的高效運(yùn)維。 

其次，在數(shù)據(jù)庫資源彈性管理層面，vivo重視資源成本優(yōu)化。圍繞資源分配、資源彈性伸縮、資源隔離分別給出了智能化解決方案，并通過套餐自動優(yōu)化，進(jìn)一步降低了管理成本。

最后，基于個人隱私數(shù)據(jù)，平臺也提供了對業(yè)務(wù)幾乎無影響的MySQL的透明加密方案，來減輕因?yàn)殡[私數(shù)據(jù)加密帶來的研發(fā)和運(yùn)維工作量。

一、云原生時代數(shù)據(jù)庫運(yùn)維挑戰(zhàn)

1.1 數(shù)據(jù)庫運(yùn)維體系演進(jìn)

從數(shù)據(jù)庫運(yùn)維體系的演進(jìn)歷程來看，

1、2000年左右，PC互聯(lián)網(wǎng)時代興起，商業(yè)數(shù)據(jù)庫是市場主流，而開源數(shù)據(jù)庫方興未艾。普遍的數(shù)據(jù)庫運(yùn)維方式，還是人工加腳本，當(dāng)時大部分公司數(shù)據(jù)庫規(guī)模量相對不大，這樣做完全夠用。人們面臨的主要運(yùn)維挑戰(zhàn)是商業(yè)數(shù)據(jù)庫軟硬件成本高，而開源數(shù)據(jù)庫軟件和配套工具不成熟，通常要自研來滿足開源數(shù)據(jù)庫自身的穩(wěn)定性和擴(kuò)展性要求，門檻高。

2、到了2010年左右，移動互聯(lián)網(wǎng)時代興起，社會數(shù)字化進(jìn)程陡然加速，數(shù)據(jù)量規(guī)模大增。此時，一個針對IT基礎(chǔ)設(shè)施的革命性的概念提出來了，那就是云計算，簡單來說，就是通過網(wǎng)絡(luò)的方式提供服務(wù)器，數(shù)據(jù)庫，或者某種軟件服務(wù)資源。在數(shù)據(jù)庫運(yùn)維領(lǐng)域，則自然衍生出了云計算的一個分支概念，DaaS，data as a service，數(shù)據(jù)庫的運(yùn)維方式因此由人工腳本方式轉(zhuǎn)變?yōu)榱藬?shù)據(jù)庫平臺的方式。同時，隨著開源數(shù)據(jù)庫技術(shù)以及各種周邊生態(tài)軟件走向成熟，開源數(shù)據(jù)庫得到了廣泛應(yīng)用。這時，數(shù)據(jù)庫運(yùn)維的挑戰(zhàn)變成了如何高效率交付資源，保障數(shù)據(jù)庫穩(wěn)定性，做好數(shù)據(jù)庫成本優(yōu)化。

3、到了2020年左右，后移動互聯(lián)網(wǎng)時代，社會數(shù)字化程度進(jìn)一步加深。云原生的概念被提了出來。微服務(wù)架構(gòu)，資源彈性，容器等云原生技術(shù)廣為傳播。數(shù)據(jù)庫的穩(wěn)定性方面，因?yàn)殚_源數(shù)據(jù)庫的高可用體系普遍成熟而大大緩解。數(shù)據(jù)庫規(guī)模方面，實(shí)例數(shù)量和品類都進(jìn)一步大增。數(shù)據(jù)庫安全方面，2021年8月我國正式出臺了個人信息保護(hù)法，個人隱私數(shù)據(jù)保護(hù)成為了數(shù)據(jù)庫運(yùn)維的時代重點(diǎn)。

1.2 云原生時代挑戰(zhàn)

這樣的時代背景下，我以為數(shù)據(jù)庫運(yùn)維主要有三個方面的挑戰(zhàn)：

1. 云原生時代應(yīng)用架構(gòu)普遍微服務(wù)化，一個系統(tǒng)拆成多個微服務(wù)，這個系統(tǒng)的數(shù)據(jù)庫也分拆成多個。這導(dǎo)致數(shù)據(jù)庫實(shí)例成倍增加，數(shù)據(jù)庫的運(yùn)維工作量也成倍增加。因此大規(guī)模數(shù)據(jù)庫實(shí)例如何有效運(yùn)維?這就是第一個挑戰(zhàn)。
2. 云原生理念應(yīng)用架構(gòu)層面的彈性伸縮，自然也要求數(shù)據(jù)庫層面做到彈性伸縮。具體來說，是效率上做到快速擴(kuò)縮，業(yè)務(wù)無損，成本上也要做到，按需按量使用。但是主流開源數(shù)據(jù)庫本身是存算一體架構(gòu)，這兩點(diǎn)支持不容易。數(shù)據(jù)庫如何做好資源彈性伸縮？這是第二個挑戰(zhàn)。
3. 數(shù)據(jù)庫安全方面，個人隱私數(shù)據(jù)需要保護(hù)，這個必要性無需多說，但是怎么技術(shù)落地？怎么識別個人隱私數(shù)據(jù)，識別之后又如何進(jìn)行數(shù)據(jù)加密。而開源數(shù)據(jù)庫在這方面，即也沒有具體的落地方案，沒有提供專門的工具，這些都有待自己探索。這是第三個挑戰(zhàn)。

挑戰(zhàn)講完了，接下來我們看下vivo在這三個挑戰(zhàn)方向的應(yīng)對。

二、vivo 大規(guī)模數(shù)據(jù)庫實(shí)例高效運(yùn)維

2.1 高效運(yùn)維實(shí)踐現(xiàn)狀

vivo是自研了數(shù)據(jù)庫運(yùn)維平臺DaaS來支撐數(shù)據(jù)庫運(yùn)維工作。

規(guī)模上，支撐了數(shù)萬數(shù)據(jù)庫實(shí)例的運(yùn)維服務(wù)，包含了6種數(shù)據(jù)庫：MySQL，Redis，MongoDB，Elasticsearch，TiDB5個開源數(shù)據(jù)庫，1個公司內(nèi)部自研的磁盤KV。

效率上，節(jié)省了92%的數(shù)據(jù)庫運(yùn)維工作量。月均數(shù)千的總工單量，其中92%都是無需運(yùn)維參與，由平臺用戶自助執(zhí)行。

故障告警處理上，70%的數(shù)據(jù)庫告警實(shí)現(xiàn)自動分析或者處理，進(jìn)一步解放了數(shù)據(jù)庫運(yùn)維人力，保障了數(shù)據(jù)穩(wěn)定性。

綜上所述，數(shù)據(jù)庫高效運(yùn)維的核心就是，工單自助，故障自愈。接下來將詳細(xì)介紹這兩點(diǎn)。

2.2 工單自助

首先看工單自助，要實(shí)現(xiàn)工單自助，主要有三點(diǎn)：

1. 95%運(yùn)維操作平臺化，用平臺操作替代手工或者腳本操作。所謂平臺化的本質(zhì)，就是用代碼的方式，將最佳的運(yùn)維經(jīng)驗(yàn)固化在平臺中。這才是一切運(yùn)維效率的基礎(chǔ)。
2. 99%工單成功率，一方面是要做到，所有運(yùn)維操作都有工單流記錄，這是運(yùn)維工作量化和進(jìn)步的基礎(chǔ)；另一方面，因?yàn)楫惓５墓芜€是要數(shù)據(jù)庫專業(yè)運(yùn)維介入處理的,所以只有工單一鍵執(zhí)行成功率達(dá)到99%以上才可以開放自助，才談得上提升了效率。
3. 部分開源數(shù)據(jù)庫生態(tài)工具是空白的，例如常見數(shù)據(jù)庫Redis 要數(shù)據(jù)變更自助，一方面需要做到變更過程業(yè)務(wù)無影響，這要求做好變革速度&負(fù)載控制，變更前排除大key等風(fēng)險因素。另一方面還需要做到變更過程數(shù)據(jù)安全，這要求變更前做好備份，變更后可隨時回滾。這些都沒有現(xiàn)成開源工具集成，vivo是通過自研逐個填補(bǔ)了這些工具空白。

2.3 故障自愈

隨著數(shù)據(jù)庫規(guī)模的成倍增加，故障告警的數(shù)目也急劇增多，vivo日均數(shù)百數(shù)據(jù)庫故障告警，存粹靠手工進(jìn)行告警問題排查處理越來越不能滿足數(shù)據(jù)庫穩(wěn)定性的要求。

數(shù)據(jù)庫故障自愈的需求就被自然提了出來。故障處理簡單分為：發(fā)現(xiàn)，定位，恢復(fù) 三個步驟，針對已經(jīng)發(fā)生的故障我們反復(fù)分析確認(rèn)，其中定位環(huán)節(jié)是最耗時，所以當(dāng)前故障自愈系統(tǒng)主要做的就是故障分析定位的工作。整體上故障自愈主要是兩個難點(diǎn)，一個故障自愈方案的確認(rèn)，另一個是相關(guān)基礎(chǔ)工具的開發(fā)。

通常認(rèn)為故障自愈方案最好是全面信息采集+機(jī)器學(xué)習(xí)自動確認(rèn)的，這樣的方案具備普適性，也更有效率且準(zhǔn)確。但是立足于團(tuán)隊(duì)和問題現(xiàn)狀，我們認(rèn)為當(dāng)前的故障自愈方案可以是全基于運(yùn)維專家經(jīng)驗(yàn)確認(rèn)的。這是因?yàn)樵跀?shù)據(jù)庫運(yùn)維方向，目前常見數(shù)據(jù)庫相關(guān)故障場景不到50個，且變量因素單一，所以即便憑借優(yōu)秀專家經(jīng)驗(yàn)枚舉處理辦法，也能自動解決大部分故障，簡單實(shí)用。另外在故障自愈的基礎(chǔ)工具上，我們主要自研了：Redis流量分析，熱key分析，MySQL 根因SQL分析等工具。

接下來介紹故障自愈的邏輯架構(gòu)：

整個系統(tǒng)是由故障告警驅(qū)動，系統(tǒng)獲取到告警消息后去查找相匹配的預(yù)案，然后執(zhí)行預(yù)案中設(shè)定的基礎(chǔ)操作，包括分析操作和恢復(fù)操作，例如Redis流量分析或者M(jìn)ySQL binlog清理等，最終生成執(zhí)行報告，其中包括中間狀態(tài)的現(xiàn)場監(jiān)控快照，智能的分析結(jié)果等，同時也提供案例標(biāo)注的能力。最后執(zhí)行結(jié)果會自動分配并通知到對應(yīng)負(fù)責(zé)的數(shù)據(jù)庫運(yùn)維人員或者消息群組當(dāng)中。

通過這套架構(gòu)，最后實(shí)現(xiàn)了超70%的故障自動分析或者處理，包括至少30個基礎(chǔ)能力建設(shè)，26個故障預(yù)案，10個故障場景全自動處理。

三、vivo 數(shù)據(jù)庫彈性資源管理

3.1 資源彈性管理問題&現(xiàn)狀

我們先來看vivo數(shù)據(jù)庫資源管理上要面臨的現(xiàn)狀和問題：

1. 傳統(tǒng)數(shù)據(jù)庫占主流，從數(shù)量上看，線上數(shù)據(jù)庫數(shù)萬個實(shí)例，85%是REDIS，10%是MySQL，剩下5%是其它數(shù)據(jù)庫。都是存算一體的傳統(tǒng)數(shù)據(jù)庫，彈性伸縮能力并不完美，例如開源Redis Cluster的彈性伸縮是單線程的，上了一定數(shù)據(jù)規(guī)模后其擴(kuò)縮速度和穩(wěn)定性都有待進(jìn)一步提升。
2. 當(dāng)前數(shù)據(jù)庫資源管理還沒有容器化，數(shù)據(jù)庫資源隔離得另想辦法。同時對于Redis等傳統(tǒng)數(shù)據(jù)庫來說，容器化也不能解決其彈性伸縮的速度和穩(wěn)定性問題，這些都只能從數(shù)據(jù)庫軟件本身上去解決。
3. 目前數(shù)據(jù)庫資源都是直接部署在物理機(jī)上，PB級數(shù)據(jù)直接部署在數(shù)千臺物理機(jī)上，數(shù)據(jù)庫成本問題比較敏感。

3.2 資源彈性管理主要實(shí)現(xiàn)點(diǎn)

針對上述問題，vivo數(shù)據(jù)庫平臺主要做了如下工作：

1. 資源分配上，實(shí)行單機(jī)器多實(shí)例多版本多套餐混合部署，同類數(shù)據(jù)庫資源池統(tǒng)一，提升資源利用率。
2. 資源彈性伸縮上，自研多線程Redis Cluster擴(kuò)縮工具，顯著加速Redis Cluster擴(kuò)縮容過程，同時增加限速，大key巡檢，歷史負(fù)載檢測，腦裂檢測等功能盡量增擴(kuò)縮容穩(wěn)定性。
3. 資源隔離上，則采用兩個措施。
   （1）程序配置實(shí)現(xiàn)隔離，如Redis，線程模型決定了幾乎只消耗一個CPU核心，而內(nèi)存占用也主要由配置決定，其它網(wǎng)絡(luò)磁盤很少存在爭用，所以混部就沒隔離問題了。
   （2）通過巡檢和容量預(yù)測的方式實(shí)現(xiàn)軟隔離，盡量解決非突增的資源爭用問題。

3.3 套餐自動優(yōu)化

在資源成本優(yōu)化上，除了剛才提過的混合部署，還可以做套餐自動優(yōu)化，進(jìn)一步降低成本。

下面介紹下具體的套餐自動優(yōu)化流程：

• 第一步 平臺自動掃描全網(wǎng)數(shù)據(jù)庫實(shí)例，挑出其中被認(rèn)定是滿足縮容條件的。
• 第二步 平臺自動發(fā)送縮容工單交由實(shí)例對應(yīng)的業(yè)務(wù)項(xiàng)目經(jīng)理審批。
• 第三步 根據(jù)審批結(jié)果執(zhí)行縮容，或者放棄本次縮容。

大概在這個功能上線后的4個月內(nèi)，平臺自動發(fā)起超千次縮容，節(jié)省了超百T空間。

四、vivo個人隱私數(shù)據(jù)全鏈路保護(hù)

4.1 隱私保護(hù)數(shù)據(jù)庫層面現(xiàn)狀

在線數(shù)據(jù)庫有數(shù)十萬張“表”，總計超千萬個字段，其中隱私數(shù)據(jù)識別覆蓋100% ，涉及MySQL，MongoDB，Elasticsearch，TiDB四種數(shù)據(jù)庫，人工抽查識別準(zhǔn)確度79%。

而當(dāng)個人隱私數(shù)據(jù)識別出來了，處理的主要手段就是加密，所以平臺也提供了對業(yè)務(wù)幾乎無影響的，MySQL的透明加密方案，來減輕因?yàn)殡[私數(shù)據(jù)加密帶來的研發(fā)和運(yùn)維工作量。

4.2 全鏈路功能

隱私數(shù)據(jù)庫保護(hù)應(yīng)該是貫穿業(yè)務(wù)研發(fā)階段，運(yùn)營階段的全鏈路保護(hù)。

• 研發(fā)階段：統(tǒng)一數(shù)據(jù)庫建表入口，同時提供平臺工具便于用戶對新建表中的隱私數(shù)據(jù)字段進(jìn)行標(biāo)記，這主要解決日常新增數(shù)據(jù)結(jié)構(gòu)的識別問題。
• 運(yùn)營階段：定期掃描全網(wǎng)表結(jié)構(gòu)數(shù)據(jù)，自動識別未標(biāo)記的隱私數(shù)據(jù)，并人工抽查校準(zhǔn)，這主要解決存量數(shù)據(jù)結(jié)構(gòu)的識別問題，同時也是研發(fā)階段識別的補(bǔ)充。
• 運(yùn)營階段操作：數(shù)據(jù)查詢結(jié)果中包含隱私數(shù)據(jù)自動加密顯示.數(shù)據(jù)導(dǎo)出隱私數(shù)據(jù)時自動加密，并添加水印。

4.3 最后的防線：數(shù)據(jù)庫加密

對于數(shù)據(jù)安全來說，數(shù)據(jù)庫加密是最后一道防線。前面提到隱私數(shù)據(jù)識別出來了，那么加密的目標(biāo)有了。基礎(chǔ)加密算法業(yè)界也比較成熟，加密方式也不缺。唯一的問題是，加密的過程。

對于新增業(yè)務(wù)來所，加密過程比較簡單，沒有業(yè)務(wù)訪問怎么做都行。但是對于存量的成熟業(yè)務(wù)來說，幾十張表，數(shù)據(jù)規(guī)模千萬記錄都是常事，怎么加密還能不影響用戶訪問，就是個麻煩的問題。為了解決這個痛點(diǎn)，目前數(shù)據(jù)庫平臺提供了一個存量業(yè)務(wù)數(shù)據(jù)無損加密方案，因?yàn)橹饕[私數(shù)據(jù)都在MySQL中，所以這是基于MySQL的。

首先介紹加密涉及的三個組件：數(shù)據(jù)庫平臺是用戶操作入口，表結(jié)構(gòu)變更工具gh-ost負(fù)責(zé)歷史數(shù)據(jù)加密轉(zhuǎn)化，MySQL代理負(fù)責(zé)讓加解密過程對業(yè)務(wù)程序透明。

接下來介紹無損加密的主要流程：

• 第一步、用戶要在數(shù)據(jù)庫平臺上配置需要加密的字段。如果不需要對歷史數(shù)據(jù)加密那么整個加密配置流程就結(jié)束了。
• 第二步、如果要加密歷史數(shù)據(jù)，就會產(chǎn)生一個數(shù)據(jù)清洗工單，交給表結(jié)構(gòu)變更工具gh-ost執(zhí)行，具體過程就是新增一個密文列復(fù)制明文列數(shù)據(jù)并加密。然后MySQL代理會自動將明文列請求轉(zhuǎn)向密文列，至此數(shù)據(jù)清洗完成。
• 第三步、步驟2執(zhí)行后，業(yè)務(wù)如果發(fā)現(xiàn)有問題，可以隨時回滾。業(yè)務(wù)方認(rèn)定數(shù)據(jù)加密后服務(wù)穩(wěn)定時，就可以選擇回收明文列，最后更新MySQL代理配置，去掉明文數(shù)據(jù)同步更新，整個加密過程就算完結(jié)，全程幾乎無需業(yè)務(wù)改動代碼，且對業(yè)務(wù)無損。

五、未來展望

5.1 故障處理

個人認(rèn)為故障自愈的演進(jìn)可以分為三個階段：

• 階段一：專家經(jīng)驗(yàn)式枚舉故障自愈（這是當(dāng)前所在的階段）。
• 階段二：在階段一基礎(chǔ)上引入AI判斷，形成AI判斷為輔，專家經(jīng)驗(yàn)為主的故障處理體系。
• 階段三：構(gòu)建AI判斷為主，專家經(jīng)驗(yàn)為輔的自愈系統(tǒng)，進(jìn)一步提升自動化程度。

3.2 資源管理

接下來在彈性資源管理這個方向，個人認(rèn)為其發(fā)展可以分為三個階段：

• 階段一：數(shù)據(jù)庫混合資源管理（這是當(dāng)前所在的階段，套餐，版本可以混合）。
• 階段二：數(shù)據(jù)庫容器混合資源管理，這一階段主要是利用容器消除機(jī)型隔離，品類隔離，有助于更高密度資源部署以及套餐統(tǒng)一標(biāo)準(zhǔn)化的實(shí)現(xiàn)。
• 階段三：存算分離架構(gòu)數(shù)據(jù)庫的資源管理。在底層資源調(diào)度層面發(fā)揮到極致后，只能通過數(shù)據(jù)庫架構(gòu)本身的升級提升資源彈性。

5.3 隱私數(shù)據(jù)治理

在個人隱私數(shù)據(jù)這個方向，還有兩個待解決的問題：

1. 第一個是，非結(jié)構(gòu)化數(shù)據(jù)隱私自動識別和加密問題。結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)，就是MySQL，MongoDB這種，通過字段的可以批量識別和處理一個表或者集合的隱私數(shù)據(jù)。但是對于Redis這種結(jié)構(gòu)，當(dāng)前一次只能識別和處理一個key-value鍵值對。解決思路是，非結(jié)構(gòu)化轉(zhuǎn)為半結(jié)構(gòu)化數(shù)據(jù)，例如特定前綴key或者正則key，綁定固定的value結(jié)構(gòu)。
2. 第二個問題是，隱私數(shù)據(jù)的識別準(zhǔn)確率問題，當(dāng)前只有79%，這個目前思路是人工標(biāo)注+AI識別。

5.4 數(shù)據(jù)庫平臺的未來展望

最后談下數(shù)據(jù)庫平臺建設(shè)，概括來說8個字，統(tǒng)一標(biāo)準(zhǔn)，開源共建。

展開來說，如今的數(shù)據(jù)庫技術(shù)市場百花齊放，DBengines網(wǎng)站榜上有名的數(shù)據(jù)庫就有395種，單個系統(tǒng)構(gòu)建依賴多個品類數(shù)據(jù)庫的情況逐漸普及，通過統(tǒng)一的數(shù)據(jù)庫平臺來支撐數(shù)據(jù)庫運(yùn)維工作，幾乎成了企業(yè)的剛性需求。但我們?nèi)狈σ粋€公認(rèn)的跨品類的數(shù)據(jù)庫運(yùn)維標(biāo)準(zhǔn)，也缺乏一個主流的跨越多品類的開源數(shù)據(jù)庫平臺。

個人期望用這樣的開源平臺來承載數(shù)據(jù)庫廠商，數(shù)據(jù)庫生態(tài)工具開發(fā)者以及企業(yè)用戶對數(shù)據(jù)庫服務(wù)共建的訴求，加速數(shù)據(jù)庫服務(wù)建設(shè)速度，讓云原生時代沒有難運(yùn)維的數(shù)據(jù)庫。