Blog

Reperibilità e burnout: il costo umano delle infrastrutture always-on

Le infrastrutture digitali always-on sono diventate la normalità operativa in quasi ogni settore. Piattaforme e-commerce, sistemi di pagamento, servizi SaaS, ambienti produttivi interconnessi, supply chain digitali e applicazioni customer-facing devono garantire continuità, reattività e disponibilità costante. Dal punto di vista del business, il principio è chiaro: ogni minuto di interruzione ha un costo economico, reputazionale e talvolta regolatorio. Dal punto di vista delle persone che progettano, gestiscono e difendono queste infrastrutture, la stessa promessa di continuità ha però un costo umano che spesso rimane sottostimato. La reperibilità, quando si prolunga nel tempo o si inserisce in contesti organizzativi fragili, può diventare un fattore di pressione cronica. In questo spazio si colloca il rischio di burnout.

La necessità della reperibilità in molti contesti è indispensabile. Il punto è comprendere che la disponibilità tecnica dei sistemi non coincide automaticamente con la disponibilità psicofisica delle persone. Confondere questi due piani porta a un errore ricorrente: trattare il carico umano come una variabile elastica, compensabile con dedizione individuale, spirito di squadra o senso di responsabilità. I dati raccolti negli ultimi anni suggeriscono il contrario. I modelli di lavoro caratterizzati da interruzioni fuori orario, elevata imprevedibilità e responsabilità operative persistenti tendono ad aumentare stress, affaticamento, errori e intenzione di lasciare il ruolo. In altri termini, il problema non è solo etico o organizzativo. È anche un problema di affidabilità.

Per i tech leader, i senior developer e i partner IT, questo tema è particolarmente rilevante perché tocca la relazione tra architettura, operations e sostenibilità del lavoro tecnico. Quando un’organizzazione dichiara di voler essere affidabile 24 ore su 24, sta implicitamente scegliendo un modello di supporto, osservabilità, escalation, staffing, ownership e gestione dell’incidente. Se questi elementi non sono progettati insieme, la continuità del servizio rischia di essere sostenuta da una continuità di allerta umana. Ed è proprio questa sovrapposizione a produrre nel medio periodo un deterioramento che spesso si manifesta prima come calo di lucidità, poi come inefficienza operativa, e infine come esaurimento, turnover o incidenti ripetuti.

Il contesto operativo delle infrastrutture sempre disponibili

Negli ultimi dieci anni l’aspettativa di disponibilità si è alzata in modo significativo. La migrazione al cloud, la diffusione di architetture distribuite, l’adozione di pratiche DevOps e SRE, l’integrazione continua con partner esterni e la pressione del time-to-market hanno cambiato il perimetro del lavoro tecnico. In teoria, automazione, infrastructure as code, autoscaling, managed services e piattaforme di osservabilità avrebbero dovuto alleggerire il carico manuale. In pratica, in molte organizzazioni si è verificato un effetto ambivalente. Alcuni compiti sono stati effettivamente standardizzati e resi meno onerosi, ma la complessità complessiva del sistema è aumentata. Più dipendenze, più segnali, più componenti, più punti di rottura e più aspettative di risposta immediata.

Questo scenario ha trasformato la reperibilità in qualcosa di più sofisticato di una semplice turnazione di supporto. Oggi chi è on-call non presidia solo un singolo server o una specifica applicazione, ma un ecosistema composto da pipeline CI/CD, cluster, database distribuiti, code di messaggistica, servizi terzi, API pubbliche, strumenti di sicurezza, monitoraggio sintetico, sistemi di identity management e talvolta vincoli normativi. L’incidente tecnico non è più sempre localizzabile rapidamente. Spesso emerge come degradazione progressiva, comportamento anomalo o interazione imprevista tra componenti formalmente sani. In questi casi la pressione cognitiva aumenta. Non si tratta solo di intervenire. Si tratta di diagnosticare in condizioni di tempo limitato e in un contesto di rischio.

