Pagina 1 di 2
Business continuity per un'azienda digitale non è un documento da certificazione archiviato in un cassetto. È un insieme di procedure, backup, architetture e test che permettono all'operatività di riprendere in tempi certi dopo un evento critico: un crash hardware, un ransomware, un errore umano, un cloud provider in down. Lavoro su piani di continuità operativa da anni, con focus sulle PMI italiane.
In questa categoria trovi articoli su piani di disaster recovery, backup strategie (incluso testing periodico del restore, che è la parte che quasi nessuno fa), ridondanza geografica, failover applicativi, gestione dei fornitori critici. Parlo anche di come comunicare questi piani al management non tecnico, che è metà del problema.
Se la tua azienda non sa cosa succederebbe se domani il server principale sparisse, parliamone prima di doverlo scoprire. Oppure leggi come affronto la continuità operativa nei progetti dei miei clienti.
Un backup che non hai mai ripristinato non è un backup. È solo una speranza su un disco.
Ho simulato uno scenario ransomware per un cliente manifatturiero con 60 dipendenti: ho mappato tutti i sistemi critici, calcolato il costo orario del downtime e testato i backup. I risultati erano scomodi: 18 ore per ripristinare i sistemi principali, 40 ore per i secondari, backup di tre settimane fa. Ecco cosa abbiamo fatto. Continua a leggere
Un gestionale PHP legacy con zero test e 3 regressioni al mese: ogni fix rompeva qualcosa. In 5 giorni ho introdotto 28 smoke test HTTP e 12 snapshot test sulle funzioni di calcolo - senza toccare il codice applicativo. Regressioni in produzione scese da 3/mese a zero nel primo trimestre. Continua a leggere
Un gestionale PHP su VPS OVH, il freelance sparito da tre mesi, credenziali perse, nessun backup del codice e il certificato SSL in scadenza tra 8 giorni. Le prime 48 ore di un subentro d'emergenza: mappatura accessi, backup immediato, rotazione credenziali e stabilizzazione prima di qualsiasi modifica. Continua a leggere
Un gestionale PHP legacy dove gli errori si scoprivano dalle telefonate dei clienti: nessun log strutturato, nessun alert, MTTR medio di 4 ore. Ho introdotto Monolog con output JSON, metriche operative con cron e alert Telegram in 5 giorni - senza riscrivere una riga di codice applicativo. MTTR sceso a 22 minuti. Continua a leggere
Un gestionale PHP 7.0 ereditato da un freelance sparito: 43.000 righe di codice, nessuna documentazione, e il titolare che deve decidere se investire nella modernizzazione o riscrivere da zero. In 30 giorni ho prodotto un audit completo con PHPStan, Psalm, analisi delle dipendenze e una roadmap di intervento con costi e priorità. Continua a leggere
Un e-commerce Laravel fermo per 14 ore perché il disco del VPS si era guastato e il backup non era mai stato testato. L'RTO stimato dal titolare era "qualche minuto", quello reale è stato 14 ore. Il piano di disaster recovery che ho costruito dopo: BorgBackup offsite, RTO verificato di 47 minuti, test trimestrale automatizzato. Continua a leggere
Un mysqldump che girava ogni notte sullo stesso disco del server non ha salvato una PMI veneta dal ransomware. Ho ricostruito la strategia di backup su BorgBackup con append-only repo su Hetzner Storage Box, encryption AES-256, retention GFS e test di ripristino automatizzati ogni domenica. Il protocollo 3-2-1-1-0 che applico a ogni VPS. Continua a leggere
Su un VPS Contabo con un gestionale Laravel 10, i backup automatici con spatie/laravel-backup fallivano da tre mesi - disco pieno sullo storage S3, credenziali scadute, e il notification channel configurato su un webhook Slack che non esisteva più. Il titolare l'ha scoperto quando ha avuto bisogno di un restore. Diagnosi delle cause di fallimento, ripristino della pipeline, test di restore verificato e monitoring che avvisa davvero quando qualcosa non funziona. Continua a leggere
Un e-commerce Laravel su Hetzner inviava 800 email transazionali al giorno tramite Postfix locale. Il 40% finiva in spam su Gmail, il 15% non arrivava affatto su Outlook. Il titolare non lo sapeva perché nessuno monitorava i bounce. Diagnosi: niente SPF, niente DKIM, niente DMARC, IP del VPS in due blacklist. La soluzione non era "aggiustare Postfix" - era ripensare come un'applicazione Laravel in produzione deve gestire le email transazionali nel 2025. Continua a leggere
Dopo aver recuperato server e credenziali, resta il problema vero: 85.000 righe di codice Laravel senza documentazione, zero test, business logic nei Blade template, e un titolare che deve sapere entro venerdì cosa può rompere e cosa si può toccare. Il metodo in 48 ore: scansione automatica con PHPStan, mappatura rotte, analisi schema, tracciamento flusso di business e consegna di una mappa di rischio prioritizzata. Continua a leggere
