Cos'è il test di recupero? con l'esempio

⚡ Riepilogo intelligente

Il test di ripristino verifica che il software sia in grado di riprendere il normale funzionamento dopo un arresto anomalo, un'interruzione di rete o un guasto hardware, ripristinando il sistema a un punto di funzionamento noto e rielaborando le transazioni fino al momento del guasto.

  • 🔁 Cosa dimostra: OperaLe procedure continuano anche dopo un disastro, non si limita alla semplice esistenza di un file di backup.
  • 🧩 Dove si trova: Una tecnica non funzionale, eseguita da tester qualificati su dati di backup protetti.
  • Fattori che determinano i tempi di recupero: Punti di riavvio, volume dei dati e competenze e strumenti del team di ripristino.
  • 🔄 Forma del processo: Funzionamento normale, disastro, interruzione, ripristino, quindi ricostruzione per tornare alla normalità.
  • 💾 Scelte strategiche: Backup singoli o multipli, su un unico sito o su più siti, online o offline, automatici o manuali.
  • Dopo il ripristino: Conta i file rispetto alla cartella originale, apri diversi tipi di file e confronta le directory con le utilità di sistema.

Cos'è il test di ripristino nel testing del software, con un esempio.

Che cosa sono i test di recupero?

Test di recupero Il test di ripristino è una tecnica di test del software che verifica la capacità del software di riprendersi da guasti quali crash del software o dell'hardware e guasti di rete. Lo scopo del test di ripristino è determinare se le operazioni del software possono continuare dopo un disastro o una perdita di integrità. Il test di ripristino prevede il ripristino del software a un punto in cui l'integrità era nota e la rielaborazione delle transazioni fino al punto del guasto.

Nell'ingegneria del software, il test di recuperabilità è un tipo di test non funzionali — copre aspetti non legati a una funzione specifica o a un'azione dell'utente, come la scalabilità o la sicurezza. Viene eseguito da tester professionisti e, prima dell'esecuzione, vengono conservati in luoghi sicuri adeguati dati di backup.

Esempio di test di recupero

Due scenari illustrano la tecnica nella sua forma più semplice. In ciascuno di essi, si provoca deliberatamente un errore e si osserva l'applicazione mentre riprende a funzionare.

  • Interruzione di rete: Mentre un'applicazione sta ricevendo dati dalla rete, scollegare il cavo di connessione. Dopo un po' di tempo, ricollegarlo e verificare se l'applicazione è in grado di continuare a ricevere dati dal punto in cui la connessione è stata interrotta.
  • Ripristino della sessione: Riavvia il sistema mentre un browser ha un certo numero di sessioni aperte e verifica se il browser le recupera tutte.

L'illustrazione sottostante presenta lo stesso concetto in forma visiva.

Concetto di test di ripristino che mostra un sistema che si guasta e viene poi ripristinato al normale funzionamento.

Il tempo necessario per il recupero dipende da:

  • Il numero di punti di riavvio
  • Il volume dei dati contenuti nell'applicazione
  • Formazione e competenze delle persone che conducono attività di recupero e strumenti disponibili per il recupero

In caso di guasti multipli, i test di ripristino dovrebbero essere eseguiti in modo strutturato anziché tutti in una volta, ovvero prima su un segmento e poi su un altro.

Ciclo di vita del processo di recupero

Prima di progettare i casi di test, è utile capire dove interviene un test di ripristino. Il ciclo di vita del processo di ripristino si articola in cinque fasi:

  1. Operazione normale
  2. Evento del disastro
  3. Interruzione e fallimento dell'operazione
  4. Eliminazione del disastro attraverso il processo di recupero
  5. Ricostruzione di tutti i processi e le informazioni, riportando l'intero sistema al normale funzionamento.

Il diagramma di flusso sottostante mostra queste cinque fasi in sequenza.

Diagramma di flusso del ciclo di vita del processo di ripristino, che comprende funzionamento normale, disastro, interruzione, ripristino e ricostruzione.

Analizziamo nel dettaglio questi cinque passaggi:

  1. Operazione normale. Un sistema composto da hardware, software e firmware, integrati per raggiungere un obiettivo comune, svolge la funzione per cui è stato progettato senza interruzioni entro un periodo di tempo prestabilito.
  2. Evento catastrofico. Un'interruzione può verificarsi a causa di un malfunzionamento del software, dovuto a cause quali un errore di input, un arresto anomalo causato da un guasto hardware o danni derivanti da incendio, furto o impatto.
  3. Interruzione e fallimento. Questa è la fase più dolorosa, che comporta perdite economiche, rottura dei rapporti, opportunità mancate, perdita di ore lavorative e, inevitabilmente, perdite finanziarie e di reputazione. Un piano di ripristino d'emergenza riduce al minimo questa fase.
  4. Sgombero post-disastro. Se sono già in atto un piano di backup e processi di mitigazione del rischio, il ripristino richiede molto meno tempo e impegno. Un team dedicato, con ruoli definiti in anticipo per ciascun membro, chiarisce le responsabilità e previene lunghi periodi di interruzione.
  5. Ricostruzione. Questa operazione potrebbe richiedere più sessioni per ricostruire tutte le cartelle e i file di configurazione. Per un ripristino corretto sono necessari una documentazione adeguata e un processo di ricostruzione ben definito.

Strategia di restauro

Il team di ripristino dovrebbe avere una propria strategia per recuperare codice e dati importanti al fine di riportare le operazioni alla normalità. Tale strategia è specifica per ogni organizzazione, in base alla criticità dei sistemi che gestisce, e per i sistemi critici si riduce a una serie di scelte:

  1. Un singolo backup o più di uno
  2. Backup multipli in un unico posto o in posti diversi.
  3. Backup online o backup offline
  4. I backup vengono eseguiti automaticamente in base a una policy oppure attivati ​​manualmente.
  5. Un team di restauro indipendente o il team di sviluppo che esegue i lavori

