一、背景目標(biāo)

首先，分享一下 B 站數(shù)據(jù)質(zhì)量保障的背景和目標(biāo)。

B 站數(shù)據(jù)建設(shè)的歷史演進(jìn)可以分為四個階段。

數(shù)據(jù)庫階段。在這個階段B 站處于初創(chuàng)階段，業(yè)務(wù)也在初步發(fā)展中，數(shù)據(jù)逐漸受到各方的重視。這一階段的質(zhì)量保障重點在于設(shè)計測試用例、驗證數(shù)據(jù)正確性，并進(jìn)行數(shù)據(jù)庫的監(jiān)控和調(diào)優(yōu)。

數(shù)據(jù)倉庫階段。這個階段的出現(xiàn)是因為隨著業(yè)務(wù)的發(fā)展，各方對數(shù)據(jù)的需求也日益增加，更加關(guān)注 OLAP 相關(guān)的需求。隨著業(yè)務(wù)的復(fù)雜性增加，我們意識到單一數(shù)據(jù)庫無法滿足需求。這一階段更加注重數(shù)據(jù)的完整性、準(zhǔn)確性、一致性和及時性的保障。

數(shù)據(jù)平臺階段。隨著中國互聯(lián)網(wǎng)浪潮的興起，數(shù)據(jù)量急劇增加，隨之進(jìn)入了數(shù)據(jù)平臺階段。在傳統(tǒng)的 OLAP 分析系統(tǒng)（如TeraData）和 SaaS 傳統(tǒng)分析系統(tǒng)中，面對大數(shù)據(jù)場景，數(shù)據(jù)無法有效地服務(wù)于應(yīng)用分析體系。因此，我們逐漸引入開源生態(tài)系統(tǒng)，如 Hadoop 和相關(guān)開源組件。這個階段更加關(guān)注保障架構(gòu)的質(zhì)量，包括鏈路的可用性和數(shù)據(jù)加工鏈路的多樣性，以及實時鏈路。

中臺階段。不僅要承接前三個階段的數(shù)據(jù)和需求，還要著重解決業(yè)務(wù)問題和數(shù)據(jù)化的核心需求。在這個階段，業(yè)務(wù)逐漸多樣化，要求能力服務(wù)化和數(shù)據(jù)智能化。在質(zhì)量保障方面，兼容了前三個階段的內(nèi)容，并基于這些內(nèi)容展開了一些延展討論。這將是接下來分享的重點。

這里想強調(diào)的一點是，數(shù)據(jù)質(zhì)量保障是持續(xù)發(fā)展的。只有了解不同階段的背景和目標(biāo)，才能更好地實現(xiàn)數(shù)據(jù)質(zhì)量保障。

B站數(shù)據(jù)中臺當(dāng)前數(shù)據(jù)架構(gòu)如下圖所示。整體上分為四個層次，自下而上分別是數(shù)據(jù)源、數(shù)據(jù)平臺、數(shù)據(jù)中臺和數(shù)據(jù)應(yīng)用。

數(shù)據(jù)源包括多個相關(guān)的服務(wù)系統(tǒng)，如賬戶系統(tǒng)、埋點系統(tǒng)、CRM 系統(tǒng)和第三方系統(tǒng)等。這些系統(tǒng)為我們的數(shù)據(jù)倉庫提供持續(xù)的數(shù)據(jù)，這些數(shù)據(jù)通過數(shù)據(jù)平臺進(jìn)行集成，并具備離線和實時的能力，將數(shù)據(jù)導(dǎo)入到數(shù)據(jù)倉庫體系中。

在部分場景下，我們推進(jìn)全域數(shù)據(jù)的中心化建設(shè)。在此基礎(chǔ)上，再進(jìn)行相應(yīng)的主題域拆解，這是互聯(lián)網(wǎng)行業(yè)常見的主題域劃分，包括用戶主題、交易主題、內(nèi)容主題、營銷社區(qū)等。此外，我們還進(jìn)行了更多類似于分析項的體系化建設(shè)。

