Se il server AI in sede si ferma: continuità e ridondanza senza sprechi

Se il server di intelligenza artificiale (AI) installato nel tuo CED — il centro elaborazione dati dell'azienda — si ferma, la risposta giusta non è «raddoppia tutto»: è classificare prima le funzioni. Alcune possono attendere qualche ora, altre devono continuare e altre ancora non dovrebbero mai dipendere dal server AI. Per ciascuna scegli tra ripristino rapido e ridondanza, poi prova la ripartenza finché non serve davvero. Questa guida ti aiuta a fare le tre cose in ordine.

Il server AI come nuovo punto critico

Quando l'intelligenza artificiale entra nei processi quotidiani — monitoraggio della rete, proposte di intervento, assistenza agli operatori — il server che la ospita diventa un punto di guasto singolo: un solo elemento il cui fermo blocca tutto ciò che dipende da lui. Vale per l'installazione locale nel CED come per la modalità via API (application programming interface, il collegamento a servizi AI remoti), con una differenza importante: nel primo caso il guasto è in casa tua e dipende dal tuo hardware; nel secondo la continuità dipende anche dalla connessione e dal servizio remoto. Anche un sistema che può operare senza Internet resta fermo se la macchina che lo ospita si guasta.

C'è un punto che spesso sfugge: gli agenti che osservano la tua infrastruttura risiedono sullo stesso server. Se il server si ferma, si fermano anche monitoraggio, segnalazioni e proposte. Il fermo va quindi rilevato da qualcosa di indipendente — il monitoraggio hardware della sala server, il gruppo di continuità, gli strumenti IT che già possiedi — e questo va previsto nel piano, non scoperto durante il guasto.

Il primo passo è un elenco onesto delle funzioni che usano il server AI, divise in tre gruppi:

Il terzo gruppo merita attenzione: nessun processo vitale dovrebbe bloccarsi perché il server AI è fermo. Se scopri dipendenze di questo tipo — per esempio una procedura che ormai esiste solo dentro l'assistente — correggile prima di ragionare su ridondanze. Il Cybersecurity Framework 2.0 del NIST colloca il recupero (Recover) tra le funzioni fondamentali della gestione del rischio: è un buon lessico per organizzare questa classificazione.

Ripristino o ridondanza: criteri di scelta

Classificate le funzioni, per ciascuna decidi come ripartire. Due misure guidano la scelta: il tempo di ripristino accettabile (in sigla RTO, recovery time objective: quante ore o minuti può durare il fermo) e la perdita di dati accettabile (RPO, recovery point objective: quanto lavoro recente puoi permetterti di rifare). Di queste due misure, e di come si applicano alle copie di sicurezza, parliamo nella guida su RPO e RTO spiegati in pratica; qui ci interessa la decisione sull'infrastruttura.

Quando basta un ripristino rapido. Se le funzioni critiche tollerano un fermo di ore, spesso è sufficiente una procedura di ripartenza documentata e collaudata: componenti di ricambio o un contratto di assistenza con tempi chiari, configurazione del server conservata in modo recuperabile, ordine di riavvio dei servizi scritto prima del guasto. Il ripristino costa meno, ma il tempo reale dipende dalla disponibilità di persone e pezzi: un guasto il sabato mattina con il tecnico reperibile il lunedì trasforma un'ora dichiarata in due giorni effettivi.

Quando serve la ridondanza. Se il fermo costa più di una seconda macchina — processi che non si fermano mai, sedi senza personale tecnico, funzioni che alimentano decisioni in tempo reale — valuta un secondo server. Esistono forme diverse: una macchina di riserva spenta, aggiornata solo a intervalli e da avviare al bisogno (più economica, ripartenza più lenta), una macchina pronta che riceve la configurazione e può subentrare in tempi brevi, fino a due sistemi attivi insieme. Ogni gradino aumenta costi e lavoro: entrambe le macchine vanno aggiornate, sorvegliate e incluse nelle prove.

Tre avvertenze prima di spendere:

• La ridondanza del solo server non basta. Se i due server condividono alimentazione, rete, un unico interruttore o lo stesso locale, il guasto comune li ferma entrambi. Elenca le dipendenze condivise prima di dichiarare il sistema ridondante.
• Ridondare ciò che può attendere è uno spreco. Ogni componente duplicato richiede manutenzione e prove per tutta la sua vita: spendi dove il fermo ha un costo reale e dimostrato.
• Anche il ripristino va progettato. «Reinstalliamo tutto» non è un piano: servono supporti di installazione, configurazioni salvate e qualcuno che sappia eseguire la procedura. Le copie dei dati restano un capitolo a parte, trattato nel cluster dedicato a backup e prove di ripristino.

Esempio illustrativo: il sabato del magazzino

Esempio illustrativo. Lo scenario seguente è inventato e serve a mostrare il ragionamento; non racconta un evento avvenuto presso un cliente.

Un'azienda di logistica alimentare usa un server AI in sede per osservare rete e sistemi del magazzino e preparare proposte di intervento ai responsabili. La classificazione ha stabilito che i giri di consegna e la gestione degli ordini non dipendono dal server AI, mentre il monitoraggio con proposte appartiene al gruppo «degrado accettabile»: in sua assenza si torna ai controlli manuali previsti prima della sua adozione.

Un sabato mattina l'alimentatore del server si guasta. Gli agenti tacciono, ma il fermo viene rilevato dal monitoraggio della sala server, indipendente dal sistema AI. Il magazzino lavora: ordini e consegne proseguono, perché non erano stati legati al server. Il responsabile reperibile segue la procedura di ripartenza già provata: ricambio disponibile in sede, configurazione recuperata dal salvataggio documentato, servizi riavviati nell'ordine scritto. Al rientro del sistema, il monitoraggio riprende e l'evento viene registrato con i tempi effettivi, confrontati con l'obiettivo dichiarato.

Due insegnamenti: l'azienda aveva scelto il ripristino rapido invece della ridondanza, e la scelta ha retto perché la classificazione era onesta; e la prova precedente aveva già fatto emergere — in un momento senza urgenza — che il ricambio non era dove la procedura diceva. Un guasto reale non è il momento giusto per scoprirlo.

Prove di ripartenza e registrazione degli esiti

Un piano di ripartenza non provato è un'ipotesi. La prova non deve necessariamente spegnere il server in produzione: si può verificare la procedura su un ambiente di test o su una macchina di riserva, in un momento concordato, con un perimetro che non metta a rischio il lavoro. Gli elementi essenziali:

• Obiettivo scritto. Tempo massimo atteso, funzioni da riattivare e loro ordine, criterio che decide se la prova è superata.
• Ruoli chiari. Chi esegue, chi verifica il risultato, chi avvisa le persone interessate. La reperibilità fa parte della prova: se il guasto tipo avviene nel fine settimana, la prova a metà mattina feriale racconta solo metà della storia.
• Procedura sotto osservazione. Si segue la procedura così com'è scritta, non la memoria del tecnico più esperto: ogni passaggio mancante, ambiguo o contraddittorio è un risultato della prova.
• Registrazione dell'esito. Tempi misurati, intoppi, correzioni da fare, responsabile e termine di ogni correzione. La revisione della procedura spetta al suo proprietario, attraverso il processo documentale concordato.

La frequenza delle prove va concordata rispetto al rischio, ai cambiamenti dell'ambiente e agli eventuali obblighi applicabili: non esiste una cadenza valida per tutti. Ogni modifica rilevante — nuovo hardware, aggiornamento importante, cambio di fornitore di assistenza — è comunque un buon motivo per riprovare, perché il piano cambia insieme al sistema.

Il contributo di OverZeus

OverZeus prevede l'installazione su server nel CED del cliente oppure l'uso di API su Azure o AWS in una regione europea concordata. Sul tema della continuità intervengono in particolare:

• Argus osserva servizi, rete e dispositivi collegati ed evidenzia anomalie e scostamenti dalla situazione attesa: durante l'operatività normale è lui a rendere visibili i segnali che precedono molti guasti, come un disco che si riempie.
• Penelope sorveglia backup, conservazione e preparazione al ripristino tramite gli strumenti collegati, aiutando a trasformare una copia in un percorso di recupero verificabile; OverZeus non include un motore di backup proprio, lavora con la piattaforma prevista dal progetto.
• Mnemosyne conserva fonti, proposte, autorizzazioni ed esiti: le prove di ripartenza e i fermi reali restano ricostruibili, con tempi e decisioni.
• Nestor recupera manuali, runbook (le procedure operative scritte) e casi precedenti rispettando i permessi: durante una prova può confrontare versioni diverse della procedura di ripartenza ed evidenziarne le contraddizioni; la revisione spetta al proprietario del documento.

Due onestà doverose. La prima: gli agenti risiedono sul server, quindi un fermo del server ferma anche loro — comprese le notifiche di Hermes, che peraltro richiedono il proprio canale di collegamento (VPN, cioè rete privata virtuale, su connessione 5G cifrata) verso l'app dei responsabili. Il rilevamento del fermo va previsto con strumenti indipendenti, come nell'esempio. La seconda: il progetto OverZeus non dichiara configurazioni ad alta disponibilità o architetture ridondate. Se la tua classificazione richiede ridondanza, è una scelta da concordare in fase di progetto — hardware, dipendenze condivise, procedure — non una funzione da dare per scontata. Anche ogni intervento di ripristino che tocchi sistemi di produzione segue la regola generale: piano visibile, conseguenze spiegate e approvazione prevista; il silenzio non autorizza.

In sintesi

La continuità del server AI in sede si costruisce con tre passi: classificare le funzioni (e slegare da esso quelle vitali), scegliere per ciascuna tra ripristino rapido e ridondanza secondo costo del fermo e dipendenze condivise, provare la ripartenza registrando gli esiti. La ridondanza è una risposta a un costo dimostrato, non uno stato d'animo: dove può attendere, un buon ripristino documentato e provato vale più di una seconda macchina trascurata.

Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.

Tutti gli articoli OverZeus