Data downtime

Wat is data downtime?

Data downtime is elke periode waarin je data ontbreekt, fout is, half geladen, dubbel of verouderd, zodat niemand ze nog vertrouwt of kan gebruiken. De cijfers staan er wel, ze kloppen alleen niet, en beslissingen die erop volgen kloppen dus ook niet.

De term komt van Barr Moses. Ze muntte data downtime rond 2016, nadat klanten en directie herhaaldelijk fouten in de rapporten opmerkten voor haar eigen team het doorhad. Later richtte ze Monte Carlo op, het bedrijf dat data observability op de kaart zette. Het idee komt recht van application downtime, de tijd dat een website of app plat ligt. Bedrijven meten dat tot op de minuut, voor hun data doen veel teams dat nog niet.

Het grote verschil zit in de zichtbaarheid. Ligt een app plat, dan ziet iedereen het meteen. Data downtime is stiller: een dashboard blijft keurige cijfers tonen, ook als de tabel eronder al een week stilstaat. Zie het als de tegenhanger in tijd van datakwaliteit: datakwaliteit zegt hoe goed je data is, data downtime hoe lang ze onbruikbaar bleef.

Hoe reken je data downtime uit?

Monte Carlo vat data downtime in een eenvoudige formule: het aantal incidenten maal de tijd tot detectie plus de tijd tot herstel.

• Aantal incidenten
  Hoe vaak er iets misloopt met je data.

• Tijd tot detectie
  Hoe lang het duurt voor je merkt dat er iets fout zit. Zonder bewaking loopt dat op tot dagen of weken.

• Tijd tot herstel
  Hoe lang je nodig hebt om de fout recht te zetten nadat je ze gevonden hebt.

De les zit in de formule zelf. Je verlaagt data downtime niet alleen door minder fouten te maken, maar vooral door ze sneller te zien en sneller op te lossen. Een fout die je binnen het uur opmerkt, kost een fractie van dezelfde fout die drie weken meedraait in elk rapport.

De oorzaken van data downtime

De meeste data downtime komt uit drie hoeken.

Een pijplijn die faalt of half draait. Een datapijplijn valt 's nachts stil op de helft, of laadt nul rijen omdat de bron een leeg bestand aanleverde. De run kleurt soms nog groen terwijl het resultaat onbruikbaar is.

Een schema dat verandert bij de bron. Een bronsysteem hernoemt of verwijdert een kolom, of voegt er stil een nieuw type event bij. De pijplijn erachter breekt of telt plots dubbel, en tien dashboards downstream tonen verkeerde cijfers.

Een bron die te laat of niet levert. Een externe partner of een API stuurt de dagelijkse gegevens niet op tijd. Je rapport draait door op de data van gisteren zonder dat iemand het aangeeft.

Een voorbeeld

Bij het Amerikaanse adtech-bedrijf Kargo leverde een externe partner op een dag niet de juiste gegevens aan. Eén centrale pijplijn viel daardoor stil. Tegen dat iemand het doorhad en de zaak rechtgezet was, waren er drie dagen voorbij en had het incident naar schatting een half miljoen dollar gekost. De fout zelf was klein, de schade kwam doordat ze zo lang onopgemerkt bleef.

Dichter bij een KMO: je nachtelijke load valt in stilte terug op de tabel van gisteren. Het omzetdashboard blijft groen en toont nette cijfers, alleen zijn ze intussen een week oud. Niemand merkt het, tot de zaakvoerder een cijfer ziet dat botst met zijn buikgevoel. Dan begint het speurwerk, en dat vraagt vaak meer tijd dan de fout zelf rechtzetten.

Hoe verlaag je data downtime?

Je werkt op twee assen tegelijk: minder incidenten, en een kortere detectie plus herstel.

Data observability. Data observability bewaakt continu of je tabellen vers zijn, of de rij-aantallen normaal blijven en of de schema's stabiel zijn, en slaat alarm bij een afwijking. Dat drukt vooral de tijd tot detectie.

Automatische data tests. Schrijf expliciete regels op de dingen die je kent: dit ordernummer is uniek, dit bedrag is positief, dit veld is nooit leeg. Zulke tests draaien bij elke verwerking en vangen voorspelbare fouten goedkoop op.

Afspraken over freshness. Leg per belangrijke tabel vast hoe vers ze moet zijn, bijvoorbeeld nooit ouder dan een uur. Overschrijdt een tabel die grens, dan is dat meteen een incident. Dat heet een data freshness-afspraak.

Behandel een data-incident als een software-incident. Geef elke belangrijke dataset een eigenaar die de melding krijgt en reageert, en hou na een grote storing een korte terugblik: wat liep mis, waarom, en wat voorkomt de herhaling. Zo daalt de kans dat dezelfde storing later opnieuw toeslaat.