Migliori pratiche o risorse per lo sviluppo di piani di ripristino di emergenza? [chiuso]

Mi è stato affidato il compito di guidare un progetto riguardante l'aggiornamento di un vecchio e in qualche modo un piano di ripristino di emergenza. Per ora stiamo solo cercando di risolvere il lato IT di DR. L'ultima volta che lo hanno fatto hanno fissato il loro scopo creando un singolo disastro (il data center è stato inondato) e pianificandolo con l'esclusione di tutti gli altri tipi di disastro. Vorrei adottare un approccio più completo. So che questo è un problema risolto, altre organizzazioni hanno scritto piani di DR.

Il nostro piano è di prendere il nostro piano di IT DR, andare avanti con esso e dire "Ehi, questo è quello che vogliamo in un piano di DR per l'IT, si adatta a ciò che il resto dell'Università sta facendo? Ci sono priorità di servizio ripristinate ti piacerebbe cambiare? " Abbiamo una buona idea di quale sia il resto del piano e ci aspettiamo che tutto vada bene.

Quello che sto cercando è una guida su come definire un piano di DR e quali domande dovrei pensare. Possiedi risorse, libri e formazione preferiti legati allo sviluppo del piano di DR?

Un'eccellente fonte di informazioni è il Disaster Recovery Journal ( informazioni ).

Le risorse della comunità disponibili includono l'attuale bozza del documento GAP (Generally Accepted Practices) , che fornisce un eccellente schema del processo e dei risultati che costituiscono un solido piano e processo di continuità aziendale. Sono disponibili anche diversi white paper che trattano vari argomenti di DR / BC.

Il processo sembra scoraggiante, ma se affrontato sistematicamente con una buona descrizione di dove vorresti finire (come il documento DRJ GAP), puoi assicurarti di ottimizzare il tempo investito e massimizzare il valore del prodotto finale.

Trovo che anche la loro pubblicazione trimestrale sia interessante e istruttiva ( iscriviti ).

Assicurati di avere un elenco di contatti di emergenza. alias un Richiamo Roster

Dovrebbe apparire come un albero e mostrare chi contatta chi. Alla fine di una filiale, l'ultima persona dovrebbe chiamare la prima e segnalare chiunque non sia stato contattato.

(Questo può essere coordinato tramite risorse umane e utilizzato per qualsiasi tipo di disastro)

Se aggiungiamo le nostre idee, potremmo creare un bel wiki da questo post una volta che tutti avranno aggiunto le proprie idee. Capisco che ci sono gruppi là fuori da seguire, ma alcuni di noi hanno priorità specifiche quando si tratta di recupero. Per iniziare, ecco il mio:

Assicurati di avere documentazione off-line / remota della tua rete

Con DR le cose fondamentali sono i tuoi RTO (Recovery Time Objectives) e RPO (Recovery Point Objectives), che si traducono approssimativamente in "quanto tempo è accettabile impiegare per recuperarlo e quanti dati possiamo permetterci di perdere". In un mondo ideale le risposte sarebbero "nessuna e nessuna", ma uno scenario di DR è una circostanza eccezionale. Questi dovrebbero davvero essere guidati dai tuoi clienti, ma dal momento che stai iniziando dal punto di vista IT puoi fare le ipotesi migliori, ma essere pronto a regolare su o giù come richiesto. Puntare il più vicino a "nessuno e nessuno" come puoi ragionevolmente ottenere è buono, ma dovrai essere in grado di riconoscere quando arriva il punto di rendimenti decrescenti.

Questi due fattori potrebbero essere diversi in diversi periodi dell'anno e diversi su sistemi diversi.

Mi piace l'approccio più completo; è allettante elencare gli eventi che possono portare a uno scenario di DR, ma questi appartengono più a un esercizio di ananisi / mitigazione del rischio. Con DR l'incidente è già avvenuto e i dettagli di ciò che è stato sono meno rilevanti (tranne forse per quanto riguarda la disponibilità delle strutture di DR). Se perdi un server devi recuperarlo, indipendentemente dal fatto che sia stato colpito da un fulmine, formattato accidentalmente o altro. È più probabile che un approccio incentrato sulla scala e sulla diffusione del disastro produca risultati.

Un approccio da utilizzare per i clienti, se ritieni che siano riluttanti a essere coinvolti, è quello di porre loro domande DR da un punto di vista non IT. Chiedere quali sono i loro piani se tutti i loro file cartacei vanno in fiamme è un esempio qui. Questo può aiutarti a coinvolgerli maggiormente nella più ampia questione DR e può fornire informazioni utili ai tuoi piani.