Ogni scelta comporta un fattore di costo e più backup possono consumare più risorse fisiche o richiedere un team indipendente. Anche la dipendenza è importante: le aziende sono esposte attraverso il codice e i dati che mantengono con un unico fornitore e un'ampia scala AWS L'interruzione del servizio ha ripetutamente messo offline contemporaneamente noti servizi di consumo. In questi casi, la capacità di ripristino indipendente è fondamentale.

Come eseguire i test di recupero

Una volta definita la strategia, la domanda successiva riguarda la configurazione del test stesso. Durante l'esecuzione dei test di ripristino, è necessario tenere in considerazione i seguenti punti.

  • Creare un ambiente di test che riproduca il più fedelmente possibile le condizioni di implementazione reali: interfaccia, protocollo, firmware, hardware e software devono corrispondere a quelli di produzione.
  • Sebbene i test esaustivi possano richiedere tempo e comportare costi elevati, è comunque opportuno eseguire una configurazione identica e un controllo completo.
  • Se possibile, esegui un test sull'hardware su cui verrà effettuato il ripristino finale, soprattutto se il ripristino avviene su una macchina diversa da quella che ha creato il backup.
  • Alcuni sistemi di backup prevedono che il disco rigido abbia esattamente le stesse dimensioni di quello da cui è stato eseguito il backup.
  • Gestire l'obsolescenza: la tecnologia delle unità avanza rapidamente e una vecchia unità potrebbe non essere compatibile con una nuova. Il ripristino a un macchina virtuale È utile perché il software di virtualizzazione può emulare l'hardware esistente, comprese le dimensioni dei dischi.
  • Anche i sistemi di backup online sono soggetti a test. La maggior parte dei fornitori protegge gli utenti dai problemi relativi ai supporti di memorizzazione tramite sistemi di archiviazione a tolleranza di errore, pertanto i guasti si manifestano in un secondo momento.
  • Sebbene i sistemi di backup online siano estremamente affidabili, è necessario testare la fase di ripristino per verificare che non vi siano problemi di recupero, sicurezza o crittografia.

Poiché il recupero viene eseguito dall'inizio alla fine, queste corse sono solitamente programmate insieme test di sistema piuttosto che a livello di unità.

Procedura di collaudo dopo il restauro

Il ripristino dei dati è solo metà del lavoro; la copia ripristinata deve ancora essere dimostrata utilizzabile. La maggior parte delle grandi aziende si affida a revisori esterni per condurre periodicamente esercitazioni di ripristino. Un piano completo di disaster recovery è costoso da mantenere e testare, quindi le organizzazioni più piccole spesso si affidano a backup e archiviazione esterna.

Dopo il ripristino di cartelle e file, i seguenti controlli confermano che il recupero è avvenuto correttamente:

  • Rinominare la cartella del documento danneggiato in modo che la copia ripristinata non possa essere confusa con essa.
  • Conta i file nelle cartelle ripristinate e confronta il conteggio con quello della cartella originale.
  • Apri alcuni file con l'applicazione che li utilizza normalmente e verifica che i dati possano essere visualizzati e aggiornati come di consueto.
  • Apri diversi file di vario tipo: immagini, MP3e documenti, alcuni grandi e altri piccoli.
  • Utilizza le utilità di confronto di file e directory che più sistemi operativi fornire.

DOMANDE FREQUENTI

Il test di failover verifica che il traffico venga trasferito correttamente a un nodo di standby. Il test di ripristino va oltre e verifica che il servizio originale, i relativi dati e le transazioni in corso vengano ripristinati a uno stato corretto.

RTO è il tempo consentito per ripristinare un servizio; RPO è la perdita di dati accettabile. Un test di ripristino misura entrambi: il tempo di ripristino per RTO e il confronto dei dati recuperati con l'ultimo stato valido noto per RPO.

Ricorrono tre varianti: ripristino di emergenza per interruzioni a livello di sito, ripristino del database per archivi dati danneggiati e ripristino dell'ambiente per configurazioni o dipendenze errate. Ognuna utilizza lo stesso ciclo di vita con un diverso fattore scatenante di errore.

I modelli di apprendimento automatico classificano i servizi in base alla cronologia degli incidenti e alla profondità delle dipendenze, in modo che i percorsi di ripristino più rischiosi vengano eseguiti per primi. Il rilevamento delle anomalie nei log di ripristino segnala anche le esecuzioni terminate ma che hanno prodotto dati incompleti.

Copilota GitHub Il sistema elabora rapidamente script di supporto per l'iniezione di errori, script di ripristino e asserzioni post-ripristino. Il tester decide comunque quale errore forzare e quale aspetto abbia uno stato di ripristino corretto, poiché entrambi seguono regole aziendali.

Le esercitazioni annuali sono comuni, con simulazioni trimestrali per i sistemi critici. Qualsiasi modifica allo strumento di backup, alla piattaforma di archiviazione o all'architettura dovrebbe innescare una nuova esecuzione, poiché una modifica non testata invalida silenziosamente il risultato precedente.

Costringe a veri fallimenti, quindi si sovrappone a prove distruttivema l'obiettivo è il ripristino, non la rottura. Eseguilo in un ambiente di test isolato, non su dati di produzione reali.

Registrare il guasto iniettato, gli orari di inizio e fine, RTO e RPO misurati, le fasi che hanno richiesto un intervento manuale e ogni discrepanza riscontrata nei dati ripristinati. Aggiungere le azioni correttive e la data del nuovo test.

Riassumi questo post con: