Lascia che almeno un diluvio, ma 1C dovrebbe funzionare! Negoziare con le imprese su DR

Immagina: stai servendo l'infrastruttura IT di un grande centro commerciale. Comincia a piovere in città. Ruscelli di pioggia sfondano il tetto, l'acqua riempie i negozi fino alle caviglie. Ci auguriamo che la tua sala server non sia nel seminterrato, altrimenti i problemi non possono essere evitati.  

La storia descritta non è una fantasia, ma una descrizione collettiva di un paio di eventi del 2020. Nelle grandi aziende, per questo caso è sempre a portata di mano un piano di disaster recovery, o piano di disaster recovery (DRP). Nelle aziende, questa è responsabilità degli specialisti della continuità aziendale. Ma nelle aziende medie e piccole, la risoluzione di tali problemi ricade sui servizi IT. Devi comprendere tu stesso la logica aziendale, capire cosa può fallire e dove, elaborare una protezione e implementarla. 

Sarebbe fantastico se uno specialista IT potesse negoziare con l'azienda e discutere la necessità di protezione. Ma ho visto più di una volta come un'azienda abbia lesinato sulla soluzione di disaster recovery (DR) perché la considerava ridondante. Quando si verificò un incidente, un lungo recupero minacciò di perdite e l'attività non era pronta. Puoi ripetere quanto vuoi: "Te l'avevo detto", ma il servizio IT dovrà comunque ripristinare i servizi.

Dalla posizione di un architetto, ti dirò come evitare questa situazione. Nella prima parte dell'articolo mostrerò il lavoro preparatorio: come discutere con il cliente tre domande per la scelta degli strumenti di sicurezza: 

• Cosa stiamo proteggendo?
• Da cosa ci stiamo proteggendo?
• Quanto proteggiamo? 

Nella seconda parte parleremo delle opzioni per rispondere alla domanda: come difendersi. Fornirò esempi di casi di come diversi clienti costruiscono la loro protezione.

Cosa proteggiamo: identificare le funzioni aziendali critiche 

È meglio iniziare i preparativi discutendo il piano d'azione post-emergenza con il cliente aziendale. La difficoltà principale qui è trovare un linguaggio comune. Al cliente di solito non interessa come funziona la soluzione IT. Gli interessa se il servizio può svolgere funzioni aziendali e portare denaro. Ad esempio: se il sito funziona, ma il sistema di pagamento non funziona, non ci sono entrate dai clienti e gli “estremisti” sono ancora specialisti IT. 

Un professionista IT può avere difficoltà in tali negoziazioni per diversi motivi:

• Il servizio IT non comprende appieno il ruolo del sistema informativo nel mondo degli affari. Ad esempio, se non è disponibile una descrizione dei processi aziendali o un modello aziendale trasparente. 
• Non l'intero processo dipende dal servizio IT. Ad esempio, quando parte del lavoro viene eseguita da appaltatori e gli specialisti IT non hanno un'influenza diretta su di essi.

Strutturerei la conversazione in questo modo: 

1. Spieghiamo alle imprese che gli incidenti capitano a tutti e che il recupero richiede tempo. La cosa migliore è dimostrare le situazioni, come ciò accade e quali conseguenze sono possibili.
2. Dimostriamo che non tutto dipende dal servizio IT, ma sei pronto ad aiutare con un piano d'azione nella tua area di responsabilità.
3. Chiediamo all'azienda cliente di rispondere: se dovesse accadere l'apocalisse, quale processo dovrebbe essere ripristinato per primo? Chi vi partecipa e come? 

   L'azienda richiede ad esempio una risposta semplice: il call center deve continuare a registrare le richieste 24 ore su 7, XNUMX giorni su XNUMX.

4. Chiediamo a uno o due utenti del sistema di descrivere questo processo in dettaglio. 
   È meglio coinvolgere un analista per aiutarti se la tua azienda ne ha uno.

   Per cominciare, la descrizione potrebbe essere questa: il call center riceve richieste per telefono, per posta e tramite messaggi dal sito. Poi li inserisce in 1C tramite l'interfaccia web e la produzione li preleva da lì in questo modo.