La letteratura sul lavoro ad alta intensità mostra da tempo che la combinazione tra elevata responsabilità, bassa prevedibilità e frequenti interruzioni è una delle configurazioni più critiche per il benessere professionale. Questo vale in modo particolare per ruoli che richiedono attenzione sostenuta, ragionamento analitico e assunzione di decisioni sotto incertezza. Nelle organizzazioni digitali mature il lavoro tecnico non è più meramente esecutivo. È un lavoro cognitivo ad alta specializzazione. Per questo il costo della reperibilità non può essere misurato soltanto in numero di ore chiamate o ticket fuori orario. Va misurato anche in termini di frammentazione del recupero, qualità del sonno, percezione di controllo, latenza decisionale, errori in produzione e stabilità del team.

Cosa intendiamo davvero per burnout nel lavoro tecnico

Il burnout viene spesso usato nel linguaggio quotidiano per descrivere stanchezza intensa o demotivazione. In realtà, in ambito scientifico e organizzativo, il concetto è più preciso. L’Organizzazione Mondiale della Sanità lo descrive come una sindrome risultante da stress cronico sul posto di lavoro che non è stato gestito con successo. Le dimensioni richiamate più spesso sono tre: esaurimento energetico, distacco mentale o cinismo verso il lavoro e ridotta efficacia professionale. Questa definizione è importante perché sposta l’attenzione dal piano individuale a quello sistemico. Il burnout non è semplicemente una fragilità personale. È spesso l’effetto di un assetto di lavoro non sostenibile.

Nel settore IT, il burnout assume forme che possono essere inizialmente scambiate per tratti di professionalità o commitment. Essere sempre raggiungibili, intervenire rapidamente, “salvare la notte”, assorbire in silenzio il rumore operativo, ridurre il numero di incidenti a costo di sacrificare il recupero, sono comportamenti che in molte culture tecniche vengono premiati implicitamente. Il problema è che questi stessi comportamenti, se ripetuti e normalizzati, rendono invisibile il deterioramento. Il professionista continua a performare, ma inizia a farlo in deficit di recupero, con soglia attentiva ridotta, irritabilità crescente e minore capacità di apprendimento. Quando il sistema dipende troppo a lungo da questo equilibrio precario, la rottura diventa probabile.

I dati a disposizione confermano che il fenomeno non è marginale. Il report annuale di Atlassian dedicato allo stato del developer experience ha evidenziato negli ultimi anni una relazione forte tra qualità del contesto di lavoro, overload e rischio di burnout percepito. Anche il report DORA di Google Cloud, pur concentrandosi sulla performance organizzativa, ha mostrato più volte che il benessere dei team e la qualità della delivery sono strettamente connessi. Team con pratiche sane, buona documentazione, processi chiari e leadership efficace non solo distribuiscono software meglio, ma mostrano anche livelli inferiori di fatica distruttiva e migliori esiti di retention. La conclusione è rilevante: affidabilità tecnica e sostenibilità umana non sono obiettivi in competizione. Tendono, al contrario, a rafforzarsi.

La reperibilità come fattore di carico invisibile

Uno degli aspetti più sottovalutati della reperibilità è che il carico non coincide con l’intervento effettivo. Anche quando l’incidente non si verifica, lo stato di disponibilità produce un vincolo psicologico e comportamentale. Chi è reperibile modifica il proprio livello di attenzione, la gestione del tempo, la libertà di movimento, la qualità del riposo e persino la possibilità di disconnettersi cognitivamente. In psicologia del lavoro, questa condizione viene spesso associata a una riduzione del recupero anticipatorio e a una minore possibilità di prendere distanza mentale dal ruolo.

Questo è particolarmente vero quando la reperibilità è poco prevedibile, mal distribuita o inserita in un clima di allarme continuo. Se gli alert sono numerosi, scarsamente prioritizzati o frequentemente falsi positivi, il team sviluppa una relazione difensiva con il monitoraggio. Da un lato aumenta la desensibilizzazione, con il rischio di sottovalutare segnali critici. Dall’altro cresce una forma di tensione latente che rende più difficile il recupero, anche in assenza di escalation reali. In pratica, non serve una notte intera di incidenti per consumare energia mentale. Basta la prospettiva credibile che la notte possa essere interrotta in qualsiasi momento da un evento opaco, urgente e ad alta responsabilità.

