Reperibilità gestita internamente, a rotazione tra i tecnici che hanno messo le mani sui sistemi del cliente. SLA 4h o 24h scritti in contratto e misurati mensilmente, con report. Stack di monitoring continuo (Prometheus, Grafana, alerting a persone reali), runbook dedicato per ogni cliente. Zero outsourcing, zero call center, zero chatbot che ti fanno premere 1 per continuare.
01Chi risponde davvero al telefono
Quando chiami il numero di reperibilità alle 03:17 di domenica, dall'altra parte c'è uno di noi. Non "operatore 47", non un triager generico che apre un ticket e ti richiama in orario d'ufficio. È un tecnico con nome e cognome, che sul tuo cluster ha lavorato — perché l'ha installato, perché l'ha aggiornato il mese scorso, perché è uno dei 2-3 che hanno la topologia in testa senza bisogno di riaprire documenti.
La rotazione è interna, settimanale, con primo e secondo livello nominati. Il primo livello prende la chiamata entro l'ack time contrattuale, valuta e — se serve — scala. Il secondo livello è di backup per i casi in cui il primo è già su un intervento critico, o per competenze specifiche (rete, storage, database). Il cliente vede in anticipo chi è di turno quella settimana, con contatto diretto.
Questo modello scala fin dove scaliamo noi. Non pretendiamo di gestire cinquecento clienti simultaneamente in reperibilità: il portafoglio è volutamente limitato proprio per preservare questa qualità. Se il numero di clienti cresce, cresce il team — non l'outsourcing.
02Gli SLA operativi, in concreto
"24/7" da solo non significa niente. I numeri che contano sono due, e li scriviamo nel contratto distinti:
- Ack time (tempo di presa in carico): da quando l'allarme/chiamata arriva a quando un tecnico dichiara di esserci. Tipicamente 15 minuti per severity critiche 24/7, 30 minuti per severity medie.
- Resolution time (tempo di ripristino del servizio): da quando prendiamo in carico a quando il servizio torna operativo. Tipicamente 4 ore per severity critica, 24 ore per severity media/bassa. Sul critical il target è spesso molto più stretto nella pratica, ma quello scritto è il commitment, non l'aspirazione.
Distinguere i due tempi è fondamentale perché troppi fornitori vendono "SLA 4 ore" senza dire se includono il tempo di risposta o solo il lavoro effettivo. Noi li separiamo in contratto, e li misuriamo entrambi.
Cosa è escluso dallo SLA lo diciamo chiaramente: disastri infrastrutturali fuori dal nostro perimetro (fibra tranciata dall'escavatore del Comune), manutenzioni programmate concordate, componenti legacy in carbon copy dove il cliente non autorizza interventi di modifica. Se non lo possiamo toccare, non possiamo garantire tempi di ripristino — lo scriviamo prima, non dopo.
03Lo stack di monitoring
La reperibilità senza monitoring decente è teatro. Il cliente chiama quando si accorge del problema — cioè quando è già tardi. Il punto è accorgersene prima noi.
Lo stack standard: Prometheus per la raccolta metriche (host, servizi, applicativi), Grafana per le dashboard, Alertmanager per il routing degli allarmi. Le severity critiche (servizio down, storage pieno, cluster degraded) vanno a persone reali via SMS e chiamata automatica, non solo email o Slack. Le severity warning restano su Slack/Teams/email.
Retention metriche: 13 mesi minimo. Non per estetica — serve quando sei in post-mortem tre settimane dopo un incidente e devi capire se il pattern anomalo era partito da prima. Retention short-retention ti lascia con le mani vuote nel momento peggiore.
Ogni allarme che squilla ha una policy di silencing e di runbook associata. Un allarme che suona sette volte senza conseguenza è un allarme disattivato — quindi o lo si calibra, o si toglie. Il tuning continuo del monitoring è parte del servizio, non un extra.
04Runbook e knowledge base per cliente
Ogni cluster in gestione ha il suo runbook versionato su git interno. Non è un wiki generico, è il manuale operativo del singolo cliente: topologia di rete aggiornata, inventario VM/container, credenziali in vault (referenziate, non scritte), procedure tipo per gli incidenti più probabili, contatti tecnici e di escalation lato cliente, finestre di manutenzione concordate.
Chi sale in reperibilità apre il runbook del cliente e ha davanti quello che serve nei primi dieci minuti — dove sono i nodi, come si accede, chi chiamare se serve decidere di fermare un servizio in produzione. Niente "lasciami guardare la documentazione", niente "te lo dico domani mattina".
Il runbook si aggiorna dopo ogni intervento rilevante. Se un incidente ha rivelato una procedura mancante o un contatto sbagliato, la correzione è parte della chiusura dell'incident, non un TODO che finisce dimenticato.
05Reperibilità vs intervento on-site
La stragrande maggioranza degli interventi critici si risolve via SSH/VPN, da casa o dalla sede nostra. Per gli ambienti virtualizzati e cloud-like è la norma: riavviare un nodo, rilanciare un servizio, spostare una VM, ripristinare un backup — non serve salire in macchina.
Quando invece serve mettere le mani fisicamente sul ferro (guasto hardware, componente da sostituire, problema di rete al rack), i tempi di arrivo reali sono: Torino e hinterland 30-60 minuti in ore d'ufficio, 60-90 fuori orario; Milano 90-120 minuti; resto Italia tipicamente gestito con partner locale pre-qualificato sul singolo cliente — cioè non "cerchiamo adesso chi viene", ma "è già definito, ha già visto il rack, ha le credenziali per l'accesso fisico".
Per clienti con infrastruttura on-premise fuori dalle zone coperte direttamente, la parte on-site è dichiarata in anticipo come non garantita sotto le 4 ore — perché altrimenti mentiremmo. In compenso offriamo disaster recovery geografico: se il sito primario è irraggiungibile, il secondario presso un nostro data center parte comunque.
06Report mensile trasparente
Ogni mese il cliente riceve un report che contiene: incidenti aperti e chiusi con tempistica, ack time medio e peggiore, resolution time medio e peggiore, SLA rispettati e mancati. Se abbiamo mancato uno SLA, è scritto. Con causa, analisi, azione correttiva.
Non nascondiamo i miss per due ragioni. Prima: il cliente ha comunque accesso ai nostri sistemi di monitoring e ai log — se mentissimo sul report, se ne accorgerebbe in un pomeriggio. Seconda, più importante: un fornitore che nasconde i problemi è un fornitore che non li risolve. Scrivere uno SLA miss in chiaro, con causa e contromisura, è l'unico modo per migliorare davvero.
Il report include anche tendenze: incidenti ricorrenti, componenti che tornano in allarme, raccomandazioni di intervento strutturale. Serve al cliente per pianificare il budget dell'anno successivo, non come materiale commerciale.
07Quando non vi serve un NOC così
Onestà: non tutti hanno bisogno di una reperibilità 24/7 contrattualizzata. Scenari in cui vi diciamo direttamente che non ve la vendiamo:
- Avete un sistemista interno competente presente in orari estesi e un'infrastruttura piccola. Probabilmente vi basta un'assistenza on-demand a ticket, con SLA su orario d'ufficio e reperibilità d'emergenza a chiamata. Costa meno e copre il rischio reale.
- I vostri sistemi sono non-critici nei fine settimana e di notte — gestionale usato solo in orario d'ufficio, nessun e-commerce, nessun servizio esposto al pubblico con traffico 24/7. Un contratto 8×5 con escalation in caso di incidente maggiore è sufficiente, e più onesto.
- State facendo shopping di SLA sulla carta per ragioni di compliance, senza intenzione reale di usarli. Qui il problema è un altro e non siamo la risposta giusta — qualcuno che vi vende il pezzo di carta esiste, ma non siamo noi.
La regola che seguiamo: se la reperibilità 24/7 non si traduce in incidenti realmente gestiti o in rischi realmente mitigati, è un costo che facciamo fatica a giustificare — e ve lo diciamo.