Plan de continuitate IT: ce faci când pică serverul

Un server cade joi după-amiază. Backup-ul există, administratorul îl verifică lunar, nimeni nu e îngrijorat — până când restaurarea completă durează trei zile, nu trei ore, pentru că nimeni nu a cronometrat vreodată procesul până la capăt. În acele trei zile, facturarea stă, comenzile se notează pe hârtie, iar clienții sună să întrebe ce se întâmplă. Firma nu a pierdut date. A pierdut timp, bani și, pentru câțiva clienți, răbdarea. Diferența dintre acest scenariu și unul care se rezolvă în câteva ore nu este bugetul alocat IT-ului, ci faptul că cineva a scris, dinainte, ce se restaurează primul și cât timp e acceptabil să dureze.

De ce un backup nu este, singur, un plan de continuitate

O copie de rezervă răspunde la o singură întrebare: dacă pierd datele, le mai am undeva? Un plan de continuitate răspunde la o întrebare diferită și mai greu de ignorat: cât timp poate firma să funcționeze fără acel sistem, și ce face în acel interval? Cele două se confundă ușor pentru că par parte din același subiect — protecția datelor — dar un backup verificat, fără un plan de restaurare testat în jurul lui, garantează doar că datele nu sunt pierdute definitiv, nu că firma nu se oprește. Multe firme mici din Moldova au deja backup-uri; puține au cronometrat vreodată cât durează, de fapt, să repună un sistem critic în funcțiune de la zero.

Ce înseamnă, de fapt, continuitate IT pentru o firmă mică

Pentru o corporație, un plan de continuitate poate însemna un centru de date de rezervă, replicare în timp real și un comitet de criză. Pentru o firmă cu zece sau cincizeci de angajați, înseamnă, de regulă, mult mai puțin și mult mai practic: o pagină — nu un document de cincizeci — care spune ce sisteme sunt critice, cine sună pe cine, ce se repornește primul și cât timp e tolerabil ca fiecare să rămână oprit. Scopul lui nu este să elimine orice pană posibilă, ceea ce nu e realist cu niciun buget, ci să elimine improvizația din momentul în care ceva chiar cade — pentru ca decizia „ce facem acum" să fi fost deja luată, la rece, înainte să fie nevoie de ea.

RTO și RPO: cele două întrebări care, de fapt, contează

În spatele oricărui plan de continuitate stau două întrebări simple, cunoscute în domeniu sub acronimele RTO și RPO. RTO (recovery time objective) este timpul maxim acceptabil în care un sistem poate rămâne oprit înainte ca oprirea să devină o problemă serioasă pentru afacere — pentru facturare sau pentru site-ul unui magazin online, acest timp e de regulă scurt; pentru o arhivă de documente vechi, poate fi de câteva zile, fără consecințe practice. RPO (recovery point objective) este cât de mult din datele cele mai recente firma își poate permite să piardă — dacă ultimul backup e de acum 24 de ore, iar sistemul cade, tot ce s-a introdus în acele 24 de ore se pierde la restaurare. Firmele care nu și-au pus niciodată aceste două întrebări tind să afle răspunsul abia în timpul unei pene reale, când e prea târziu să mai conteze ca decizie și contează doar ca pierdere.

Ce inventariezi înainte să scrii planul

Primul pas practic nu este tehnic, ci de listă: ce sisteme folosește, de fapt, firma zi de zi — poșta electronică, programul de facturare sau 1C, site-ul web, baza de date a clienților, aplicațiile de gestiune a stocului — și cât de grav ar fi, pentru fiecare în parte, dacă ar fi indisponibil o oră, o zi, o săptămână. Nu toate sistemele au aceeași miză: poșta electronică și facturarea opresc de regulă activitatea aproape imediat, în timp ce un arhivă de rapoarte vechi poate aștepta fără pierdere reală. Această listă, scrisă o singură dată și actualizată când apare un sistem nou, este diferența dintre un plan util și o discuție teoretică reluată de la zero la fiecare incident.

Ordinea de restaurare: ce repornești primul