5. Quindi esaminiamo quali soluzioni hardware e software supportano il processo. Per una protezione completa, prendiamo in considerazione tre livelli: 
   • applicazioni e sistemi all'interno del sito (livello software),   
   • il sito stesso in cui vengono eseguiti i sistemi (livello di infrastruttura), 
   • rete (spesso se ne dimenticano).

6. Scopriamo i possibili punti di guasto: nodi del sistema da cui dipende la prestazione del servizio. Notiamo separatamente i nodi supportati da altre società: operatori di telecomunicazioni, provider di hosting, data center e così via. In questo modo potrete tornare al cliente commerciale per il passaggio successivo.

Da cosa ci proteggiamo: i rischi

Successivamente, scopriamo dal cliente commerciale da quali rischi ci proteggiamo per primi. Tutti i rischi possono essere suddivisi in due gruppi: 

• perdita di tempo dovuta a interruzione del servizio;
• perdita di dati dovuta a impatti fisici, fattori umani, ecc.

Le aziende hanno paura di perdere dati e tempo: tutto ciò porta a una perdita di denaro. Quindi, ancora una volta, poniamo domande per ciascun gruppo a rischio: 

• Per questo processo, possiamo stimare quanto costa in denaro la perdita di dati e di tempo? 
• Quali dati non possiamo perdere? 
• Dove non possiamo consentire tempi di inattività? 
• Quali eventi sono più probabili e più minacciosi per noi?

Dopo la discussione, capiremo come dare priorità ai punti di guasto. 

Quanto proteggiamo: RPO e RTO 

Quando i punti critici di guasto sono chiari, calcoliamo gli indicatori RTO e RPO. 

Ricordo che RTO (obiettivo tempo di recupero) — questo è il tempo consentito dal momento dell'incidente fino al completo ripristino del servizio. Nel linguaggio degli affari, questo è un tempo di inattività accettabile. Se sappiamo quanti soldi ha portato il processo, possiamo calcolare le perdite per ogni minuto di inattività e calcolare la perdita accettabile. 

RPO (obiettivo del punto di ripristino) — punto di ripristino dati valido. Determina il tempo durante il quale possiamo perdere dati. Dal punto di vista aziendale, la perdita di dati può comportare, ad esempio, sanzioni pecuniarie. Tali perdite possono anche essere convertite in denaro. 

Il tempo di recupero deve essere calcolato per l'utente finale: per quanto tempo potrà accedere al sistema. Quindi per prima cosa sommiamo il tempo di recupero di tutti gli anelli della catena. Spesso si commette un errore: prendono l’RTO del fornitore dallo SLA e dimenticano i termini rimanenti.

Diamo un'occhiata a un esempio specifico. L'utente accede a 1C, il sistema si apre con un errore del database. Contatta l'amministratore di sistema. Il database si trova nel cloud, l'amministratore di sistema segnala il problema al fornitore di servizi. Diciamo che tutte le comunicazioni richiedono 15 minuti. Nel cloud, un database di queste dimensioni verrà ripristinato da un backup in un'ora, pertanto l'RTO dal lato del fornitore di servizi è di un'ora. Ma questa non è la scadenza finale; per l'utente sono stati aggiunti 15 minuti per rilevare il problema. 
 
Successivamente, l'amministratore di sistema deve verificare che il database sia corretto, collegarlo a 1C e avviare i servizi. Ciò richiede un’altra ora, il che significa che l’RTO da parte dell’amministratore è già di 2 ore e 15 minuti. L'utente ha bisogno di altri 15 minuti: effettua il login, controlla che siano apparse le transazioni necessarie. In questo esempio, 2 ore e 30 minuti è il tempo totale di ripristino del servizio.

Questi calcoli mostreranno all'azienda da quali fattori esterni dipende il periodo di recupero. Ad esempio, se l'ufficio è allagato, è necessario prima individuare la perdita e ripararla. Ci vorrà del tempo, che non dipende dall'IT.  

Come proteggiamo: scegliere gli strumenti per i diversi rischi

Dopo aver discusso tutti i punti, il cliente comprende già il costo di un incidente per l'azienda. Ora puoi scegliere gli strumenti e discutere il budget. Utilizzando esempi di casi di clienti, ti mostrerò quali strumenti offriamo per le diverse attività. 

