Chiar dacă este o inundație, 1C ar trebui să funcționeze! Suntem de acord cu afacerea despre DR

Imaginați-vă: deserviți infrastructura IT a unui centru comercial mare. Începe să plouă în oraș. Fluxuri de ploaie trec prin acoperiș, apa umple spațiile de vânzare cu amănuntul până la glezne. Sperăm că camera dvs. de server nu este la subsol, altfel problemele nu pot fi evitate.  

Povestea descrisă nu este o fantezie, ci o descriere colectivă a câtorva evenimente din 2020. În companiile mari, un plan de recuperare în caz de dezastru sau un plan de recuperare în caz de dezastru (DRP) este întotdeauna la îndemână pentru acest caz. În corporații, aceasta este responsabilitatea specialiștilor în continuitatea afacerii. Dar în companiile mijlocii și mici, rezolvarea unor astfel de probleme revine serviciilor IT. Trebuie să înțelegeți singur logica afacerii, să înțelegeți ce poate eșua și unde, să veniți cu protecție și să o implementați. 

Este grozav dacă un specialist IT poate negocia cu afacerea și discuta despre necesitatea protecției. Dar am văzut de mai multe ori cum o companie a zgârcit cu o soluție de recuperare în caz de dezastru (DR) pentru că o considera redundantă. Când a avut loc un accident, o recuperare îndelungată amenința cu pierderi, iar afacerea nu era pregătită. Puteți repeta cât de mult doriți: „Ți-am spus”, dar serviciul IT va trebui totuși să restabilească serviciile.

Din postura de arhitect, vă voi spune cum să evitați această situație. În prima parte a articolului, voi arăta lucrările pregătitoare: cum să discutați trei întrebări cu clientul pentru alegerea instrumentelor de securitate: 

• Ce protejam?
• De ce ne protejam?
• Cât de mult protejăm? 

În a doua parte, vom vorbi despre opțiuni pentru a răspunde la întrebarea: cum să te aperi. Voi da exemple de cazuri în care diferiți clienți își construiesc protecția.

Ce protejăm: identificarea funcțiilor critice de afaceri 

Este mai bine să începeți pregătirea discutând planul de acțiune post-urgență cu clientul de afaceri. Principala dificultate aici este găsirea unui limbaj comun. Clientului, de obicei, nu îi pasă cum funcționează soluția IT. Îi pasă dacă serviciul poate îndeplini funcții de afaceri și poate aduce bani. De exemplu: dacă site-ul funcționează, dar sistemul de plată este în funcțiune, nu există venituri de la clienți, iar „extremiștii” sunt încă specialiști IT. 

Un profesionist IT poate avea dificultăți în astfel de negocieri din mai multe motive:

• Serviciul IT nu înțelege pe deplin rolul sistemului informațional în afaceri. De exemplu, dacă nu există o descriere disponibilă a proceselor de afaceri sau un model de afaceri transparent. 
• Nu întregul proces depinde de serviciul IT. De exemplu, atunci când o parte a lucrării este efectuată de antreprenori, iar specialiștii IT nu au influență directă asupra acestora.

Aș structura conversația astfel: 

1. Le explicăm companiilor că accidentele se întâmplă tuturor, iar recuperarea necesită timp. Cel mai bun lucru este să demonstrezi situațiile, cum se întâmplă acest lucru și ce consecințe sunt posibile.
2. Arătăm că nu totul depinde de serviciul IT, dar ești gata să ajuți cu un plan de acțiune în zona ta de responsabilitate.
3. Cerem clientului de afaceri să răspundă: dacă se întâmplă apocalipsa, care proces ar trebui restabilit mai întâi? Cine participă și cum? 

   Este necesar un răspuns simplu din partea companiei, de exemplu: call center-ul trebuie să continue înregistrarea aplicațiilor 24/7.

4. Solicităm unuia sau doi utilizatori ai sistemului să descrie acest proces în detaliu. 
   Este mai bine să implicați un analist care să vă ajute dacă compania dvs. are unul.

   Pentru început, descrierea poate arăta astfel: call center-ul primește cereri prin telefon, prin poștă și prin mesaje de pe site. Apoi le introduce în 1C prin interfața web și de acolo producția le preia în acest fel.

