Runbook per incidenti nelle app no-code: rilevare, valutare, ripristinare

Cos'è questo runbook e quando usarlo

Un incidente è qualsiasi problema imprevisto che impedisce alle persone di usare la tua app, la rende dolorosamente lenta o mette a rischio i dati. Nelle app no-code questo può manifestarsi come improvvisi fallimenti di login, schermate rotte dopo una modifica, automazioni di background che smettono di partire, errori API o workflow “riusciti” che scrivono silenziosamente valori sbagliati nel database.

Un runbook scritto trasforma un momento stressante in una serie di azioni piccole e chiare. Riduce congetture, accelera le decisioni (per esempio quando effettuare un rollback) e aiuta tutti a condividere gli stessi fatti. La maggior parte dei ritardi durante gli incidenti non è tecnica: deriva dall'incertezza: È reale? Chi sta guidando? Cosa è cambiato? Cosa diciamo agli utenti?

Questo playbook è per chiunque tocchi l'app quando le cose vanno male: i builder che rilasciano modifiche, gli ops o i proprietari di piattaforma che gestiscono deploy e accessi, i team di supporto che ricevono le prime segnalazioni e i responsabili di prodotto o business che giudicano impatto e priorità.

È volutamente leggero, anche per i team che costruiscono su piattaforme come AppMaster dove potresti avere logica visuale, servizi generati e più opzioni di deployment.

Copre l'intero ciclo dell'incidente: rilevare e confermare un problema reale, triage rapido, stabilizzare e recuperare (inclusa la decisione sul rollback), comunicare durante il blackout e poi svolgere una breve review post-incidente in modo che lo stesso problema sia meno probabile in futuro.

Non copre la riprogettazione architetturale a lungo termine, forensi di sicurezza approfondite o procedure complesse di compliance. Se gestisci dati regolamentati o infrastrutture critiche, aggiungi passaggi più rigorosi a questo runbook.

Prima che qualcosa si rompa: definisci baseline e ruoli

Gli incidenti sembrano caotici quando non sai com'è il “normale”. Definisci la baseline così il team può individuare reali problemi rapidamente. Per un'app no-code, i segnali iniziali di solito arrivano da una combinazione di salute della piattaforma, metriche di business e persone.

Annota i segnali che guarderai ogni giorno, non solo durante i blackout. Tra i più comuni: uptime, tasso di errori, schermate lente, login falliti, pagamenti non riusciti e picchi di ticket di supporto o messaggi utente.

Definisci la severità in linguaggio semplice così chiunque può usarla:

• SEV1: La maggior parte degli utenti non può usare l'app, o denaro/sicurezza è a rischio.
• SEV2: Una funzione chiave è rotta, ma esiste una soluzione alternativa.
• SEV3: Problemi minori, utenti limitati o bug estetici.

Imposta obiettivi di risposta che creino slancio. Esempi: riconoscere entro 5 minuti, pubblicare il primo aggiornamento entro 15 minuti e mirare a stabilizzare entro 60 minuti (anche se la correzione completa richiede più tempo).

Decidi i ruoli prima di averne bisogno. Nomina chi può dichiarare un incidente, chi lo guida e chi è backup se quella persona è offline. Nei team AppMaster, spesso è la persona che possiede la logica Business Process, più un backup che può gestire deploy o export.

Infine, tieni un posto condiviso per le note dell'incidente. Usa timestamp per ogni azione (cosa è cambiato, quando, da chi) così puoi ricostruire la storia dopo senza indovinare.

Rilevare e confermare: è reale e quanto è grave

Conferma l'impatto prima di fissarti sui dashboard. Fai una domanda chiara: chi non può fare cosa in questo momento? “Il team di supporto non può aprire ticket” è più utile di “l'app è lenta”. Se possibile, riproduci il problema usando lo stesso ruolo e dispositivo dell'utente affetto.

