作者 ｜ 開發(fā)套件團隊

基于字節(jié)跳動分布式治理的理念，數(shù)據(jù)平臺數(shù)據(jù)治理團隊自研了 SLA 保障平臺，目前已在字節(jié)內(nèi)部得到廣泛使用，并支持了絕大部分數(shù)據(jù)團隊的 SLA 治理需求，每天保障的 SLA 鏈路數(shù)量過千，解決了數(shù)據(jù) SLA 難對齊、難保障、難管理的問題。

一、背景介紹

SLA(Service Level Agreement)：服務(wù)級別協(xié)議，對互聯(lián)網(wǎng)公司來說是網(wǎng)站服務(wù)可用性的保證。數(shù)據(jù) SLA，即數(shù)據(jù)可用性保證，一般以數(shù)據(jù)產(chǎn)出時間作為 SLA。

在海量數(shù)據(jù)任務(wù)開發(fā)場景中，因業(yè)務(wù)多樣化、數(shù)據(jù)量大、數(shù)據(jù)任務(wù)復雜等問題，導致數(shù)據(jù)任務(wù)鏈路依賴復雜、鏈路長、跨團隊節(jié)點依賴多，因此，在實際開發(fā)運維過程中，任務(wù)負責人為保證自身數(shù)據(jù)準時產(chǎn)出，會遇到如下困難：

• 溝通成本高：任務(wù)負責人嘗試與上游任務(wù)負責人約定 SLA，但由于上游任務(wù)數(shù)多(可至上千個)，且跨越多個團隊，溝通成本非常高
• 權(quán)責不清晰：由于鏈路復雜，如何制定 SLA?誰來負責保障 SLA?
• 運維壓力大：無法及時發(fā)現(xiàn)上游任務(wù)延遲，導致下游任務(wù)負責人承擔絕大部分運維壓力，且運維效果較差，往往發(fā)現(xiàn)延遲已經(jīng)錯過了補救的時間。

為解決上述問題，字節(jié)跳動數(shù)據(jù)平臺通過自研的 SLA 保障平臺，規(guī)范并推進各業(yè)務(wù)團隊進行任務(wù)鏈路治理，有效保障數(shù)據(jù)的 SLA，數(shù)據(jù) SLA 達標率達到 99.1%。

理想的一組任務(wù)的完成時間與對應(yīng) SLA 之間的關(guān)系如下圖所示，即各個任務(wù)及其上游任務(wù)都在對應(yīng)的 SLA 之前完成，這也是平臺的治理目標。

二、應(yīng)用場景

SLA 保障平臺除了解決上文的困難外，對不同的用戶還有以下使用場景：

• 數(shù)據(jù)業(yè)務(wù)方：“我們團隊的業(yè)務(wù)很依賴一份重要數(shù)據(jù)，希望能對其進行保障，希望上游能承諾 SLA”
• 數(shù)據(jù)負責人：“我們團隊有很多對外承諾 SLA 的數(shù)據(jù)，希望能有一個平臺對 SLA 進行集中管理，并能提供一些統(tǒng)計大盤、風險分析等內(nèi)容”
• 數(shù)據(jù)治理方：“我們希望能提升團隊內(nèi)核心數(shù)據(jù)的數(shù)據(jù)質(zhì)量，對齊進行 SLA 管理，及時發(fā)現(xiàn)風險，并進行事故復盤和改進，最終不斷優(yōu)化數(shù)據(jù)質(zhì)量”

根據(jù)以上不同角色需求，SLA 保障平臺提出自身解決方案。針對團隊數(shù)據(jù)治理需求，平臺提供完善的治理看板能力;針對任務(wù)鏈路復雜導致的 SLA 難達成，平臺通過各項優(yōu)化，簡化了 SLA 達成流程;針對下游任務(wù)運維壓力大的問題，平臺優(yōu)化通知體系，及時播報 SLA 狀態(tài)。

那么，SLA 保障平臺有哪些核心模塊?平臺是如何運轉(zhuǎn)的呢?

三、核心概念介紹

