Från nattliga CSV-exporter till ett mappnings-API i realtid: så gör du bytet
Du har ärvt pipelines som läser mappningar från CSV-filer. Själva mappningarna finns någon annanstans: i Excel, i en liten databas eller i ett leverantörssystem som exporterar varje natt. Varje pipeline läser CSV-filen när körningen startar, gör en join mot transaktionerna och skriver resultatet till datalagret. Allt fungerar. Teamet är nöjt.
Sedan frågar någon om mappningarna kan uppdateras i realtid. Ekonomiteamet vill lägga till en ny kund kl. 10:00 och få med den i eftermiddagens rapport. Det klarar inte dagens upplägg. CSV-filen uppdateras vid midnatt.
Bytet görs inte i en handvändning. De flesta pipelines byggdes utifrån att mappningen är en fil. Frågan är hur du byter utan att något i drift går sönder.
Migreringen i fyra faser
Fas 1. Sätt upp API:et. Mappningssystemet har troligen redan ett, eller går att ställa in så att det får ett. Det första du gör är att kontrollera att API:et returnerar exakt samma innehåll som CSV-filen vid samma tidpunkt. Lägg en vecka på att stämma av skillnaderna. Det du inte får att stämma här får du betala för senare.
Fas 2. Kör skuggtrafik. Varje pipeline anropar API:et samtidigt som den läser CSV-filen och skriver API:ets svar till en plats vid sidan av. Logiken i pipelinen är densamma, och API-svaret används inte skarpt än. Poängen är att se att API:et klarar belastningen i produktion innan du binder dig vid det.
Fas 3. Byt en pipeline i taget. Börja med den som ställer till minst skada om något går fel, till exempel en rapportpipeline som bara berör ett team. Låt den läsa från API:et. Håll koll på den i en vecka. Går något sönder byter du tillbaka. Går inget sönder går du vidare. Ordningen spelar roll: den minsta först, sedan de som är lättast att följa och de mest kritiska sist. När det är dags för den kritiska pipelinen har du flera veckors erfarenhet från drift.
Fas 4. Stäng av CSV-exporten. Först när alla pipelines läser från API:et och inget annat system läser CSV-filen. Låt CSV-filen finnas kvar en månad efter det sista bytet. Någonstans finns ett hemsnickrat skript som läser den, och det är bättre att ägaren upptäcker det i lugn och ro.
Det här ändras
| Område | Fil | API |
|---|---|---|
| Fördröjning | Uppdateras en gång per dygn | Direkt |
| Schema | Inga krav | Fast kontrakt |
| Fel | Filen saknas | Tillfälliga fel med omförsök |
| Autentisering | Behörigheter på mappen | Tjänstekonto eller nyckel |
| Spårbarhet | Filens ändringstid | Per ändring |
| Övervakning | Finns filen? | Svarstid, felfrekvens, aktualitet |
Det mesta av migreringen handlar om att vänja sig vid tabellens högra kolumn. När API:et väl står framför datan ser arbetet runt omkring (autentisering, omförsök, övervakning) ut som i vilken annan API-integration som helst.
Det här behöver du planera för
Svarstid. Ett nätverksanrop i stället för att läsa en lokal fil. De flesta pipelines klarar det utan problem. Undantagen är pipelines som gjorde många små uppslag. De behöver batchanrop eller en cache som fylls när körningen startar.
Autentisering. CSV-filen krävde ingen inloggning. Det gör API:et. Sätt upp tjänstekonton före migreringen, så att inloggningsuppgifter inte blir flaskhalsen när en pipeline ska byta.
Omförsök. CSV-filen fanns, eller så fanns den inte. API:et kan ge ett tillfälligt fel. Lägg till omförsök med ökande väntetid (backoff) där det saknas. De flesta HTTP-klienter har det inbyggt.
Schemaändringar. CSV-filen var platt. API:et kan ge mer. Bestäm tidigt om varje pipeline ska använda den rikare strukturen eller platta till den igen. Det första alternativet kräver mer arbete men gör nya saker möjliga.
Övervakning. Frågan ”fanns filen?” blir ”hur ser svarstiden och felfrekvensen ut?” Sätt upp övervakningen under migreringen, inte efteråt.
Flyttar du till gridmap sköter Lookup API allt det här: behörigheter per nyckel, enskilda uppslag och batchuppslag, och loggning av användningen i samma granskningslogg som du ser när du redigerar.
En realistisk tidplan
För ett typiskt medelstort företag med tjugo till trettio pipelines: tre till sex månader. Det mesta görs i tur och ordning, och det mesta är ganska tråkigt. Varje byte tar en eller två dagar plus en veckas övervakning.
Vinsten: nästa gång verksamheten ber om data i realtid är svaret ja, direkt, i stället för ”jag ska se vad vi kan göra”.
Vanliga frågor
Måste vi byta alla pipelines? Förr eller senare, men ni bestämmer ordningen. Pipelines som verkligen inte behöver färsk data kan ligga kvar på CSV-filen tills de ändå ska skrivas om av något annat skäl.
Hur gör vi med system som inte kan läsa från ett API alls? En schemalagd filexport från API:et ger det gamla systemet en fil, medan allt nyare läser direkt. Då är filen en kopia av sanningen, inte en mellanhand framför den.
Hur vet vi att migreringen är klar? När filexporten är avstängd och det har varit tyst i trettio dagar. Fram till dess pågår den.