在數(shù)據(jù)應(yīng)用層面，可以簡單地分為 PC 端和移動端的數(shù)據(jù)應(yīng)用。我們著重關(guān)注埋點分析看板，包括增長、運營、內(nèi)容等方面的數(shù)據(jù)展示。我們可以看到數(shù)據(jù)的流轉(zhuǎn)管道，即數(shù)據(jù)管道，已經(jīng)擴展得非常龐雜。與傳統(tǒng)的數(shù)據(jù)倉庫不同，質(zhì)量保障不再僅僅基于單一的 OLAP 系統(tǒng)，而可能涉及多層次、多組件、多團隊甚至多部門之間的合作和溝通，以推進(jìn)保障工作。

隨著業(yè)務(wù)的發(fā)展，對數(shù)據(jù)質(zhì)量保障的需求也日益增加。下圖中展示了一些來自與我們合作頻繁的團隊的反饋，這些反饋涉及到日常合作中經(jīng)常出現(xiàn)的問題。這進(jìn)一步證明了數(shù)據(jù)質(zhì)量保障的需求隨著業(yè)務(wù)的發(fā)展而增加。

我們收集到的反饋包括但不限于以下幾點：

首先，分析看板的頁面顯示數(shù)據(jù)沒有展示透出，這可能會影響用戶體驗。

其次，分析師可能會反饋某天的數(shù)據(jù)指標(biāo)為零是否合理，因為這可能會影響他們的業(yè)務(wù)決策。

此外，開發(fā)同學(xué)也有數(shù)據(jù)質(zhì)量方面的需求，比如夜間的值班報警電話頻繁響起，起夜率爆表等，這會嚴(yán)重影響同學(xué)們的正常作息。

基于以上情況，我們抽象出三個方面的核心保障痛點：

數(shù)據(jù)使用方，希望數(shù)據(jù)能夠按預(yù)期時間產(chǎn)出，并且數(shù)據(jù)準(zhǔn)確可信。在故障發(fā)生時，希望能夠快速恢復(fù)，不影響正常使用。

作為數(shù)據(jù)建設(shè)方，我們需要根據(jù)業(yè)務(wù)發(fā)展的時間推演，確定哪些數(shù)據(jù)是用戶真正關(guān)注的，優(yōu)先進(jìn)行強保障，而對于長尾部分可以適當(dāng)降級。開發(fā)同學(xué)也希望了解用戶對數(shù)據(jù)質(zhì)量和時效性的具體要求。

管道方是與數(shù)據(jù)倉庫協(xié)同配合的兄弟團隊，他們對于流轉(zhuǎn)到其管道中的數(shù)據(jù)也有保障需求。因為作為數(shù)據(jù)鏈路的上下游相關(guān)方，任何一個節(jié)點出現(xiàn)問題都可能導(dǎo)致數(shù)據(jù)不準(zhǔn)確，數(shù)據(jù)質(zhì)量不達(dá)標(biāo)。他們的訴求更多是在極端情況下的恢復(fù)響應(yīng)要求以及不同場景的保障要求。

總體目標(biāo)是通過持續(xù)改善數(shù)據(jù)質(zhì)量，減少事故糾錯成本，降低數(shù)據(jù)使用風(fēng)險，并提升業(yè)務(wù)服務(wù)滿意度。

讓我們進(jìn)一步深入探討，了解質(zhì)量問題產(chǎn)生的根本原因。我們進(jìn)行了一些梳理，將其分為四個部分：

技術(shù)原因。數(shù)據(jù)經(jīng)過多個層次的加工才得到最終結(jié)果，因此不同鏈路的標(biāo)準(zhǔn)制定對于數(shù)據(jù)質(zhì)量至關(guān)重要。這包括模型設(shè)計的合理性，是否充分理解數(shù)據(jù)的業(yè)務(wù)含義，并根據(jù)此進(jìn)行相應(yīng)的數(shù)據(jù)加工，以獲得準(zhǔn)確的結(jié)果。此外，數(shù)據(jù)采集和清洗過程是否符合標(biāo)準(zhǔn)規(guī)范也是關(guān)鍵。

業(yè)務(wù)原因。數(shù)據(jù)主要承載業(yè)務(wù)的表達(dá)。脫離了業(yè)務(wù)場景，數(shù)據(jù)往往就不再有任何價值。因此，如果對業(yè)務(wù)理解不到位，包括業(yè)務(wù)流程的變更沒有及時了解，都會影響最終數(shù)據(jù)質(zhì)量的展現(xiàn)。