5. Apoi ne uităm la ce soluții hardware și software sprijină procesul. Pentru o protecție completă, luăm în considerare trei niveluri: 
   • aplicații și sisteme din cadrul site-ului (nivel de software),   
   • site-ul însuși unde rulează sistemele (nivel de infrastructură), 
   • rețea (deseori uită de ea).

6. Aflam posibile puncte de defectare: noduri de sistem de care depinde performanta serviciului. Notăm separat noduri care sunt acceptate de alte companii: operatori de telecomunicații, furnizori de găzduire, centre de date și așa mai departe. Cu aceasta, vă puteți întoarce la clientul de afaceri pentru următorul pas.

De ce protejăm: riscuri

În continuare, aflăm de la clientul business de ce riscuri ne protejăm mai întâi. Toate riscurile pot fi împărțite în două grupe: 

• pierdere de timp din cauza timpului de întrerupere a serviciului;
• pierderea datelor din cauza impactului fizic, a factorilor umani etc.

Întreprinderilor le este frică să nu piardă atât date, cât și timp - toate acestea duc la pierderi de bani. Deci, din nou, punem întrebări pentru fiecare grup de risc: 

• Pentru acest proces, putem estima cât costă în bani pierderea de date și pierderea de timp? 
• Ce date nu putem pierde? 
• Unde nu putem permite timpi de nefuncționare? 
• Ce evenimente sunt cele mai probabile și cele mai amenințătoare pentru noi?

După discuție, vom înțelege cum să acordăm prioritate punctelor de eșec. 

Cât de mult protejăm: RPO și RTO 

Când punctele critice de eșec sunt clare, calculăm indicatorii RTO și RPO. 

Permiteți-mi să vă reamintesc asta RTO (obiectiv de timp de recuperare) — acesta este timpul permis din momentul accidentului până la restabilirea completă a serviciului. În limbajul de afaceri, acesta este un timp de nefuncționare acceptabil. Dacă știm câți bani a adus procesul, putem calcula pierderile din fiecare minut de oprire și putem calcula pierderea acceptabilă. 

RPO (obiectiv punct de recuperare) — punct valid de recuperare a datelor. Acesta determină timpul în care putem pierde date. Din punct de vedere al afacerii, pierderea datelor poate duce la amenzi, de exemplu. Astfel de pierderi pot fi, de asemenea, convertite în bani. 

Timpul de recuperare trebuie calculat pentru utilizatorul final: cât timp se va putea conecta în sistem. Așadar, mai întâi adunăm timpul de recuperare al tuturor verigilor din lanț. Aici se face adesea o greșeală: preiau RTO al furnizorului din SLA și uită de termenii rămași.

Să ne uităm la un exemplu concret. Utilizatorul se conectează la 1C, sistemul se deschide cu o eroare a bazei de date. El contactează administratorul de sistem. Baza de date este localizată în cloud, administratorul de sistem raportează problema furnizorului de servicii. Să presupunem că toate comunicările durează 15 minute. În cloud, o bază de date de această dimensiune va fi restaurată dintr-o copie de rezervă într-o oră, prin urmare, RTO din partea furnizorului de servicii este de o oră. Dar acesta nu este termenul limită final pentru utilizator, i s-au adăugat 15 minute pentru a detecta problema. 
 
Apoi, administratorul de sistem trebuie să verifice dacă baza de date este corectă, să o conecteze la 1C și să pornească serviciile. Acest lucru necesită încă o oră, ceea ce înseamnă că RTO din partea administratorului este deja de 2 ore și 15 minute. Utilizatorul are nevoie de încă 15 minute: conectați-vă, verificați dacă au apărut tranzacțiile necesare. 2 ore și 30 de minute este timpul total de recuperare a serviciului din acest exemplu.

Aceste calcule vor arăta afacerii de ce factori externi depinde perioada de recuperare. De exemplu, dacă biroul este inundat, mai întâi trebuie să găsiți scurgerea și să o remediați. Va dura timp, care nu depinde de IT.  

Cum ne protejăm: alegerea instrumentelor pentru diferite riscuri

După ce a discutat toate punctele, clientul înțelege deja costul unui accident pentru afacere. Acum puteți alege instrumentele și puteți discuta despre buget. Folosind exemple de cazuri de clienți, vă voi arăta ce instrumente oferim pentru diferite sarcini. 

