資料所有權設定中需要注意的事項

來源：資料驅動智慧

透過對數千名資料從業者調查，“在準備資料進行分析時，您認為最具挑戰性的是什麼？ ”。 43% 的受訪者回答說，不明確的資料所有權是他們面臨的最大挑戰，這一比例在所有答案中最高。

隨著資料堆疊變得越來越複雜，一個人不再可能將所有事情都記在腦子裡，而且通常情況下，發現問題的人並不是解決問題的合適人選。同時，上游和下游依賴關係的數量呈爆炸式增長，使得找到正確的上游所有者或通知受影響的利益相關者變得具有挑戰性。

良好的所有權說起來容易做起來難，而且不乏失敗的所有權舉措。這篇文章包含了從我們所看到的行之有效的方法中學到的經驗教訓。

• 為業主設定期望

• 定義所有權

• 在正確的背景下通知正確的人

• 克服文化所有權挑戰

一 為業主設定期望

對於某些人來說，成為所有者意味著有責任解決所擁有的資料資產的問題。對於其他人來說，這意味著有責任向下遊利益相關者通知問題或資料管理、隨時間跟蹤資料質量，並確保定義相關後設資料。如果沒有明確的指導方針，每個團隊都會做出自己的解釋。期望應與資料資產的重要性相關聯，例如：

• 低——新增到待辦事項中以在本週末之前修復它

• 中——讓利益相關者在一天結束前瞭解並解決問題

• 高——立即停止正在做的一切來解決問題

如果不滿足預期，我們建議首先概述您的依賴項和現有的資料控制。

不必要求許多資料團隊來理解理想狀態：上游生產者擁有並管理其資料質量，相關資料團隊承擔責任，利益相關者發現問題的時代已經結束。

但實現這一目標說起來容易做起來難。將其分解為幾個步驟可以更清楚地表明差距：(1) 整合後設資料，(2) 透過相關測試檢測問題，(3) 分配所有權，(4) 以他們可以的方式通知相關人員問題採取行動。

如果在沒有進行相關測試的情況下過度定義所有權，可能會很好地通知人們，但無法主動檢測重要問題。

如果在沒有所有權的情況下過度索引檢測重要問題，則警報可能會在繁忙的 Slack 通道的噪音中丟失。

只有將有意的測試和相關所有權正確結合起來，才能取得成功。例如，雖然失敗的關係測試對於客戶資料的所有者來說可能沒有多大意義，但知道特定帳戶 ID 的建立日期晚於截止日期是他們可以修復的問題。

二 定義所有權

在理想的情況下，可以將堆疊整齊地分組為邊界清晰的明確區域。但實際上，所有權界限可能會變得模糊，因此，如果無法輕鬆地將所有權分配給所有資產，請不要灰心。在定義所有權時，我們將考慮一些最重要的考慮因素，例如定義程式碼與 UI 中的所有權、跨工具所有權以及跨依賴項的所有權。

理論上——理想的所有權圖

實踐中——界限模糊

三 在正確的背景下通知正確的人

我們建議全面考慮資料所有權——從上游團隊擁有的資料來源到終端使用者擁有的儀表板。為簡單起見，我們將建議分為以下幾組：(1) 資料團隊、(2) 上游團隊 (3) 業務利益相關者。

管理資料團隊內的警報
管理資料團隊內的所有權是最直接的。團隊掌控一切；通常，這些工具位於您管理的堆疊中。您可以使用現有的所有權定義來確保正確的所有者瞭解正確的問題。假設您使用 Slack 等通訊工具，實現此目的的兩種最有效方法是標記所有者並根據所有權定義傳送警報：

• 標記所有者 - 使用 Slack 控制程式碼關聯所有者來標記群組或個人並提高對問題的認識。

• 路由警報 - 將 Slack 渠道與所有權聯絡起來，並向相關團隊的渠道傳送警報。這是克服中央通道警報過載的好方法。

通知上游團隊
讓上游團隊掌控其資料質量是每個資料團隊的夢想。這裡的問題遠離資料團隊的控制，並且通常是最令人沮喪。

我們通常會看到兩種需要以不同方式發出警報的上游團隊：技術團隊（例如工程團隊）和非技術團隊（例如擁有客戶資料的 SalesOps 團隊）。

a.技術團隊- 您傳送的警報不需要與上面資料團隊的示例中的警報有所不同。如果您在源頭進行了測試並檢測到了問題，工程師應該能夠將源頭和錯誤訊息之間的點聯絡起來，並將問題追溯到他們的系統。對於在攝取資料的團隊（例如，資料平臺）和生成資料的團隊（例如，前端工程師）之間有明確劃分的大型團隊來說，用有關其所涉及的事件或服務的詳細資訊來補充錯誤訊息可能會有所幫助。

b.非技術團隊——將源系統質量的所有權交給非技術團隊的作用被低估了。很多時候，繁瑣的輸入錯誤（例如不正確的客戶數量或重複的客戶數量）employee_id最終需要資料團隊進行除錯、分類和找到合適的所有者。有了正確的上下文，這些團隊就可以開始擁有它，而無需資料團隊的參與.

如果做得好，這將創造奇蹟。根據測試的所有權自動標記企業主，並將警報傳送到他們監控的渠道。錯誤訊息是描述性的，並連結到操作手冊、到源系統的直接連結以及一些示例記錄 - 換句話說，非技術團隊在沒有資料團隊輸入的情況下采取行動所需的一切。

通知利益相關者
有時，您可以提醒利益相關者主動向他們通知問題。如果您的利益相關者是精通資料的團隊（例如業務領域的一組分析師），那麼這種方法效果最佳。但是，向您的營銷總監傳送 Slack 警報，告知有五行未透過訂單資料模型的獨特測試，這並不是最好的主意。

根據我們的經驗，通知受影響的利益相關者的最佳方式是由具有相關背景的人“宣告”。一個示例是在儀表板中顯示正在進行的事件，並提供易於理解的描述、資料所有者、狀態以及宣告事件的時間。

這樣做可以最大限度地降低利益相關者依賴存在持續問題的資料的風險，並減少向受影響的利益相關者傳送有針對性的 Slack 訊息所需的工作。

四 文化所有權的挑戰

一件事是被指定為所有者；另一個正在被追究責任。成功擁有所有權既是一項技術挑戰，也是一項文化挑戰。

當開始資料所有權的工作時，需要考慮以下幾點。

請注意在個人層面上分配所有權。雖然將所有權分配給個人很誘人（例如，John Doe），但這通常不是最好的主意。如果個人離開公司、調動團隊或去度假，個人所有權會使管理變得更加困難。相反，請考慮將所有權設定給一組對某個領域有相關了解的人。

高層支援是上游所有權的關鍵。為了讓上游團隊負責解決源自其系統的問題，您通常需要高階管理層的人員支援並幫助執行。人們很忙，他們最不希望看到的就是另一波需要關注的警報。理想情況下，找到一個參與其中的人，其主要目標和目標受到最近資料質量問題的影響。

注意訊雜比。沒有什麼比警報超載更快地扼殺良好的所有權意圖了。如果您向上遊團隊傳送數百個不相關的警報，他們就不太可能繼續關注。請注意警報過載，寧可傳送較少的警報，也不要傳送過多的警報。

明確期望。明確成為所有者意味著什麼。例如，對於嚴重程度較高的問題，業主必須在四小時內解決問題，但預計不會在工作時間外進行監控。如果沒有明確定義的期望，團隊中最關心的人最終將隱含地承擔大部分問題。宣佈資料問題事件是將這種透明度公開化的好方法。

從小事做起。很多時候，所有權計劃因過度規劃而變得過於複雜，結果卻在上路時失敗。相反，從一個已經積極採取措施提高資料質量的團隊或領域開始。展示一些成功，找出有效的方法，然後加倍努力。