Disaster recovery, backupuri, RTO/RPO, failover și, mai presus de toate, întrebarea pe care multe companii și-o pun abia după o avarie: putem cu adevărat să restaurăm sistemul și să revenim la lucru?
Defecțiunea serverului. Bază de date deteriorată. Eroare după implementare. Ransomware. Probleme cu furnizorul de infrastructură. Ștergere accidentală de date. Defecțiunea întregii regiuni.
Scenariile sunt numeroase. Problema este că majoritatea companiilor se pregătesc în primul rând pentru ca avaria să nu aibă loc.
Și mult mai rar se pregătesc pentru situația în care totuși are loc.
Acesta este exact domeniul disaster recovery.
Și aici apare întrebarea de bază: dacă aplicația ta încetează să funcționeze astăzi la 14:00, cât timp îți trebuie ca să o repornești și câte date poți pierde în acest proces?
Dacă răspunsul este „avem backup”, atunci încă nu este răspunsul la această întrebare.
Backupul nu este disaster recovery
Backupul este o copie a datelor. Disaster recovery este procesul de refacere a funcționării sistemului.
Aceasta este o distincție foarte importantă.
Poți avea copii ale bazei de date realizate zilnic și totuși să nu știi:
-
dacă ultima copie este corectă,
-
dacă poate fi restaurată,
-
cât va dura restaurarea,
-
dacă după restaurare baza de date va coopera cu versiunea actuală a aplicației,
-
dacă vei restaura și configurația sistemului,
-
dacă ai toate cheile, certificatele și secretele necesare pentru a porni mediul,
-
dacă infrastructura necesară pentru pornirea aplicației mai este disponibilă,
-
cine trebuie să execute pașii individuali,
-
dacă întregul proces se încadrează în timpul acceptabil pentru business.
NIST indică în mod direct necesitatea testării restaurării copiilor, iar ghidurile actuale AWS tratează, de asemenea, testele periodice de recovery ca pe o modalitate de verificare dacă backupul permite într-adevăr atingerea RTO și RPO asumate.
De aceea backupul este un element al strategiei de recovery, nu echivalentul ei complet.
Întrebarea cea mai importantă: ce se întâmplă după o avarie?
Să ne imaginăm un magazin online.
La 10:17 baza de date încetează să mai răspundă.
Serverul aplicației continuă să funcționeze, dar utilizatorii nu se pot autentifica. Comenzile nu funcționează. Panoul de administrare nu mai răspunde. Sistemul de plăți nu primește informații corecte.
Echipa verifică situația.
Se dovedește că ultimul backup al bazei de date a fost realizat la 8:00.
Teoretic, datele pot fi recuperate.
Dar apoi apar alte întrebări;
- Se știe unde se află copia?
- Se știe cum se restaurează?
- Este disponibilă persoana care știe să facă asta?
- Backupul este complet?
- Configurația aplicației corespunde versiunii salvate în copie?
- După restaurare, baza de date va funcționa cu aplicația actuală?
- Și cel mai important: cât va dura restabilirea funcționării magazinului?
Dacă nimeni nu a verificat asta înainte, răspunsul poate fi surprinzător.
RTO - cât downtime putem accepta?
RTO, adică Recovery Time Objective, stabilește timpul maxim acceptabil pentru recuperarea sistemului după o avarie.
De exemplu: RTO = 4 ore înseamnă că organizația presupune posibilitatea de a restabili funcționarea sistemului în maximum patru ore.
Asta nu înseamnă însă că fiecare aplicație ar trebui să aibă un RTO de patru ore.
Pentru un sistem intern folosit de câteva ori pe zi, un astfel de timp poate fi acceptabil. Pentru o platformă de vânzări care funcționează 24/7 poate însemna pierderi foarte serioase.
Prin urmare, RTO ar trebui să rezulte din business, nu din ceea ce oferă în prezent infrastructura.
NIST definește RTO ca timpul în care un sistem poate rămâne în faza de recuperare înainte ca acest lucru să afecteze negativ activitatea organizației.
RPO - câte date putem pierde?
Al doilea parametru de bază este RPO, adică Recovery Point Objective.
RPO răspunde la întrebarea: cât de departe în timp ne putem întoarce cu datele după o avarie?
Exemplu: RPO = 1 oră înseamnă că organizația acceptă o posibilă pierdere de cel mult aproximativ o oră de date.
Dacă sistemul se defectează la 15:00, iar ultima copie utilizabilă provine de la 14:00, exact acest scenariu se încadrează în RPO-ul asumat. Dar dacă backupul se face o dată pe zi, este greu să te aștepți la un RPO de o oră.
RPO influențează astfel direct modul de realizare a copiilor, replicarea datelor și proiectarea infrastructurii.
RTO ne spune în primul rând cât timp putem fi indisponibili.
RPO spune câte date putem pierde.
Acești doi parametri ar trebui stabiliți împreună cu businessul, deoarece atingerea lor implică costuri și soluții tehnice. Microsoft subliniază, de asemenea, că RTO și RPO ar trebui să rezulte din cerințe reale de business, nu din presupunerea abstractă „zero downtime și zero pierdere de date”.
Backupul poate exista și totuși să fie inutil
Acesta este unul dintre cele mai periculoase mituri din IT.
„Backupul este realizat corect” nu înseamnă automat: „sistemul poate fi restaurat din el”.
Copia poate fi incompletă. Poate fi coruptă. Poate conține date care nu pot fi folosite corect. Poate fi realizată într-un mod care nu permite refacerea întregului mediu.
De aceea backupul trebuie testat prin restaurare reală.
Nu este suficient să verifici dacă fișierul există.
Trebuie restaurat.
Trebuie pornit sistemul.
Trebuie verificate datele.
Trebuie validate dependențele.
Trebuie verificată configurația.
Trebuie măsurat timpul.
Și trebuie răspuns la întrebarea dacă rezultatul corespunde ipotezelor RTO și RPO.
AWS indică drept eroare tipică tocmai restaurarea backupului fără a verifica dacă resursa restaurată funcționează efectiv și dacă datele recuperate pot fi folosite.
Failover - când nu vrem să așteptăm restaurarea
Nu orice aplicație își poate permite câteva ore de așteptare pentru recuperare. În astfel de cazuri se folosesc, printre altele, mecanisme de failover.
Failover înseamnă comutarea funcționării de la mediul principal la un mediu de rezervă pregătit.
Poate fi vorba despre:
-
server de rezervă,
-
o a doua zonă de disponibilitate,
-
o a doua regiune,
-
o replică a bazei de date,
-
un mediu standby,
-
o infrastructură alternativă pregătită pentru pornire.
În cel mai simplu model, aplicația funcționează într-un singur loc, iar în caz de avarie pornim mediul de rezervă. În soluțiile mai avansate, o parte din infrastructură funcționează în paralel și este pregătită să preia traficul.
Totuși, nu există o singură strategie potrivită pentru toți.
Backupul și restore-ul sunt de obicei mai ieftine, dar pot însemna un timp de recuperare mai lung. Soluțiile de tip warm standby sau redundanța activă pot scurta semnificativ recuperarea, dar necesită investiții mai mari și o infrastructură mai complexă.
Și failover-ul trebuie testat
Aici apare o altă problemă.
Compania poate avea un mediu de rezervă, dar nu l-a folosit de doi ani;
- Mai funcționează încă?
- Configurația corespunde producției?
- Are performanță suficientă?
- Sunt disponibile toate serviciile?
- Certificatele sunt actuale?
- DNS-ul va comuta corect?
- Aplicația se va conecta la bază?
- Va funcționa mecanismul de autorizare?
- Știe echipa exact ce trebuie să facă?
Doar testul răspunde la aceste întrebări.
AWS recomandă testarea regulată a failover-ului tocmai pentru a verifica funcționarea căii de recuperare și pentru a vedea dacă RTO și RPO reale corespund presupunerilor.
Un mediu de disaster recovery care nu a fost niciodată testat este doar parțial o presupunere.
Disaster recovery nu înseamnă doar infrastructură
Este ușor să privești DR exclusiv prin prisma serverelor.
Este o greșeală.
Recuperarea include și:
- Date
Sunt toate datele importante protejate? - Aplicația
Avem versiunea corectă a codului și posibilitatea de a o implementa? - Configurația
Știm ce setări sunt necesare pentru a porni sistemul? - Secretele și certificatele
Avem acces securizat la chei, tokenuri și certificate? - Dependențele externe
Ce se întâmplă dacă nu este disponibil un sistem extern de plăți, un API, un furnizor de identitate sau un serviciu SaaS? - Infrastructura
Avem un loc în care aplicația poate fi pornită? - Oamenii
Se știe cine ia decizia de declanșare a procedurii? - Procedurile
Există un runbook concret sau recuperarea se bazează pe cunoștințele unei singure persoane?
Acest ultim aspect este deosebit de important.
Dacă doar un singur administrator știe cum să refacă sistemul, încă nu avem o procedură rezilientă. Avem o dependență de o persoană anume.
Cel mai prost moment pentru a scrie procedura de recovery
Este momentul în care sistemul nu mai funcționează.
Atunci apar presiunea timpului, stresul, telefoanele de la clienți și întrebările conducerii.
De aceea, procedura ar trebui pregătită din timp.
Ar trebui să stabilească, printre altele:
-
când pornim disaster recovery,
-
cine ia decizia,
-
care sisteme au cea mai mare prioritate,
-
unde se află backupurile,
-
cum le restaurăm,
-
ce dependențe trebuie pornite,
-
cum arată failover-ul,
-
cum verificăm corectitudinea funcționării,
-
cum comunicăm avaria,
-
când poate începe failback-ul,
-
cine aprobă revenirea la mediul principal.
În cazul unei avarii grave nu ar trebui să existe loc pentru întrebarea: „Ce facem acum?”
Procedura ar trebui să răspundă la asta dinainte.
DR ar trebui testat ca o funcționalitate a aplicației
O abordare bună este să tratezi recuperarea în mod similar cu testele software. Nu este suficient să pregătești procedura o singură dată.
Sistemul se schimbă.
Baza de date crește.
Se schimbă dependențele.
Apare infrastructură nouă.
Se schimbă versiunile aplicației.
Apar integrări noi.
Se schimbă permisiunile.
De aceea, strategia de recovery necesită și ea verificare continuă.
Testul poate începe cu un scenariu simplu: „Baza de date a fost pierdută. Să o refacem din ultima copie.”
Apoi se poate trece la scenarii mai complexe:
- „Serverul de aplicație nu funcționează.”
- „Întregul mediu de producție este indisponibil.”
- „Datele au fost criptate.”
- „Nu funcționează regiunea principală a infrastructurii.”
- „Nu avem acces la administratorul principal.”
Fiecare astfel de test poate scoate la iveală probleme care nu sunt vizibile în timpul funcționării normale a sistemului.
Are nevoie fiecare aplicație de disaster recovery avansat?
Nu.
Și asta este important.
Proiectarea unei infrastructuri rezistente la orice scenariu posibil poate fi disproporționat de scumpă.
Dacă avaria unei aplicații interne poate însemna o oră de disconfort, nu avem neapărat nevoie de o infrastructură active-active în mai multe regiuni. Dacă însă avaria unui sistem înseamnă oprirea vânzărilor, producției, suportului pentru clienți sau a unui proces de business critic, situația arată cu totul altfel.
Mai întâi trebuie stabilit impactul avariei asupra businessului.
Abia apoi se alege tehnologia.
Asta poate duce la soluții diferite:
Backup + restore
O soluție mai simplă și mai ieftină pentru sistemele cu criticitate mai redusă.
Warm standby
Mediul de rezervă este parțial pregătit și poate fi pornit rapid.
Hot standby
Mediul de rezervă funcționează într-o măsură mai mare în paralel și este gata să preia sarcina.
Active-active
Două medii pot deservi simultan traficul, reducând dependența de un singur punct de avarie.
Alegerea soluției ar trebui să rezulte din RTO, RPO, criticitatea sistemului, costul întreruperii și posibilitățile tehnice.
Checklist: este aplicația ta pregătită pentru avarie?
Merită să răspunzi la câteva întrebări simple.
1. Avem backup?
Asta este doar începutul.
2. Backupul este stocat într-un mod care îl protejează și de avaria mediului de producție?
3. Am făcut vreodată o restaurare completă?
4. Cât durează, de fapt, restore-ul?
5. Cunoaștem RTO?
6. Cunoaștem RPO?
7. Putem restabili nu doar datele, ci și aplicația și configurația ei?
8. Avem o procedură de recovery?
9. Mai mult de o persoană știe să o execute?
10. Am testat failover-ul?
11. Mediul de rezervă este actual?
12. După ultimele schimbări din sistem, am retestat recovery-ul?
Dacă la câteva întrebări răspundem „nu știu”, atunci este un moment foarte bun să analizăm strategia de disaster recovery.
Cel mai important test sună așa: „Arată-mi”
În IT, e foarte ușor să spui:
- „Avem backup.”
- „Avem server de rezervă.”
- „Avem o procedură.”
- „Avem disaster recovery.”
- Dar securitatea sistemului nu ar trebui să se bazeze exclusiv pe declarații.
Întrebarea cea mai importantă este: Arată că îl poți restaura.
- Pornește restore-ul.
- Măsoară timpul.
- Verifică datele.
- Testează aplicația.
- Execută failover-ul.
- Verifică procedura.
- Repetă testul după modificări importante.
Abia atunci se poate spune că strategia de recovery a fost verificată în practică.
Backup-ul protejează datele. Recovery-ul readuce afacerea
Aceasta este probabil cea mai importantă diferență.
Backup-ul răspunde la întrebarea: „Avem o copie?”
Disaster recovery răspunde la o întrebare mult mai dificilă: „După o avarie, putem reveni la funcționare?”
Iar între una și cealaltă se află întreaga arhitectură de recuperare: RPO, RTO, replicare, backup-uri, restore, failover, configurare, proceduri, responsabilitate și teste regulate.
Un sistem bine proiectat nu pornește de la premisa că avaria nu se va întâmpla. Pornește de la premisa că va veni un moment în care avaria se va întâmpla și va trebui să știm ce avem de făcut.
Pentru că adevărata reziliență a aplicației nu înseamnă că nu se strică niciodată. Înseamnă că atunci când ceva merge prost, organizația poate reveni la funcționare într-un mod previzibil, controlat și aliniat cerințelor de business.
Glosar
Disaster Recovery (DR) - strategie și proceduri care permit restabilirea funcționării sistemelor după o avarie majoră.
Backup - copie a datelor destinată restaurării lor ulterioare.
Restore - procesul de refacere a datelor sau a sistemului din copie.
RTO (Recovery Time Objective) - timpul maxim acceptabil pentru recuperarea sistemului.
RPO (Recovery Point Objective) - pierderea maximă acceptabilă de date exprimată în timp.
Failover - comutarea funcționării sistemului din mediul principal către cel de rezervă.
Failback - revenirea funcționării la mediul principal după eliminarea cauzei avariei.
Recovery test - test menit să confirme că sistemul poate fi într-adevăr restaurat conform ipotezelor asumate.
Runbook - instrucțiune detaliată de acțiune într-un scenariu specific de avarie.
