Quando il server regge ma l’ospedale si ferma: la lezione per IBM i

L’1 di notte si fermano i server di Aria Lombardia. Alle 10 del mattino, scrive la Repubblica Milano il 4 dicembre 2025, gli ospedali pubblici sono ancora in tilt. A Genova, al San Martino, GenovaToday racconta l’attivazione di “un sistema di backup” per gestire le accettazioni pazienti. Bastano tre fotogrammi per capire il punto: il guasto sanitario non è un problema da CED, è un problema da corridoio.

Quando salta l’operatività invisibile, la differenza tra un disservizio corto e un blocco vero la fanno le dipendenze laterali: stampe, etichette, code, telefoni, accessi, procedure di ripiego. E per chi lavora su IBM i il nodo non cambia. La macchina può essere robusta quanto si vuole; se il servizio non è progettato per degradare bene, la robustezza resta una qualità del ferro, non del processo.

Il guasto non abita nel datacenter da solo

Nei contesti sanitari il primo punto che cede è spesso l’accettazione. Non perché sia il reparto più debole, ma perché è il primo contatto tra sistema e persone. Se l’accettazione si ferma, si fermano gli arrivi, i prelievi si accodano, la radiologia aspetta richieste che non escono, il laboratorio riceve campioni senza il solito flusso digitale, le stampe diventano improvvisamente carta preziosa. E se in mezzo ci sono telefoni interni o centralini VoIP agganciati male all’infrastruttura, la confusione accelera. Il fermo non è mai un singolo allarme sul monitor. È una fila che si allunga e un operatore che comincia a chiedere fogli e penne.

Qui casca la retorica del “server solido”. Un sistema può reggere anni senza un colpo, poi basta un guasto su storage, rete, autenticazione, spool di stampa o instradamento telefonico per scoprire che la continuità era stata data per scontata. Il Rapporto Clusit 2024 aggiunge un dettaglio poco comodo: analizza solo incidenti gravi emersi da fonti pubbliche. Tradotto: quello che finisce nei giornali è già una selezione. Il resto – rallentamenti, switch falliti, backup inutilizzabili, procedure cartacee improvvisate – spesso resta dentro le mura. Eppure è lì che si misura la tenuta di un’organizzazione.

Autopsia di un fermo: dove cede davvero la catena

Nel budget finiscono hardware, licenze e i costi di consulenza per As 400 e poco altro; i test di fermo, quelli che scoprono se accettazione, stampa e telefonia sopravvivono a uno switch, saltano per primi. È una vecchia cattiva abitudine. Si compra la replica, si mette in piedi un secondo nodo, si verifica che i dati ci siano, e ci si racconta che basti. Ma un backup non è alta disponibilità, e l’alta disponibilità non coincide con il ritorno al lavoro dell’utente. Tra le due cose c’è di mezzo il mondo reale: nomi di rete, code di stampa, profili, condivisioni, certificati, routing, dispositivi appesi a un indirizzo IP che nessuno ha mappato bene.

Il backup che nessuno prova è solo arredamento. Il caso del San Martino dice esattamente questo, senza bisogno di enfasi: se si attiva un sistema di backup per le accettazioni, vuol dire che qualcuno aveva capito che il problema non era salvare i dati a posteriori, ma tenere viva la funzione mentre il resto traballa. Sembra banale. Non lo è affatto. Sul campo si vede spesso il contrario: copie impeccabili, tempi di ripristino teorici, operatori lasciati senza uno script operativo decente.

La procedura degradada – quella che molti scrivono in fretta e poi parcheggiano in una cartella dimenticata – decide più del server secondario. Se manca, il guasto si mangia minuti nei passaggi che nessuno aveva tradotto in gesto concreto. Chi stampa cosa. Da dove. Con quali credenziali. Su quale modulo. Come si riconciliano le operazioni fatte a mano quando il sistema rientra. Chi autorizza il passaggio in modalità ridotta. Chi avvisa il laboratorio. Chi avvisa il centralino. Sono dettagli? Sì. Ed è per questo che fanno male: i fermi seri nascono quasi sempre dai dettagli lasciati senza padrone.