Poi valuta quanto è esteso. È un solo account, un segmento di clienti o tutti? Fai divisioni rapide: regione, tipo di account, web vs mobile e una singola feature vs tutta l'app. Negli strumenti no-code, qualcosa può sembrare globale quando in realtà è una regola di permessi o una schermata rotta.

Controlla cosa è cambiato. Guarda indietro 1-2 ore per un rilascio, un toggle di configurazione, una modifica allo schema del database o un import di dati. Su piattaforme come AppMaster, cambi alla logica di business, ai modelli dati o alle impostazioni di auth possono impattare molti flussi contemporaneamente, anche se l'interfaccia sembra a posto.

Prima di incolpare la tua app, escludi dipendenze esterne. Provider di email/SMS, pagamenti (come Stripe) e integrazioni (Telegram, AWS services, AI APIs) possono fallire o limitare le richieste. Se l'app si rompe solo quando invia messaggi o addebita carte, il problema potrebbe essere a monte.

Usa una checklist decisionale semplice:

• Monitor: se l'impatto è basso e gli errori non stanno aumentando.
• Mitigare ora: se gli utenti sono bloccati in compiti core o i dati sono a rischio.
• Dichiarare un incidente: se il problema è diffuso, sensibile al tempo o poco chiaro.
• Escalare: se il problema tocca pagamenti, autenticazione o dati di produzione.
• Impostare un orario di check-in: (per esempio, ogni 15 minuti) così il team non si disperde.

Una volta classificata severità e portata, puoi passare da “è reale?” a “cosa facciamo per primo?” senza indovinare.

Triage passo-passo (primi 30 minuti)

Apri subito un record di incidente. Daglielo un titolo chiaro che descriva l'impatto sull'utente, non la causa sospetta (per esempio, “Checkout in errore per clienti UE”). Scrivi l'orario di inizio (primo alert o prima segnalazione). Questo diventerà il luogo unico per decisioni, timestamp e cosa è cambiato.

Assegna i ruoli così il lavoro non si sovrappone. Anche in un team piccolo, nominare i responsabili riduce gli errori sotto stress. Al minimo, vuoi:

• Incident lead: mantiene il focus, imposta le priorità, decide contenimento vs rollback
• Fixer: indaga e applica le modifiche
• Comms: pubblica aggiornamenti a stakeholder e support
• Note taker: registra azioni, orari e risultati

Scrivi due cose: cosa sai per certo e quale è la tua ipotesi corrente. “Conosciuto” potrebbe essere: il tasso di errore è salito, un endpoint specifico fallisce, solo il mobile è interessato. L'ipotesi può essere sbagliata, ma dovrebbe guidare il prossimo test. Aggiorna entrambi man mano che impari.

Mentre le cose sono instabili, imposta una cadenza di aggiornamento di 15 minuti. Se nulla è cambiato, dillo. Aggiornamenti regolari fermano discussioni laterali e prevengono ping duplicati del tipo “qualche novità?”.

Scegli la prima azione di contenimento. L'obiettivo è ridurre il danno velocemente, anche se la causa radice non è ancora chiara. Mosse tipiche: mettere in pausa job di background, disabilitare un feature flag rischioso, limitare il traffico a un modulo o passare a una configurazione nota come sicura. In AppMaster, questo spesso significa disattivare uno specifico flow nel Business Process Editor o nascondere temporaneamente un percorso UI che scatena i fallimenti.

Se la containment non migliora le metriche entro una finestra di cadenza, inizia parallelamente a pianificare il rollback.

Stabilizzare prima: contenere l'impatto

Una volta confermato che è un incidente reale, passa da “trovare il bug” a “fermare l'emorragia”. Stabilizzare ti compra tempo. Protegge anche utenti, entrate e dati mentre indaghi.

Inizia con il cambiamento più piccolo che riduce il danno. La containment è spesso più veloce di una correzione completa perché puoi disabilitare una nuova feature, mettere in pausa un workflow o bloccare un percorso di input rischioso senza ricostruire.

