Una lista di controllo in 11 punti per definire e rispettare gli SLA sui dati (con modello di SLA incluso)

Oseremmo dire che nessun team è troppo piccolo per elaborare e impegnarsi a rispettare un accordo sul livello di servizio sui dati, o SLA sui dati. Cos'è uno SLA sui dati? Si tratta di una promessa pubblica di fornire un livello di servizio quantificabile. Proprio come i fornitori di Infrastructure as a Service (IaaS) si impegnano a garantire un tempo di attività del 99,99%, tu ti impegni a fornire dati di una certa qualità, entro determinati parametri.

È importante che l'impegno sia pubblico. (All'interno dell'azienda, almeno.) La pubblicità crea una migliore responsabilità, ti aiuta a allineare tutti i team su ciò che è più importante e ti consente di costruire una struttura che supporti la qualità.

In questa guida esploreremo come definire il tuo SLA sui dati.

Gli SLA sui dati formalizzati e scritti rendono i tuoi impegni informali concreti e reciprocamente accettabili. Ogni relazione di dati comporta impegni informali, indipendentemente dal fatto che tu li dichiari o meno, e molto spesso due parti possono concordare qualcosa senza rendersi conto che stanno parlando di cose diverse.

Quindi cos'è esattamente lo SLA sui dati? Si tratta di un semplice documento scritto, solitamente di 250-500 parole, pubblicato in uno spazio condiviso come una wiki aziendale o Google Doc. Dovrebbe includere 6 elementi:

• Scopo: perché esiste questo SLA sui dati? Quali problemi ti aspetti che risolva e come speri che venga utilizzato?

• Promessa: cosa prometti agli altri team?

• Misurazione: come misurerai lo SLA sui dati, chi lo misurerà e qual è l'intervallo di tempo dello SLA?

• Ramificazioni: cosa succede se non si rispetta lo SLA sui dati? Chi è responsabile e quali tipi di correzioni sono disponibili, se ce ne sono?

• Requisiti: cosa ti aspetti in cambio? In che modo le tue promesse sono condizionate?

• Firme: chi si impegna a rispettare lo SLA sui dati?

Quando scrivi il tuo SLA sui dati, comunicalo con il minor numero di parole possibile senza alterarne il significato. Ciò richiede molte modifiche, ma ti consigliamo di scrivere tutto in un unico passaggio disordinato e di tornare a modificare in un secondo momento. Il motivo è che, se fissi la pagina troppo a lungo, potresti sviluppare quella che gli scrittori chiamano "ansia da pagina bianca" e continuare a rimandare. Stampa subito una bozza di scarsa qualità, non aspettare.

Ecco un esempio di accordo sul livello di servizio sui dati:

Lo scopo di questo documento è stabilire una promessa pubblica da parte del nostro team agli altri di mantenere un'alta qualità dei dati entro parametri precisi. La nostra speranza è che ciò crei comprensione, ci aiuti a lavorare tutti insieme e a far sì che i nostri team siano reciprocamente responsabili.

La nostra promessa: forniremo dati sulle vendite con un punteggio di qualità dei dati di almeno il 95% entro le 11:00 ogni giorno in modo che il team possa rispondere a domande come "Quali sono state le vendite ieri?" Riconosceremo tutte le richieste entro 1 giorno lavorativo e le ordineremo per ticket semplici e complessi. Risolveremo le richieste semplici entro tre giorni lavorativi e le richieste complesse entro 2 settimane.

Misureremo la qualità dei dati confrontando i KPI di consegna dei dati come Run Start Time e Run Complete Time, Record Count e rapporto tra Null e Record Count e punteggi di distribuzione e deriva con gli standard predefiniti per la freschezza, la completezza e la fedeltà dei dati.

Se non rispettiamo uno SLA sui dati, entro tre giorni lavorativi, il nostro team pubblicherà una scusa pubblica prendendosi il merito, spiegando perché è successo e misure precise che stiamo mettendo in atto per risolverlo.

Per mantenere questa promessa, abbiamo bisogno del tuo aiuto. Il nostro team ha bisogno di indicazioni tempestive, input e feedback chiari su come vengono utilizzati i dati, oltre a un preavviso di almeno quattro settimane per eventuali modifiche complesse richieste.

Indirizza tutte le domande, i commenti e i dubbi a data-eng@team.com.

Con impegno,

– Il tuo team di ingegneria dei dati

Con il tuo SLA definito (o mentre lo stai modificando), inizia a riflettere su tutto ciò che devi predisporre prima di poterti impegnare a rispettarlo.

Ad esempio:

Cerca di eliminare quanta più ambiguità possibile da questa frase. Definisci il concetto in termini concreti e inequivocabili. A nostro avviso, ci sono quattro caratteristiche che puoi utilizzare per definire dati di alta qualità. Una volta definito il concetto, assicurati che gli altri team siano d'accordo su tale definizione.

Chiediti:

• Qual è il risultato di dati di buona qualità per l'azienda?
• Quali caratteristiche uniche definiscono i dati di buona qualità?
• Quali caratteristiche definiscono i dati errati?

Per il monitoraggio, avrai bisogno di uno strumento di observability, così da sapere effettivamente se alcune parti della tua pipeline sono inattive. Senza di esso, è piuttosto difficile misurare se si sta violando uno SLA, figuriamoci diagnosticare la causa principale. Ti aiuterà anche a capire gli errori, così potrai risolvere i problemi molto più velocemente.