Să începem cu primul grup de riscuri: pierderi datorate timpului de întrerupere a serviciului. Soluțiile pentru această problemă ar trebui să ofere un RTO bun.

1. Găzduiește aplicația în cloud 

   Pentru început, puteți trece pur și simplu în cloud - furnizorul s-a gândit deja la problemele de înaltă disponibilitate. Gazdele de virtualizare sunt asamblate într-un cluster, puterea și rețeaua sunt rezervate, datele sunt stocate pe sisteme de stocare tolerante la erori, iar furnizorul de servicii este responsabil financiar pentru timpul de nefuncționare.

   De exemplu, puteți găzdui o mașină virtuală cu o bază de date în cloud. Aplicația se va conecta la baza de date extern printr-un canal stabilit sau din același cloud. Dacă apar probleme cu unul dintre serverele din cluster, VM-ul va reporni pe serverul vecin în mai puțin de 2 minute. După aceea, DBMS-ul va porni în el și în câteva minute baza de date va deveni disponibilă.

   RTO: măsurat în minute. Acești termeni pot fi specificati în contractul cu furnizorul.
   Costa: calculăm costul resurselor cloud pentru aplicația dvs. 
   De ce nu te va proteja: de la defecțiuni masive la sediul furnizorului, de exemplu, din cauza accidentelor la nivel de oraș.

2. Grupați aplicația  

   Dacă doriți să îmbunătățiți RTO, puteți consolida opțiunea anterioară și puteți plasa imediat o aplicație în cluster în cloud.

   Puteți implementa un cluster în modul activ-pasiv sau activ-activ. Creăm mai multe VM-uri pe baza cerințelor furnizorului. Pentru o mai mare fiabilitate, le distribuim pe diferite servere și sisteme de stocare. Dacă serverul cu una dintre bazele de date eșuează, nodul de rezervă preia încărcarea în câteva secunde.

   RTO: Măsurat în secunde.
   Costa: puțin mai scump decât un cloud obișnuit, vor fi necesare resurse suplimentare pentru clustering.
   De ce nu te va proteja: Încă nu va proteja împotriva defecțiunilor masive la fața locului. Dar perturbările locale nu vor dura atât de mult.

   Din practică: Compania de retail avea mai multe sisteme informatice si site-uri web. Toate bazele de date au fost localizate local în biroul companiei. Nu s-a gândit la nici un DR până când biroul a rămas fără curent de mai multe ori la rând. Clienții au fost nemulțumiți de blocările site-ului. 
    
   Problema cu disponibilitatea serviciului a fost rezolvată după mutarea în cloud. În plus, am reușit să optimizăm încărcarea bazelor de date prin echilibrarea traficului dintre noduri.

3. Treceți la un nor rezistent la dezastre

   Dacă trebuie să vă asigurați că nici măcar un dezastru natural pe site-ul principal nu interferează cu munca dvs., puteți alege un cloud rezistent la dezastre. În această opțiune, furnizorul distribuie clusterul de virtualizare în 2 centre de date. Replicarea sincronă constantă are loc între centrele de date, unu-la-unu. Canalele dintre centrele de date sunt rezervate și merg pe rute diferite, astfel încât un astfel de cluster nu se teme de problemele de rețea. 

   RTO: tinde spre 0.
   Costa: Cea mai scumpă opțiune de cloud. 
   De ce nu te va proteja: Nu va ajuta împotriva coruperii datelor, precum și a factorului uman, așa că este recomandat să faceți copii de siguranță în același timp. 

   Din practică: Unul dintre clienții noștri a dezvoltat un plan cuprinzător de recuperare în caz de dezastru. Aceasta este strategia pe care a ales-o: 

   • Un cloud tolerant la dezastre protejează aplicația de eșecuri la nivel de infrastructură. 
   • Backup-ul pe două niveluri oferă protecție în caz de eroare umană. Există două tipuri de backup: „rece” și „fierbinte”. O copie de rezervă „rece” este într-o stare dezactivată și necesită timp pentru a fi implementată. O copie de rezervă „fierbintă” este deja gata de utilizare și este restaurată mai rapid. Este stocat pe un sistem de stocare special dedicat. A treia copie este înregistrată pe bandă și stocată într-o altă cameră. 

   O dată pe săptămână, clientul testează protecția și verifică funcționalitatea tuturor copiilor de rezervă, inclusiv a celor de pe bandă. În fiecare an, compania testează întregul cloud rezistent la dezastre. 