Le ricerche sul sonno e sul lavoro in reperibilità hanno mostrato che l’aspettativa di interruzione può incidere negativamente sulla qualità del riposo anche quando il numero di chiamate è basso. Il sonno frammentato o percepito come vulnerabile ha effetti rapidi su memoria di lavoro, velocità decisionale, regolazione emotiva e capacità di problem solving. In ambito infrastrutturale questo punto è cruciale. Molte decisioni prese durante un incidente richiedono valutazione di trade-off, lettura di segnali ambigui, coordinamento con più stakeholder e capacità di distinguere tra workaround temporaneo e correzione strutturale. Se il capitale cognitivo disponibile è ridotto, aumenta il rischio di mitigazioni parziali, rollback affrettati, diagnosi incomplete e accumulo di debito operativo.

I numeri dietro il problema

Quando si affronta il rapporto tra always-on e burnout, conviene evitare impressioni aneddotiche e osservare alcuni dati. Il burnout è difficile da misurare in modo perfettamente uniforme, ma esistono indicatori robusti su cui ragionare. Secondo il report State of the Global Workplace di Gallup, lo stress quotidiano rimane elevato in molte organizzazioni e rappresenta una variabile con effetti diretti su engagement, produttività e intenzione di turnover. Nel settore knowledge work, la percezione di essere sempre “attivabili” è tra i fattori più spesso associati a sovraccarico e difficoltà di recupero.

Sul versante specifico dell’operatività IT, il report The DevOps Research and Assessment ha mostrato che la qualità del flusso di lavoro, la stabilità dei processi e la cultura organizzativa incidono in modo misurabile non solo sulla software delivery performance ma anche sul benessere. Quando il deployment è ad alto stress, quando i processi di approvazione sono lenti ma l’urgenza resta alta, quando la documentazione è scarsa e la collaborazione tra team è frammentata, il carico psicologico cresce. Non perché le persone siano meno competenti, ma perché il sistema richiede loro di compensare continuamente difetti strutturali.

Anche il tema della perdita economica è meno astratto di quanto sembri. Il burnout tende ad aumentare assenteismo, errori, turnover e riduzione della produttività sostenibile. Sostituire profili senior in ambito infrastrutturale o piattaforma ha costi elevati, spesso non limitati al recruiting. A ogni uscita si sommano perdita di contesto, indebolimento delle rotazioni, maggiore pressione sui colleghi rimasti, rischio di knowledge silos e rallentamento dei progetti strategici. In organizzazioni piccole o medie, la dipendenza da poche persone chiave accentua ulteriormente il fenomeno. Qui la reperibilità può trasformarsi da misura di continuità a moltiplicatore di fragilità.

Un altro dato utile arriva dai report di settore sulla developer experience e sull’ingegneria di piattaforma. Dove la qualità dei tool interni, della documentazione e dei percorsi di supporto è alta, diminuisce la quantità di lavoro interruttivo e aumenta il tempo disponibile per attività a maggiore valore. Questo non elimina la necessità della reperibilità, ma ne riduce la frequenza traumatica. In altre parole, le metriche di benessere non dipendono soltanto da quante persone ci sono in turnazione. Dipendono anche da quanto il sistema è progettato per fallire in modo leggibile, contenibile e recuperabile.

Nella maggior parte dei casi il burnout associato alla reperibilità non nasce da un unico fattore. Nasce da una combinazione di scelte tecnologiche, vincoli di business e pratiche organizzative. Uno dei casi più frequenti è la disallineata distribuzione della responsabilità. Un team può essere owner del servizio in produzione senza avere reale controllo sulle dipendenze da cui il servizio dipende. In questo assetto la reperibilità diventa una responsabilità senza piena leva. Il team risponde all’incidente ma non possiede tutti gli strumenti per prevenirlo, diagnosticarlo o risolverlo in autonomia. Questa condizione è intrinsecamente usurante, perché aggiunge frustrazione a un carico già elevato.

