Instruktionen som raderade fel 26 språk

Jag instruerade min egen sajts automation att krympa bloggen till fyra språk. Två dagar senare upptäckte jag att den i samma veva tyst hade raderat tjugosex språk från startsidan också, utan att vare sig jag eller en enda besökare hade märkt det.

TL;DR

• En instruktion som var tänkt för bloggdelen tillämpades i stället på hela sajten.
• 26 av 30 språk försvann från startsidan, CV-sidan och alla navigeringstexter.
• Inget kraschade och inget gav 404, så ingen märkte något på två dagar.
• Lösningen kom från git-historiken, inte från minnet av hur sajten brukade se ut.
• Den verkliga lärdomen: innan en automatiserad ändring körs, namnge exakt vilka filer den rör, och läs den listan innan något raderas.

Varför jag ville ha färre språk från början

Min sajt hade på några månader växt till trettio språk: startsida, CV-sida och en blogg jag uppdaterar nästan var och varannan dag. Jag har redan skrivit om hur farligt det kan bli: maskinöversättning är flytande nog för att se bra ut och fel nog för att göra dig till åtlöje, på ett språk du själv inte kan kontrollera. Startsidan och CV:t ändras knappt, så den risken kunde jag leva med där. Bloggen var en annan sak. Nya inlägg går ut ofta, och jag kan uppriktigt sagt inte gå i god för översättningskvaliteten på en färsk artikel på estniska samma dag den publiceras.

Så jag bestämde mig för att skära ner antalet språk bloggen översätts till, till de fyra jag faktiskt litar på att jag själv kan kvalitetssäkra: engelska, ryska, tyska, tjeckiska. Allt annat blir kvar utanför bloggen tills jag har ett bättre sätt att verifiera det på. Den delen av planen var förnuftig. Det som gick fel var hur jag bad om det.

En mening, fel omfattning

Jag gav en enda instruktion: håll bloggen till fyra språk. Kort och konkret, trodde jag. Det som faktiskt kördes rörde tre olika saker på en gång. Det trimmade korrekt ner bloggens egna innehållsmappar till de fyra jag ville ha. Men det skrev också om sajtens övergripande språklista, konfigurationsfilen som avgör vilka språk som överhuvudtaget finns, och raderade startsidans innehåll och navigeringstexter för de andra tjugosex.

Problemet är att ”bloggen” och ”hela sajtens språklista” bor i samma konfigurationsfil. Ingenting i den filen skiljer på vilka språk bloggen stöder och vilka språk sajten som helhet stöder. Ta bort ett språk från listan, och varje sektion som läser från den, startsidan inräknad, förlorar det i ett enda drag. Min instruktion namngav en sektion. Ändringen som faktiskt kördes hade omfattningen av allt.

Det som gjorde det här farligt snarare än bara fel: ingenting gick sönder högljutt. Inget felmeddelande, ingen 404, ingen misslyckad build. Sajten slutade helt enkelt tyst att generera startsida och CV-sida för tjugosex språk, och språkväljaren slutade erbjuda dem. En besökare som brukade läsa sajten på portugisiska hamnade nu bara tyst på engelska i stället. Borttaget-för-att-det-raderades ser exakt likadant ut som har-aldrig-funnits, och ingen av dem kastar ett felmeddelande.

Två dagar gick innan jag upptäckte det, och bara av en slump, mitt i en helt orelaterad fix, när en ”Blogg”-länk i navigeringen pekade nånstans konstigt för ett av de språk jag trodde fortfarande var aktiva. Just den där döda länken var den enda synliga tråden tillbaka till hela problemet.

Vad diffen faktiskt visade

Det ärliga misslyckandet här är inte omfattningsmisstaget i sig. Det är att jag aldrig kontrollerade listan över filer som ändringen faktiskt skulle röra innan jag lät den köra. Jag läste en enradig beskrivning av vad den skulle göra och antog att den beskrev vad den faktiskt gjorde. Det gjorde den inte.

Reparationen började med en fråga: vad ändrades, och var. Jag diffade den skarpa sajten mot den senaste committen innan ”trimma bloggen”-instruktionen, och svaret kom omedelbart och entydigt: den övergripande språkkonfigurationen, startsidans innehållsmapp och tjugosex språkspecifika textfiler, ingen av dem i närheten av bloggkatalogen. Git hade varenda en av de filerna kvar exakt som de var. Ingenting var faktiskt förlorat, bara överskrivet vid deploy.

Jag återställde startsida, CV och navigeringstexter för alla trettio språk från den historiken, och lät bloggmappen ligga kvar precis så trimmad som jag ville ha den: fyra språk, med flit. En lös tråd återstod. ”Blogg”-länken för ett återställt språk pekade på en bloggutgåva på det språket som inte längre finns. Att duplicera fyra inlägg till tjugosex extra språk bara för att fylla den ena länken var inte värt det, så jag ställde in mallen så att den i stället leder till den engelska bloggen, och lämnade det så.

Vad jag skulle kontrollera annorlunda nästa gång

Innan jag i dag låter en automatiserad ändring röra en skarp sajt med flera sektioner ställer jag en extra fråga högt: namnge exakt vilka filer det här kommer att röra, inte funktionen det ska lösa. Är svaret vagt är det signalen att stanna upp och kontrollera, inte att köra och se vad som händer. Och innan något raderas vill jag ha den faktiska fillistan framför mig, inte en enradig sammanfattning av vad instruktionen förmodligen menade. Ett omfattningsord i en instruktion, ”bloggen”, ”det här teamet”, ”bara frontend”, är inte automatiskt detsamma som omfattningen på ändringen instruktionen faktiskt utlöser, och de två stämmer bara överens om någon faktiskt kontrollerade det: precis den fråga jag skickar tillbaka till dig. Vad är den minsta, mest självsäkert avgränsade instruktion du gett på sistone som aldrig kontrollerades mot vad den faktiskt rörde?