Vent'anni, dall'infrastruttura allo schermo

La misura del lavoro invisibile è che viene giudicato solo quando cede. Per vent'anni l'ho imparato; poi sono passato al lato visibile.

Le carriere sembrano ordinate a posteriori. Non lo sono mentre si vivono: ogni periodo comincia con un problema che il precedente non è riuscito a risolvere.

Questo testo parla di quattro periodi. Ma non è un curriculum — parla di quale abitudine si sia rivelata utile nello strato successivo e quale sia stato necessario lasciar cadere.

2005–2013 — Infrastruttura aziendale

Server, storage, backup, continuità.

Se questo periodo ha insegnato una cosa, è questa: un sistema che funziona è invisibile finché funziona. I backup non entrano nell'agenda di nessuno per anni. Poi un giorno servono, e quel giorno è l'esame di tutto ciò che è stato fatto fino ad allora.

La conseguenza professionale è strana. Il lavoro infrastrutturale ben fatto non produce lodi, solo silenzio. La lode arriva solo quando qualcosa cede e il ripristino è rapido — cioè il vostro momento più visibile è il vostro giorno peggiore.

L'abitudine portata avanti: scrivere lo scenario di ripristino prima dell'installazione. La prima domanda nel costruire un sistema non è "come funzionerà" ma "come torniamo quando si rompe". Che un backup esista non basta; il ripristino deve essere stato provato. Un backup non testato non è un backup.

2013–2019 — Reti e sicurezza

Routing, firewall, accesso.

Il lavoro di rete insegna a vedere un sistema come una topologia. Non singole scatole ma le relazioni fra esse. Da dove passa un pacchetto, quale regola lo ferma, perché un percorso è preferito a un altro.

La lezione più duratura di questo periodo non riguarda la sicurezza ma la visibilità: la precondizione per risolvere un problema è poterlo vedere. La maggior parte dei guasti di rete non è misteriosa; è soltanto non misurata. Mettete un contatore nel punto giusto e il mistero si dissolve.

La seconda lezione riguarda i valori predefiniti. Le regole del firewall si accumulano nel tempo; ognuna è servita una volta, nessuna è mai stata rimossa. Cinque anni dopo nessuno sa spiegare l'intero elenco. Una squadra che non scrive perché una regola esiste non potrà mai cancellarla.

Per questo i commenti al codice che scrivo oggi spiegano "perché è così", non "cosa fa". Cosa fa è già scritto nel codice.

2019–2024 — Identità e M365

Active Directory, migrazioni, identità cloud. Ordine alla scala di migliaia di account.

Il lavoro sull'identità è una lezione di scala. Dieci account li gestite a mano. A migliaia, tutto ciò che è fatto a mano prima o poi si trasforma in incoerenza — perché il lavoro manuale non è ripetibile.

L'abitudine portata avanti: un'eccezione non è una soluzione, è un debito. Una regola speciale aperta per un utente resta nel sistema molto dopo che quell'utente se n'è andato. Alla scala giusta la risposta non è registrare l'eccezione ma riscrivere la regola in modo che l'eccezione diventi inutile.

I progetti di migrazione aggiungono la loro lezione: una migrazione senza piano di ritorno non è una migrazione, è una scommessa. E il piano di ritorno va provato prima della migrazione, non dopo.

2024 — oggi

Applicazioni web basate sull'IA e tecnologie web. Modelli e agenti, rivolti allo schermo con la stessa disciplina.

Il passaggio è meno netto di quanto sembri. Un'applicazione web moderna sono problemi di sistemi distribuiti in miniatura: gestione dello stato, coerenza, ripristino dagli errori, osservabilità. I nomi cambiano, le domande restano.

Lo strato IA, intanto, premia le abitudini infrastrutturali in modo inatteso. Un modello linguistico è un componente incerto: può restituire output diversi per lo stesso input, può sbagliare in silenzio e fallisce senza produrre un messaggio d'errore. È esattamente la classe di guasti su cui si è lavorato per anni — è cambiato solo lo strato.

Perciò le domande che mi pongo scrivendo un agente sono le stesse di quando montavo un server: Dove sto misurando? Come capisco che ha risposto in modo sbagliato? Quanto indietro posso tornare se si rompe?

La differenza si acuisce in un punto. Quando un server si rompe, ve lo dice: il servizio cade, il monitoraggio avvisa, una riga finisce nel log. Quando si rompe un modello linguistico, produce una frase fluente. Il guasto è silenzioso e per giunta persuasivo.

La conseguenza pratica è che il monitoraggio classico non basta. Per un server basta "è su"; per un modello bisogna chiedere a parte "è giusto", e quella domanda non si risponde da sola. Legare l'output a un terreno verificabile — una fonte, un calcolo, una misura — deve far parte dell'architettura.

Vent'anni di abitudine calzano qui alla perfezione: fidatevi non dell'output ma della sua base.

Cosa è stato portato avanti