Un secondo fattore è il rumore operativo. Alerting mal calibrato, osservabilità incompleta, runbook obsoleti, escalation poco chiare e incident review orientate alla colpa costringono il personale tecnico a colmare continuamente gap di sistema attraverso esperienza tacita e memoria individuale. Questo modello può funzionare finché il team è stabile e i volumi restano gestibili. Quando però aumentano complessità, crescita del business o rotazione del personale, il sistema perde resilienza. I singoli diventano infrastruttura. E quando le persone diventano infrastruttura, la probabilità di burnout cresce in modo netto.

Un terzo elemento riguarda la cultura della disponibilità. In alcune organizzazioni la reperibilità formale convive con una reperibilità informale ancora più pervasiva. Chat serali, notifiche persistenti, decisioni urgenti demandate sempre agli stessi esperti, escalation che bypassano il turno ufficiale, release critiche pianificate in orari sfavorevoli, mancanza di confini tra supporto e delivery. Tutto questo crea un ambiente in cui il tempo di recupero viene costantemente eroso. Il problema è che tale erosione non appare subito nelle metriche classiche. I sistemi restano apparentemente stabili. I ticket vengono chiusi. Le persone continuano a rispondere. Il costo emerge dopo, sotto forma di stanchezza cumulativa, qualità altalenante, conflitti interni o abbandono.

Il paradosso dell’eroismo operativo

Molte culture tecniche continuano a premiare l’eroismo operativo. La persona che interviene alle tre del mattino, che conosce il sistema “meglio della documentazione”, che trova il fix sotto pressione e rimette in piedi il servizio viene spesso celebrata. Questo riconoscimento è comprensibile. In una crisi reale, competenza e sangue freddo fanno la differenza. Il problema nasce quando l’eccezione diventa norma e l’eroismo viene trattato come modello operativo desiderabile.

Da un punto di vista manageriale, l’eroismo è un segnale ambiguo. Può indicare alto livello professionale, ma può anche indicare che il sistema dipende troppo da conoscenza non codificata, procedure immature o debito tecnico non affrontato. Se gli stessi nomi compaiono in ogni incidente grave, il messaggio non è che l’organizzazione è solida. Il messaggio è spesso il contrario. Significa che l’affidabilità del servizio è concentrata in poche persone e che il rischio umano è già materializzato, anche se non è ancora contabilizzato.

Inoltre, l’eroismo ha un costo culturale. Rende difficile normalizzare il bisogno di confini, recupero e rotazioni sane. Chi segnala sovraccarico teme di apparire meno committed. Chi chiede più struttura viene talvolta percepito come burocratico. Chi prova a ridurre il rumore operativo può scontrarsi con l’idea che “in produzione serve reagire, non discutere”. Nel lungo periodo, però, le organizzazioni più affidabili sono quasi sempre quelle che riducono la dipendenza dall’eroismo. Standardizzano, documentano, automatizzano, condividono contesto e accettano che la continuità tecnica richiede anche continuità di energie.

Misurare il costo umano con metriche utili

Per trattare il problema in modo data driven serve misurarlo con indicatori più intelligenti di una generica percezione di stress. Le organizzazioni mature iniziano distinguendo tra volume di incidenti e qualità dell’esperienza on-call. Non basta sapere quante pagine arrivano in un mese. Serve capire quante sono azionabili, quante sono falsi positivi, quanto dura mediamente la diagnosi, quante escalation attraversano più team, quante notti vengono effettivamente interrotte e quanto tempo serve per il recupero post-incidente.

