無(wú)感平滑遷移：海量高并發(fā)數(shù)據(jù)庫(kù)如何進(jìn)行國(guó)產(chǎn)化改造？

　　作者簡(jiǎn)介：鄭鴻健，中國(guó)移動(dòng)通信集團(tuán)信息技術(shù)公司政企業(yè)務(wù)支撐中心，數(shù)據(jù)庫(kù)專(zhuān)家，主要負(fù)責(zé)政企業(yè)務(wù)支撐中心數(shù)據(jù)層高性能、高可靠架構(gòu)的設(shè)計(jì)、優(yōu)化以及國(guó)產(chǎn)化的落地。

　　歷任騰訊DBA、樂(lè)信數(shù)據(jù)SRE負(fù)責(zé)人、業(yè)務(wù)SRE中心總監(jiān)，有豐富的數(shù)據(jù)庫(kù)、大數(shù)據(jù)、中間件及業(yè)務(wù)運(yùn)維經(jīng)驗(yàn)，主導(dǎo)過(guò)多種業(yè)務(wù)場(chǎng)景下高性能、高可用架構(gòu)設(shè)計(jì)、業(yè)務(wù)全鏈路容災(zāi)體系建設(shè)、SRE體系落地等大型項(xiàng)目。

　　今天分享的主題是“無(wú)感平滑遷移：海量高并發(fā)數(shù)據(jù)庫(kù)國(guó)產(chǎn)化改造及應(yīng)用”。

　　首先，講一下數(shù)據(jù)庫(kù)國(guó)產(chǎn)化的大背景。

　　國(guó)家戰(zhàn)略方面的，隨著外部形勢(shì)的日益復(fù)雜，核心技術(shù)急需實(shí)現(xiàn)自主可控、安全可靠、高效開(kāi)放；另一個(gè)要求是業(yè)務(wù)方面的，當(dāng)業(yè)務(wù)高速發(fā)展后各種問(wèn)題會(huì)接踵而至，單機(jī)數(shù)據(jù)庫(kù)達(dá)到瓶頸，業(yè)務(wù)拆分、垂直拆分、水平拆分等，都需要花費(fèi)大量的研發(fā)時(shí)間。

　　首先和大家分享一下目前主流的數(shù)據(jù)庫(kù)架構(gòu)。目前業(yè)內(nèi)主流的數(shù)據(jù)庫(kù)架構(gòu)大體分為三類(lèi)：Shared-Everything、Shared-Nothing，Shared-Storage。

　　Shared-Everything

　　這一種架構(gòu)可能大家都比較熟悉，是很經(jīng)典的一個(gè)架構(gòu)，主機(jī)上的所有進(jìn)程共享CPU、內(nèi)存、IO，任意一個(gè)硬件達(dá)到了瓶頸，也就意味著數(shù)據(jù)庫(kù)達(dá)到了瓶頸。Shared-Nothing

　　這里可以再細(xì)分出兩個(gè)架構(gòu)，一種是基于 Proxy 的架構(gòu)，這個(gè)架構(gòu)由傳統(tǒng)的單機(jī)數(shù)據(jù)庫(kù)演變而來(lái)，當(dāng)我們單機(jī)數(shù)據(jù)庫(kù)達(dá)到瓶頸以后，我們?cè)偻霞右粚?Proxy，通過(guò) Proxy 把我們的數(shù)據(jù)打散到不同的節(jié)點(diǎn)上，以此來(lái)解決數(shù)據(jù)擴(kuò)展性問(wèn)題；另一種 Shared-Nothing 架構(gòu)，是目前在國(guó)內(nèi)比較火的像 TiDB、OB 這樣的數(shù)據(jù)庫(kù)。

　　Shared-Storage

　　這種架構(gòu)在業(yè)內(nèi)比較有名的是的 Aurora，還有目前在國(guó)內(nèi)也比較火的阿里的 PolarDB。首先，先詳細(xì)介紹一下 Shared-Everything 架構(gòu)。這個(gè)架構(gòu)可能大家都比較熟悉，它是一種傳統(tǒng)的單機(jī)數(shù)據(jù)庫(kù)架構(gòu)，當(dāng)我們的數(shù)據(jù)庫(kù)達(dá)到瓶頸以后，我們通常會(huì)采用各種各樣的方式把我們的數(shù)據(jù)打散到各個(gè) set 里面去，以此來(lái)解決數(shù)據(jù)庫(kù)當(dāng)?shù)厝萘可舷薜膯?wèn)題。

　　有很多公司會(huì)通過(guò)這種方式來(lái)實(shí)現(xiàn)，把應(yīng)用層、接入層、網(wǎng)關(guān)層都根據(jù)同樣的分片邏輯，把數(shù)據(jù)整合到一個(gè) set 里面，從而實(shí)現(xiàn)數(shù)據(jù)在 set 里面的閉環(huán)。通過(guò)這樣的一套架構(gòu)能做非常多有意思的事情。比如一些全鏈路在線的壓測(cè)，因?yàn)閿?shù)據(jù)已經(jīng)在一個(gè) set 里面不閉環(huán)了，如果我在一個(gè)測(cè)試 set 里面做數(shù)據(jù)壓測(cè)，它不會(huì)污染到線上真實(shí)的數(shù)據(jù)，還可以做一些向線上的灰度引流、灰度發(fā)版等。Shared-Storage 架構(gòu)中，目前在國(guó)外做得特別好的是 AWS 的Aurora，在國(guó)內(nèi)做得比較好的是阿里的 PolarDB。因?yàn)樗鼘?duì)數(shù)據(jù)庫(kù)研發(fā)投入非常高，同時(shí)需要依托底層一個(gè)非常強(qiáng)大的底座，所以一開(kāi)始這些數(shù)據(jù)庫(kù)推出來(lái)之后，像 Aurora 至今都是只支持在云上部署。Shared-Nothing 架構(gòu)，大家已經(jīng)比較熟悉了，我們傳統(tǒng)的數(shù)據(jù)庫(kù)達(dá)到瓶頸演進(jìn)后，單機(jī)解決不了性能、容量問(wèn)題，于是就加一層Proxy，在 Proxy 上做各種各樣的路由，這樣的架構(gòu)慢慢地演進(jìn)到現(xiàn)在。國(guó)內(nèi)有非常多基于這樣的架構(gòu)去演化出來(lái)的數(shù)據(jù)庫(kù)，目前移動(dòng)用的比較多的數(shù)據(jù)庫(kù)都是類(lèi)似的架構(gòu)。

