Il punto di partenza
Nel 2026, il DevOps è una disciplina dallo statuto particolare. Quasi tutti i team di ingegneria affermano di praticarlo. Molto meno numerosi sono quelli che possiedono davvero le proprietà operative che il termine prometteva all'origine: lead time brevi, un basso tasso di fallimento dei cambiamenti, un recupero rapido dopo l'incidente e una cultura in cui il deploy non è un evento trimestrale.
Il divario tra i due si è allargato con l'arrivo dei prodotti che si appoggiano all'IA. La cadenza di deploy che bastava a un'applicazione CRUD crolla quando il prodotto comporta un endpoint servito da un modello, suscettibile di derivare, di degradarsi o di essere limitato in rate da un fornitore a monte. Il DevOps che funzionava non basta più.
Questo articolo riguarda ciò che il livello operativo deve davvero consegnare per prodotti che integrano funzionalità di IA e il modo in cui l'IA stessa trasforma il lavoro DevOps.
Due fattori hanno teso il livello operativo nello stesso tempo
La cadenza e la superficie di esposizione sono entrambe aumentate. Il DevOps che bastava ha smesso di bastare.
Il primo fattore è la cadenza. L'ingegneria assistita dall'IA ha compresso il tempo tra la scrittura di un cambiamento e il momento in cui è pronto a essere consegnato. Team che mettevano una settimana a integrare un cambiamento non banale lo integrano ora in una giornata. La pipeline che inquadrava la cadenza più lenta diventa il collo di bottiglia della nuova.
Il secondo fattore è la superficie di esposizione. Le funzionalità di IA aggiungono dipendenze a monte (fornitori di modelli, sistemi di recupero, database vettoriali, harness di valutazione) che non esistevano in un'applicazione web classica. Ciascuna di esse può fallire in un modo che il resto dell'applicazione deve gestire con eleganza. Il livello operativo deve conoscerle tutte.
Insieme, questi due fattori hanno riportato il DevOps da una disciplina di sfondo al centro dell'ingegneria. I team che non hanno investito di conseguenza producono più interruzioni dal raggio d'impatto più ampio. Quelli che l'hanno fatto consegnano di più, più in fretta, con una risposta agli incidenti più serena.
Pipeline, infrastruttura-as-code, observability, risposta agli incidenti
In SDEN, il livello operativo si articola attorno a quattro pratiche. Le pipeline: ogni cambiamento è compilato, testato e deployato dalla stessa meccanica, senza passo manuale che dipenda dal portatile di qualcuno. L'infrastruttura as code: ogni ambiente è riproducibile a partire dal repository, compresa la struttura dei segreti (non i loro valori). L'observability: metriche, log e tracce di ogni componente, con dashboard detenute dal team che detiene il componente. La risposta agli incidenti: runbook scritti, una rotazione di reperibilità umana e revisioni post-incidente che producono cambiamenti reali.
Queste quattro pratiche costituiscono lo zoccolo minimo. È anche il punto in cui la maggior parte delle missioni arenate rivela lacune (di solito nell'observability e nella risposta agli incidenti), perché le pipeline e l'IaC sono visibili mentre le altre due lo diventano solo al momento delle interruzioni.
Proprietà operative senza le quali un prodotto di IA non può essere consegnato
Un prodotto che dipende da un modello in produzione ha bisogno di proprietà operative di cui un prodotto web classico può fare a meno. La ridondanza dei fornitori: almeno due fornitori di modelli cablati tramite un sottile livello di astrazione, con la capacità di basculare in pochi secondi. La valutazione degli output in produzione: una verifica automatizzata per campionamento che il modello produca ancora output accettabili, con alert quando la qualità deriva. Gli interruttori di costo: limiti stretti che restringono o disattivano le funzionalità di IA quando la fattura prende una direzione che l'azienda non ha approvato. E un rollback che include il prompt: non solo il codice, ma il prompt, l'indice di recupero e la suite di valutazione, tutti versionati insieme.
Niente di tutto questo è esotico. È l'equivalente, in disciplina operativa, dell'allacciare la cintura di sicurezza. Il costo dell'omissione è il tipo di incidente che diventa un post-mortem che nessuno ha voglia di scrivere.
Tre scelte di default che decidono se un team può consegnare serenamente
Sono le pratiche che installiamo a ogni missione. Non sono negoziabili: ometterle produce gli incidenti che dobbiamo poi ripulire.
Una sola pipeline, nessun passo manuale
Ogni cambiamento passa per la stessa pipeline: compilazione, test, verifica di sicurezza, deploy. Nessun passo manuale dipende dal portatile, dall'account o dalla memoria di un ingegnere in particolare.
Un'observability detenuta dal team
Le dashboard, gli alert e i runbook sono detenuti dal team che detiene il codice. L'observability non è una funzione separata; fa parte del lavoro di ingegneria.
Una reperibilità umana
Le rotazioni di reperibilità sono dimensionate perché un ingegnere non sia di reperibilità più di una settimana su cinque. Gli alert sono calibrati perché un ingegnere di reperibilità possa dormire. Se il sistema non può garantirlo, si corregge il sistema, non la rotazione.
Un team che consegna ogni giorno e dorme ogni notte
La maturità operativa si sente come noia, e la noia, in questa disciplina, è l'obiettivo.
Un livello operativo maturo cambia il ritmo del team di ingegneria. I deploy non sono più eventi. Gli incidenti sono rari, contenuti, e producono apprendimento anziché trauma. L'ingegnere di reperibilità passa una settimana senza essere chiamato. Il team consegna costantemente piccoli cambiamenti, perché i piccoli cambiamenti sono sicuri e i grandi no.
Quando questo funziona, è invisibile. Il test onesto è cosa dicono gli ingegneri della rotazione di reperibilità. Se la descrivono come umana, il livello operativo è sano. Se la descrivono altrimenti, resta del lavoro da fare.
Quando SDEN conclude una missione DevOps, il deliverable non è un manifesto Kubernetes. È un team capace di far funzionare il sistema senza di noi, e che ne ha voglia.
DevOps e automazione
le domande che ci fanno più spesso.
Risposte dirette alle domande che ci vengono poste più spesso. Se la tua non c'è, scrivi al team.