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.

Dette kapittelet handler 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?

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 de fleste 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

Legger dere samme krav på alt, ender dere med for mye regime eller for lite troverdighet. Tre nivåer holder for å være presise uten å bli tunge.

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 love stabil semantikk for definert bruk, og ha noen få tester/alarmer dere 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. Se kapittel 8 om endring og utfasing for hvordan dere håndterer dette i praksis.

Ta Kunde 360 – Core som eksempel: de navngitte konsumentene (salgsteamet og kundeservice) har ulike toleranser. Salgsdashboardet kan tåle én dag gammelt tall. Kundeservice-systemet kan ikke. Det er to SLO-er, ikke ett felles krav.

SLO: løfter dere 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:

• 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 følger opp.

Respons ved avvik: stopp, degrader eller signal

Kvalitet blir først reelt når dere har en tydelig respons. Tre responstyper holder:

• 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 bruken av produktflaten:

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

Har dere ikke 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 holder en kort rutinebeskrivelse:

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

Hensikten er at både eierteam og kunder får en forutsigbar håndtering – ikke at dere skriver en manual.

Neste steg er å bestemme hvordan dere håndterer endringer og utfasing uten å miste konsumentenes tillit: Endring og utfasing av dataprodukter.