　　這套架構(gòu)主要可以分成三類(lèi)組件：GTM 組件負(fù)責(zé)全局的協(xié)調(diào)，主要用來(lái)取協(xié)調(diào)分布式事務(wù)的管理，包括全局 ID 的生成活躍，GTE ID 的快照等等。Proxy/計(jì)算節(jié)點(diǎn)。一開(kāi)始 Proxy 這一層可能只是簡(jiǎn)單做數(shù)據(jù)的路由，但是后面隨著整個(gè)數(shù)據(jù)庫(kù)架構(gòu)的演進(jìn)，Proxy 這一層也承擔(dān)起一定的計(jì)算能力，包括分布式事務(wù)的優(yōu)化、計(jì)算的下推，還有一些 SQL 解析等。底層的存儲(chǔ)節(jié)點(diǎn)，大多數(shù)目前都是基于開(kāi)源的數(shù)據(jù)庫(kù)去做二次開(kāi)發(fā)，目前比較常見(jiàn)的就是 MySQL 和 PostgreSQL。它的架構(gòu)的好處就是比較成熟穩(wěn)定。但是它的壞處就是整個(gè)改造的過(guò)程非常痛苦，因?yàn)槲覀冊(cè)谡麄€(gè)改造的過(guò)程中，第一步需要去選取分片鍵，然后根據(jù)我們的分片鍵把數(shù)據(jù)打散到不同的節(jié)點(diǎn)上去，這一步就足以讓業(yè)務(wù)抓狂。Shared-Nothing 的另外一種架構(gòu)是剛剛提到的OB、TiDB。這里以TiDB為例， TiDB是基于谷歌的論文去開(kāi)發(fā)的一套分布式數(shù)據(jù)庫(kù)。這個(gè)數(shù)據(jù)庫(kù)它分成三層，調(diào)度層PD，計(jì)算節(jié)點(diǎn)TiDB，然后是底層的存儲(chǔ)節(jié)點(diǎn)TiKV。但是TiDB它在使用的過(guò)程中不需要顯式地去指定分片鍵，它數(shù)據(jù)的分片拆分都是與依托于底下的數(shù)據(jù)庫(kù)自動(dòng)去完成的，所以采用這樣的架構(gòu)的話，改造成本可能會(huì)相對(duì)于低一些。小結(jié)，以上提到的四種數(shù)據(jù)庫(kù)架構(gòu)，可以看到它們?cè)跀U(kuò)展性層面，除了第一種沒(méi)辦法做到動(dòng)態(tài)橫向擴(kuò)容，后面的三種其實(shí)只要改造完了，基本上都能做到數(shù)據(jù)層的橫向擴(kuò)容。在一致性方面，第一種和最后一種基本上都是依托于半同步去保證各個(gè)節(jié)點(diǎn)之間的一致性。中間這兩類(lèi)數(shù)據(jù)庫(kù)一般都是用了分布式一致性協(xié)議，目前用的比較多的是 Paxio協(xié)議，還有的 Raft 協(xié)議。

　　下面，跟大家分享我們?cè)跀?shù)據(jù)庫(kù)國(guó)產(chǎn)化挑戰(zhàn)與探索上的一些實(shí)踐經(jīng)驗(yàn)。業(yè)務(wù)邏輯和數(shù)據(jù)層的深度綁定是我們整個(gè)數(shù)據(jù)庫(kù)改造過(guò)程中最頭疼的一個(gè)點(diǎn)，于是出現(xiàn)了各種各樣的數(shù)據(jù)庫(kù)遷移方案，總結(jié)下來(lái)無(wú)非是以下七步：選型、測(cè)試、同步、改造、灰度、上線、保障。

　　首先是選型階段，我們關(guān)注更多的是穩(wěn)定性、效率、成本以及生態(tài)。選型階段是一個(gè)很重要的階段，因?yàn)槿绻x型選得好，可以極大地降低我們?cè)诤竺鏀?shù)據(jù)庫(kù)國(guó)產(chǎn)化改造的過(guò)程中的成本。但是很多時(shí)候我們?cè)谧鰯?shù)據(jù)庫(kù)改造的過(guò)程中，選型階段除了考慮技術(shù)的因素外，還有很多非技術(shù)的因素需要去考慮，所以最后我們只能在有限的范圍內(nèi)選出最優(yōu)解。不能指望在選型階段就把整個(gè)數(shù)據(jù)庫(kù)國(guó)產(chǎn)化改造中的所有問(wèn)題都一并解決掉。緊接著是測(cè)試階段，我們拿到一塊數(shù)據(jù)庫(kù)之后，可能會(huì)做各種各樣的測(cè)試，比如基礎(chǔ)功能測(cè)試、可用性測(cè)試、可維護(hù)性測(cè)試，還有一些基礎(chǔ)的性能測(cè)試等。但是哪怕我們做了這樣的測(cè)試以后，也不能保證這套數(shù)據(jù)庫(kù)可以滿足業(yè)務(wù)的需求，更多的是我們?cè)谧鐾赀@樣的一些測(cè)試之后，淘汰一些不滿足我們需求的一些數(shù)據(jù)庫(kù)。如果我們想篩選出哪些數(shù)據(jù)庫(kù)能基本符合我們的要求，可能還要結(jié)合一些線上的流量錄制以及流量回放的一些東西。數(shù)據(jù)同步這里可以稍微展開(kāi)講一下，這一塊主要是分為全量數(shù)據(jù)同步和增量數(shù)據(jù)同步，我強(qiáng)烈建議大家在做這種大數(shù)據(jù)量的遷移時(shí)候，不要上來(lái)就去研究全備要用物理備份還是邏輯備份，哪個(gè)工具強(qiáng)，哪個(gè)工具差。第一步更多的是需要去分析一下自己的業(yè)務(wù)，分析自己的庫(kù)表、業(yè)務(wù)邏輯是怎樣的、數(shù)據(jù)到底是怎么分布的，哪些是歷史數(shù)據(jù)、熱數(shù)據(jù)、冷數(shù)據(jù)，哪些數(shù)據(jù)是可以現(xiàn)在立馬要遷移的、哪些數(shù)據(jù)是可以放到放到后面慢慢遷的……在做完這樣的數(shù)據(jù)分析之后，再來(lái)做全量和增量的數(shù)據(jù)遷移，往往可以做到事半功倍。

　　在增量同步這一塊，我們內(nèi)部也開(kāi)發(fā)了類(lèi)似的一個(gè)增量數(shù)據(jù)的同步工具。它是去監(jiān)聽(tīng)了數(shù)據(jù)庫(kù)變化的日志，然后把這些變化通過(guò)通過(guò)中間件的方式寫(xiě)到像 Kafka 這樣的消息中間件，然后有需求的業(yè)務(wù)再去定從我們的中間件里面去訂閱。通過(guò)這樣的一個(gè)工具能做非常多有意思的事情。像我們剛剛提到的數(shù)據(jù)遷移，那么可以通過(guò)這些工具的來(lái)做異構(gòu)數(shù)據(jù)的同步，還可以做一些像數(shù)據(jù)庫(kù)當(dāng)緩存之間的同步，或者是說(shuō) OLTP 向 OlAP之間的同步等等。通過(guò)這個(gè)工具能解決非常多的業(yè)務(wù)的痛點(diǎn)。業(yè)務(wù)改造這一塊也是非常痛苦的一個(gè)點(diǎn)。我們改造的關(guān)鍵點(diǎn)主要分兩塊，一塊是應(yīng)用，應(yīng)用這一塊更多的是關(guān)注一些驅(qū)動(dòng)程序、語(yǔ)法兼容、數(shù)據(jù)對(duì)象等等、API、 SQL 等等的一些東西。數(shù)據(jù)庫(kù)這一層更多的是關(guān)注一些像數(shù)據(jù)分片、冷熱分離、輕重隔離、SQL優(yōu)化、讀寫(xiě)分離等等這一些的東西。

　　這個(gè)適配改造我們目前改造的積累下來(lái)的需要關(guān)注的點(diǎn)，已經(jīng)到大幾十項(xiàng)了，所以這里我也沒(méi)有詳細(xì)地列出來(lái)，只是稍微地把它匯總了一下。我剛剛在前面幾頁(yè)提到的就是數(shù)據(jù)庫(kù)國(guó)產(chǎn)化改造中最大的一個(gè)痛點(diǎn)就是業(yè)務(wù)邏輯和數(shù)據(jù)庫(kù)的深度耦合，把這個(gè)問(wèn)題給解決掉。所以我們?cè)诟脑斓倪^(guò)程中逐步地把那個(gè) DB 給弱化成一個(gè)簡(jiǎn)單的存儲(chǔ)，然后明確應(yīng)用和數(shù)據(jù)之間的一個(gè)邊界，然后再去做各種各樣的適配改造。通過(guò)這一系列操作把數(shù)據(jù)庫(kù)國(guó)產(chǎn)化的這件事情，也作為我們整一個(gè)架構(gòu)的梳理和優(yōu)化。切換方案這里可以稍微簡(jiǎn)單地提一下。我們的切換方案主要有兩種，目前這兩種方案都有在用：第一種是基于數(shù)據(jù)層的中間件的方案，這種方案相對(duì)而言會(huì)比較簡(jiǎn)單一些，另一種方案是基于應(yīng)用的雙寫(xiě)方案，這種方案可能相對(duì)比較復(fù)雜，但是這種穩(wěn)定性和安全性要求會(huì)對(duì)穩(wěn)定性和要求的保障會(huì)更好一些。

　　我先簡(jiǎn)單介紹一下基于數(shù)據(jù)層的切換，一開(kāi)始我們的應(yīng)用可能都是直接連到我們的 DB，中間有一些 VIP 的東西，我直接給它省略掉。開(kāi)始我們給它加了一層中間件，從第一步到第二步之間，因?yàn)橹虚g件指向的也是我們的這個(gè)DB，所以研發(fā)可以慢慢地去改。這個(gè)改造的過(guò)程耗費(fèi)十天半個(gè)月都沒(méi)有關(guān)系，這它對(duì)業(yè)務(wù)是不會(huì)有任何的影響的。當(dāng)我們把所有的流量都切到中間件以后，我們?cè)跀?shù)據(jù)庫(kù)這一層去抓包，確保我們的那個(gè)請(qǐng)求全部都是通過(guò)中間件來(lái)的。等到應(yīng)用全部改造完成了之后，我們把數(shù)據(jù)全量地同步到新的數(shù)據(jù)庫(kù)去，然后可以把我們的讀流量放到新數(shù)據(jù)庫(kù)上。因?yàn)閼?yīng)用已經(jīng)通過(guò)我們的中間件過(guò)來(lái)的，所以我們?cè)谥虚g件上做讀寫(xiě)分離，對(duì)到應(yīng)用來(lái)說(shuō)是完全透明的。我們把我們的讀流量打到我們的新的數(shù)據(jù)庫(kù)上來(lái)，以此去驗(yàn)證新的數(shù)據(jù)庫(kù)是否能夠滿足業(yè)務(wù)的要求，當(dāng)然通過(guò)這樣的架構(gòu)其實(shí)是沒(méi)有辦法做到寫(xiě)流量的驗(yàn)證的。在切換過(guò)程，對(duì)業(yè)務(wù)的影響就只是那么零點(diǎn)幾秒的閃斷，替換完之后我們?cè)侔褦?shù)據(jù)往回同步，如果真的出現(xiàn)了問(wèn)題，我們還有一個(gè)退路可以往回退。第二種方案是業(yè)務(wù)雙寫(xiě)的方案，這一個(gè)方案可能會(huì)相對(duì)于上一個(gè)方案來(lái)說(shuō)更穩(wěn)妥，但是也更復(fù)雜一些。首先我們準(zhǔn)備一套新的數(shù)據(jù)庫(kù)，先做全量同步，再做增量同步，保證兩邊的數(shù)據(jù)是追平的。然后我們?cè)僬乙粋€(gè)時(shí)間窗口，當(dāng)然前提是我們就上一步已經(jīng)執(zhí)行完了，就是我們應(yīng)用的適配卡照已經(jīng)執(zhí)行完了，然后通過(guò)我們的應(yīng)用去開(kāi)啟我們的雙寫(xiě)，然后保證兩邊的數(shù)據(jù)都寫(xiě)一致，這個(gè)時(shí)候我再去把增量同步給停掉，然后底下再開(kāi)啟一個(gè)腳本，異步地去對(duì)比兩邊的數(shù)據(jù)，保證兩邊的數(shù)據(jù)是一致的。對(duì)賬的過(guò)程中如果發(fā)現(xiàn)不一致的東西，就打日志出來(lái)，然后人工分析，當(dāng)保證兩邊是一致以后，就可以開(kāi)始去分析一下。因?yàn)檫@個(gè)時(shí)候我們的業(yè)務(wù)是以老庫(kù)為主，新庫(kù)為輔，這個(gè)時(shí)候新庫(kù)它是既有讀又有寫(xiě)的，我們可以從業(yè)務(wù)上去觀察到新庫(kù)的各種解指標(biāo)，包括耗時(shí)、錯(cuò)誤率等等，如果新庫(kù)是有問(wèn)題的，在這個(gè)階段基本上都能發(fā)現(xiàn)，而且對(duì)業(yè)務(wù)是毫無(wú)影響的。足夠穩(wěn)定之后我們?cè)龠M(jìn)行雙寫(xiě)扭轉(zhuǎn)，把新庫(kù)為主，舊庫(kù)為輔，然后這樣再持續(xù)穩(wěn)運(yùn)行一段時(shí)間。當(dāng)我們發(fā)現(xiàn)用新的庫(kù)足夠穩(wěn)定之后，再把雙寫(xiě)給下掉。做完了上面那一步，就到了上線后的保障階段。這里主要分兩塊來(lái)做，一塊是可觀致性，另外一塊是可控性、可觀測(cè)性，保證了我們?cè)诔霈F(xiàn)故障的時(shí)候能夠快速地發(fā)現(xiàn)，快速地定位，可控性保證了我們?cè)诔霈F(xiàn)故障之后可以快速地響應(yīng)以及快速地恢復(fù)。可觀測(cè)性這一塊loging、 tracing、metric 這三個(gè)大家都經(jīng)常聽(tīng)到，就不細(xì)說(shuō)了。在我們內(nèi)部其實(shí)也針對(duì)剛剛的那幾個(gè)點(diǎn)做了對(duì)應(yīng)的建設(shè)，包括底層資源的監(jiān)控，業(yè)務(wù)層的監(jiān)控、日志采集平臺(tái)、調(diào)用鏈路分析平臺(tái)。在可恢復(fù)這一塊，其實(shí)我們通過(guò)過(guò)往的故障可以發(fā)現(xiàn)就是故障的時(shí)候，故障恢復(fù)的時(shí)間大多數(shù)并不是花在就是故障的修復(fù)的那一刻，時(shí)間更多的是花在信息的溝通人員的分工上，就從故障的出現(xiàn)到協(xié)調(diào)到對(duì)應(yīng)的人，然后再把信對(duì)應(yīng)的信息同步，再到?jīng)Q策要做怎么樣的操作。我們對(duì)時(shí)間分布做了一整套應(yīng)急響應(yīng)體系。我們把故障分為輕微問(wèn)題、中等問(wèn)題、還有重大問(wèn)題，以此打造了一個(gè)預(yù)案管理平臺(tái)，平時(shí)運(yùn)維可能更多的只需要在上面建立我們的原子化的一些預(yù)案能力。舉個(gè)例子，SQL 的kill，數(shù)據(jù)庫(kù)的主從切換等等這樣的一些原子能力。然后我們把這樣各種各樣的非常成熟的原子能力整合到那個(gè)預(yù)案平臺(tái)，然后在預(yù)案平臺(tái)上做各種各樣的故障預(yù)案的編排，結(jié)合AI，在出現(xiàn)故障的時(shí)候，自動(dòng)地去推薦預(yù)案再輔以人為的判斷。通過(guò)把這樣的一些智能化的預(yù)案推送到我們的移動(dòng)端，那么人可能需要做的事情只是在移動(dòng)端上點(diǎn)一點(diǎn)，那么它就可以自動(dòng)化地去執(zhí)行我們的預(yù)案。像遇到一些在改造過(guò)程中遇到的比較簡(jiǎn)單的問(wèn)題，就執(zhí)行降級(jí)操作，降級(jí)包括業(yè)務(wù)降級(jí)、請(qǐng)求降級(jí)、底層的資源降級(jí)，技術(shù)層面可能我們還會(huì)做一些架構(gòu)的降級(jí)。