4. Organizați replicarea pe alt site 

   O altă opțiune despre cum să evitați problemele globale pe site-ul principal: furnizați geo-rezervare. Cu alte cuvinte, creați mașini virtuale de rezervă la un site din alt oraș. Soluțiile speciale pentru DR sunt potrivite pentru asta: în compania noastră folosim VMware vCloud Availability (vCAV). Cu ajutorul acestuia, puteți configura protecția între mai multe site-uri furnizori de cloud sau puteți restabili în cloud de pe un site local. Am vorbit deja mai detaliat despre schema de lucru cu vCAV aici. 

   RPO și RTO: de la 5 minute. 

   Costa: mai scump decât prima opțiune, dar mai ieftin decât replicarea hardware într-un nor rezistent la dezastre. Prețul constă în costul unei licențe vCAV, taxe de administrare, costul resurselor cloud și al resurselor de rezervă conform modelului PAYG (10% din costul resurselor de lucru pentru VM-urile oprite).

   Din practică: Clientul a păstrat 6 mașini virtuale cu baze de date diferite în cloud-ul nostru din Moscova. La început, protecția a fost asigurată prin backup: unele dintre copiile de rezervă au fost stocate în cloud la Moscova, iar unele au fost stocate pe site-ul nostru din Sankt Petersburg. De-a lungul timpului, bazele de date au crescut în dimensiune, iar restaurarea dintr-o copie de rezervă a început să dureze mai mult timp. 
    
   Replicarea bazată pe VMware vCloud Availability a fost adăugată la copiile de rezervă. Replicile mașinilor virtuale sunt stocate pe un site de rezervă din Sankt Petersburg și sunt actualizate la fiecare 5 minute. Dacă apare o defecțiune la site-ul principal, angajații trec în mod independent la o replică a mașinii virtuale din Sankt Petersburg și continuă să lucreze cu aceasta. 

Toate soluțiile luate în considerare oferă o disponibilitate ridicată, dar nu protejează împotriva pierderii de date din cauza unui virus ransomware sau a unei erori accidentale a angajatului. În acest caz, vom avea nevoie de copii de rezervă care vor furniza RPO-ul necesar.

5. Nu uitați de backup

Toată lumea știe că trebuie să faci copii de rezervă, chiar dacă ai cea mai bună soluție rezistentă la dezastre. Așa că vă voi aminti pe scurt câteva puncte.

Strict vorbind, backup-ul nu este DR. Si de aceea: 

• E mult timp. Dacă datele sunt măsurate în terabytes, recuperarea va dura mai mult de o oră. Trebuie să restaurați, să atribuiți o rețea, să verificați dacă se pornește, să verificați dacă datele sunt în ordine. Deci, este posibil să oferiți un RTO bun numai dacă există puține date. 
• Este posibil ca datele să nu fie restaurate prima dată și trebuie să acordați timp pentru repetarea acțiunii. De exemplu, există momente în care nu știm exact când s-au pierdut datele. Să zicem că pierderea a fost observată la ora 15.00, iar copiile se fac din oră. De la ora 15.00 ne uităm la toate punctele de recuperare: 14:00, 13:00 și așa mai departe. Dacă sistemul este important, încercăm să minimizăm vechimea punctului de recuperare. Dar dacă copia de rezervă proaspătă nu conține datele necesare, luăm următorul punct - acesta este un timp suplimentar. 

În acest caz, programul de rezervă poate oferi ceea ce este necesar RPO. Pentru copii de rezervă, este important să oferiți geo-rezervare în cazul unor probleme cu site-ul principal. Se recomandă să stocați separat câteva copii de rezervă.

Planul final de recuperare în caz de dezastru ar trebui să conțină cel puțin 2 instrumente:  

• Una dintre opțiunile 1-4, care va proteja sistemele de defecțiuni și căderi.
• Backup pentru a proteja datele de pierdere. 

De asemenea, merită să aveți grijă de un canal de comunicare de rezervă în cazul în care furnizorul principal de internet scade. Și - voila! — DR la salariul minim este deja gata. 

Sursa: www.habr.com