Home / Vault & Second Brain / Een terugdraaiing die werkt verstopt de fout die hem nodig maakte

Een terugdraaiing die werkt verstopt de fout die hem nodig maakte

Een terugdraaiing die werkt verstopt de fout die hem nodig maakte

Deze week stond er een rode regel in mijn nachtelijke systeembulletin. Eén maar, en dat was juist het punt: het bulletin leert eindelijk een echte fout los te zien van de routine-ruis, dus voor het eerst las ik de regel echt in plaats van langs zes regels tegelijk te scheren. Eén script was omgevallen — de nachtelijke back-up van het geheugen van mijn agent. Hij was gefaald om 03:15 en sindsdien niet meer geslaagd.

Dus ik opende het script in de verwachting van een stukke back-up. De back-up was in orde. Vijfendertig geheugenbanken, nul fouten, een schoon bestand op schijf. Wat omviel was de kleine stap erna: een patchscript dat een bekend opmaakprobleem in mijn geheugenbestanden opruimt.

De fout was dom op de manier waarop alleen echte systemen dom zijn. Dat patchscript bevatte een zelfherstel-stap: zoek de markering # [CHARLY-PATCH, herschrijf hem naar -- [CHARLY-PATCH. Die was geschreven voor precies één patch, waar de markering binnen een SQL-string zit — en daar is # geen geldig commentaar terwijl -- dat wel is. Maar de stap liep over elke patch, in elk bestand. En mijn andere patches zitten in Python-code, waar # juist correct is en -- een syntaxfout.


Er brak niets, en dat was juist het probleem

Hier is het deel dat me even kostte om te zien. Er brak niets. Elk bestand wordt direct na het patchen op syntax gecontroleerd, en die controle draaide alle twaalf beschadigde bestanden netjes terug. Het script deed precies wat het moest doen: niets beschadigen.

En juist doordat het dat deed, kwam de oorzaak de volgende nacht terug, en de nacht daarna, en de nacht daarna. Hij kwam alleen bovendrijven als een exit-code zonder gevolg — een rode regel die betekende “het vangnet heeft het weer opgevangen” in plaats van “er is iets mis.”

Een terugdraaiing die werkt, verstopt de fout die hem nodig maakte.

Ik was stilletjes trots geweest op dat vangnet. Ik had het gebouwd zodat een slechte patch mijn geheugenbestanden nooit in een kapotte staat kon achterlaten — en het deed zijn werk perfect, zo perfect dat het de echte fout dagenlang in leven en onzichtbaar hield. Het net ving de val voor me op, en ik stopte met naar het koord te kijken.

Twee lessen eronder

De eerste is smal en mechanisch: een herstelstap moet weten welk soort ding hij aan het repareren is. Wanneer één script meerdere soorten vervangingen doorvoert, kan een zelfherstel-actie niet globaal zijn. # en -- zijn niet uitwisselbaar — elk is geldig in een andere taal, en een blinde tekstvervanging heeft geen idee in welke taal hij net is terechtgekomen. Mijn oplossing was om het zelfherstel te koppelen aan de ene patch die het nodig heeft, via een zesde veld in de patchtabel dat zegt: “deze gebruikt SQL-commentaar.”

De tweede is breder: een automatische correctie hoort zichzelf te melden. Het script maakte zijn eigen schade elke nacht stil ongedaan en zei nooit één keer “ik moest iets terugdraaien.” Een vangnet dat nooit spreekt is niet te onderscheiden van een vangnet dat niets te doen heeft. De hele waarde van een vangnet is niet dat het je veilig houdt — het is dat het vertelt wanneer het je moest redden. Een stil vangnet is geen geruststellend vangnet; het is een onge­meten vangnet.


Een vraag aan jou

Dus hier blijf ik op terugkomen: vertelt jouw automatisering je wanneer ze je gered heeft, of alleen wanneer ze faalde? Als je laatste honderd zelfherstel-acties allemaal stil slaagden en je er nooit een woord over hoorde — hoe zou je dan het verschil weten tussen een systeem dat gezond is en een systeem dat elke nacht stilletjes dezelfde wond dichtplakt? Ik hoor graag hoe jij dat aanpakt.

Wat vond je van dit bericht?

Laat een reactie achter

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *