Incident Response voor Data Pipeline Failures inrichten

Detectie bepaalt hoe snel u op de hoogte bent van een failure. Het verschil tussen een probleem detecteren om 03:00 uur en om 08:30 uur (wanneer de eerste gebruiker een report opent) is het verschil tussen een stille fix en een zichtbaar incident met impact op stakeholders.

Goede detectie vereist geautomatiseerde alerts van meerdere lagen:

Pipeline laag: Failure meldingen van ADF en Fabric Pipelines via Azure Monitor webhook triggers. Deze worden binnen enkele minuten na een failure geactiveerd.

Dataset laag: Power BI refresh failure meldingen via het ingebouwde alert systeem van Power BI Service. Deze vangen failures op die de pipeline laag mist, bijvoorbeeld wanneer een pipeline slaagt maar de Power BI model refresh mislukt door geheugenlimieten of een query timeout.

Volume laag: Geautomatiseerde controles op het aantal rijen die na elke refresh draaien. Dit is de enige manier om silent failures te onderscheppen: refreshes die slagen maar foute data laden.

Voor on-call doeleinden moeten alerts bruikbaar zijn zonder van context te wisselen. Een melding met de tekst 'Sales Overview dataset — refresh succeeded but row count dropped 65% compared to last run' is veel bruikbaarder dan 'refresh failed'. Het vertelt u direct de probleemcategorie.

Stuur kritieke alerts (datasets die board reports, financiële afsluitingen en operationele dashboards voeden) naar een paging systeem dat u wakker maakt. Stuur niet-kritieke alerts (kleine volume dalingen, performance degradatie) naar een teamkanaal voor review de volgende ochtend. Niet elk dataprobleem rechtvaardigt iemand wakker maken om 03:00 uur.

Zodra u om 03:00 uur wakker bent en weet dat er een probleem is, moet u het snel diagnosticeren. Een standaard diagnostische checklist elimineert de cognitieve overhead van beslissen waar u als eerste moet kijken.

Voer deze vijf checks in volgorde uit:

1. Controleer de pipeline laag: Heeft de ADF of Fabric pipeline gedraaid? Is die geslaagd? Als die mislukt is, wat was de specifieke fout? (Azure Monitor → Pipeline runs → specifieke run → foutdetails op activiteitsniveau.)

1. Controleer het volume: Hoeveel rijen heeft de pipeline gekopieerd ten opzichte van de vorige run? Een kopie met nul rijen is een ander probleem dan een gedeeltelijke lading. Nul rijen betekent doorgaans dat de bron geen data heeft aangeleverd. Een gedeeltelijke lading suggereert dat de pipeline onderbroken is.

1. Controleer de bron: Is het bronsysteem bereikbaar? Kunt u de brontabel rechtstreeks opvragen en de verwachte rijen ophalen? Dit sluit bronsijde failures uit: een database die down is, een API die 503s retourneert of een SFTP-server die het exportbestand niet heeft aangeleverd.

1. Controleer de gateway: Als de pipeline een on-premises data gateway gebruikt, is die online? Zijn er andere datasets die tegelijkertijd zijn mislukt? Meerdere gelijktijdige failures die verwijzen naar gateway-verbonden datasets wijzen op een gateway probleem, niet een pipeline probleem.

1. Controleer de Power BI refresh: Heeft de dataset refresh gedraaid nadat de pipeline klaar was? Is die geslaagd? Als zowel de pipeline als de refresh zijn geslaagd maar de data klopt niet, dan zit het probleem in de data zelf: een silent failure die volume en watermark onderzoek vereist.

Documenteer deze checklist en deel hem met iedereen in de on-call rotatie. De eerste vijf minuten van een incident om 03:00 uur moeten gestructureerd onderzoek zijn, niet vrij debuggen.

Stel vast wie er getroffen is voordat u iets fixt. Dit bepaalt de urgentie van uw reactie en bepaalt wie er op de hoogte moet worden gesteld en wanneer.

De impactanalyse beantwoordt vier vragen:

Welke reports zijn getroffen? Welke Power BI reports zijn gebouwd op de mislukte dataset? Zijn er downstream datasets die hieruit importeren? Zonder lineage tooling vereist dit het handmatig controleren van de data source configuratie van elk report, wat tijdrovend is in grote omgevingen.

Wie gebruikt die reports? Welke bedrijfsprocessen zijn afhankelijk van deze data? Is dit een board-level report, een operationeel dashboard dat per uur wordt gebruikt of een self-service analyse die onregelmatig wordt geraadpleegd?

Wat is de tijdsdruk? Is dit report nodig voor een vergadering van het management om 08:00 uur? Drijft het een dagelijks bedrijfsproces dat om 09:00 uur start? Of kan het wachten tot de volgende geplande refresh cyclus zonder enige impact op gebruikers?

Wat is er precies mis met de data? Ontbreekt de data volledig (geen rijen geladen, gebruikers zien geen data)? Is die fout (silent failure, gebruikers zien onjuiste cijfers)? Of is die vertraagd (refresh loopt achter, gebruikers ontvangen correcte data zodra die klaar is)?

De antwoorden op deze vragen bepalen uw communicatieprioriteit. Als de getroffen data een vergadering van het board over 4 uur voedt en de fix 90 minuten kost, moet de betreffende executive assistent nu op de hoogte worden gesteld zodat de vergadering kan worden verplaatst of de databeperking vooraf kan worden erkend. Als de getroffen data een zelden gebruikt analysehulpmiddel is, volstaat een Slack bericht 's ochtends.

De herstelprocedure is volledig afhankelijk van de hoofdoorzaak. Veelvoorkomende patronen en hun fixes:

Pipeline failure: Voer de pipeline opnieuw uit. Bevestig voordat u dat doet dat de hoofdoorzaak is opgelost. Als de pipeline mislukte omdat het bronsysteem niet beschikbaar was, helpt direct opnieuw uitvoeren niet. Controleer eerst de beschikbaarheid van de bron en de verwachte data.

Kopie met nul rijen: De pipeline heeft gedraaid maar geen data geladen. Wacht tot het bronsysteem zijn export aanlevert en voer daarna opnieuw uit. Als de bron een SLA heeft voor aanlevering en die niet heeft gehaald, escaleer naar de eigenaar van het bronsysteem voordat u opnieuw uitvoert.

Power BI refresh failure: Trigger een handmatige refresh vanuit Power BI Service of via de REST API. Houd de voortgang van de refresh in de gaten in plaats van te wachten op een melding. Live meekijken geeft u snellere feedback als die opnieuw mislukt.

Gateway failure: Herstart de gateway service. Bevestig of de gateway geconfigureerd is voor automatisch herstarten. Als de gateway down is door een Windows update of een verlopen certificaat, is de fix anders dan bij een gecrashte service en duurt die langer.

Verificatie is net zo belangrijk als de fix. Na het herstel:

1. Bevestig dat het aantal rijen in de doeltabel overeenkomt met de verwachting
2. Bevestig dat het watermark (max datumveld) is bijgewerkt naar de verwachte waarde
3. Trigger een Power BI refresh en bevestig dat die voltooid met het verwachte aantal rijen
4. Open het getroffen report en bevestig visueel dat de data er correct uitziet

Verklaar een incident niet gesloten totdat u end-to-end hebt geverifieerd. Een pipeline die succesvol heeft gedraaid maar naar de verkeerde tabel heeft geladen, of een refresh die is voltooid maar nog steeds gecachte data serveert, veroorzaakt binnen enkele uren een nieuw incident.

Een incident review is geen schuldenverdeling. Het is een gestructureerde analyse van wat er is gebeurd, waarom bestaande detectie- of preventiemechanismen het niet eerder hebben onderschept en welke specifieke wijzigingen de kans op herhaling verkleinen.

Voor data pipeline incidents zijn de meest nuttige incident review vragen:

Detectie gap: Hoe lang heeft het probleem bestaan voordat iemand het wist? Als het antwoord 'totdat een gebruiker het om 09:30 meldde' is, heeft u een monitoring gap. Welk specifiek alert had dit om 03:00 uur onderschept?

Nauwkeurigheid van de impactanalyse: Hoeveel reports waren getroffen? Zijn alle getroffen reports geïdentificeerd tijdens de impactanalyse, of werden er later alsnog ontdekt wanneer gebruikers klaagden? Als er zijn gemist, is de lineage documentatie onvolledig.

Analyse van hersteltijd: Hoe lang heeft het geduurd van alert tot oplossing? Waar is het onderzoek vertraagd? Welke diagnostische stap zou sneller zijn gegaan met betere tooling of documentatie?

Voorkombaarheid: Had deze failure voorkomen kunnen worden? Een verlopen credential is te voorkomen met proactieve monitoring. Een uitval van een bronsysteem is aan uw kant niet te voorkomen, maar de downstream impact kan worden verminderd met betere fallback afhandeling of eerdere communicatie naar stakeholders.

Ken voor elk actiepunt een specifieke eigenaar en een deadline toe. 'Monitoring verbeteren' zonder eigenaar en specifieke wijziging is geen actiepunt. De meest voorkomende waardevolle acties na een incident review zijn: een volume check toevoegen die ontbrak, een lineage link documenteren die niet werd bijgehouden en een escalatiepad toevoegen voor een stakeholder groep die te laat werd geïnformeerd.

Voer incident reviews uit voor elk incident dat iemand wakker heeft gemaakt, een stakeholder SLA heeft gebroken of ertoe heeft geleid dat beslissingen werden genomen op basis van foute data. Bundel kleinere incidents maandelijks en zoek naar patronen in plaats van individuele hoofdoorzaken.