Se sospetti che i dati vengano corrotti, prima ferma le scritture. Questo può significare disabilitare form, mettere in pausa automazioni che aggiornano record o bloccare un endpoint API che accetta aggiornamenti. Leggere dati corrotti è doloroso, ma scrivere dati corrotti moltiplica il lavoro di pulizia.

Se gli utenti sono bloccati, tratta il login come priorità assoluta. Controlla prima le impostazioni di autenticazione e il flusso di login. Ogni altra correzione è più lenta se gli utenti (e il tuo team) non possono accedere all'app.

Se l'app è lenta o va in timeout, riduci il carico e rimuovi i percorsi costosi. Disattiva schermate pesanti, metti in pausa job di background e disabilita integrazioni nuove che fanno aumentare le richieste. In AppMaster, la containment può essere semplice come disabilitare un Business Process problematico o rimuovere temporaneamente un'azione UI che scatena una catena costosa.

Mantieni le azioni deliberate e documentate. Sotto pressione, i team ripetono passaggi o annullano una correzione per errore. Scrivi ogni cambiamento e il risultato.

Una semplice sequenza di stabilizzazione:

• Ferma le scritture se è possibile corruzione dei dati e conferma che i nuovi record non cambiano più.
• Disabilita il feature flag, l'automazione o l'integrazione più recente coinvolta nella timeline.
• Proteggi gli accessi: ripristina login e sessioni per gli admin prima, poi per tutti gli utenti.
• Riduci il carico mettendo in pausa job batch e rimuovendo il percorso utente più lento.
• Registra ogni azione con timestamp, responsabile ed effetto osservato.

L'obiettivo è “sicuro e utilizzabile”, non “completamente risolto”. Una volta contenuto l'impatto, puoi diagnosticare con calma e scegliere il giusto rollback o fix.

Scelte di rollback e controlli sul rischio

Quando qualcosa si rompe, la velocità conta, ma la mossa più sicura vince. Di solito hai tre opzioni pratiche: rollback, spedire una correzione in avanti o fare un revert parziale (disattivare una feature lasciando il resto).

Prima, chiarisci cosa significa “rollback” nel tuo contesto. Può voler dire deployare la versione precedente dell'app, annullare una modifica di configurazione o ripristinare uno stato di database. Su piattaforme come AppMaster, una “versione” può includere logica backend, UI web, build mobile e impostazioni di ambiente.

Usa questi controlli sul rischio per decidere se il rollback è sicuro:

• Cambiamenti allo schema del database: il rollback può fallire se la versione vecchia si aspetta tabelle o campi diversi.
• Scritture irreversibili: rimborsi, cambi di stato o messaggi inviati non si possono annullare.
• Job in coda e webhook: la logica più vecchia potrebbe rielaborare elementi o fallire su payload nuovi.
• Dipendenze esterne: integrazioni di pagamento, email/SMS o Telegram potrebbero comportarsi diversamente.

Imposta una regola go/no-go semplice prima di toccare qualsiasi cosa. Scegli 2-3 metriche che devono migliorare entro 10-15 minuti dall'azione, come tasso di errori, successo login, completamento checkout o latenza API. Se non migliorano nel modo giusto, fermati e cambia strategia.

Pianifica anche il backout del rollback. Sai come lo annullerai se la versione più vecchia causa nuovi problemi: quale build ridistribuire, quale config riapplicare e chi approva quel secondo cambiamento. Tieni una persona responsabile della decisione finale di “ship” così non cambiate direzione a metà strada.

Comunicazione durante l'incidente

Il silenzio peggiora gli incidenti. Usa un modo semplice e ripetibile per tenere le persone informate mentre il team indaga.

Inizia con aggiornamenti interni. Avvisa chi riceverà prima le domande e chi può rimuovere i blocchi. Mantieni il messaggio breve e fattuale. Di solito servono:

• Support o customer success: cosa vedono gli utenti e cosa dire subito
• Sales o account: quali account sono impattati e cosa non promettere
• Builder/engineering: cosa è cambiato, cosa si sta rollbackando, chi ci lavora
• Un referente exec: impatto, rischio, prossimo orario di aggiornamento
• Un owner che approvi il messaggio esterno

Per gli aggiornamenti esterni, attieniti a ciò che sai. Evita di indovinare la causa o incolpare un vendor. Gli utenti vogliono soprattutto tre cose: conferma, impatto e quando riceveranno il prossimo aggiornamento.

Template di messaggio semplice

Mantieni una linea di stato coerente su tutti i canali:

• Status: Investigating | Identified | Mitigating | Monitoring | Resolved
• Impact: “Alcuni utenti non riescono a fare login” o “I pagamenti falliscono per nuovi ordini”
• Workaround: “Riprova tra 10 minuti” o “Usa l'app mobile mentre il web è down” (solo se vero)
• Next update: “Prossimo aggiornamento alle 14:30 UTC”

Se gli utenti sono arrabbiati, ammetti prima, poi sii specifico: “Sappiamo che il checkout non funziona per alcuni clienti. Stiamo rollbackando l'ultima modifica ora. Prossimo aggiornamento tra 30 minuti.” Non promettere scadenze, crediti o fix permanenti durante l'incidente.

Risolto vs monitoring

Dichiara risolto solo quando il sintomo principale è scomparso e i controlli chiave sono puliti (login, flussi core, tassi di errore). Usa monitoring quando hai applicato una correzione (per esempio rollback o ripristino config) ma hai ancora bisogno di tempo per osservare ripetizioni. Indica sempre cosa monitorerai, per quanto tempo e quando pubblicherai l'aggiornamento finale.

Diagnosticare la causa: controlli rapidi che restringono il campo

Una volta che le cose sono stabili, passa dal firefighting alla raccolta del minimo insieme di fatti che spiega i sintomi. L'obiettivo non è la root cause perfetta, ma una causa probabile su cui agire senza peggiorare l'incidente.

Sintomi diversi indicano sospetti diversi. Pagine lente spesso significano query DB lente, un picco di traffico o un servizio esterno in ritardo. Timeout possono derivare da un processo bloccato, backend sovraccarico o un'integrazione che impiega troppo. Un picco di errori o retry spesso torna a una modifica recente, un input errato o un'outage a monte.

Controlli rapidi (15 minuti)

Esegui un percorso utente reale end-to-end con un account di test normale. Spesso è il segnale più veloce perché tocca UI, logica, database e integrazioni.

Concentrati su pochi controlli:

• Riproduci un percorso: effettua il login, esegui l'azione chiave, conferma il risultato.
• Individua il passo lento/che fallisce: caricamento pagina, chiamata API, salvataggio su DB, webhook.
• Controlla i dati recenti: analizza gli ultimi 20-50 record per duplicati, campi mancanti o totali incoerenti.
• Valida le integrazioni: tentativi di pagamento recenti (per esempio Stripe), consegne webhook e qualsiasi messaggistica (email/SMS o Telegram).
• Conferma il contesto della modifica: cosa è stato rilasciato, configurato o migrato subito prima del picco?

Se sei su AppMaster, questo spesso si mappa chiaramente a uno step del Business Process, a una modifica del Data Designer o a una configurazione di deploy.

Decidere: mantenere la mitigazione o correggere avanti

Se i controlli rapidi individuano un colpevole chiaro, scegli la mossa più sicura: mantieni la mitigazione corrente o applica una piccola correzione permanente. Rimuovi i rate limit, i feature toggle o le soluzioni manuali solo dopo che il percorso ha avuto successo due volte e il tasso di errori rimane stabile per qualche minuto.

Scenario esempio: rilascio fallito durante l'orario di lavoro