Il denominatore comune dei quattro periodi sono quattro abitudini:

Tutte e quattro fanno oggi lo stesso lavoro. La suite di verifica di questo sito — la serie di test che si rifiuta di guardare screenshot e legge invece la luma dal canvas — è un prodotto diretto della seconda. I verbali di decisione nel repository sono della quarta.

Il filo comune: un budget d'errore

C'è un concetto che ritorna in tutti e quattro i periodi, anche se il nome cambia ogni volta.

Nell'infrastruttura si chiamava "obiettivo di disponibilità". Il cento per cento di disponibilità non esiste; ciò che esiste è dire in anticipo quanta interruzione accettate. Una squadra che non lo dice rifà da capo la stessa discussione a ogni disservizio.

In rete si chiamava "latenza accettabile". In sicurezza "rischio accettato". Nella gestione delle identità "quali eccezioni sono approvate". Sul lato prodotto "budget di prestazione".

Sono tutti la stessa cosa: scrivere un limite in anticipo. Dove nessun limite è scritto, ogni decisione diventa una trattativa, e le trattative le vince di solito chi in quel momento parla più forte.

Anche la sezione di scrittura di questo sito ha un budget scritto: massima resa del contenuto sotto i 2,5 secondi, script di pagina sotto i 60 KB, nessun cancello di opacità davanti al testo. Tutti e tre sono misurati dalla suite di verifica a ogni esecuzione. Superato il numero, il test diventa rosso — non si apre alcuna discussione.

Potrebbe essere la lezione più pratica di vent'anni: le buone intenzioni non sono un meccanismo di controllo. Un limite o è misurato o non esiste.

Cosa è rimasto indietro

Ci sono cose che non sono state portate avanti, e lasciarle è stato più difficile che portarle.

L'aspettativa di un funzionamento impeccabile. Nell'infrastruttura l'obiettivo è zero interruzioni. Sul lato prodotto un obiettivo di zero difetti porta a non pubblicare mai nulla. Il nuovo criterio è diventato non "non si rompe mai" ma "cosa succede quando si rompe".

La resistenza al cambiamento. In sala server la mossa più sicura è non muoversi; toccare un sistema che funziona è un rischio. Sul lato prodotto vale l'opposto: ciò che non si tocca invecchia. La stessa prudenza va applicata in un'altra direzione — non impedire la mossa, ma renderla reversibile.

Considerare l'invisibilità una virtù. Per vent'anni il buon lavoro è stato lavoro non notato. Quel criterio era giusto nel proprio campo ma non si generalizza. Dove c'è un campo in cui il lavoro dovrebbe essere visibile, lì il silenzio non è virtù ma assenza.

Questo sito è il verbale di quella differenza. Per vent'anni ho costruito sistemi che nessuno vede; ora costruisco la superficie — e imparo che anche la superficie deve essere misurabile.

Perché il passaggio sembra facile e non lo è

La maggior parte di chi passa dall'infrastruttura al prodotto cade nella stessa trappola: presume che la competenza tecnica sia trasferibile. Lo è — ma da sola non basta.

Ciò che manca non è tecnico. Nell'infrastruttura "giusto" è di solito singolare: una configurazione funziona o non funziona, un backup ripristina o non ripristina. Sul lato prodotto il giusto è plurale e dipende dal contesto. Se una decisione d'interfaccia sia "giusta" cambia a seconda di per chi è e cosa deve ottenere.

Per un'abitudine ingegneristica è uno stato scomodo. La certezza a cui si è abituati non c'è più. Al suo posto subentra la misura: dove la verità non è singolare, misurare cosa produce ciascuna opzione resta l'unica via onesta.

La seconda lacuna: il lavoro invisibile non ha pubblico, quello visibile sì. Per vent'anni l'interlocutore del lavoro è stato un sistema. Ora l'interlocutore è una persona, e la sua pazienza, la sua attenzione e il suo contesto variano. Non è un problema da risolvere ma una realtà di cui tenere conto.

Una nota

Ciascuno dei periodi sopra contiene eventi concreti raccontabili uno per uno: una determinata migrazione, una determinata notte di guasto, una determinata decisione architetturale. Questo testo non li contiene.

La ragione è semplice: questo testo parla di discipline, non di casi. I casi meritano testi propri, e ognuno dovrebbe arrivare con la propria misura — come gli altri scritti di questa sezione.

Nel generalizzare c'è un rischio e ne sono consapevole: ridurre vent'anni a quattro voci appiattisce le decisioni reali prese in quegli anni. Spiegare da dove viene un'abitudine non è lo stesso che spiegare come l'avete acquisita. La seconda cosa richiede più tempo e pretende esempi più concreti.

Eppure questo elenco ha una funzione: fissa il terreno su cui leggerete il prossimo testo. Perché una sezione di scrittura così legata alla misura sia stata costruita in questo modo si spiega con queste quattro abitudini. Il resto sta nei casi.