　　最后我們還有我們的兜底方案，前面提到的切換方案中，不管是我們的雙寫(xiě)方案，還是我們基于數(shù)據(jù)庫(kù)中間件切換的方案，都能保證我們?cè)诿爰?jí)內(nèi)做那個(gè)數(shù)據(jù)庫(kù)的回退。像雙寫(xiě)方案，因?yàn)槲覀儼涯莻€(gè)雙寫(xiě)作為做一個(gè)配置項(xiàng)存的一個(gè)開(kāi)關(guān)里面，我們做回退只需要修改一下那個(gè)數(shù)據(jù)庫(kù)切換的一個(gè)開(kāi)關(guān)，像中間件的方案，我們只需要切換一下后端的指向。最后，對(duì)我們?cè)跀?shù)據(jù)庫(kù)國(guó)產(chǎn)化改造的經(jīng)驗(yàn)做個(gè)小結(jié)。第一是合適就好。其實(shí)大多數(shù)時(shí)候，集中式的數(shù)據(jù)庫(kù)仍然是當(dāng)前的一個(gè)最優(yōu)解，如果你的數(shù)據(jù)可能只有幾百G，甚至可能就兩三個(gè)T，那么集中式數(shù)據(jù)庫(kù)可能仍是當(dāng)前最好的選擇，因?yàn)槟悴恍枰コ袚?dān)數(shù)據(jù)分片，還有這種各種的各樣跨節(jié)點(diǎn)同步的耗時(shí)這樣一系列的問(wèn)題。第二是沒(méi)有銀彈，但不要指望用一種數(shù)據(jù)庫(kù)去解決所有的問(wèn)題。過(guò)去我們?cè)谟?Oracle 的時(shí)候，然后 Oracle 承擔(dān)了太多不應(yīng)該他承擔(dān)的東西了。現(xiàn)在我們?cè)谧龅臄?shù)據(jù)庫(kù)改造的過(guò)程中，慢慢的我們也在解決這樣的一個(gè)問(wèn)題，像該扛量的我們用 Redis，像即席查詢，那么用 clickhouse 這樣的一些數(shù)據(jù)庫(kù)去扛，然后做一些大的一些報(bào)表分析的這樣的一些東西。可能我們會(huì)通過(guò)我們的同步工具同步到我們的大數(shù)據(jù)平臺(tái)，通過(guò)大數(shù)據(jù)平臺(tái)去做這樣的一些分析。第三是拆掉運(yùn)維里的墻，打破技術(shù)和業(yè)務(wù)的壁壘。技術(shù)只有服務(wù)于業(yè)務(wù)、和業(yè)務(wù)結(jié)合，而運(yùn)維只有跳出自己的框框，站到全局的視角去看待問(wèn)題，那么才能真正做到的事半功倍，才能稱(chēng)之為真正的技術(shù)運(yùn)營(yíng)。以上是我這次的分享，非常感謝大家。還不過(guò)癮？還想了解更多國(guó)產(chǎn)數(shù)據(jù)庫(kù)改造的精彩話題？6月29-6月30，DevOps 國(guó)際峰會(huì)（DOIS） 2023 · 北京站，BizDevOps、精益/敏捷、信創(chuàng)、SRE 穩(wěn)定性、技術(shù)運(yùn)營(yíng)，關(guān)于運(yùn)維、DevOps 的精彩內(nèi)容，都在這里！

　　長(zhǎng)按圖片二維碼，訪問(wèn)大會(huì)官網(wǎng)！近期好文：運(yùn)維人如何少背鍋？這 7 種常見(jiàn)監(jiān)控工具，你是否全用過(guò)？投稿郵箱：jiachen@greatops.net，或添加聯(lián)系人微信：greatops1118。點(diǎn)個(gè)“在看”，一年不宕機(jī)