Sono le 10:15 di martedì. Un team rilascia una piccola modifica su un portale clienti costruito con AppMaster. Nel giro di minuti, gli utenti vedono pagine vuote dopo il login e i nuovi ordini si fermano.

Il support riceve tre ticket con lo stesso messaggio: “Login funzionante, poi il portale non carica mai.” Contemporaneamente il monitoring mostra un picco di errori 500 sull'app web e una diminuzione delle chiamate API riuscite. Lo tratti come un incidente reale.

L'incident lead fa una rapida conferma: prova a fare il login come utente di test su desktop e mobile e controlla l'orario dell'ultimo deploy. La tempistica coincide con il rilascio, quindi si assume che l'ultima modifica sia coinvolta finché non si dimostra il contrario.

I primi 30 minuti potrebbero essere così:

• Contain: mettere il portale in maintenance mode (o disabilitare temporaneamente il feature flag interessato) per fermare più utenti dal raggiungere il flusso rotto.
• Decidere rollback: se il failure è iniziato subito dopo il rilascio e impatta molti utenti, rollback immediato.
• Comunicare: pubblicare un breve aggiornamento interno (cosa è rotto, impatto, azione corrente, prossimo aggiornamento). Inviare un messaggio clienti conciso che stai lavorando.
• Recover: redeploy della ultima versione nota buona (o revert del modulo specifico). Ritestare login, caricamento dashboard e una azione core come “crea ticket” o “effettua ordine”.
• Monitor: osservare tasso di errori, successo login e volume ticket support per 10-15 minuti prima di dichiarare stabilità.

Alle 10:40 gli errori tornano alla normalità. Si mantiene il monitoraggio mentre il support conferma la riduzione dei nuovi ticket.

Dopo, il team fa una breve review: cosa ha rilevato per primo il problema (alert vs support), cosa ha rallentato la risoluzione (mancanza di owner, passi rollback poco chiari) e cosa cambiare. Un miglioramento comune è aggiungere una smoke-test checklist di release per i top 3 flussi del portale e rendere il rollback un'azione documentata e semplice.

Errori comuni che peggiorano gli incidenti

La maggior parte degli incidenti peggiora per due ragioni: si lascia il sistema continuare a fare danno durante le indagini, o si cambiano troppe cose troppo in fretta. Questo runbook serve a proteggerci da entrambi.

Un tranello comune è investigare mentre l'app continua a scrivere dati errati. Se un workflow è in loop, un'integrazione posta duplicati o un bug di permessi permette agli utenti sbagliati di modificare record, metti in pausa il processo offensivo prima. In AppMaster, questo può significare disabilitare un Business Process, spegnere un'integrazione modulo o limitare temporaneamente gli accessi così il problema non si propaga.

Un altro errore è “fixare” per tentativi. Quando diverse persone fanno click e cambiano impostazioni, perdi la timeline. Anche piccole modifiche contano durante un incidente. Concorda un unico driver, tieni un change log semplice ed evita di impilare tweak su incognite.

Errori che causano ripetutamente outage più lunghi:

• Indagare prima e contenere dopo, mentre continuano scritture dannose o azioni duplicate
• Fare più cambi contemporaneamente senza appunti, così non capisci cosa ha aiutato o peggiorato
• Aspettare a comunicare o inviare aggiornamenti vaghi che generano più domande che fiducia
• Rollbackare alla cieca senza controllare lo stato del database e eventuali job in coda, email o webhook
• Chiudere l'incidente senza un chiaro step di verifica

La comunicazione è parte del recovery. Condividi ciò che sai, ciò che non sai e quando arriverà il prossimo aggiornamento. “Stiamo rollbackando e confermeremo gli eventi di fatturazione corretti entro 15 minuti” è meglio di “Stiamo guardando il problema.”

Non chiudere l'incidente solo perché gli errori si sono fermati. Verifica con una checklist breve: le schermate chiave si caricano, i nuovi record si salvano correttamente, le automazioni critiche girano almeno una volta e i backlog (code, retry, job schedulati) sono svuotati o messi in pausa in modo sicuro.

