Twintig jaar, van infrastructuur naar het scherm

De maat van onzichtbaar werk is dat het alleen beoordeeld wordt als het faalt. Twintig jaar heb ik dat geleerd; daarna ben ik naar de zichtbare kant gegaan.

Loopbanen zien er achteraf netjes uit. Tijdens het leven zijn ze dat niet: elke periode begint met een probleem dat de vorige niet kon oplossen.

Dit stuk gaat over vier periodes. Maar het is geen cv — het gaat over welke gewoonte in de volgende laag nuttig bleek en welke moest worden losgelaten.

2005–2013 — Bedrijfsinfrastructuur

Servers, opslag, back-up, beschikbaarheid.

Als deze periode één ding heeft geleerd, is het dit: een werkend systeem is onzichtbaar zolang het werkt. Back-ups komen jarenlang op niemands agenda. Dan zijn ze op een dag nodig, en die dag is het examen voor alles wat tot dan toe is gedaan.

Het professionele gevolg is vreemd. Goed uitgevoerd infrastructuurwerk levert geen lof op, alleen stilte. Lof komt pas als iets faalt en het herstel snel is — je zichtbaarste moment is dus je slechtste dag.

De meegenomen gewoonte: schrijf het herstelscenario vóór de opbouw. De eerste vraag bij het bouwen van een systeem is niet "hoe gaat het werken" maar "hoe komen we terug als het stukgaat". Dat een back-up bestaat is niet genoeg; het terugzetten moet geoefend zijn. Een ongeteste back-up is geen back-up.

2013–2019 — Netwerken en beveiliging

Routering, firewalls, toegang.

Netwerkwerk leert je een systeem als topologie te zien. Niet losse kasten maar de relaties ertussen. Waar een pakket langsgaat, welke regel het tegenhoudt, waarom het ene pad boven het andere gaat.

De blijvendste les van deze periode gaat niet over beveiliging maar over zichtbaarheid: de voorwaarde om een probleem op te lossen is het kunnen zien. De meeste netwerkstoringen zijn niet mysterieus; ze zijn alleen ongemeten. Zet op het juiste punt een teller en het mysterie lost op.

De tweede les gaat over standaardwaarden. Firewallregels stapelen zich op; elke regel was ooit nodig, geen enkele werd ooit verwijderd. Vijf jaar later kan niemand de hele lijst uitleggen. Een team dat niet opschrijft waarom een regel bestaat, kan hem nooit verwijderen.

Daarom leggen de codecommentaren die ik vandaag schrijf uit "waarom het zo is", niet "wat het doet". Wat het doet staat al in de code.

2019–2024 — Identiteit en M365

Active Directory, migraties, cloudidentiteit. Orde op de schaal van duizenden accounts.

Identiteitswerk is een les in schaal. Tien accounts beheer je met de hand. Bij duizenden verandert alles wat handmatig gebeurt vroeg of laat in inconsistentie — want handwerk is niet herhaalbaar.

De meegenomen gewoonte: een uitzondering is geen oplossing, het is een schuld. Een speciale regel die voor één gebruiker is geopend, blijft lang in het systeem nadat die gebruiker is vertrokken. Op schaal is het juiste antwoord niet de uitzondering vastleggen, maar de regel zo herschrijven dat de uitzondering overbodig wordt.

Migratieprojecten voegen hun eigen les toe: een migratie zonder terugvalplan is geen migratie maar een gok. En het terugvalplan moet vóór de migratie geoefend zijn, niet erna.

2024 — vandaag

AI-gedreven webapplicaties en webtechnologieën. Modellen en agents, met dezelfde discipline naar het scherm gekeerd.

De overgang is minder scherp dan hij lijkt. Een moderne webapplicatie is problemen van gedistribueerde systemen in het klein: toestandsbeheer, consistentie, foutherstel, waarneembaarheid. De namen veranderen, de vragen blijven.

De AI-laag beloont infrastructuurgewoonten intussen op een onverwachte manier. Een taalmodel is een onzeker onderdeel: het kan bij dezelfde invoer verschillende uitvoer geven, het kan stil fout zijn, en het faalt zonder een foutmelding te produceren. Precies die foutklasse is jarenlang bewerkt — alleen de laag is veranderd.

Daarom zijn de vragen die ik stel bij het schrijven van een agent dezelfde als bij het opzetten van een server: Waar meet ik? Hoe weet ik dat hij verkeerd geantwoord heeft? Hoe ver kan ik terugrollen als hij stukgaat?

Het verschil verscherpt op één punt. Als een server stukgaat, zegt hij het: de dienst valt uit, de monitoring waarschuwt, er belandt een regel in een logbestand. Als een taalmodel stukgaat, produceert het een vloeiende zin. De fout is stil en bovendien overtuigend.

Praktisch betekent dat: klassieke monitoring volstaat niet. Voor een server is "draait hij" genoeg; bij een model moet je "klopt het" apart vragen, en die vraag beantwoordt zichzelf niet. De uitvoer binden aan verifieerbare grond — een bron, een berekening, een meting — moet onderdeel van de architectuur zijn.

Twintig jaar gewoonte past hier precies: vertrouw niet de uitvoer maar de basis ervan.

Wat meeging