A questo si possono affiancare metriche organizzative che spesso sono già disponibili ma raramente vengono lette insieme. La distribuzione del carico tra persone senior e junior, la concentrazione delle escalation su pochi nominativi, la frequenza di interventi fuori orario per servizio, il tasso di incidenti ricorrenti, la presenza di postmortem con azioni preventive realmente completate, il tempo dedicato alla manutenzione preventiva rispetto al firefighting, il tasso di ferie residue non utilizzate e la rotazione volontaria nei team di piattaforma sono segnali molto più parlanti di una survey annuale isolata.

Anche le metriche DORA possono essere lette in questa chiave. Un lead time elevato combinato con forte pressione sul rilascio aumenta la probabilità di cambiamenti fatti in condizioni non ottimali. Un change failure rate alto si traduce spesso in più interventi fuori orario e più carico emotivo. Un tempo di ripristino lungo, a parità di volume incidentale, segnala complessità diagnostica e possibile insufficienza di strumenti, documentazione o ownership. Misurare soltanto l’uptime senza osservare questi elementi produce una visione incompleta. Un servizio può sembrare affidabile perché i professionisti compensano in modo straordinario le debolezze del sistema. Ma questa non è affidabilità scalabile. È consumo di risorse umane ad alta intensità.

Leve architetturali e organizzative per ridurre il danno

Affrontare la reperibilità in modo sostenibile non significa eliminare l’urgenza dai sistemi critici. Significa progettare l’organizzazione in modo che l’urgenza sia l’eccezione e non il tessuto ordinario del lavoro. La prima leva è architetturale. Sistemi osservabili, compartimentati e dotati di meccanismi di degrado controllato riducono il numero di incidenti realmente notturni. Un servizio che fallisce in modo rumoroso ma chiaro è meno costoso di un servizio che degrada in silenzio per ore. Allo stesso modo, circuit breaker, code ben gestite, fallback dichiarati, feature flag, release progressive e rollback affidabili hanno un impatto diretto non solo sulla resilienza tecnica, ma sulla qualità della vita di chi supporta il sistema.

La seconda leva è la qualità del segnale. Un alert deve avere soglia, contesto e azionabilità. Se ogni deviazione statistica si trasforma in una chiamata, il team perde fiducia nel sistema di monitoraggio. Le organizzazioni più mature lavorano per ridurre il rumore, distinguere severità e correlare eventi in modo da svegliare le persone solo quando esiste una ragione operativa concreta. Questo approccio richiede investimento, ma produce uno dei ritorni più sottovalutati in assoluto: preserva attenzione e credibilità.

La terza leva è la redistribuzione dell’ownership. Se un team è chiamato a rispondere, deve disporre di documentazione aggiornata, accessi adeguati, strumenti di diagnosi e margine di intervento proporzionato alla responsabilità. In assenza di questa coerenza, la reperibilità diventa una forma di esposizione passiva. Nei contesti multi-team o multi-vendor è utile formalizzare bene i confini operativi e gli SLA interni, non come esercizio contrattuale, ma come riduzione della frizione nelle escalation.

La quarta leva è il recupero. Molte aziende parlano di benessere ma non implementano meccanismi reali di decompressione dopo gli incidenti gravi. Se una persona trascorre parte della notte in gestione di crisi e il giorno dopo viene comunque assorbita da riunioni, review e consegne, l’organizzazione sta trasferendo tutto il costo sull’individuo. Il recupero post-incidente non è un favore. È una misura di sicurezza operativa. Persone esauste prendono decisioni peggiori e sono più esposte a errore.

Il ruolo della leadership tecnica

Per i tech leader il punto centrale è smettere di considerare il burnout un tema da gestire solo in area HR. Nelle organizzazioni infrastrutturali il burnout è profondamente connesso a come si definiscono priorità, investimenti e criteri di qualità. Se la roadmap assorbe sistematicamente tutto il tempo disponibile, la manutenzione preventiva verrà rimandata. Se il debito operativo non trova spazio nelle pianificazioni, gli incidenti ricorrenti continueranno a erodere energia. Se la leadership misura soltanto velocità e disponibilità esterna, senza misurare il carico interno necessario a sostenerle, tenderà a ottimizzare la superficie del servizio a scapito della sostenibilità.

