Kvalitet og pålitelighet

Tre nivåer, få SLO-er, og en respons som gjør at folk stoler på produktet.

Kvalitet er en del av produktløftet

Når dere sier at noe er et dataprodukt, sier dere samtidig at andre kan bruke det over tid – uten å måtte gjette på ferskhet, endringer eller kvalitet.

Derfor handler dette kapittelet ikke om “perfekte data”. Det handler om å gjøre løftet tydelig og driftbart:

• hva betyr “godt nok” for den navngitte bruken?
• hva måles for å oppdage avvik tidlig?
• hva skjer når avvik oppstår?

“Godt nok” betyr brukbar for formålet. Datakvalitet blir fort en diskusjon uten rammer. I dataprodukter bør rammene være enkle:

Kvalitet = godt nok for en navngitt bruk, for en navngitt kundegruppe.

Det gjør det mulig å være konkret. For mange dataprodukter er det tre ting som betyr mest:

• Ferskhet: data kommer når den skal brukes
• Stabilitet i semantikk/keys/tidslogikk: det dere mener med “ordre”, “kunde”, “omsetning” endrer seg ikke uten kontroll
• Kvalitetssignal: kundene kan se om produktet er “ok”, “degradert” eller “stoppet”

Nivåer: ikke alt skal ha samme strenghet

Hvis alt skal ha samme krav, ender dere ofte med enten for mye regime – eller for lite troverdighet. Tre nivåer er som regel nok til å være presis uten å bli tungt.

Utforskning Data brukes til å lære og teste hypoteser. Her er poenget å være tydelig på at løftet er begrenset: hyppige endringer er ok, og dere trenger først og fremst synlighet (status + grunnmålinger).

Standard Data brukes i rapportering og løpende beslutninger. Her bør dere kunne love stabil semantikk for definert bruk, og ha noen få tester/alarmer dere faktisk reagerer på.

Forretningskritisk Feil har høy kost eller høy risiko. Her må løftet være skarpere: tydelige SLO-er, klar respons ved avvik og kontrollert endring (som vi bygger videre på i neste kapittel).

SLO: få løfter dere faktisk kan måle og følge opp

SLO fungerer best når dere er strenge på antall. Start med 2–4 per dataprodukt.

De fleste dataprodukter trenger ikke mer enn disse kategoriene:

• Ferskhet (oppdatering)
• Tilgjengelighet (lesbarhet)
• Kvalitetssignal (noen få indikatorer som treffer bruken)

SLO må knyttes til målbare indikatorer. Disse kan være enkle å komme i gang med:

• minutter siden siste vellykkede refresh (ferskhet)
• andel vellykkede leseforsøk mot produktflaten (tilgjengelighet)
• andel null/ugyldige nøkler, duplikater på business key eller ugyldige statusverdier (kvalitetssignal)

Det viktigste er ikke å velge “riktig” måling på første forsøk – det viktigste er at dere velger noe dere faktisk følger opp.

Respons ved avvik: stopp, degrader eller signal

Kvalitet blir først reelt når dere har en tydelig respons. I praksis holder det med tre responstyper:

• Stopp: Brukes når risikoen for feilbruk er høy, eller når feil gir stor konsekvens. Produktet publiseres ikke som “ok” hvis kritiske gates feiler.
• Degrader: Brukes når produktet fortsatt kan brukes, men med tydelig begrensning (for eksempel “stale”, eller en kjent del av innholdet har avvik). Status må være synlig på produktsiden.
• Signal: Brukes når risikoen er lav, eller i utforskning. Avvik gjøres synlig og varsles, men uten at det automatisk blokkerer bruk. Poenget er at kundene skal slippe å gjette på tilstand.

Tester: få som treffer bruken slår mange generiske

Start med 3–7 valideringer som treffer den faktiske bruken av produktflaten. Typisk:

• obligatoriske felt
• unike keys (der det skal være unikt)
• gyldige verdier (status/enum)
• referanseintegritet (der det er relevant)
• én eller to forretningsregler som ofte skaper feil eller misforståelser

Hvis dere ikke har en definert respons på en test som feiler, er det et signal om at testen enten er feil valgt – eller at terskelen/ansvaret er uklart.

Minimum for driftbarhet: en kort rutinebeskrivelse

For dataprodukter som deles på tvers av team er en kort rutinebeskrivelse nyttig. Den kan være enkel:

• kontaktpunkt + ansvarlig team
• hva betyr “stopp” og “degradert” for dette produktet?
• vanligste feilkilder (upstream/transform/tilgang)
• hvor status og changelog oppdateres

Det trenger ikke være mer. Hensikten er at både eierteam og kunder får en forutsigbar håndtering.