Checklist rapida da eseguire sotto pressione

Quando le cose si rompono, il tuo cervello cercherà di fare dieci cose contemporaneamente. Usa questo per restare calmo, mantenere le persone al sicuro e ripristinare il servizio.

Appunta questa sezione dove il tuo team la vede davvero.

• Conferma che è reale e determina l'impatto (5 minuti): Controlla se gli alert corrispondono a quanto riportato dagli utenti. Scrivi cosa sta fallendo (login, checkout, pannello admin), chi è impattato e da quando. Se possibile, riproduci in una sessione pulita (incognito o account di test).

Prenditi un minuto per nominare un owner dell'incidente. Una persona decide, tutti gli altri supportano.

• Stabilizza e contenimento (10 minuti): Ferma l'emorragia prima di cercare la root cause. Disabilita il percorso rischioso (feature toggle, banner temporaneo, pause alle code) e testa un percorso chiave end-to-end. Scegli il percorso che conta di più per il business, non quello più facile da testare.

• Recupera il servizio (10-20 minuti): Scegli la mossa più sicura: rollback alla ultima versione nota buona o applica una correzione minima. Su piattaforme come AppMaster questo può significare redeploy di una build precedente o revert dell'ultima modifica, poi confermare che tassi di errore e tempi di risposta tornino normali.

• Comunica (durante tutto): Pubblica aggiornamenti brevi con cosa è impattato, cosa devono fare gli utenti e quando sarà il prossimo aggiornamento. Fornisci al support uno script di due frasi così tutti dicono la stessa cosa.

• Chiudi pulito (prima di dimenticare): Registra cosa è successo, cosa hai cambiato e quando il servizio è tornato. Assegna i passi successivi con owner e scadenza (tweak monitoring, gap nei test, pulizia dati, fix di follow-up).

Dopo l'incidente: imparare, correggere e prevenire ripetizioni

Un incidente non è veramente “finito” quando l'app è di nuovo su. Il modo più veloce per ridurre futuri downtime è catturare cosa è successo mentre è ancora fresco e trasformare quell'apprendimento in piccoli cambiamenti reali.

Pianifica una breve post-incident review entro 2-5 giorni. Mantienila senza colpe e pratica. Lo scopo non è trovare un colpevole, ma rendere il prossimo incidente più facile da gestire.

Scrivi un resoconto che qualcuno possa leggere mesi dopo: cosa hanno visto gli utenti, quando lo avete rilevato, cosa avete provato, cosa ha funzionato e quando il servizio è tornato. Includi la root cause se la conosci e segnala fattori contributivi come alert mancanti, ownership poco chiara o passi di rollout confusi.

Trasforma gli apprendimenti in task con owner e scadenze. Concentrati sui cambiamenti più piccoli che prevengono la stessa falla:

• Chiudi gap di monitoring (aggiungi un alert o un controllo dashboard che lo avrebbe intercettato prima)
• Aggiungi un guardrail (regola di validazione, rate limit, default di feature flag, step di approvazione)
• Migliora i test per l'area a rischio (login, pagamenti, import dati, permessi)
• Aggiorna il runbook con i passi esatti che avresti voluto avere
• Fai un breve refresh formativo per on-call o proprietari dell'app

Scegli una misura preventiva per incidente, anche piccola. “Ogni cambio ai ruoli richiede un secondo revisore” o “Le migrazioni dati devono girare prima su una copia di staging” possono prevenire outage ripetuti.

Tieni questo runbook vicino al tuo processo di build e release. Se costruisci con AppMaster, annota dove ogni app è deployata (AppMaster Cloud, AWS, Azure, Google Cloud o self-hosted), chi può redeployare rapidamente e chi può rollbackare. Se vuoi una sede unica per quella documentazione, tenerla accanto alle note del progetto AppMaster (appmaster.io) la rende più facile da trovare quando i minuti contano.