De gemene deler van vier periodes zijn vier gewoonten:

Alle vier doen vandaag hetzelfde werk. De verificatiesuite van deze site — de testreeks die weigert naar screenshots te kijken en in plaats daarvan luma van het canvas leest — is een direct product van de tweede. De besluitverslagen in de repository zijn dat van de vierde.

De rode draad: een foutenbudget

Er is één begrip dat in alle vier de periodes terugkeert, ook al verandert de naam telkens.

In de infrastructuur heette het "beschikbaarheidsdoel". Honderd procent beschikbaarheid bestaat niet; wat bestaat is vooraf zeggen hoeveel uitval je accepteert. Een team dat dat niet zegt, voert bij elke storing dezelfde discussie opnieuw.

In het netwerk heette het "acceptabele latentie". In de beveiliging "geaccepteerd risico". In identiteitsbeheer "welke uitzonderingen goedgekeurd zijn". Aan de productkant "prestatiebudget".

Het is allemaal hetzelfde: een grens vooraf opschrijven. Waar geen grens geschreven staat, wordt elk besluit een onderhandeling, en onderhandelingen wint meestal wie op dat moment het hardst praat.

Het schrijfgedeelte van deze site heeft ook een geschreven budget: grootste inhoudelijke weergave onder 2,5 seconden, paginascript onder 60 KB, geen opaciteitspoort voor de tekst. Alle drie worden bij elke run door de verificatiesuite gemeten. Wordt het getal overschreden, dan wordt de test rood — er begint geen discussie.

Dat is misschien de praktischste les van twintig jaar: goede bedoelingen zijn geen controlemechanisme. Een grens wordt gemeten, of hij bestaat niet.

Wat achterbleef

Er zijn dingen die niet meegingen, en die loslaten was zwaarder dan meenemen.

De verwachting van foutloze werking. In de infrastructuur is het doel nul uitval. Aan de productkant leidt een doel van nul fouten ertoe dat je nooit iets uitbrengt. Het nieuwe criterium werd niet "gaat het nooit stuk" maar "wat gebeurt er als het stukgaat".

Weerstand tegen verandering. In de serverruimte is de veiligste zet niet bewegen; een werkend systeem aanraken is risico. Aan de productkant geldt het omgekeerde: wat niet wordt aangeraakt veroudert. Dezelfde voorzichtigheid moet in een andere richting werken — niet de zet verhinderen, maar hem omkeerbaar maken.

Onzichtbaarheid voor een deugd houden. Twintig jaar lang was goed werk onopgemerkt werk. Dat criterium klopte in het eigen veld maar laat zich niet veralgemenen. Waar er een veld is waarin het werk zichtbaar hoort te zijn, is stilte daar geen deugd maar afwezigheid.

Deze site is het verslag van dat verschil. Twintig jaar bouwde ik systemen die niemand ziet; nu bouw ik het oppervlak — en leer ik dat ook het oppervlak meetbaar moet zijn.

Waarom de overgang makkelijk lijkt en het niet is

De meesten die van infrastructuur naar product gaan, trappen in dezelfde val: ze nemen aan dat technische bekwaamheid overdraagbaar is. Dat is ze — maar op zichzelf niet genoeg.

Wat ontbreekt is niet technisch. In de infrastructuur is "juist" meestal enkelvoudig: een configuratie werkt of werkt niet, een back-up herstelt of herstelt niet. Aan de productkant is juist meervoudig en contextafhankelijk. Of een interfacebesluit "juist" is, verandert met voor wie het is en wat het moet bereiken.

Voor een ingenieursgewoonte is dat een ongemakkelijke toestand. De vertrouwde zekerheid is weg. Wat ervoor in de plaats komt is meting: waar de waarheid niet enkelvoudig is, blijft meten wat elke optie oplevert de enige eerlijke weg.

Het tweede gat: onzichtbaar werk heeft geen publiek, zichtbaar werk wel. Twintig jaar lang was de tegenpartij van het werk een systeem. Nu is de tegenpartij een mens, en diens geduld, aandacht en context wisselen. Dat is geen probleem om op te lossen maar een werkelijkheid om mee te rekenen.

Een noot

Elk van bovenstaande periodes bevat concrete gebeurtenissen die je stuk voor stuk zou kunnen vertellen: een bepaalde migratie, een bepaalde storingsnacht, een bepaald architectuurbesluit. Dit stuk bevat ze niet.

De reden is eenvoudig: deze tekst gaat over disciplines, niet over gevallen. Gevallen verdienen eigen stukken, en elk zou met zijn eigen meting moeten komen — net als de andere teksten in dit gedeelte.

Er zit een risico in veralgemenen en ik ben me daarvan bewust: twintig jaar tot vier punten terugbrengen vlakt de echte besluiten in die jaren af. Uitleggen waar een gewoonte vandaan kwam is niet hetzelfde als uitleggen hoe je haar hebt verworven. Het tweede duurt langer en vraagt concretere voorbeelden.

Toch heeft deze lijst een functie: hij bepaalt de grond waarop u het volgende stuk leest. Waarom een zo aan meting gebonden schrijfgedeelte zo gebouwd is, valt met deze vier gewoonten te verklaren. De rest zit in de gevallen.