Encara que sigui una inundació, 1C hauria de funcionar! Estem d'acord amb el negoci en DR

Imagineu-vos: esteu donant servei a la infraestructura informàtica d'un gran centre comercial. Comença a ploure a la ciutat. Els corrents de pluja travessen el terrat, l'aigua omple els locals comercials fins als turmells. Esperem que la vostra sala de servidors no estigui al soterrani, en cas contrari no es poden evitar problemes.  

La història descrita no és una fantasia, sinó una descripció col·lectiva d'un parell d'esdeveniments del 2020. A les grans empreses, un pla de recuperació de desastres, o pla de recuperació de desastres (DRP), sempre està a mà per a aquest cas. A les corporacions, aquesta és responsabilitat dels especialistes en continuïtat de negoci. Però a les empreses mitjanes i petites, resoldre aquests problemes recau en els serveis informàtics. Heu d'entendre vosaltres mateixos la lògica de negoci, entendre què pot fallar i on, crear protecció i implementar-la. 

És fantàstic que un especialista en TI pugui negociar amb l'empresa i discutir la necessitat de protecció. Però he vist més d'una vegada com una empresa escatimava en una solució de recuperació de desastres (DR) perquè la considerava redundant. Quan es va produir un accident, una llarga recuperació amenaçava amb pèrdues i el negoci no estava preparat. Pots repetir tant com vulguis: "T'ho vaig dir", però el servei informàtic encara haurà de restaurar els serveis.

Des de la posició d'arquitecte, us diré com evitar aquesta situació. A la primera part de l'article, mostraré el treball preparatori: com discutir tres preguntes amb el client per triar les eines de seguretat: 

• Què estem protegint?
• De què estem protegint?
• Quant protegim? 

A la segona part, parlarem de les opcions per respondre a la pregunta: com defensar-se. Posaré exemples de casos de com diferents clients construeixen la seva protecció.

El que protegim: identificar les funcions crítiques del negoci 

És millor començar a preparar-se discutint el pla d'acció posterior a l'emergència amb el client empresarial. La principal dificultat aquí és trobar un llenguatge comú. Al client normalment no li importa com funciona la solució informàtica. Li importa si el servei pot realitzar funcions comercials i aportar diners. Per exemple: si el lloc funciona, però el sistema de pagament està caigut, no hi ha ingressos dels clients i els "extremistes" segueixen sent especialistes en informàtica. 

Un professional informàtic pot tenir dificultats en aquestes negociacions per diversos motius:

• El servei informàtic no entén completament el paper del sistema d'informació en els negocis. Per exemple, si no hi ha una descripció disponible dels processos de negoci o un model de negoci transparent. 
• No tot el procés depèn del servei informàtic. Per exemple, quan part del treball és realitzat per contractistes i els especialistes informàtics no tenen influència directa sobre ells.

Estructuraria la conversa així: 

1. Expliquem a les empreses que els accidents passen a tothom i que la recuperació requereix temps. El millor és demostrar situacions, com passa això i quines conseqüències són possibles.
2. Mostrem que no tot depèn del servei informàtic, però estàs disposat a ajudar amb un pla d'acció en la teva àrea de responsabilitat.
3. Demanem al client empresarial que respongui: si es produeix l'apocalipsi, quin procés s'ha de restaurar primer? Qui hi participa i com? 

   Es requereix una resposta senzilla de l'empresa, per exemple: el centre de trucades ha de continuar registrant les sol·licituds les 24 hores del dia.

4. Demanem a un o dos usuaris del sistema que descriguin aquest procés amb detall. 
   És millor implicar un analista per ajudar-lo si la vostra empresa en té.

   Per començar, la descripció pot semblar així: el centre de trucades rep les sol·licituds per telèfon, per correu i mitjançant missatges del lloc web. A continuació, els introdueix a 1C a través de la interfície web i la producció els porta d'allà d'aquesta manera.

5. A continuació, analitzem quines solucions de maquinari i programari admeten el procés. Per a una protecció integral, tenim en compte tres nivells: 
   • aplicacions i sistemes dins del lloc (nivell de programari),   
   • el mateix lloc on funcionen els sistemes (nivell d'infraestructura), 
   • xarxa (sovint se n'obliden).

6. Descobrim possibles punts de fallada: nodes del sistema dels quals depèn el rendiment del servei. Anotem per separat els nodes que són compatibles amb altres empreses: operadors de telecomunicacions, proveïdors d'allotjament, centres de dades, etc. Amb això, podeu tornar al client empresarial per al següent pas.

Del que protegim: riscos

A continuació, descobrim del client empresarial quins riscos ens protegim primer. Tots els riscos es poden dividir en dos grups: 

• pèrdua de temps per temps d'inactivitat del servei;
• pèrdua de dades per impactes físics, factors humans, etc.

Les empreses tenen por de perdre dades i temps; tot això comporta la pèrdua de diners. Així que tornem a fer preguntes per a cada grup de risc: 

• Per a aquest procés, podem estimar quant costa en diners la pèrdua de dades i la pèrdua de temps? 
• Quines dades no podem perdre? 
• On no podem permetre temps d'inactivitat? 
• Quins esdeveniments són més probables i més amenaçadors per a nosaltres?

Després de la discussió, entendrem com prioritzar els punts de fallada. 

Quant protegim: RPO i RTO 

Quan els punts crítics de fallada estan clars, calculem els indicadors RTO i RPO. 

Permeteu-me que us recordi això RTO (objectiu de temps de recuperació) — és el temps permès des del moment de l'accident fins que el servei es restabli completament. En llenguatge comercial, aquest és un temps d'inactivitat acceptable. Si sabem quants diners ha aportat el procés, podem calcular les pèrdues de cada minut d'inactivitat i calcular la pèrdua acceptable. 

RPO (objectiu del punt de recuperació) — punt de recuperació de dades vàlid. Determina el temps durant el qual podem perdre dades. Des del punt de vista empresarial, la pèrdua de dades pot comportar multes, per exemple. Aquestes pèrdues també es poden convertir en diners. 

Cal calcular el temps de recuperació per a l'usuari final: quant de temps podrà iniciar sessió al sistema. Així que primer sumem el temps de recuperació de tots els enllaços de la cadena. Sovint es comet un error aquí: prenen l'RTO del proveïdor del SLA i s'obliden dels termes restants.

Vegem un exemple concret. L'usuari inicia sessió a 1C, el sistema s'obre amb un error de base de dades. Es posa en contacte amb l'administrador del sistema. La base de dades es troba al núvol, l'administrador del sistema informa del problema al proveïdor de serveis. Suposem que totes les comunicacions triguen 15 minuts. Al núvol, una base de dades d'aquesta mida es restaurarà a partir d'una còpia de seguretat en una hora, per tant, el RTO al costat del proveïdor de serveis és d'una hora. Però aquest no és el termini definitiu; per a l'usuari, s'hi han afegit 15 minuts per detectar el problema. 
 
A continuació, l'administrador del sistema ha de comprovar que la base de dades és correcta, connectar-la a 1C i iniciar els serveis. Això requereix una hora més, el que significa que el RTO per part de l'administrador ja és de 2 hores i 15 minuts. L'usuari necessita 15 minuts més: inicieu sessió, comproveu que han aparegut les transaccions necessàries. 2 hores i 30 minuts és el temps total de recuperació del servei en aquest exemple.

Aquests càlculs mostraran a l'empresa de quins factors externs depèn el període de recuperació. Per exemple, si l'oficina està inundada, primer cal trobar la fuita i arreglar-la. Prendrà temps, que no depèn de TI.  

Com protegim: escollint eines per a diferents riscos

Després de discutir tots els punts, el client ja entén el cost d'un accident per al negoci. Ara podeu triar eines i discutir el pressupost. Utilitzant exemples de casos de clients, us mostraré quines eines oferim per a diferents tasques. 

Comencem pel primer grup de riscos: les pèrdues per temps d'inactivitat del servei. Les solucions per a aquest problema haurien de proporcionar un bon RTO.

1. Allotjament de l'aplicació al núvol 

   Per començar, simplement podeu passar al núvol: el proveïdor ja ha pensat en els problemes d'alta disponibilitat. Els amfitrions de virtualització s'agrupen en un clúster, es reserven l'alimentació i la xarxa, les dades s'emmagatzemen en sistemes d'emmagatzematge tolerants a errors i el proveïdor de serveis és responsable financerament del temps d'inactivitat.

   Per exemple, podeu allotjar una màquina virtual amb una base de dades al núvol. L'aplicació es connectarà a la base de dades externament mitjançant un canal establert o des del mateix núvol. Si sorgeixen problemes amb un dels servidors del clúster, la màquina virtual es reiniciarà al servidor veí en menys de 2 minuts. Després d'això, el SGBD s'iniciarà en ell i, en pocs minuts, la base de dades estarà disponible.

   OTR: mesura en minuts. Aquestes condicions es poden especificar en l'acord amb el proveïdor.
   Cost: calculem el cost dels recursos al núvol per a la vostra aplicació. 
   Del que no et protegirà: de fallades massives al lloc del proveïdor, per exemple, a causa d'accidents a nivell de ciutat.

2. Agrupeu l'aplicació  

   Si voleu millorar RTO, podeu reforçar l'opció anterior i col·locar immediatament una aplicació agrupada al núvol.

   Podeu implementar un clúster en mode actiu-passiu o actiu-actiu. Creem diverses màquines virtuals en funció dels requisits del venedor. Per a una major fiabilitat, els distribuïm en diferents servidors i sistemes d'emmagatzematge. Si el servidor amb una de les bases de dades falla, el node de còpia de seguretat es fa càrrec de la càrrega en pocs segons.

   OTR: Mesurat en segons.
   Cost: una mica més car que un núvol normal, es necessitaran recursos addicionals per agrupar-los.
   Del que no et protegirà: encara no protegirà contra fallades massives in situ. Però les interrupcions locals no duraran tant.

   Des de la pràctica: L'empresa minorista disposava de diversos sistemes d'informació i pàgines web. Totes les bases de dades estaven localitzades a l'oficina de l'empresa. No es va pensar en cap DR fins que l'oficina es va quedar sense electricitat diverses vegades seguides. Els clients no estaven satisfets amb els bloquejos del lloc web. 
    
   El problema amb la disponibilitat del servei es va resoldre després de passar al núvol. A més, hem aconseguit optimitzar la càrrega de les bases de dades equilibrant el trànsit entre nodes.

3. Passa a un núvol a prova de desastres

   Si us heu d'assegurar que fins i tot un desastre natural al lloc principal no interfereixi amb la vostra feina, podeu triar un núvol resistent a desastres. En aquesta opció, el proveïdor distribueix el clúster de virtualització en 2 centres de dades. Es produeix una replicació sincrònica constant entre centres de dades, un a un. Els canals entre els centres de dades estan reservats i van per diferents rutes, de manera que aquest clúster no té por dels problemes de xarxa. 

   OTR: tendeix a 0.
   Cost: L'opció de núvol més cara. 
   Del que no et protegirà: No ajudarà contra la corrupció de dades, així com pel factor humà, per la qual cosa es recomana fer còpies de seguretat al mateix temps. 

   Des de la pràctica: Un dels nostres clients va desenvolupar un pla integral de recuperació en cas de desastre. Aquesta és l'estratègia que va triar: 

   • Un núvol tolerant a desastres protegeix l'aplicació de fallades a nivell d'infraestructura. 
   • La còpia de seguretat de dos nivells proporciona protecció en cas d'error humà. Hi ha dos tipus de còpies de seguretat: "fred" i "calente". Una còpia de seguretat "freda" es troba en un estat desactivat i triga temps a desplegar-se. Una còpia de seguretat "calenta" ja està preparada per utilitzar-la i es restaura més ràpidament. S'emmagatzema en un sistema d'emmagatzematge especialment dedicat. La tercera còpia s'enregistra en cinta i s'emmagatzema en una altra habitació. 

   Un cop a la setmana, el client prova la protecció i comprova la funcionalitat de totes les còpies de seguretat, incloses les de la cinta. Cada any, l'empresa prova tot el núvol resistent a desastres. 

4. Organitzeu la replicació a un altre lloc 

   Una altra opció sobre com evitar problemes globals al lloc principal: proporcionar geo-reserva. En altres paraules, creeu màquines virtuals de còpia de seguretat en un lloc d'una altra ciutat. Les solucions especials per a la DR són adequades per a això: a la nostra empresa utilitzem VMware vCloud Availability (vCAV). Amb la seva ajuda, podeu configurar la protecció entre diversos llocs de proveïdors de núvol o restaurar-los al núvol des d'un lloc local. Ja he parlat amb més detall sobre l'esquema per treballar amb vCAV aquí. 

   RPO i RTO: a partir de 5 minuts. 

   Cost: més car que la primera opció, però més barata que la rèplica de maquinari en un núvol a prova de desastres. El preu consisteix en el cost d'una llicència vCAV, les taxes d'administració, el cost dels recursos al núvol i els recursos de reserva segons el model PAYG (10% del cost dels recursos de treball per a les VM apagades).

   Des de la pràctica: El client guardava 6 màquines virtuals amb diferents bases de dades al nostre núvol a Moscou. Al principi, la protecció es proporcionava mitjançant còpies de seguretat: algunes de les còpies de seguretat s'emmagatzemaven al núvol a Moscou i algunes es desaven al nostre lloc de Sant Petersburg. Amb el temps, les bases de dades van augmentar de mida i la restauració a partir d'una còpia de seguretat va començar a prendre més temps. 
    
   S'ha afegit a les còpies de seguretat la replicació basada en la disponibilitat de VMware vCloud. Les rèpliques de màquines virtuals s'emmagatzemen en un lloc de còpia de seguretat a Sant Petersburg i s'actualitzen cada 5 minuts. Si es produeix un error al lloc principal, els empleats canvien de manera independent a una rèplica de la màquina virtual a Sant Petersburg i continuen treballant-hi. 

Totes les solucions considerades proporcionen una alta disponibilitat, però no protegeixen contra la pèrdua de dades a causa d'un virus de ransomware o d'un error accidental de l'empleat. En aquest cas, necessitarem còpies de seguretat que proporcionin l'RPO requerit.

5. No us oblideu de la còpia de seguretat

Tothom sap que heu de fer còpies de seguretat, fins i tot si teniu la solució a prova de desastres més fantàstica. Així que només us recordaré breument alguns punts.

En sentit estricte, la còpia de seguretat no és DR. I per això: 

• Fa molt de temps. Si les dades es mesuren en terabytes, la recuperació trigarà més d'una hora. Heu de restaurar, assignar una xarxa, comprovar que s'encén, veure que les dades estan en ordre. Per tant, només podeu proporcionar un bon RTO si hi ha poques dades. 
• És possible que les dades no es puguin restaurar la primera vegada i haureu de donar temps per repetir l'acció. Per exemple, hi ha moments en què no sabem exactament quan es van perdre les dades. Diguem que la pèrdua es va notar a les 15.00 hores, i se'n fan còpies cada hora. A partir de les 15.00 mirem tots els punts de recuperació: 14, 00 i així successivament. Si el sistema és important, intentem minimitzar l'antiguitat del punt de recuperació. Però si la còpia de seguretat nova no contenia les dades necessàries, prenem el punt següent: aquest és un temps addicional. 

En aquest cas, el programa de còpia de seguretat pot proporcionar el necessari RPO. Per a les còpies de seguretat, és important proporcionar geo-reserva en cas de problemes amb el lloc principal. Es recomana emmagatzemar algunes còpies de seguretat per separat.

El pla final de recuperació en cas de desastre ha de contenir almenys dues eines:  

• Una de les opcions 1-4, que protegirà els sistemes de fallades i caigudes.
• Còpia de seguretat per protegir les dades de la pèrdua. 

També val la pena tenir cura d'un canal de comunicació de seguretat en cas que el proveïdor d'Internet principal cau. I - voilà! — El DR al salari mínim ja està llest. 

Font: www.habr.com