Cominciamo con il primo gruppo di rischi: perdite dovute ai tempi di inattività del servizio. Le soluzioni a questo problema dovrebbero fornire un buon RTO.

1. Ospita l'applicazione nel cloud 

   Per cominciare, puoi semplicemente passare al cloud: il provider ha già pensato ai problemi dell'alta disponibilità. Gli host di virtualizzazione sono assemblati in un cluster, l'alimentazione e la rete sono riservate, i dati vengono archiviati su sistemi di storage con tolleranza agli errori e il fornitore di servizi è finanziariamente responsabile dei tempi di inattività.

   Ad esempio, puoi ospitare una macchina virtuale con un database nel cloud. L'applicazione si collegherà al database esternamente tramite un canale stabilito o dallo stesso cloud. Se si verificano problemi con uno dei server del cluster, la VM si riavvierà sul server vicino in meno di 2 minuti. Successivamente, il DBMS verrà avviato e in pochi minuti il ​​database sarà disponibile.

   RTO: misurato in minuti. Questi termini possono essere specificati nel contratto con il fornitore.
   costo: Calcoliamo il costo delle risorse cloud per la tua applicazione. 
   Da cosa non ti proteggerà: da massicci guasti presso la sede del fornitore, ad esempio, a causa di incidenti a livello cittadino.

2. Raggruppare l'applicazione  

   Se desideri migliorare l'RTO, puoi rafforzare l'opzione precedente e posizionare immediatamente un'applicazione in cluster nel cloud.

   È possibile implementare un cluster in modalità attivo-passivo o attivo-attivo. Creiamo diverse VM in base ai requisiti del fornitore. Per una maggiore affidabilità, li distribuiamo su diversi server e sistemi di archiviazione. Se il server con uno dei database si guasta, il nodo di backup si assume il carico in pochi secondi.

   RTO: Misurato in secondi.
   costo: leggermente più costoso di un normale cloud, saranno necessarie risorse aggiuntive per il clustering.
   Da cosa non ti proteggerà: Non protegge ancora da massicci guasti in loco. Ma le interruzioni locali non dureranno così a lungo.

   Dalla pratica: L'azienda di vendita al dettaglio disponeva di diversi sistemi informativi e siti Web. Tutti i database erano ubicati localmente negli uffici dell'azienda. Non si è pensato a nessun DR finché l'ufficio non è rimasto senza elettricità più volte di seguito. I clienti non erano soddisfatti dei crash del sito web. 
    
   Il problema con la disponibilità del servizio è stato risolto dopo il passaggio al cloud. Inoltre, siamo riusciti a ottimizzare il carico sui database bilanciando il traffico tra i nodi.

3. Passa a un cloud a prova di disastro

   Se vuoi assicurarti che anche un disastro naturale sulla sede principale non interferisca con il tuo lavoro, puoi scegliere un cloud resistente ai disastri: in questa opzione, il provider distribuisce il cluster di virtualizzazione su 2 data center. La replica sincrona costante avviene tra data center, uno a uno. I canali tra i data center sono riservati e seguono percorsi diversi, quindi un tale cluster non ha paura dei problemi di rete. 

   RTO: tende a 0.
   costo: L'opzione cloud più costosa. 
   Da cosa non ti proteggerà: Non aiuta contro la corruzione dei dati, così come dal fattore umano, quindi si consiglia di eseguire contemporaneamente i backup. 

   Dalla pratica: Uno dei nostri clienti ha sviluppato un piano completo di ripristino di emergenza. Questa è la strategia che ha scelto: 

   • Un cloud resistente ai disastri protegge l'applicazione dai guasti a livello di infrastruttura. 
   • Il backup a due livelli fornisce protezione in caso di errore umano. Esistono due tipi di backup: “a freddo” e “a caldo”. Un backup "a freddo" è in uno stato disabilitato e richiede tempo per essere distribuito. Un backup “a caldo” è già pronto per l'uso e viene ripristinato più velocemente. Viene archiviato su un sistema di archiviazione appositamente dedicato. La terza copia viene registrata su nastro e conservata in un'altra stanza. 

   Una volta alla settimana il client testa la protezione e controlla la funzionalità di tutti i backup, compresi quelli su nastro. Ogni anno l'azienda testa l'intero cloud resistente ai disastri. 