管理原因。首先，流程管理是否足夠完善是一個重要方面。其次，團隊成員是否具備足夠的質(zhì)量保障意識也很關(guān)鍵。第三，獎懲機制的設(shè)立也是必要的。因為質(zhì)量保障是一個嚴(yán)肅的話題，一旦出現(xiàn)問題，我們需要有明確的責(zé)任分配計劃，以引起大家對此事的關(guān)注，并確保日常數(shù)據(jù)的持續(xù)保障。

推進(jìn)方面的原因。一旦確立了相關(guān)標(biāo)準(zhǔn)，我們需要將這些準(zhǔn)則明確地推進(jìn)到各個工作的細(xì)節(jié)中，以確保歷史相關(guān)問題不再重現(xiàn)。此外，長期的可持續(xù)優(yōu)化策略對于數(shù)據(jù)質(zhì)量的保障也非常重要。

根據(jù)以上對問題原因的梳理，我們總結(jié)了三個主要方向上的痛點：

首先是整體數(shù)據(jù)質(zhì)量保障的范圍和目標(biāo)不夠清晰。這體現(xiàn)在各個團隊對需要保障的數(shù)據(jù)范圍缺乏清晰的認(rèn)識，有些鏈路甚至沒有進(jìn)行日常的保障。并且，保障分級不夠準(zhǔn)確，導(dǎo)致無法區(qū)分不同能力投入的保障需求。隨著數(shù)據(jù)建設(shè)的推進(jìn)，架構(gòu)變得越來越復(fù)雜。保障目標(biāo)沒有拆解到相關(guān)團隊，導(dǎo)致這些團隊沒有進(jìn)行相應(yīng)的保障工作，影響了數(shù)據(jù)保障的最終結(jié)果。

另一方面的痛點是無法衡量保障效果。我們上學(xué)時都對分?jǐn)?shù)有著深刻的體驗，分?jǐn)?shù)可以衡量學(xué)習(xí)的好壞。同樣的邏輯也適用于數(shù)據(jù)質(zhì)量保障，但我們無法衡量我們的保障工作對整體目標(biāo)的貢獻(xiàn)。其次是當(dāng)前保障推進(jìn)到什么階段，缺乏相應(yīng)的指標(biāo)來指導(dǎo)和持續(xù)優(yōu)化，需要持續(xù)衡量的方法論。

第三個方面的痛點是整個保障機制的規(guī)范性還不夠完善，大多是單點保障。然而，當(dāng)前的發(fā)展趨勢是數(shù)據(jù)上下游鏈路需要協(xié)同解決這些問題。

基于剛剛介紹的背景、痛點和發(fā)展趨勢，我們總結(jié)出了四個重點的保障目標(biāo)。

第一個保障目標(biāo)是準(zhǔn)確識別核心場景，并支持?jǐn)?shù)字化的效果衡量，以提升待辦事項的信息化水平。

第二個保障目標(biāo)是確保數(shù)據(jù)滿足四個基本原則：完整性、準(zhǔn)確性、一致性和時效性。同時，還需要滿足各個用戶實際場景的定制化需求。

第三個保障目標(biāo)是確保數(shù)據(jù)保障貫穿整個數(shù)據(jù)生命周期的全鏈路。包括事前、事中和事后，涵蓋數(shù)據(jù)的生產(chǎn)、傳輸、加工、組裝和服務(wù)等各個環(huán)節(jié)。

第四個保障目標(biāo)是基于日常保障工作的經(jīng)驗，沉淀方法論，并推進(jìn)數(shù)據(jù)中臺相應(yīng)的工具能力建設(shè)，支持在預(yù)防、響應(yīng)、處理、恢復(fù)和復(fù)查等階段高效地解決問題。

二、體系架構(gòu)

基于上述目標(biāo)，我們以質(zhì)量數(shù)倉建設(shè)為基礎(chǔ)，構(gòu)建三大核心能力：完備的質(zhì)量保障體系、數(shù)字化驅(qū)動持續(xù)優(yōu)化，以及高效的故障處理能力。

1、質(zhì)量數(shù)倉建設(shè)