Su IBM i il punto non è la robustezza, è il montaggio del servizio

Su IBM i la tentazione di sentirsi al riparo è nota. In parte è persino comprensibile: stabilità, affidabilità, anni di esercizio senza drammi. Però IBM, nella sua documentazione sull’implementazione di alta disponibilità per IBM i, tratta il tema in modo molto meno romantico. E fa bene. L’alta disponibilità è un insieme di scelte su replica, ruoli, switch, verifiche, dipendenze applicative. Nelle procedure di installazione e aggiornamento, poi, IBM ricorda implicitamente un fatto che chi lavora in produzione conosce già: la disponibilità del sistema si gioca spesso durante la manutenzione ordinaria, non nel giorno del disastro da copertina.

Per le aziende che usano ancora AS/400, iSeries, IBM i per ordini, contabilità, stampe, flussi bancari o documenti fiscali, la lezione sanitaria è molto concreta. Se il nodo secondario subentra ma le code di stampa puntano ancora a un vecchio percorso, la bolla non esce. Se l’applicazione risponde ma la cartella di scambio usata da un reparto resta fuori sincronizzazione, il reparto si blocca lo stesso. Se il database è in piedi ma l’operatore non sa quale sessione aprire o quale procedura usare in degradato, il sistema per lui è giù. E se il centralino o i recapiti interni non hanno un piano alternativo, il fermo tecnico diventa fermo organizzativo. Il cliente, o il paziente, non fa differenze.

Da chi frequenta queste piattaforme arriva sempre la stessa scena: la macchina torna, il servizio no. Perché? Perché il piano di continuità si è fermato al rack, mentre l’utente comincia molto più in là.

C’è anche un punto meno spettacolare e più fastidioso: gli aggiornamenti. Una PTF, un cambio di release, una modifica di rete, un driver di stampa riscritto male, una dipendenza esterna spostata senza allineare il resto. Niente che faccia titolo, finché non cade tutto alle 8:03, cioè quando l’ufficio apre davvero. Il guasto clamoroso arriva di rado. Il fermo da montaggio incompleto, invece, è ordinaria amministrazione.

Checklist minima per non scoprire il fermo alle 8:03

La delibera ASL Roma 3 n. 630/2024 richiama “riservatezza, integrità e disponibilità” e lega il tema all’obiettivo di “migliorare la qualità e la sicurezza dei servizi”. È una formula amministrativa, certo. Ma il messaggio è netto: la disponibilità non è un lusso tecnico, è servizio erogato oppure no. Su questo, un ambiente IBM i non chiede poesia. Chiede disciplina.

• Mappare il processo end-to-end, non il solo server: accettazione, stampa, telefonia, code, autorizzazioni, periferiche, scambi file.
• Distinguere backup e alta disponibilità: il primo protegge il dato, la seconda deve tenere in piedi la funzione entro tempi dichiarati.
• Definire RTO e RPO per servizio, non per infrastruttura generica. Un’etichetta di laboratorio ha priorità diversa da un report interno.
• Provare lo switch con utenti veri, su stampanti vere e flussi veri. I test da sala riunioni servono poco.
• Scrivere la procedura degradata in forma operativa: chi decide, chi comunica, chi stampa, chi registra a mano, chi riconcilia.
• Includere installazioni e aggiornamenti nel piano di continuità: finestra, rollback, verifiche post-change, responsabilità chiare.
• Verificare i punti laterali: spool, share, certificati, linee, numerazioni, script, integrazioni esterne. È lì che si annida il fermo che “non dovrebbe esserci”.

Alla fine il giudice non è il datasheet del server. È la prima accettazione che non passa, il primo referto che non stampa, la prima chiamata interna che non parte. La robustezza di IBM i resta un vantaggio, certo. Ma senza fallback pensati bene, senza procedure degradate e senza prove sporche di realtà, resta un vantaggio dimezzato. E nei contesti critici – sanità in testa, aziende subito dietro – il conto arriva sempre in orario.