3.1 角色：

目前 SLA 保障平臺的核心角色有三類，分別是：

• 申報人：即 SLA 提申報的人，一般是數(shù)據(jù)業(yè)務(wù)方，其提申報的目的是保障業(yè)務(wù)數(shù)據(jù)的 SLA;
• 管理員：滿足數(shù)據(jù)治理方的需求設(shè)置的角色，負責申報的審核、批準、管理、統(tǒng)計、登記、復盤等，其目的是不斷優(yōu)化所屬團隊的數(shù)據(jù)質(zhì)量。
• 任務(wù)負責人：即待保障 SLA 數(shù)據(jù)鏈路中的任務(wù) owner，負責確定及簽署所負責任務(wù)的 SLA，平臺會按照其簽署的 SLA 進行保障;

3.2 任務(wù)：

即產(chǎn)出數(shù)據(jù)的任務(wù)，通過數(shù)據(jù)任務(wù)的元信息，可構(gòu)建整條數(shù)據(jù)生產(chǎn)鏈路的完整 DAG。在本平臺中，所涉及的任務(wù)元信息一般需要包含以下內(nèi)容：

3.3 申報單

申報人提起的一次申報內(nèi)容，被稱為一個“申報單”，一個申報單一般包含的核心內(nèi)容如下：

四、申報簽署流程詳解

SLA 保障的前提是先達成 SLA 協(xié)議。在 SLA 保障平臺中，以申報單簽署的形式達成 SLA 協(xié)議。平臺核心特點是優(yōu)化了 SLA 達成的流程，先通過 “系統(tǒng)卡點計算” 減少待簽署任務(wù)的數(shù)量，再通過 “SLA 推薦計算” 自動簽署部分任務(wù)，最后為剩下的待簽署任務(wù)智能提供合適的 SLA，進一步降低簽署成本。

在申報簽署環(huán)節(jié)中，各個環(huán)節(jié)的變化將通過通知模塊傳遞信息給相應(yīng)負責人，實時通知降低信息交流成本，加速了 SLA 的達成。

4.1 流程簡介

上圖為申報簽署的一般流程，在實際操作時，如任務(wù)鏈路變化、SLA 時間商討待確認等特殊情況，申報簽署流程會有微調(diào)。

首先需要申報人填寫申報單，在申報人提交后，系統(tǒng)會根據(jù)申報單中的申報任務(wù)拉取上游的所有任務(wù)，構(gòu)成一個完整的 DAG，并進行任務(wù)鏈路分析。鏈路分析的結(jié)果是后續(xù)算法的前提，也是管理員審批時的重要參考因素，可以讓用戶快速了解到自身任務(wù)在鏈路中所處的位置及上下游運行情況。

在理想情況下，為保證申報任務(wù)順利推進，需要該任務(wù)的所有上游任務(wù)都簽署 SLA 才算完成簽署。而鏈路復雜導致的上游任務(wù)多、跨團隊溝通成本高、SLA 難以確定等問題，成了整體 SLA 達成的最大阻礙。通過“卡點計算”與“SLA 推薦計算”可以跨越此阻礙。

4.2 卡點計算

本系統(tǒng)采取一定的“卡點策略”，計算出此 DAG 中的部分需要被簽署的任務(wù)，此類任務(wù)稱為“卡點任務(wù)”，這個過程稱之為“卡點計算”。計算得到卡點任務(wù)后，在簽署過程中可以忽略其他任務(wù)，從而大大降低簽署成本。

一個申報單會關(guān)聯(lián)多個任務(wù)(即該申報任務(wù)及其上游的卡點任務(wù))，同理一個任務(wù)也會關(guān)聯(lián)多個申報單，因為在一個 DAG 中，申報任務(wù)可能從任意節(jié)點起，因此二者是 N:N 的關(guān)系。

當兩個申報單有部分任務(wù)列表重合時，如 Task4 關(guān)聯(lián)了兩個申報單，該任務(wù)的申報方、治理團隊等數(shù)據(jù)是兩個申報單的去重合集，而等級則取所有申報單中最高者。