4. Organizzare la replica su un altro sito 

   Un'altra opzione su come evitare problemi globali sul sito principale: fornire la geo-prenotazione. In altre parole, crea macchine virtuali di backup in un sito in un'altra città. A questo scopo sono adatte soluzioni speciali per il DR: nella nostra azienda utilizziamo VMware vCloud Availability (vCAV). Con il suo aiuto, puoi configurare la protezione tra diversi siti di provider cloud o ripristinare nel cloud da un sito locale. Ho già parlato più in dettaglio dello schema per lavorare con vCAV qui. 

   RPO e RTO: da 5 minuti. 

   costo: più costosa della prima opzione, ma più economica della replica hardware in un cloud a prova di disastro. Il prezzo è composto dal costo della licenza vCAV, dalle spese amministrative, dal costo delle risorse cloud e dalle risorse di riserva secondo il modello PAYG (10% del costo delle risorse di lavoro per le VM spente).

   Dalla pratica: Il cliente ha mantenuto 6 macchine virtuali con diversi database nel nostro cloud a Mosca. Inizialmente, la protezione è stata fornita dal backup: alcune copie di backup sono state archiviate nel cloud a Mosca, altre nella nostra sede di San Pietroburgo. Nel corso del tempo, le dimensioni dei database sono aumentate e il ripristino da un backup ha iniziato a richiedere più tempo. 
    
   Ai backup è stata aggiunta la replica basata sulla disponibilità di VMware vCloud. Le repliche delle macchine virtuali sono archiviate in un sito di backup a San Pietroburgo e vengono aggiornate ogni 5 minuti. Se si verifica un guasto nella sede principale, i dipendenti passano autonomamente a una replica della macchina virtuale a San Pietroburgo e continuano a lavorarci. 

Tutte le soluzioni considerate garantiscono un'elevata disponibilità, ma non proteggono dalla perdita di dati dovuta a un virus ransomware o a un errore accidentale del dipendente. In questo caso, avremo bisogno di backup che forniscano l'RPO richiesto.

5. Non dimenticare il backup

Tutti sanno che è necessario eseguire i backup, anche se si dispone della soluzione più interessante a prova di disastro. Quindi mi limiterò a ricordarvi brevemente alcuni punti.

A rigor di termini, il backup non è DR. Ed ecco perché: 

• È tanto tempo. Se i dati vengono misurati in terabyte, il ripristino richiederà più di un'ora. È necessario ripristinare, assegnare una rete, verificare che si accenda, vedere che i dati siano in ordine. Quindi puoi fornire un buon RTO solo se i dati sono pochi. 
• I dati potrebbero non essere ripristinati la prima volta ed è necessario attendere il tempo per ripetere l'azione. Ad esempio, ci sono momenti in cui non sappiamo esattamente quando sono andati persi i dati. Diciamo che la perdita è stata notata alle 15.00 e le copie vengono effettuate ogni ora. Dalle 15.00 esaminiamo tutti i punti di ripristino: 14:00, 13:00 e così via. Se il sistema è importante, proviamo a ridurre al minimo l'età del punto di ripristino. Ma se il nuovo backup non contiene i dati necessari, passiamo al punto successivo: si tratta di tempo aggiuntivo. 

In questo caso, la pianificazione del backup può fornire quanto richiesto RPO. Per i backup è importante fornire la geo-prenotazione in caso di problemi con il sito principale. Si consiglia di archiviare separatamente alcune copie di backup.

Il piano di disaster recovery finale dovrebbe contenere almeno 2 strumenti:  

• Una delle opzioni 1-4, che proteggerà i sistemi da guasti e cadute.
• Backup per proteggere i dati dalla perdita. 

Vale anche la pena prendersi cura di un canale di comunicazione di riserva nel caso in cui il principale provider Internet non funzioni. E - voilà! — Il DR con salario minimo è già pronto. 

Fonte: habr.com