首先，我們引入相關(guān)的保障服務(wù)數(shù)據(jù)，統(tǒng)一數(shù)據(jù)倉庫的建設(shè)，并依托數(shù)據(jù)中臺的能力快速構(gòu)建數(shù)倉架構(gòu)。完成數(shù)倉架構(gòu)后，我們將以數(shù)倉質(zhì)量數(shù)據(jù)為指引，描述相應(yīng)的保障問題，并支持決策數(shù)據(jù)的使用。同時，數(shù)倉的數(shù)據(jù)將支持日常的數(shù)據(jù)檢測和分析等工作，以消除事前的問題。數(shù)倉還有一個核心的保障工作，即與相關(guān)團隊協(xié)商保障目標(biāo)，并進(jìn)行衡量和拆解。

整個架構(gòu)可以分為四個層次，自下而上分別是數(shù)據(jù)源、數(shù)倉建設(shè)、分析項目建設(shè)和最終的應(yīng)用。在質(zhì)量數(shù)倉的數(shù)據(jù)源層，包括了告警服務(wù)、基線服務(wù)、DQC服務(wù)、血緣數(shù)據(jù)、事件管理和值班系統(tǒng)等相關(guān)的數(shù)據(jù)服務(wù)系統(tǒng)。我們將這些系統(tǒng)的數(shù)據(jù)統(tǒng)一導(dǎo)入到數(shù)倉中，并進(jìn)行相應(yīng)的分層建設(shè)。

在分層方面，我們進(jìn)行了明細(xì)層、進(jìn)度匯總層和高度匯總層的區(qū)分。在這些分層中，我們將保障效果的數(shù)據(jù)進(jìn)行抽象，包括異常清單和告警情況，并進(jìn)行相應(yīng)的數(shù)據(jù)建設(shè)，最終呈現(xiàn)在看板上。這為數(shù)倉團隊和橫向團隊提供了數(shù)據(jù)能力，包括質(zhì)量分運營看板、實時保障看板和告警歸因看板等一系列數(shù)據(jù)服務(wù)能力。

在質(zhì)量數(shù)倉的基礎(chǔ)之上，接下來是三個核心能力。

2、完備的質(zhì)量保障體系

第一個核心能力是完備的質(zhì)量保障體系。目標(biāo)是確保數(shù)據(jù)滿足用戶要求。各方需要對數(shù)據(jù)質(zhì)量負(fù)責(zé)，并按照標(biāo)準(zhǔn)監(jiān)控數(shù)據(jù)質(zhì)量。我們會沉淀規(guī)則庫，為實現(xiàn)保障目標(biāo)提供服務(wù)，并推進(jìn)可持續(xù)改進(jìn)計劃。

這一核心能力可以進(jìn)一步拆解為三個部分。

第一部分是構(gòu)建監(jiān)測體系。

在這個體系中，我們將通過數(shù)據(jù)資產(chǎn)的定級來觸發(fā)加工鏈路的卡點校驗，并進(jìn)一步監(jiān)控數(shù)據(jù)風(fēng)險點。這包括常見的數(shù)據(jù)保障實體、基線任務(wù)和模型，并通過這些來衡量數(shù)據(jù)質(zhì)量的效果。其次是構(gòu)建質(zhì)量分衡量機制，并支持從多維度的視角進(jìn)行衡量。最后是制定保障規(guī)則，并識別各個數(shù)據(jù)資產(chǎn)的待優(yōu)化項。在這個過程中，有兩個重要的方面需要提及，第一個方面是卡點校驗規(guī)則庫，這個規(guī)則庫主要涵蓋完整性、一致性、有效性和及時性等與數(shù)倉傳統(tǒng)卡點校驗相關(guān)的內(nèi)容，我們在此基礎(chǔ)上將進(jìn)一步擴展到埋點、集成、加工、組裝、出倉和 API 服務(wù)等相關(guān)環(huán)節(jié)；第二個方面是建立事故歸因知識庫，這個知識庫主要用于歸因相關(guān)的問題，并結(jié)合告警和恢復(fù)工具的能力，提高用戶解決問題的效率，降低異常成本。

第二部分是部門間的協(xié)同保障。