4.3 SLA 推薦計算

利用任務(wù)及其上下游任務(wù)的歷史運行信息，再結(jié)合推薦算法，得到該任務(wù)的推薦 SLA，這個過程稱之為SLA 推薦計算。

在負責人簽署 SLA 之前，SLA 推薦算法會智能計算每個任務(wù)的推薦的 SLA，并以此進一步通過算法自動簽署部分待簽署的任務(wù)，進一步降低簽署成本。據(jù)平臺數(shù)據(jù)統(tǒng)計，此功能可以自動簽署近40% 的 SLA，是最核心的功能之一。

而對于剩余的待簽署任務(wù)，會將算法推薦的 SLA 提供給任務(wù)負責人。任務(wù)負責人可以直接選擇直接用這個 SLA 簽署，也可以自行決定 SLA。一般情況下，智能推薦的 SLA 已經(jīng)能滿足絕大多數(shù)的需求，通過推薦 SLA，任務(wù)負責人更快的做出簽署決定，再次降低了簽署成本。

4.4 系統(tǒng)保障監(jiān)控

當一個申報單完成簽署之后，平臺將對申報單中的任務(wù)進行保障服務(wù)。保障服務(wù)的核心就是通過監(jiān)控 SLA 的狀態(tài)變化及時播報消息通知，為相應(yīng)負責人及時提供一手資料，以此降低運維成本。對于一個離線任務(wù)，評價其 SLA 主要是依據(jù)其完成時間和其所承諾的 SLA 來判斷，SLA 的狀態(tài)分為四種，分別是：

• 未到 SLA：即當前時間，任務(wù)未產(chǎn)出，且還未到 SLA 時間(繼續(xù)監(jiān)控);
• 已達成：即任務(wù)已完成，且完成時間在所承諾的 SLA 之前(發(fā)送就緒通知);
• 已延遲：即任務(wù)未完成，且當前時間已在所承諾的 SLA 之后(發(fā)送延遲通知);

已延遲(產(chǎn)出)：即任務(wù)已完成，但完成時間在所承諾的 SLA 之后(發(fā)送延遲產(chǎn)出通知);

從下圖可以看到在任務(wù)達成、未達成兩種情況下，隨著時間的推移，其 SLA 狀態(tài)的變化。

SLA 的實時狀態(tài)是數(shù)據(jù)業(yè)務(wù)方所需要的重要信息，因此平臺會所有任務(wù)的 SLA 進行監(jiān)控，并在 SLA 狀態(tài)變化時實時對相關(guān)人員發(fā)送通知，相關(guān)人員根據(jù)收到的通知知曉 SLA 的具體情況，并能做出應(yīng)對措施。

五、復盤管理詳解

復盤管理是本平臺提供的響應(yīng)式治理服務(wù)的實現(xiàn)方式，是數(shù)據(jù)治理方的重點關(guān)注對象。復盤管理又分為問題管理與事故管理，問題管理側(cè)重于“為什么”——即整理分析 SLA 破線的原因，事故管理側(cè)重于“怎么做”——即 SLA 破線事故之后該怎么治理。

5.1 問題管理

問題管理模塊的整體目標是滿足數(shù)據(jù)治理團隊對 SLA 問題的登記管理，支持對登記后的問題數(shù)據(jù)進行不同維度根因數(shù)據(jù)分析，輔助用戶對問題根因進行治理，沉淀治理問題經(jīng)驗。

平臺在進行系統(tǒng)保障監(jiān)控時，會在 SLA 延遲時進行通知播報，并持續(xù)提醒負責人進行問題登記。在問題登記時，平臺提供了一組根因樹輔助登記，明確問題根因類別，方便統(tǒng)計分析。任務(wù)負責人進行問題登記后，累積數(shù)據(jù)展示在問題看板上，數(shù)據(jù)治理方由此做問題分析歸納總結(jié)。

平臺保證了 SLA 延遲記錄與問題之間是一一對應(yīng)的關(guān)系，并在問題看板上關(guān)聯(lián)了 SLA 詳情信息，包括任務(wù)鏈路、負責人、任務(wù)起止時間等。

