Best practice risposta agli incidenti per dev solisti
Riassunto
I dev solisti non hanno bisogno di 40 pagine di playbook enterprise. Hanno bisogno di tre cose: sapere quando qualcosa si è rotto, sapere cosa farne, comunicare lo stato agli utenti. Questa guida copre alerting senza false positives, runbook per leggere mezzo-addormentato, e una status page self-hosted che costa zero.
Best practice risposta agli incidenti
Le best practice risposta agli incidenti le scrivono per i team enterprise, non per i dev solisti. Lanci un side project, trovi gli utenti, e una mattina qualcuno su Twitter dice che è offline da tre ore. Tu non lo sapevi. Nessun alert. Nessun runbook. Nessuna status page.
Questo è il failure mode del 90% dei prodotti costruiti da una sola persona. Non è una breach, non è un evento infrastrutturale catastrofico. È semplicemente: nessuno te l'ha detto che era rotto, non avevi un piano, e i tuoi utenti l'hanno scoperto prima di te.
Non ti serve un playbook di 40 pagine o una stack enterprise. Ti servono tre cose: sapere quando qualcosa si è rotto, sapere cosa farne, e comunicare lo stato a chi ne dipende. Questa guida copre ognuno di questi punti dal punto di vista di chi costruisce, incluso cosa buildarsi da solo e cosa collegare da tool esistenti.
Cosa si rompe per primo quando sei solista e on-call
La prima volta che gestisci un incident da solo, passerai 12 minuti a capire dove le cose sono prima di spendere 4 minuti effettivamente a ripararle.
Questo è il vero costo. Non il downtime. L'overhead coordinamento di un team di una persona che non ha scritto niente. Dove sono le variabili d'ambiente? Quale servizio sta fallendo davvero? Colpisce tutti gli utenti o solo uno? Passi la finestra d'oro di un incident a cercare risposte che avresti dovuto pre-rispondere.
La fix non è tool complessi. È avere già risposto a quelle domande prima delle 3 di notte.
C'è un test utile: immagina che il tuo production API cade adesso. Hai 10 minuti. Riesci a trovare i log rilevanti, identificare il componente che fallisce, e fare rollback o hotfix senza aprire più di due tab che non avessi già aperto? Se la risposta è no, quello è esattamente quello che risolve la response agli incidenti.
Le tre cose che ogni setup indie di incident response davvero ti serve
Prima di buildarti qualcosa, dai un nome a quello che il sistema deve fare:
Detect il problema prima che un utente te lo scriva in DM
Ti dice cosa fare quando sei semi-addormentato e hai solo il contesto dell'alert
Dici ai tuoi utenti cosa sta succedendo senza peggiorare le cose
Ogni tool incident response, da PagerDuty al tuo cron job, mappa su uno di questi tre lavori. Buildati la versione più semplice che fa tutti e tre, poi stop.
La tentazione è di buildarti verso la versione enterprise: on-call schedules, escalation policies, severity levels P0 through P5, postmortem templates. Quello è appropriato a 20 engineers e 500K utenti. Con un dev e 500 utenti, quelle astrazioni ti bruciano i weekend e rimangono non usate. La versione minimal è fattibile questo weekend. Shippa quella prima.
Buildarti il tuo alert layer: il problema false positive viene per primo
Ogni dev che ha buildato il suo alerting ha la stessa storia: la prima regola che ha scritto era sbagliata, e ha spento il pager dopo due settimane di rumore.
Inizia con un check che conta. Un health check endpoint che fallisce basta.
# Simple health check endpoint (Express/Node)
app.get('/health', (req, res) => {
res.json({ status: 'ok', timestamp: Date.now() });
});Poi collegaci un cron job che lo pinga ogni 60 secondi. Se fallisce tre volte di fila, ricevi un SMS. Questo è il tuo primo alert layer. Cattura l'80% degli incidents che toccano gli utenti.
Il false positive rate su questo setup è quasi zero. Ricevi un alert quando il servizio è davvero down, non quando uno spike CPU ha triggerato una threshold che non era mai stata calibrata. Questo è il più difficile da fare bene nell'alerting: l'alert deve essere vero, ogni volta, altrimenti ti addestri a ignorarlo.
Log-based alerting viene dopo che l'uptime check funziona e te lo fidi. Per stack self-hosted, Grafana lo maneggia bene a costo basso. Datadog inizia a avere senso quando stai managgiando più di due o tre servizi e vuoi una unified view con facile integrazione alla tua deployment pipeline.
Runbook è il documento che scrivi alle 23 e leggi alle 3 di notte
Un runbook non è documentazione. La documentazione spiega come qualcosa funziona. Un runbook dice a una versione futura di te che è stressata, quasi addormentata, e sotto pressione esattamente cosa fare adesso.
Il formato che funziona per i progetti solisti:
Cosa è rotto? Una frase, solo i sintomi osservabili
È urgente? Colpisce clienti che pagano proprio ora?
Cosa faccio? Tre a cinque step numerati, iniziando con la cosa più veloce da provare per prima
Basta così. Scrivilo quando non sei in un incident. Rileggi e aggiorna dopo un incident per vedere se era davvero utile.
Dove stori i runbook conta meno che l'abitudine di scriverli. Una pagina Notion, un Markdown file nel tuo repo, un doc condiviso. Il test: puoi aprirlo sul tuo phone in 30 secondi, semi-addormentato, alle 3 di notte?
L'argomento pratico per Notion sopra un file di repo è l'accesso mobile. Se dormi accanto al tuo phone perché hai produzione traffic e una brutta sensazione su un deploy che hai appena fatto, quello conta. GitBook è un'altra opzione solida se preferisci qualcosa di più strutturato che raddoppia come public developer docs.
Buildarti una status page pubblica: quello che gli utenti vogliono davvero quando le cose si rompono
I tuoi utenti non hanno bisogno di un real-time observability dashboard. Hanno bisogno di sapere due cose: è rotto per tutti, e te ne sei accorto?
La status page minimal viable ha tre elementi:
Un indicatore di stato con al massimo tre stati: operativo, degradato, down
Un timestamp di quando lo stato attuale è stato aggiornato per ultimo
Una riga di inglese semplice quando qualcosa non va
Gli utenti che controllano una status page durante un incident non leggono architecture diagrams. Vogliono smettere di fare troubleshooting della loro setup perché ora sanno che non è colpa loro.
Buildarla ti prende meno di quattro ore:
Una pagina HTML statica con uno snippet JavaScript che fetcha lo stato da un endpoint
Una tabella Supabase con due campi: status (enum) e message (text)
Un cron job che aggiorna lo status basandosi sul risultato del tuo health check
Un admin endpoint dietro auth per scrivere un messaggio manuale quando serve
La parte difficile non è la build. È l'abitudine di aggiornarla durante un incident invece di buttarsi dritto nel fix. L'aggiornamento prende 30 secondi e ti salva 15 customer support emails.
L'altro argomento per buildarla tu: gli strumenti status page commercial caricano $30 a $100 al mese per quello che è fondamentalmente un endpoint JSON e una pagina HTML statica. Buildalo una volta, proprietà tua. I tuoi utenti non hanno bisogno di Statuspage.io. Hanno bisogno di un URL che funziona ancora quando il tuo main domain cade.
Post-mortem quando sei l'unica persona da incolpare
I post-mortem nei setting enterprise sono su non incolpare gli individui e identificare i fallimenti sistemici. Solisti, tu sei il sistema. La psicologia è diversa, ma la pratica ha ancora importanza.
Il motivo di scrivere post-mortem da solo: risolverai la stessa classe di problema due volte se non lo fai. Tre mesi dopo starai guardando una query database che ha locked perché su un indice che non avevi aggiunto, e avrai un vago ricordo di aver riparato qualcosa di simile prima, ma non ti ricorderai cosa.
Un formato da cinque minuti che si mantiene:
Cosa è successo (un paragrafo, solo fatti, nessun linguaggio da incolpare)
Cosa hai fatto per riparlo
Una cosa da cambiare nel sistema
Una cosa da cambiare nel tuo processo
Scrivilo nello stesso posto dei tuoi runbook. Diventa l'input per il prossimo aggiornamento del runbook. Oltre sei mesi, questo crea un record leggero dei tuoi fallimenti di sistema che nessuno strumento enterprise postmortem replica per un builder solista.
Dovrebbe buildarmi questo o collegare tool che già esistono?
La risposta onesta dipende da dove sei.
Se hai zero clienti che pagano: buildatelo tu tutto. Health check cron, status page, Notion runbook. Questo è il progetto giusto per imparare i pattern. Shippa nel weekend. Ti insegna cosa incident response davvero richiede. E se decidi dopo di buildarla e venderla come prodotto, hai già validato i requirement su te stesso.
Se hai clienti che pagano che dipendono dall'uptime oggi: inizia con tool che esistono. Collegati Grafana Cloud free tier, configura un uptime monitor, e apri una pagina Notion runbook questo pomeriggio. Hai bisogno di coverage adesso, non dopo tre weekend di building.
Il pezzo che vale la pena buildarti indipendentemente dallo stage: la status page. Possessione tua, hostala su un dominio separato, buildala questo weekend. Tutto il resto puoi collegarti da free tier esistenti finché la complessità non giustifica buildarla.
Il gap che nessuna guida incident response parla
Il problema non è il tooling. È le 48 ore tra "dovrebbe configurare alerting" e "l'ho davvero configurato".
La maggior parte dei dev solo stack hanno abbastanza osservabilità primitiva per buildarsi un primo incident response layer in un singolo giorno. L'health check endpoint esiste da qualche parte. I log sono da qualche parte. La pipeline deploy ha qualche error handling. Quello che manca è 90 minuti di focused wiring: health check a uptime monitor, uptime monitor a SMS o Telegram alert, una pagina Notion con tre runbook, pagina statica con un Supabase status endpoint.
Questo non è il progetto che shippa agli utenti. È il progetto che shippa per te.
Buildalo questo weekend. La prima volta che qualcosa si rompe alle 3 di notte e spendi 4 minuti ripararlo invece di 40 minuti a trovarlo, capirai perché incident response best practice esistono. Non perché i team enterprise lo hanno mandato, ma perché l'alternativa è peggio.