數(shù)據(jù)中臺的鏈路已經(jīng)相對復(fù)雜，因此如何與數(shù)據(jù)中臺的上下游相關(guān)方協(xié)同合作，共同制定符合 SLA 保障標(biāo)準(zhǔn)的機制，并形成跨團隊的保障機制，是非常重要的保障環(huán)節(jié)。

這里重點介紹夜間值班的情況。

夜間值班的流程包括：緊急跟進(jìn)、原因定位、數(shù)據(jù)恢復(fù)和影響通知。數(shù)倉團隊的值班同學(xué)會觸發(fā)卡點校驗的告警監(jiān)控。一旦觸發(fā)，我們會立即采取止損措施，并評估數(shù)據(jù)是否對業(yè)務(wù)產(chǎn)生潛在影響。如果有影響，我們會及時通知相關(guān)方，并將問題轉(zhuǎn)交給兄弟團隊進(jìn)行跟進(jìn)和數(shù)據(jù)恢復(fù)。恢復(fù)完成后，我們會再次通知相關(guān)業(yè)務(wù)方，并對整個事項進(jìn)行歸檔。

第三部分是推進(jìn)日常運營。

日常運營化是指周期性地同步基于質(zhì)量數(shù)倉產(chǎn)出的保障核心指標(biāo)和目標(biāo)的情況，確保其達(dá)到標(biāo)準(zhǔn)。同時，我們會定期回顧過去一段時間的歷史問題，并進(jìn)行規(guī)則的沉淀和歸類，以避免類似問題的重復(fù)發(fā)生。我們會定期確定保障項目的效果，推動代辦人員進(jìn)行相應(yīng)事項的完善。

在推進(jìn)過程中，我們對保障目標(biāo)進(jìn)行了抽象，并確定了衡量和提升的方法。基于當(dāng)前中臺的核心衡量維度，我們關(guān)注數(shù)據(jù)的完整性、一致性、準(zhǔn)確性和告警響應(yīng)度，以及監(jiān)控的覆蓋率、作業(yè)穩(wěn)定性、時效性和鏈路保障率等方面。我們還基于八個維度構(gòu)建了質(zhì)量分，滿分為 100 分，并將其拆分為多個維度。通過質(zhì)量分，我們可以衡量當(dāng)前保障工作的進(jìn)展和目標(biāo)。接下來，我們將基于質(zhì)量分來分發(fā)待辦事項。例如，對于模型監(jiān)控覆蓋率方面，我們會提醒相關(guān)人員進(jìn)行相應(yīng)的操作，如配置完整性檢查和逐漸重復(fù)檢查。

3、數(shù)字化驅(qū)動持續(xù)優(yōu)化

第二大核心能力是數(shù)字化驅(qū)動的持續(xù)優(yōu)化。在這一部分，我們主要關(guān)注在構(gòu)建基于源數(shù)據(jù)的數(shù)倉體系后的決策判斷。我們的推進(jìn)策略按照以下鏈路進(jìn)行管控：首先是構(gòu)建衡量指標(biāo)，然后進(jìn)行現(xiàn)狀分析的描述，接著基于數(shù)據(jù)發(fā)現(xiàn)問題并提出解決方案，最后持續(xù)跟進(jìn)優(yōu)化效果。整體目標(biāo)是通過數(shù)字化的衡量來驅(qū)動質(zhì)量保障，并持續(xù)提升保障效果。

4、高效的故障處理能力

第三大核心能力是高效的故障處理能力。根據(jù)過去的保障實踐經(jīng)驗，質(zhì)量問題是難以避免的。在面對質(zhì)量保障問題時，我們需要快速響應(yīng)，將問題最小化，甚至在短時間內(nèi)實現(xiàn)快速恢復(fù)，以確保用戶無感知。這是一個重要的方向。

基于此，我們進(jìn)行了一些功能支持和方法論的設(shè)計。從數(shù)據(jù)開發(fā)的視角，提供了機械風(fēng)險診斷、告警能力優(yōu)化、故障恢復(fù)系統(tǒng)和規(guī)則配置系統(tǒng)等。另外，從底層服務(wù)的視角，致力于構(gòu)建一鍵恢復(fù)的故障鏈路、分級全鏈路保障和統(tǒng)一運維值班機制。