問題登記往往是一個從多到少的過程，前期出現(xiàn)的問題在逐一治理解決后，將對后期的治理起到很好的參考警示作用，它的數(shù)據(jù)價值如下：

• 不同 SLA 問題類型的趨勢分布，針對性的治理問題
• 相同根因引發(fā)了多少 SLA 問題，涉及影響多少數(shù)據(jù)資產(chǎn)
• 哪些數(shù)據(jù)資產(chǎn)經(jīng)常出現(xiàn) SLA 問題，問題的分類以及是什么根因造成的
• SLA 問題經(jīng)驗總結(jié)，方便類似問題發(fā)生后，后期做推薦輔助快速定位根因

根據(jù)平臺運營的記錄顯示，常見的問題有資源隊列阻塞、上游任務(wù)故障、數(shù)據(jù)傾斜等。某數(shù)據(jù)團隊雙月問題登記總結(jié)如下，問題數(shù)量和問題根因種類得到了有效的收斂：

5.2 事故管理

事故管理用于記錄 SLA 破線事故的復盤與改進管理，每個事故至少對應(yīng)一條 SLA 問題記錄，而每個 SLA 問題不一定會造成事故。

事故可以在任意節(jié)點進行，一般在 SLA 破線并造成實際的業(yè)務(wù)影響之后，需要進行事故登記，事故登記同樣會關(guān)聯(lián)相關(guān)的 SLA 信息。一個事故的處理流程如下所示：

如圖所示，事故主要包含 SLA 事故明細、SLA 事故根因、改進計劃及 SLA 消耗這幾部分，在這其中可以關(guān)注以下幾點：

• 事故在登記時，會根據(jù)事故明細確認事故根因，并讓相應(yīng)負責人提出改進計劃
• 用戶可以訂閱事故，在事故的復盤狀態(tài)及其改進計劃的完成狀態(tài)變化時，都會通知訂閱人
• 任務(wù)的改進計劃在完成前，每日都會提醒計劃負責人，直到計劃完成為止

SLA 事故管理平臺的數(shù)據(jù)是數(shù)據(jù)治理方治理成果的重要依據(jù)，也是整個 SLA 保障平臺使用效果的體現(xiàn)，它的數(shù)據(jù)價值如下：

• 對事故的復盤歸檔管理，方便后期隨時查閱，定位相關(guān) SLA 信息
• 針對不同數(shù)據(jù)團隊發(fā)生 SLA 事故的整體情況進行對比查看，互相借鑒
• 對事故的改進計劃管理跟蹤，驗收 SLA 的治理效果

以下是某個團隊的雙月事故統(tǒng)計：

通過上述數(shù)據(jù)可知，本平臺有效保障了核心任務(wù)的穩(wěn)定產(chǎn)出，輔助降低了穩(wěn)定性事故發(fā)生的概率，現(xiàn)在每雙月該類型事故數(shù)量長期維持在個位數(shù)。

六、平臺架構(gòu)總結(jié)

平臺整體主要分為基礎(chǔ)組件、規(guī)劃式治理服務(wù)、響應(yīng)式治理服務(wù)三大塊，系統(tǒng)組件架構(gòu)圖如下：

6.1 規(guī)劃式治理服務(wù)

所謂“規(guī)劃式治理”，即在問題發(fā)現(xiàn)前治理，通過主動規(guī)劃約定 SLA 的形式保障任務(wù)產(chǎn)出。規(guī)劃式治理是 SLA 相關(guān)問題發(fā)現(xiàn)的過程。

規(guī)劃式治理服務(wù)即“提供以申報單簽署的方式達成 SLA 協(xié)議的服務(wù)”，包括在此過程中申報單的生命周期管理操作，申報任務(wù)的鏈路分析，以及達成 SLA 之后的系統(tǒng)保障監(jiān)控，服務(wù)于“申報簽署流程”。

6.2 響應(yīng)式治理服務(wù)