La leadership tecnica efficace introduce una disciplina diversa. Chiede quanti alert sono realmente utili. Verifica se l’on-call è distribuito in modo equo. Pretende postmortem orientati all’apprendimento e non alla colpa. Difende il tempo per l’automazione e la stabilizzazione. Legge l’uptime insieme al tasso di interruzione del sonno, alla concentrazione del carico e all’attrito tra team. Soprattutto, evita di romanticizzare il sacrificio. Nelle organizzazioni sane, la persona che non viene svegliata inutilmente è un risultato operativo, non un lusso.

Questo cambio di sguardo è importante anche nelle relazioni con clienti e partner. Nel mercato della consulenza informatica la pressione del servizio continuo è forte e spesso legittima. Ma una governance matura sa distinguere tra esigenza di supporto e modello di sostenibilità del supporto. Contratti, SLA, finestre di intervento, processi di escalazione e responsabilità condivise possono essere costruiti in modo da tutelare il servizio senza normalizzare l’iperdisponibilità permanente del personale tecnico. Per un partner IT, questo non è solo un tema di welfare. È anche una leva di qualità del delivery e di reputazione professionale.

Le infrastrutture always-on hanno trasformato la continuità operativa in un requisito di base. Questa trasformazione ha generato enormi benefici in termini di accessibilità, velocità e valore di business. Ha però reso più visibile una tensione che il settore tecnologico ha a lungo sottovalutato: i sistemi possono essere progettati per restare sempre disponibili, le persone no. Quando la reperibilità si appoggia su processi fragili, ownership ambigue, rumore operativo e cultura dell’eroismo, il costo umano cresce fino a diventare un problema tecnico, economico e organizzativo.

Parlare di burnout in questo contesto non significa introdurre un tema laterale o “soft”. Significa discutere di affidabilità nel senso più completo del termine. Un’organizzazione affidabile non è solo quella che ripristina in fretta, ma quella che non consuma sistematicamente la lucidità dei propri team per mantenere la promessa di continuità. Le aziende che leggono insieme uptime, qualità del segnale, carico on-call, recupero e retention dispongono di una base migliore per decidere dove intervenire. Possono investire in automazione, osservabilità, architetture resilienti e governance operativa con una finalità più ampia: non solo ridurre gli incidenti, ma rendere sostenibile il lavoro che tiene in piedi l’infrastruttura.

In un mercato in cui la disponibilità è data per scontata, la vera differenza competitiva potrebbe non stare soltanto nel costruire sistemi che non dormono mai, ma nel farlo senza chiedere alle persone di vivere come se non ne avessero bisogno.

Fonti citate

• Atlassian. (2024). State of Developer Experience 2024. Atlassian. atlassian.com
• Forsgren, N., Humble, J., Kim, G., Brown, A., Kersten, M., & others. (2023). DORA report: The science behind high performance technology organizations. Google Cloud. cloud.google.com
• Gallup. (2024). State of the Global Workplace: 2024 report. Gallup. gallup.com
• Maslach, C., & Leiter, M. P. (2016). Understanding the burnout experience: Recent research and its implications for psychiatry. World Psychiatry, 15(2), 103–111. doi.org
• World Health Organization. (2019). Burn-out an occupational phenomenon: International Classification of Diseases. World Health Organization. who.int
• Dorrian, J., Lamond, N., Holmes, A. L., Burgess, H. J., Roach, G. D., & Fletcher, A. (2000). The ability to self-monitor performance during a week of simulated night shifts. Sleep, 23(5), 1–7. doi.org
• Sonnentag, S., & Fritz, C. (2015). Recovery from job stress: The stressor-detachment model as an integrative framework. Journal of Organizational Behavior, 36(S1), S72–S103. doi.org
• West, C. P., Dyrbye, L. N., Erwin, P. J., & Shanafelt, T. D. (2016). Interventions to prevent and reduce physician burnout: A systematic review and meta-analysis. The Lancet, 388(10057), 2272–2281.

Autore: Martina Pegoraro