Puoi trattare il tuo SLA dei dati come una metrica guida, una sorta di stella polare che orienta tutti. Tuttavia, al suo interno c'è ovviamente molta complessità nascosta, e sarà necessario monitorare una serie di KPI per comprendere cosa accade a monte e a valle.

Ecco alcune raccomandazioni specifiche:

1. Imposta test automatici per monitorare la qualità dei dati nelle sue quattro dimensioni
   • Pre-produzione dei dati di test
   • Test in ogni fase: completezza, anomalie
2. Misura quanto bene scopri, rispondi e affronti i problemi
   • Tempo di scoperta
   • Tempo di risoluzione
   • Incidenti per asset
3. Documenta le cause immediate e le cause principali di ogni problema
   • Il partner dati ha saltato una consegna
   • Timeout
   • Processo bloccato in una coda
   • Trasformazione inaspettata
   • Problema di autorizzazione
   • Errore di tempo di esecuzione
   • Modifiche al programma

Sii prudente riguardo a ciò a cui ti impegni. Non puoi essere ovunque e prepararti a tutto, e uno SLA con un tempo di attività del 99,999% significa che puoi avere solo 5 minuti di tempo di inattività all'anno. Per raggiungere questo obiettivo, probabilmente avresti bisogno di più personale, più visibilità, più ridondanze e persone che lavorano tutto il giorno.

Probabilmente avrai bisogno di uno strumento di ticketing come Jira o ServiceNow. Ciò consente agli utenti dei dati di creare ticket, al tuo team di monitorarli e a te di comprendere la natura di tali ticket, in modo da poter elaborare correzioni a lungo termine e identificare le aree problematiche.

Potresti non volerlo specificare nello SLA sui dati pubblico, ma è meglio definire i proprietari dell'origine dati e della pipeline. Sono loro i veri responsabili se qualcosa va storto. Specifica anche cosa succede se vanno in vacanza o lasciano l'azienda.

Imposta gli avvisi da pubblicare nell'app di messaggistica del tuo team come Slack o in un sistema di gestione degli incidenti come PagerDuty. Più dettagli sull'incidente riesci a inserire in quell'avviso, più velocemente puoi diagnosticarlo. Questi avvisi ti diranno in anticipo chi altro dovrai coinvolgere o da dove iniziare la tua analisi. (IBM Databand può inviare questi avvisi e aggiungere utili insight e contesto.)

Supponiamo che un consumatore di dati ti dica che una tabella sulla sua dashboard non funziona. Come confermi il problema e rispondi? Scrivi una procedura chiara così, quando si verifica un incidente, non rischi l'effetto spettatore, dove tutti pensano che qualcun altro se ne occuperà e quindi nessuno interviene.

A seconda della dimensione del tuo team e della sua distribuzione nel mondo, potresti voler prendere questa cosa molto sul serio e nominare quello che gli operatori di emergenza chiamano un "incident commander". Questa persona diventa il responsabile dell'incidente e coordina tutti gli altri. (Ciò garantisce una risposta coordinata e aiuta a evitare che più persone si occupino dello stesso problema.)

Se possibile, crea pannelli di avviso sulle dashboard delle persone in modo da poter comunicare lo stato del sistema. Se qualcosa va storto, puoi scrivere: "Stiamo riscontrando un'interruzione: ecco il tempo stimato per la risoluzione". In questo modo verranno diffusi avvisi ripetuti da tutti i consumatori di dati e sarà possibile rispondere effettivamente.

Se non puoi creare pannelli di avviso, come minimo, designa una persona chiave in ogni team a cui puoi dirlo, che poi lo dirà a tutti gli altri.

Monitora come i tuoi consumatori di dati utilizzano i dati (e se li utilizzano). Conduci sondaggi occasionali, formali o informali, per valutare la loro fiducia in quei dati e invitare suggerimenti. Comunica ai consumatori interessati la tua roadmap.

Stabilisci periodi di manutenzione periodica in cui il tuo team esamina le cause dei guasti e discute le possibili correzioni. Chiedi perché quei problemi sono stati possibili, conduci un'analisi post-incidente senza colpevoli, documenta i risultati, assegna le correzioni necessarie e monitora l'efficacia delle soluzioni adottate.

Una volta chiariti tutti questi aspetti, puoi modificare e rivedere il tuo SLA sui dati. Pubblica il documento nella wiki aziendale o in un'area condivisa, ottieni l'impegno di tutti e impegnati a rispettarlo.

Gli SLA sui dati ti aiutano a mantenere te e il tuo team responsabili. Sebbene siano formulati come una promessa pubblica verso gli altri, rappresentano in realtà un accordo bilaterale: tu ti impegni a fornire i dati entro parametri specifici, ma in cambio hai bisogno della partecipazione e della comprensione delle persone.

Molto può andare storto nell'ingegneria dei dati e molto ha a che fare con problemi di comunicazione. Documentare il tuo SLA è un passo importante per chiarire tutto, in modo da poter raggiungere il tuo obiettivo finale: infondere una maggiore fiducia nei dati all'interno della tua organizzazione.

Inizia a rilevare tempestivamente i problemi di integrità dei dati e smetti di perdere soldi a causa del mancato rispetto degli SLA. Scopri come puoi fornire ai tuoi tecnici avvisi avanzati e rilevamento delle anomalie per risolvere i problemi di qualità sul nascere. Se desideri approfondire ulteriormente l'argomento, prenota subito una demo.