Când mai multe sisteme cad odată — ceea ce se întâmplă des, pentru că multe depind de aceeași conexiune la internet sau de același server — ordinea în care sunt repornite contează la fel de mult ca viteza. Conexiunea la internet și rețeaua internă vin de regulă primele, pentru că nimic altceva nu funcționează fără ele. Urmează sistemele de care depind direct veniturile — facturarea, site-ul, aplicația cu care lucrează clienții — și abia după acestea aplicațiile interne mai puțin urgente. Dependențele dintre sisteme (o aplicație care are nevoie de baza de date pornită înainte de ea) trebuie documentate dinainte, nu deduse în grabă în mijlocul unei pene, când greșelile de ordine costă timp suplimentar exact atunci când timpul contează cel mai mult.

Măsuri ieftine care reduc riscul fără buget mare

Nu toată protecția costă mult. Un UPS (sursă de alimentare neîntreruptibilă) pentru serverul sau routerul firmei costă relativ puțin și elimină cea mai frecventă cauză banală de oprire — o pană scurtă de curent care resetează tot echipamentul de rețea. O a doua conexiune la internet, chiar și un router mobil ca rezervă, acoperă situația în care problema nu e la firmă, ci la furnizorul de internet. O copie de rezervă păstrată în afara biroului — într-un serviciu cloud sau fizic, în altă locație — protejează exact scenariul în care problema afectează clădirea întreagă, nu doar un echipament. Și, poate cel mai ieftin pas dintre toate: procedurile scrise pe o singură pagină, accesibilă oricui din echipă, nu doar persoanei care „știe cum funcționează serverul" — pentru că acea persoană poate fi în concediu, bolnavă sau plecată din firmă exact când apare problema.

Testarea planului: de ce unul netestat e la fel de riscant ca lipsa unuia

Un plan scris, dar niciodată testat, dă o siguranță falsă — pare să existe o soluție, dar nimeni nu știe dacă funcționează până nu e nevoie de ea, moment în care e deja prea târziu să afli că nu funcționează. Testarea reală înseamnă restaurarea efectivă a unui backup într-un mediu separat, cronometrarea procesului și verificarea că datele restaurate sunt complete și utilizabile, nu doar confirmarea că fișierul de backup există și are o dimensiune rezonabilă. O cadență anuală, cu o verificare mai scurtă după orice schimbare majoră de sistem (un server nou, o migrare, un furnizor cloud schimbat), este un ritm rezonabil pentru majoritatea firmelor mici — suficient de des cât să prindă o problemă înainte să devină critică, fără să consume resurse disproporționat de mari.

Greșeli frecvente

Cea mai frecventă greșeală este confundarea existenței unui backup cu existența unui plan — firma are copii de rezervă, dar nimeni nu a calculat niciodată cât durează o restaurare completă. A doua este concentrarea cunoștințelor într-o singură persoană, fără nicio procedură scrisă: dacă acea persoană nu poate fi contactată, planul nu există, oricât de bine funcționează el în mintea ei. A treia este ignorarea penelor scurte, considerate prea mici pentru a merita un plan — exact aceste pene mici sunt cele mai frecvente în practică și, fără o procedură minimă, pot dura mult mai mult decât ar trebui doar din cauza improvizației. A patra este tratarea accesului la distanță ca pe o soluție de avarie configurată în grabă: o conexiune VPN improvizată, fără mentenanță, poate deveni ea însăși un punct de defecțiune în momentul în care e cel mai nevoie de ea.

Cine se ocupă de asta, în practică

Construirea unui plan de continuitate implică decizii de infrastructură — unde stau datele, cât de repede pot fi restaurate, ce redundanță are sens pentru mărimea firmei — exact zona acoperită de serviciile noastre de infrastructură cloud, de la alegerea arhitecturii potrivite până la configurarea copiilor de rezervă externe și testarea lor periodică. Pentru firmele fără un angajat IT dedicat care să mențină planul la zi și să coordoneze un test anual, acest rol intră de regulă în contractul de suport IT externalizat, alături de restul mentenanței infrastructurii — astfel încât planul să rămână un document viu, actualizat pe măsură ce firma adaugă sisteme noi, nu o pagină scrisă o dată și uitată într-un sertar.

Solicită o discuție gratuită despre infrastructura firmei tale și află, concret, cât timp ar dura o restaurare reală — nu doar dacă există un backup, ci dacă funcționează.