03/09/2026
L'Ingegneria del Software è Più di un Semplice Codice: Parliamo di On-Call
Quando senti parlare di "ingegneria del software", probabilmente pensi a scrivere codice, correggere bug, sviluppare applicazioni e lavorare con diversi linguaggi di programmazione. Ma c'è un'altra parte fondamentale di questo lavoro che chi aspira a diventare ingegnere del software dovrebbe comprendere: l'**on-call** (la reperibilità).
Quindi, cosa significa esattamente *on-call*?
Essere *on-call* significa semplicemente essere disponibili ad intervenire quando qualcosa non va in un sistema o in un'applicazione, specialmente al di fuori del normale orario di lavoro. Immagina un'azienda con un'applicazione usata da migliaia o milioni di persone e che, all'improvviso, alle 2:00 del mattino qualcosa smetta di funzionare. Gli utenti non sanno che il team di ingegneri è tornato a casa; sanno solo che l'app non va. Qualcuno deve indagare sull'accaduto, individuare il problema e lavorare per ripristinare il sistema. Quella persona è l'ingegnere che in quel momento è di turno *on-call*.
Questo non significa necessariamente che un ingegnere debba stare sveglio ogni notte a monitorare il sistema. La maggior parte dei team adotta una **rotazione di reperibilità**, in cui i membri si alternano nella responsabilità di rispondere agli incidenti.
Potresti essere di turno per una settimana, per poi lasciare il posto a un collega la settimana successiva. Durante il tuo turno, sei tenuto a rispondere agli allarmi critici e ad analizzare i problemi che richiedono attenzione immediata. A seconda dell'azienda, strumenti come PagerDuty, Slack o altri sistemi di monitoraggio e *alerting* ti notificheranno quando c'è qualcosa da verificare.
L'on-call non consiste solo nel svegliarsi e mettersi a scrivere codice. Spesso significa:
* Analizzare i log e consultare le dashboard di monitoraggio
* Verificare le modifiche recenti al sistema
* Comunicare con altri ingegneri e coordinare l'intervento
* Eseguire il *rollback* di un rilascio o riavviare un servizio
* Valutare se il problema richiede un livello superiore di *escalation*
È necessario saper pensare con chiarezza sotto pressione, perché i problemi in ambiente di produzione si verificano raramente al momento opportuno.
Ecco perché l'ingegneria del software va ben oltre la semplice scrittura di codice. Richiede capacità di *problem solving*, pensiero critico, comunicazione e una solida comprensione di come i sistemi creati si comportino realmente in produzione.
Se aspiri a diventare un ingegnere del software, non chiederti solo: *"Come scrivo questo codice?"*
Inizia a chiederti: *"Cosa succede quando questo codice è attivo in produzione e qualcosa va storto?"*
Perché sviluppare il software è solo una parte del lavoro. Mantenerlo affidabile è l'altra.