響應(yīng)式治理是指通過復盤管理模塊對 SLA 相關(guān)的事故/問題進行登記、管理、復盤的過程。在發(fā)現(xiàn) SLA 相關(guān)問題之后，需要對問題進行處理，形成一個完整的閉環(huán)，在發(fā)現(xiàn)問題后進行的治理成為響應(yīng)式治理。

響應(yīng)式治理服務(wù)模塊抽象出問題登記和事故管理兩個模塊，更加靈活的服務(wù)于數(shù)據(jù) SLA 的問題歸因與事故統(tǒng)計。

6.3 基礎(chǔ)組件

基礎(chǔ)組件提供了配置、播報、看板等基本功能模塊服務(wù)，為規(guī)劃式、響應(yīng)式治理服務(wù)提供了必要支撐，是整體 SLA 保障服務(wù)不可或缺的一環(huán)。

6.3.1 系統(tǒng)配置

治理團隊配置

治理團隊為 SLA 的管理團隊，每個申報單都需要綁定一個治理團隊，治理團隊主要負責審批申報單。

數(shù)據(jù)團隊配置

數(shù)據(jù)團隊為數(shù)據(jù)的歸屬方，一個數(shù)據(jù)團隊對應(yīng)一個業(yè)務(wù)團隊，數(shù)據(jù)團隊的設(shè)計保障了各個業(yè)務(wù)團隊獨立治理的需求。平臺通過對數(shù)據(jù)團隊的靈活配置支持，可以更細粒度的劃分數(shù)據(jù)與任務(wù)的歸屬，解決權(quán)責不清的問題。

訂閱配置

訂閱管理是配置訂閱信息的平臺，本平臺的訂閱為 SLA 監(jiān)控的通知播報，通過訂閱管理可以將通知指定發(fā)動到個人或者群組。訂閱管理是 SLA 監(jiān)控保障服務(wù)不可或缺的一環(huán)。

6.3.2 通知播報

通知播報是本平臺所提供的基礎(chǔ)通知能力，是降低溝通成本、實現(xiàn)保障服務(wù)、提升用戶體驗的重要手段。在重要節(jié)點變更、用戶操作、SLA 狀態(tài)變化等情況下，都會進行通知播報。通知播報形式多樣，根據(jù)不同的場景，有普通文本消息、加急消息、卡片通知、郵件通知、電話通知等。

6.3.3 SLA 大盤展板

SLA 大盤展板是數(shù)據(jù)治理方最為關(guān)心的部分，展板提供當日 SLA 整體統(tǒng)計信息、SLA 延遲趨勢分析信息、SLA 等級分布明細、任務(wù)健康度明細、團隊 SLA 達成信息統(tǒng)計等豐富信息，是很多團隊數(shù)據(jù)治理指標重要參照來源。

七、未來展望

未來字節(jié)跳動數(shù)據(jù)治理團隊將持續(xù)打磨 SLA 保障平臺，在卡點策略優(yōu)化、SLA 推薦算法優(yōu)化、基于 SLA 的任務(wù)管理機制上持續(xù)提升技術(shù)能力：

• 卡點策略優(yōu)化：卡點計算作為優(yōu)化簽署流程中核心一環(huán)，卡點策略優(yōu)化代表著簽署流程進一步的簡化，未來可以探索利用更多有效的信息優(yōu)化卡點策略。
• SLA 推薦算法優(yōu)化：SLA 推薦算法是本平臺的核算算法之一，已經(jīng)申請了專利。隨著業(yè)務(wù)的拓展，以及不同種類任務(wù)的支持，此算法還有廣闊的提升空間，如進一步提升自動簽署率，進一步提升準確率等。
• 基于 SLA 的任務(wù)管理機制：任務(wù)簽署 SLA 信息之后，即可依托 SLA 信息進行資源調(diào)度優(yōu)化，并進行資源分配傾斜。

同時，文中闡述的部分能力已經(jīng)通過火山引擎 DataLeap 產(chǎn)品向企業(yè)客戶開放，歡迎關(guān)注。