目標(biāo)是通過日常保障實踐來沉淀方法論，持續(xù)打磨產(chǎn)品能力，提升數(shù)據(jù)質(zhì)量標(biāo)準(zhǔn)。同時，我們也致力于優(yōu)化故障響應(yīng)效率，降低夜間值班的成本。

三、案例分享

接下來，分享B站在保障方面的一個實際案例。

以上是數(shù)據(jù)開發(fā)的正常流程，包括任務(wù)上線、日常跑批的監(jiān)控覆蓋以及可能觸發(fā)的告警。在發(fā)生問題后，我們會進(jìn)行相應(yīng)的響應(yīng)和數(shù)據(jù)恢復(fù)，并推動問題的歸檔。

在開發(fā)階段，我們面臨的問題是線上待保障的任務(wù)較多。目前，我們已經(jīng)有超過五千個核心任務(wù)，但整個保障事項的監(jiān)控覆蓋率不足 50%。此外，我們還存在監(jiān)控覆蓋缺乏審批規(guī)則和發(fā)布流程相對不完善的問題。

在值班階段，我們面臨的問題是值班響應(yīng)的 SOP 流程不完善，跟進(jìn)效率較低。夜間故障信息同步鏈路也不完善。同時，我們的夜間值班率較高，達(dá)到了50%左右。這意味著每周大約有三到四天需要有同學(xué)進(jìn)行夜間值班來響應(yīng)故障。由于故障經(jīng)常發(fā)生，恢復(fù)時間較長，人力投入也較大。

在復(fù)盤階段，我們發(fā)現(xiàn)許多問題并不是由數(shù)倉的日常操作引起的，同時也有一些反復(fù)出現(xiàn)的保障問題。

總結(jié)起來，這些問題可以歸結(jié)為三個方面：數(shù)據(jù)鏈路過長且組件過多，不知從何處著手進(jìn)行保障；當(dāng)前的保障指標(biāo)表現(xiàn)不佳，能推進(jìn)到什么程度心里沒底；不知是否有推進(jìn)套路可以借鑒。

在初始階段，大家的保障意識薄弱。隨著時間的推移，我們逐漸進(jìn)入了起步階段，推進(jìn)人員開始意識到保障的重要性。隨著保障工作逐步推進(jìn)，形成了方法論，進(jìn)而建立了相應(yīng)的分級保障機制。之后逐漸進(jìn)入了基于質(zhì)量數(shù)倉的量化管理階段。我們可以基于特定的指標(biāo)對事項進(jìn)行拆解，并衡量數(shù)據(jù)目標(biāo)的達(dá)成情況，從而推動持續(xù)優(yōu)化的工作。

整個推進(jìn)思路按照以下三個步驟進(jìn)行推演：數(shù)據(jù)鏈路的拆解、保障分級的建設(shè)以及全生命周期的覆蓋。

在數(shù)據(jù)鏈路拆解環(huán)節(jié)，我們將中臺鏈路簡圖進(jìn)一步抽象成數(shù)倉的建設(shè)流程。包括從埋點數(shù)據(jù)轉(zhuǎn)入數(shù)倉加工，數(shù)倉模型校驗和數(shù)據(jù)服務(wù)構(gòu)建，API 構(gòu)建，最終將數(shù)據(jù)出倉給服務(wù)應(yīng)用。在這個過程中，我們還可以抽象出保障的數(shù)據(jù)實體。當(dāng)前的中臺保障實體包括埋點、離線和實時項目任務(wù)，模型表、Kafka 主題，模型字段數(shù)據(jù)指標(biāo)，數(shù)據(jù)基線以及數(shù)據(jù)基線 API 等相關(guān)實體。

保障分級建設(shè)。在許多公司和數(shù)倉建設(shè)的初期階段，對保障的意識可能不夠完善。隨著業(yè)務(wù)的發(fā)展，大家逐漸認(rèn)識到質(zhì)量保障的重要性。在實施保障分級的鏈路中，我們按照以下方法論進(jìn)行迭代推演：確定分級標(biāo)準(zhǔn)，評估數(shù)據(jù)現(xiàn)狀，完成數(shù)據(jù)的分級，并基于分級推動持續(xù)優(yōu)化。

