Home / Vault & Second Brain / Toen mijn AI-gateway om 2 uur ’s nachts crashte, repareerde het systeem zichzelf

Toen mijn AI-gateway om 2 uur ’s nachts crashte, repareerde het systeem zichzelf

Toen mijn AI-gateway om 2 uur ‘s nachts crashte, repareerde het systeem zichzelf

Toen mijn AI-gateway om 2 uur ‘s nachts crashte, repareerde het systeem zichzelf

Om 02:10 vannacht is mijn Hermes-gateway gecrasht. Geen nette afsluiting, geen graceful exit — gewoon een heartbeat die halverwege stopte en nooit meer aansloeg. Ik kwam het later te weten, niet via een alarm maar via het logboek. Het interessante is niet dat het crashte. Het is dat 30 seconden later een nieuwe gateway stond, elke verbinding terug was en één sessie stilletjes verderging waar hij was gebleven. Ik hoefde geen vinger uit te steken.

Dit is geen geluk. Het is het verschil tussen een systeem dat draait en een systeem dat herstelt. Die les leerde ik op de harde manier in juli, toen een VM-shutdown alles meenam — in-memory state weg, cron-jobs leeg, een blogpost die nooit gepubliceerd werd omdat zijn tijdelijke bestanden in het RAM verdwenen. Dat incident kostte me een ochtend hoofdkrabben voordat ik doorhad dat de gateway gewoon twee minuten nodig had om wakker te worden.


Wat overleeft een crash?

Dus bracht ik precies in kaart wat op schijf staat en wat alleen in het geheugen leeft. De uitkomst stuurde elk besluit sindsdien:

  • Alles wat ertoe doet staat op schijf. Alle 60+ cron-schema’s worden bij het opstarten hersteld uit een JSON-bestand. Gesprekken, geheugen, skills, config — allemaal bestanden op schijf die elke reboot overleven.
  • In-memory state behandel ik als wegwerpbaar. Draaiende sessies sterven, actieve verbindingen vallen weg. Ik stopte met doen alsof het anders was en bouwde eromheen.
  • Eén simpele regel: schrijf tussenbestanden nooit naar /tmp/. Dat is RAM, en RAM vergeet. Elke cron-job schrijft nu naar een persistente state-map op schijf.

Precies die laatste regel redde me vandaag. Toen de gateway crashte en herstartte, pakten mijn cron-jobs hun tussenbestanden van schijf — niets verloren, niets hoefde opnieuw gegenereerd te worden.


Nog beter: de backups repareerden zichzelf

Een uur na de herstart merkte mijn backup-scanner dat zeven wiki-pagina’s verdwenen waren door een verkeerd gelopen telefoon-sync — en herstelde stilletjes alle zeven uit de Synology-backup. Geen melding, geen ticket, geen “hé, dit moet je even bekijken.” Alleen een logregel die zei dat het geregeld was.

Dat was het moment waarop ik besefte dat veerkracht geen groot kenmerk is. Het is een stapel kleine, saaie gewoontes: persistentie op schijf, restart-met-altijd, health-checks bij het opstarten, en backups die niet hoeven te merken dat ze draaien.


De les

Je kunt niet elke crash voorkomen. Maar je kunt ervoor zorgen dat een systeem een crash behandelt als een kleine hobbel in plaats van een ramp. De meetwaarde die telt is niet “gaat hij uit?” — alles gaat uiteindelijk uit. Het is “hoe snel komt hij terug, en hoeveel hoef ik erbij te doen?”

Vannacht: 30 seconden om te herstellen, nul betrokkenheid van mij. Zo voelt goed systeemontwerp.

Weet jij wat een herstart op jouw opstelling daadwerkelijk overleeft — of kom je er alleen op de harde manier achter? Ik hoor graag hoe jij omgaat met crash-resilience in je eigen systemen.

Wat vond je van dit bericht?

Laat een reactie achter

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