Cosa ho imparato gestendo sistemi HA durante le festività (senza panico)

Ogni anno, puntuale come il cenone di Natale o il brindisi di Capodanno, arriva anche lui:
l’incidente in produzione durante le ferie.

Chi lavora con sistemi ad alta disponibilità lo sa bene: per i nostri servizi non esistono orari d’ufficio, non esistono “chiusure per ferie”. E per anni ho affrontato questo tema da sysadmin, poi da lead tecnico e infine da CTO.

La conclusione a cui sono arrivato è semplice, ma non banale:

La calma, più della tecnologia, è la vera chiave dell’alta disponibilità.

La tecnologia è complessa, ma relativamente prevedibile. Le persone, sotto stress, molto meno. E la differenza tra un incidente gestito bene e una notte di panico totale sta quasi sempre nel metodo, nella comunicazione e nella capacità di non farsi travolgere dall’urgenza.

Di seguito condivido cosa ho imparato, soprattutto in quel periodo dell’anno in cui metà del team è in ferie, i clienti sono ipersensibili e gli SLA non vanno in vacanza.

Scenario: ferie, incidenti e SLA

Le festività sono un perfetto stress test organizzativo.

Hai:

• meno persone reperibili,
• più traffico su alcuni servizi,
• finestre di manutenzione ridotte,
• clienti che, se qualcosa va giù proprio “il 24 sera”, lo vivono come un affronto personale.

In teoria, i sistemi HA dovrebbero assorbire guasti e picchi: cluster ridondati, load balancer, storage replicato, backup testati. In pratica, sappiamo che gli incidenti non si presentano mai in forma “pulita”:

• un nodo che cade non da solo, ma proprio mentre stai deployando;
• un alert che arriva, ma chi è di turno non ne capisce la natura;
• un failover che funziona, ma impatta le performance proprio nel momento più sensibile.

Quello che ho capito è che gli SLA non si difendono solo con l’architettura, ma con il modo in cui l’azienda si organizza intorno ai suoi sistemi:

• chi decide cosa;
• chi parla con i clienti;
• chi ha l’ultima parola se serve “rompere il change freeze”.

Durante le festività, questo diventa ancora più evidente: ogni ambiguità organizzativa si trasforma in minuti di downtime.

Processi di escalation e comunicazione

La prima volta che ti chiama un cliente grosso alle 17:00 del 31 dicembre, capisci immediatamente quanto sia importante non improvvisare.

Escalation: meno fantasia, più script

Un buon processo di escalation è quasi noioso, e va bene così.
Quando succede qualcosa, chi è di reperibilità deve avere:

• una lista chiara di step: cosa verificare, in che ordine;
• contatti di secondo livello (database, network, applicativo, cloud provider);
• soglie chiare per “alzare il livello”: quando coinvolgere il CTO, quando coinvolgere il commerciale, quando dichiarare l’incidente ufficialmente.

La regola che applico è:

“Piuttosto un’escalation in più che una in meno.”

È molto meglio disturbare qualcuno e poi ridimensionare, che tentare di “sistemare al volo” qualcosa che sta già degenerando.

Comunicazione: chi tace, aumenta il downtime percepito

La verità è che, durante un incidente, il silenzio pesa più del disservizio.

Ci sono due comunicazioni fondamentali:

1. Interna

   • Un canale unico (tipo #incident-<data>).
   • Un incident commander, anche solo “di fatto”, che coordina e decide.
   • Log degli eventi in tempo reale: chi fa cosa, cosa è stato provato, cosa è stato escluso.

2. Esterna (clienti / stakeholder)

   • Un messaggio iniziale breve e onesto: stiamo investigando.
   • Un aggiornamento regolare (meglio dire “ogni 15 minuti” che “ti aggiorniamo appena possibile”).
   • Una comunicazione di chiusura con:
     • cosa è successo,
     • quanto è durato,
     • cosa faremo per evitare che riaccada.

Mi sono accorto che un incidente gestito bene, raccontato bene, aumenta la fiducia.
Un incidente gestito in modo confuso, anche se tecnicamente risolto in fretta, lascia una scia di dubbi.

Prevenzione e monitoraggio

La parte visibile degli incidenti sono le notti in bianco.
La parte invisibile, ma davvero decisiva, è il lavoro fatto prima.

Prevenzione: il vero “hero work” è noioso

Le attività che salvano davvero le festività sono raramente glam:

• test di failover fatti davvero, non solo “sulla carta”;
• verifica periodica di:
  • runbook aggiornati,
  • numeri di telefono corretti,
  • credenziali d’accesso di emergenza funzionanti;
• dry-run delle procedure di ripristino in ambienti di test o staging.

Investire tempo in queste cose prima delle festività, rende il ROI enorme in termini di incidenti “non nati”.

Monitoraggio: allarme sì, allarmismo no

Avere un ambiente HA significa anche accettare che qualcosa sia sempre rotto da qualche parte, in modo controllato. Il monitoraggio deve riflettere questa filosofia.

Quello che cerco in un buon setup di monitoring è:

• alert pochi ma significativi, legati a:
  • impatto utente,
  • impatto sugli SLA,
  • rischio concreto per i dati;
• osservabilità vera, non solo metriche:
  • log centralizzati,
  • tracing dove serve,
  • dashboard chiare, non muri di grafici incomprensibili;
• silenzi intelligenti durante i lavori programmati, ma senza oscurare segnali importanti.

Un indicatore che ho imparato a valutare è questo:
se chi è di reperibilità ignora sistematicamente alcuni tipi di alert, allora il problema non è la persona, è il sistema di monitoring.

Il valore della ridondanza umana

Parliamo sempre di ridondanza di server, region, circuiti… ma la ridondanza più critica è quella delle persone.

Evitare il “bus factor 1” mascherato da “esperto”

Se c’è una persona “che sa tutto” di un sistema critico, è un rischio.
Durante le festività, quel rischio diventa esposizione reale:

• quella persona può essere in ferie,
• può ammalarsi,
• può semplicemente non essere raggiungibile.

Quello che ho imparato a fare è:

• distribuire la conoscenza con:
  • documentazione vivibile (non romanzi in wiki dimenticate),
  • sessioni di pair su procedure critiche,
  • rotazione vera delle reperibilità su stack diversi;
• accettare che:
  • qualcuno meno esperto ci metterà 10 minuti in più,
  • ma l’organizzazione nel complesso sarà molto più resiliente.

Proteggere chi “tiene su la baracca”

C’è poi il tema umano: chi fa reperibilità durante le festività si porta un carico extra di stress (e di rinunce).

Ho visto netta differenza quando:

• la reperibilità è riconosciuta davvero (economicamente e a livello di cultura aziendale);
• c’è un backup anche solo “light” (qualcuno che puoi chiamare, se serve, senza sentirti in colpa);
• dopo un incidente pesante, c’è un minimo di decompressione:
  • un giorno più leggero,
  • niente riunioni inutili,
  • o almeno un riconoscimento esplicito del lavoro fatto.

Alta disponibilità non significa spremere sempre le stesse persone “perché loro sanno come fare”.
Significa costruire un team che può reggere nel tempo.

Takeaway pratici per CTO e sysadmin

Se dovessi riassumere in poche azioni concrete ciò che ha fatto la differenza nella gestione di sistemi HA durante le festività, direi:

Per CTO / responsabili tecnici

1. Definisci un processo di incident management semplice e condiviso

   • Chi decide cosa.
   • Come si apre, gestisce e chiude un incidente.
   • Come e quando si comunica con i clienti.

2. Rendti il tuo team capace di pianificare le festività come un progetto, non come un “periodo a caso”

   • chi è di reperibilità,
   • chi è backup,
   • quali cambi sono proibiti (change freeze) e con quali eccezioni.

3. Investi in ridondanza umana

   • documentazione minima ma utile,
   • knowledge sharing su stack critici,
   • rotazione delle responsabilità.

4. Dai dignità alla reperibilità

   • riconoscimento economico,
   • riconoscimento culturale (“sei parte centrale della nostra affidabilità”),
   • supporto post-incident.

Per sysadmin / SRE / dev on-call

1. Preparati prima

   • verifica accessi,
   • prova VPN, bastion, strumenti,
   • rileggi i runbook delle parti più critiche.

2. Segui il processo, non l’istinto del “fix veloce”

   • prima capisci,
   • poi agisci,
   • annota cosa fai: ti servirà per il post-mortem (e per non ripetere tentativi inutili).

3. Comunica, anche se non hai ancora la soluzione

   • “stiamo investigando su X, prossimo update alle HH:MM”
   • è sempre meglio di un silenzio di 40 minuti.

4. Tieni la calma come asset tecnico

   • se ti accorgi che stai cliccando “a caso”, fermati,
   • respira, rileggi gli ultimi log, fatti una domanda semplice:
     “Cosa so per certo, e cosa sto assumendo?”

In chiusura

Gestire sistemi HA durante le festività non è una prova di eroismo tecnico, è un test di maturità organizzativa.

Le tecnologie cambiano, gli stack evolvono, i cloud provider si moltiplicano.
Quello che resta costante è che:

• la calma batte il panico,
• il metodo batte l’improvvisazione,
• le persone battono sempre le macchine.

Se riusciamo a tenere questi tre punti al centro, non solo sopravviviamo alle festività… ma costruiamo un’infrastruttura – tecnica e umana – che vale molto di più di qualsiasi uptime “a colpi di fortuna”.