預(yù)期的收益是能夠梳理出整個核心保障鏈路的數(shù)量，并推進(jìn)重要分級保障場景的覆蓋率。通過這樣的工作，我們可以明確討論哪些數(shù)據(jù)是重要的，并與相關(guān)的上下游方制定相應(yīng)的保障策略。剛剛我們也提到了保障分級建設(shè)的思路。

全生命周期的覆蓋。前文提到了基于數(shù)據(jù)實體的抽象，針對這些抽象后的實體，我們將跟進(jìn)相應(yīng)的事前、事中和事后的保障機制。

事前階段包括埋點數(shù)據(jù)的準(zhǔn)備、開發(fā)階段的監(jiān)控標(biāo)準(zhǔn)以及發(fā)布階段的準(zhǔn)備工作。在事中階段，我們會進(jìn)行卡點校驗、值班機制的執(zhí)行以及事故的修復(fù)工作。在事后階段，我們重點關(guān)注事件的反饋、保障的衡量，進(jìn)行事后復(fù)盤，并沉淀到知識庫中。

這里再介紹一個B 站保障中存在的痛點問題，即公司層面進(jìn)行機房遷移工作時，對數(shù)倉保障施加了巨大壓力。由于各個組件服務(wù)的混部部署，機房遷移會導(dǎo)致極大程度出現(xiàn)告警，并且一旦出現(xiàn)告警，由于基礎(chǔ)服務(wù)的原因，會導(dǎo)致全鏈路的擊穿。

因此，在多重原因復(fù)合的情況下，進(jìn)行告警原因歸類成為迫切需要解決的問題。項目挑戰(zhàn)在于單次告警計算涉及全鏈路，并觸發(fā)大量告警，同時涉及所有任務(wù)的 OWNER。在極端情況下，連續(xù)五周工作日的夜間值班率達(dá)到 80%以上。這種情況下，數(shù)據(jù)異常和修復(fù)成本都極高，峰值時達(dá)到單次事故 80+人天。

基于上述情況，我們首先將所有的告警梳理到數(shù)倉的相關(guān)鏈路中，并對其原因進(jìn)行歸類。通過原因的歸類，進(jìn)一步確定問題是由平臺方、工具方還是數(shù)倉相關(guān)原因引起的?；谶@個歸類，我們建議優(yōu)先推進(jìn)解決這些主要問題，并與相關(guān)方對齊優(yōu)化方案和規(guī)則的后續(xù)覆蓋。

通過保障體系的建設(shè)和推進(jìn)，我們的整體保障情況符合預(yù)期。

事件數(shù)在三個季度的優(yōu)化過程中呈下降趨勢，降低了 50%。事件捕獲率趨近于 100%，數(shù)倉起夜天數(shù)也呈下降趨勢，降低了55%。核心基線破線數(shù)逐步收斂，近三個季度中逐季累降。起夜人次相較于保障之前已經(jīng)下降了59%。夜間耗時也下降了 86%。

結(jié)合保障分級的推進(jìn)，我們也清楚梳理了核心場景的范圍，并進(jìn)行了相應(yīng)的保障率的推進(jìn)，達(dá)到了 100%。

在整個保障推進(jìn)過程中，我們也發(fā)現(xiàn)了一些問題。

保障的入手比較困難，因為保障事項本身具有一定的學(xué)習(xí)成本，并且涉及的范圍較廣。同時，如何選擇合適的推廣路徑也是一個較大的問題。

推進(jìn)落地比較困難。目前，一些相關(guān)規(guī)范的推進(jìn)仍然依賴人工的推動，需要有更好的方法來提高效率。

可視化效果不足。正如之前提到的，我們通過質(zhì)量分來衡量保障情況，但還需要更好的可視化方式來展示結(jié)果。

工作仍然容易陷入"運動式治理"，缺乏可持續(xù)的效果。

我們在 B 站數(shù)據(jù)平臺部門貢獻(xiàn)了方法論，并開發(fā)了相應(yīng)的治理平臺。通過這個平臺，我們可以衡量規(guī)則、代辦事項以及未完成操作的同學(xué)，并嵌入到平臺組件中，以支持快速點擊、覆蓋和響應(yīng)。

四、未來展望

未來的工作主要分為兩個方向。

第一個方向，持續(xù)擴大保障范圍，豐富保障策略，繼續(xù)踐行數(shù)據(jù)化驅(qū)動的方法，在保障存量可控的基礎(chǔ)上，持續(xù)提升增量覆蓋優(yōu)化。