Infine, testare regolarmente il piano è fondamentale per il successo. Non va bene avere un bellissimo piano di DR che sembra fantastico sulla carta ma che non soddisfa i suoi obiettivi.

In realtà, il modello di sviluppo del "singolo incidente" è una buona idea, come primo passo. Uno dei motivi è che rende l'esercizio di pianificazione più realistico e mirato. Pianifica l'alluvione, fino in fondo. Supponi quindi un incidente diverso (per esempio un'interruzione di corrente a lungo termine), applica quel piano e correggi ciò che si rompe. Dopo alcune iterazioni, il piano dovrebbe essere relativamente solido.

Alcuni pensieri ... - assicurati di tenere conto delle persone non disponibili. In caso di alluvione, non si può presumere che tutto il personale rilevante sia disponibile. Qualcuno potrebbe essere in vacanza, o ferito, o avere a che fare con la propria famiglia.
- pianificare problemi di comunicazione e punti deboli. Hanno più numeri e più modalità.
- il piano DR richiede una catena di comando. Conoscere chi prende le decisioni è fondamentale.
- il piano deve essere ampiamente distribuito, anche fuori sede e fuori rete. Deve essere accessibile durante il disastro!

Dove lavoro, sono stato coinvolto nell'esecuzione di un test DR su larga scala in ciascuno degli ultimi due anni. Abbiamo scoperto che è stato utile testare i nostri servizi, persone e processi in situazioni "realistiche". Alcune lezioni apprese (forse ovvie), nella speranza che le trovi utili:

• I servizi non testati, nonostante ciò che hanno scritto nella loro documentazione DR, di solito hanno dipendenze implicite che inducono catastrofi. Scuotendoli con un test realistico o due è un risultato utile e misurabile di un processo di preparazione DR.
• Le persone non testate tendono a pensare che i loro sistemi stiano bene e "sapranno cosa fare" in una situazione di disastro. Li scuotendo up con un test realistico o due è grande.
• I processi non testati si rompono rapidamente nelle situazioni di emergenza reali. In particolare, i complessi processi di escalation si sono concentrati principalmente sull'informazione in modo spettacolare della rottura della direzione superiore. Processi leggeri focalizzati sulle esigenze del personale operativo e di altri soccorritori, fonti centrali di informazioni sull'emergenza in corso, trasferimento esplicito di responsabilità e procedure di risposta di emergenza "quotidiane" funzionano meglio.

Suppongo che dovrei cercare di non rendere teorico tutto ciò che riguarda il processo di pianificazione della DR. Chiedere l'autorizzazione per interrompere effettivamente le cose e quindi ottenere dati concreti sulla preparazione dell'organizzazione. Ciò richiederà un serio sostegno da parte della direzione, ovviamente, ma può essere meravigliosamente focalizzato sul fatto che l'azienda trascorra un paio di giorni a provare veramente il peggio.

Cian

Esistono diversi standard del British Standards Institute (BSi) incentrati sulla gestione della continuità e sul ripristino di emergenza.

• BS 25999-1: 2006 Gestione della continuità operativa, Parte 1: Codice di condotta
• BS 25999-2: 2007 Gestione della continuità operativa . specificazione
• BS 25777: 2008 Gestione della continuità della tecnologia dell'informazione e delle comunicazioni. Codice di pratica

Può sembrare ovvio, ma per andare con la documentazione offsite sopra, assicurati di avere backup offsite (preferibilmente fuori dalla regione). Questo potrebbe essere un servizio di archiviazione online o un luogo in cui prendere i nastri.

Dico preferibilmente fuori dalla regione perché vengo da un'area in cui non abbiamo molti disastri naturali ogni anno, ma, se / quando ne abbiamo uno, è su scala regionale con distruzione di massa (terremoti, vulcani). Va bene avere il tuo backup in una cassetta di sicurezza in banca, fino a quando la tua banca è sotto magma caldo liquido (/ Dr. Evil Voice).

Qualcosa di cui ho letto sono le agenzie che condividono i costi di gestione di un sito caldo per quando colpisce quello grosso. Esse mettono in atto piani per ripristinare la missione di entrambe le società critiche per il sito caldo utilizzando la virtualizzazione e simili, e quindi condividono il personale a livello di lampeggianti sicuri per tutte le luci. Solo un pensiero.

Per i libri c'è Disaster Recovery Planning di Jon William Toigo, giunto alla terza edizione, con un blook di quarta edizione (blog + libro) all'orizzonte.

Laura,

Ecco un link da SQLServerPedia che fornisce le basi del DR.

http://sqlserverpedia.com/blog/sql-server-backup-and-restore/disaster-recovery-basics-tutorial/

Leggi anche su "Business Continuity"