讀資料質量管理：資料可靠性與資料質量問題解決之道12應對與緩解

躺柒發表於2024-11-23

1. 解決

1.1. 當你發現資料出了故障，並且瞭解到它的初步影響時，下一步（有時甚至在根因分析之前）就是要解決這個問題，並且和利益相關方溝通，協商接下來該怎麼做

1.2. 在事故解決後，無論是透過修改程式碼、資料或者執行環境中的哪種方式，資料團隊都應該與受到影響的各方及時溝通，並在接下來的幾天安排一場覆盤

2. 不做指責的覆盤

2.1. 覆盤是指一場會議，這場會議要總結這次資料事件的關鍵資訊、事件序列、相關各方人員、有關技術以及其他的重要事實，並用文件記錄下來

2.2. 覆盤不僅要談論事件造成的影響和結果，更要把發生的事情都記載下來，這樣才可以採取積極的措施來避免類似事故的再次發生

2.3. 對於每個事件來說，出錯的是系統，而不是寫程式碼的人

  • 2.3.1. 好的系統應該能夠容許人的失誤

  • 2.3.2. 系統的本職工作就是允許你犯錯誤

2.4. 資料管道應當可以容錯，其中應該存在流程和框架來應對資料管道中那些“已知的未知”和“未知的未知”​

2.5. 無論資料事件是哪種型別的或者是由哪種原因導致的，資料工程團隊都應該在解決問題並進行根因分析後進行一場跨領域的全面覆盤

2.6. 最佳實踐

  • 2.6.1. 將一切當作一次學習經歷

  • 2.6.1.1. 覆盤分析必須不做任何指責才能有建設性

  • 2.6.2. 利用這次機會，評估應對未來事件的能力

  • 2.6.2.1. 執行指令碼是詳細描述如何執行一個共同的任務或流程的文字，被DevOps和IT團隊廣泛使用

  • 2.6.3. 記錄每一次覆盤，並與更大範圍內的資料團隊分享

  • 2.6.3.1. 對出了什麼問題、系統是如何被影響的，以及問題的根本原因進行文件記錄常常是不被重視的一項工作

  • 2.6.3.2. 文件記錄與事件管理中的其他步驟同樣重要，因為它可以把資料工程師的個人經驗總結下來並變成整個團隊的經驗

  • 2.6.4. 修訂SLA

  • 2.6.4.1. SLA是許多公司用來界定供應商、產品或內部團隊所提供的服務級別的一種方法，同時也規定了當服務不達標時的補救方案

  • 2.6.4.2. 6個月前合理的SLA現在未必依然合理，你的團隊需要率先了解到這些需要的改動，並且和下游客戶進行溝通

2.7. 事後覆盤對於資料團隊和軟體工程師團隊來說都很重要

  • 2.7.1. 隨著我們在該領域不斷進步​，對資料當機發生的方式和原因不斷加深瞭解是我們持續改進系統和流程的彈性的唯一途徑

3. 事件應對與緩解策略

3.1. 測試只能觸及資料質量問題中“已知的未知”部分

  • 3.1.1. 這個流程中“被動應對”的階段

3.2. 預防則是“積極主動”的階段

3.3. 建立事件管理的標準程式

  • 3.3.1. 很多時候，資料工程師的職責不僅包括修復資料問題，還包括確定修復內容的優先順序順序，如何進行修復，以及隨事件進展及時溝通情況

  • 3.3.2. 資料團隊應當輪流承擔事件指揮官的職責，比如每週或者每天輪換，或者根據不同職能團隊所負責的具體資料集來分配

  • 3.3.3. 建立一個良好、可重複的事件管理機制（來明確指定事件指揮官）是一個文化建設的過程，但致力於自動化流程以及對資料健康的持續檢查，可以讓你受益深遠

  • 3.3.4. 不斷學習並積累經驗了

  • 3.3.5. 關鍵步驟

  • 3.3.5.1. 通知適當的團隊成員

>  3.3.5.1.1. 團隊成員分散在不同的業務部門中，而不同領域的資料團隊成員則為利益相關方分門別類地處理資料事件

>  3.3.5.1.2. 中心化的資料團隊直接向首席資料官或資料總監彙報，並且同時處理不同業務部門的資料查詢和事件
  • 3.3.5.2. 評估事件的嚴重性
>  3.3.5.2.1. 在資料管道的所有者得知資料出現問題後，第一步就是評估該事件的嚴重性

>  3.3.5.2.2. 當你的資料團隊開始處理事件時，最好可以對事件的狀態進行標記，比如是否已經修復、是否在計劃內、是否在調查中、無須行動，或者是假陽性警報

>  3.3.5.2.3. 對狀態進行標記可以幫助使用者評估事件的嚴重性，並且可以在與該資料的利益相關方溝通進展的過程中發揮重要作用，這樣可以幫助他們根據資料受損的情況採取適當的行動

>  3.3.5.2.4. 利用資料沿襲的視覺化工具來理解資料是如何服務於業務需求的，從而找出最重要的資料集

>  3.3.5.2.5. 當你的資料團隊能夠分析出事件是否影響到了關鍵資料，那麼它就能更好地瞭解資料當機的嚴重程度
  • 3.3.5.3. 儘可能頻繁地通報事件狀態的更新
>  3.3.5.3.1. 在響應資料事件的繁忙工作中，良好的溝通可以使你受益良多

>  3.3.5.3.2. 要採用對你團隊的結構、資源和優先事項來說最合適的方案

  >   3.3.5.3.2.1. 指定一名團隊成員在某一時間段內值班，並負責處理其間發生的任何事件

3.3.5.3.2.1.1. 值班人員會負責處理所有型別的資料事件

3.3.5.3.2.1.2. 有些團隊會指定一個人來全職負責該團隊中所有事件的處理

3.3.5.3.2.1.3. 其他團隊則會設立一個值班表，每週指定一名團隊成員來值班

  >   3.3.5.3.2.2. 團隊成員各自負責某些資料表

3.3.5.3.2.2.1. 團隊成員會在進行日常工作的同時，處理各自所負責的資料表或報告中出現的問題

3.3.5.3.2.2.2. 一名團隊成員負責的資料表通常與他最熟悉的資料和管道相一致

  • 3.3.5.4. 定義並與資料的SLO和SLI達成一致，以避免未來的資料事件和資料當機
>  3.3.5.4.1. 事件指揮官並不負責制定SLO，但是他們通常負責滿足這些SLO

>  3.3.5.4.2. SLO是很多公司常用的一種界定供應商、產品或內部團隊所提供的服務級別的一種方法，同時也規定了當服務不達標時的補救方案

>  3.3.5.4.3. 作為對SLA的量化度量標準，SLI的制定取決於具體的用例，但也有一些常用的指標，用來量化分析事件響應與資料質量

  >   3.3.5.4.3.1. 在某一資料資產中的資料事件的數量

  >   3.3.5.4.3.2. 檢測所需時間

3.3.5.4.3.2.1. 當事故發生時，該指標可以量化資料團隊收到警報的速度

  >   3.3.5.4.3.3. 解決所需時間

3.3.5.4.3.3.1. 在你的團隊收到關於事故的警報後，該指標可以度量解決事故的速度

3.3.5.4.3.3.2. 努力減少TTD和TTR，從而構建更可靠的資料系統

3.4. 資料事件指揮官

  • 3.4.1. 時間是應對資料事件的關鍵

  • 3.4.1.1. 對於事件指揮官來說，時間既是敵人，也是朋友

  • 3.4.1.2. 企業都希望資料事故可以儘快解決

  • 3.4.2. 一名事件指揮官可以充分使用合理的流程、藉助一些自動化措施、調動企業內部的合作，從而有效地為資料管道的可靠性提供保障

4. 使用DevOps的最佳實踐來規模化資料事件管理

4.1. 確保事件管理能覆蓋整個資料生命週期

  • 4.1.1. 資料可觀測性對於監控和保障資料倉儲中的資料質量是至關重要的

4.2. 事件管理要包含噪聲抑制

  • 4.2.1. 對實現資料監控和異常檢測來說，資料中的噪聲是個大問題

  • 4.2.2. 用訊雜比來評價一個警報系統的可執行性，並努力把訊雜比降到最低

4.3. 將資料資產和資料事件分組，智慧化地路由警報

  • 4.3.1. 資料可觀測性是任何資料事件管理步驟（包括事故響應和升級）發生前必須進行的一步

  • 4.3.2. ​“我的資料沒有更新”與異常的趨勢或指標是完全不同的問題

  • 4.3.3. 如果資料問題隨著時間的變化而存在，資料團隊應當及時認識到這樣的問題

  • 4.3.4. 警報資訊會被傳遞給商業智慧團隊，讓其也能監控並根據需要採取行動

相關文章