第二個方向，理論結(jié)合實踐，持續(xù)推進(jìn)工具化能力迭代支持，完善溝通機制。

最后，隨著質(zhì)量保障工作的發(fā)展，我們希望從最初的手工操作階段逐漸進(jìn)入信息化階段，進(jìn)而推進(jìn)到智能化階段。在智能化階段，隨著保障方法論和規(guī)則庫的沉淀豐富，通過產(chǎn)品化能力支持，最終做到質(zhì)量保障可描述、好衡量、易操作。

五、問答環(huán)節(jié)

Q:數(shù)據(jù)質(zhì)量分有八項規(guī)則構(gòu)成，但每個表的規(guī)則、數(shù)量、規(guī)則重要性都不一樣。怎么做到所有表的拉齊?

A:在B站，我們按照五個分級等級進(jìn)行數(shù)據(jù)質(zhì)量保障，重點關(guān)注線上數(shù)據(jù)，如 BOSS看板和公司級分析產(chǎn)品。基于此，我們制定了各個保障分級的規(guī)范標(biāo)準(zhǔn)。例如，針對線上服務(wù)的數(shù)據(jù)模型，我們制定了一系列質(zhì)量規(guī)則。除了基礎(chǔ)規(guī)則，如表組件的唯一性規(guī)則配置和表行數(shù)規(guī)則配置，我們還推進(jìn)了基于該模型上游埋點數(shù)據(jù)的規(guī)則，如一致性校驗和跨省校驗。同時，針對最高優(yōu)先級的分級場景，我們還配置了及時性規(guī)則，以驗證線上服務(wù)的基線情況。對于較低級別的分級場景，我們僅配置基礎(chǔ)規(guī)則，以確保基本模型的可用性。

Q：文中提到了一個實時任務(wù)是部署在一個系統(tǒng)平臺的 Flink任務(wù)。如果不是在不同的平臺維護(hù)，怎么拉齊評估整體的數(shù)據(jù)質(zhì)量？

A:在過去的一段時間里，我們重點推進(jìn)了解決一個問題，即在不同平臺配置的情況下，我們無法獲取相關(guān)信息的挑戰(zhàn)。在B站內(nèi)部，由于涉及跨部門的情況，不同部門的調(diào)度系統(tǒng)也存在不一致性。為了解決這個問題，我們的推進(jìn)思路是將易購平臺的原始數(shù)據(jù)信息同步到質(zhì)量數(shù)倉中，基于相同的鏈路進(jìn)行規(guī)范和代辦事項的梳理。并按照規(guī)范的數(shù)據(jù)格式進(jìn)行整理。整個鏈路可以復(fù)用，最終可以呈現(xiàn)類似于質(zhì)量分和代辦事項的結(jié)果。

Q：復(fù)盤的時候出現(xiàn)最多的是什么問題？有什么加速排查的工具嗎？

A:第一個問題：在復(fù)盤過程中，最常見的問題取決于不同階段。在保障的初級階段，最常見的問題是告警爆炸或告警湮沒的情況，即告警數(shù)量非常多。在這個階段，我們面臨的問題是如何從大量的告警中提取有效的告警。針對這個問題，我們的重點工作是：首先，如何有效地降低告警數(shù)量，同時確保現(xiàn)有規(guī)則的生效和保障結(jié)果不受影響；其次，針對無效告警的原因進(jìn)行進(jìn)一步分析，以不斷調(diào)整保障規(guī)則的內(nèi)容。有些規(guī)則內(nèi)容可能會隨著時間和迭代的過程進(jìn)行更替。

第二個問題：我們正在與協(xié)同的產(chǎn)品團隊和開發(fā)團隊一起重點推進(jìn)，即加速排查工具的開發(fā)。這是為了解決告警數(shù)量過多的問題。我們的目標(biāo)是建立一個事故知識庫，并基于該知識庫進(jìn)行合理的告警分發(fā)。通過這個知識庫的分發(fā)，我們可以將告警合理地分發(fā)給相關(guān)的團隊，從而減輕數(shù)倉層面的值班壓力。這樣，相關(guān)團隊可以更快速地進(jìn)行排查和處理。