Pred izvedbo stresnega testa marsikdo jemlje Disaster Recovery plan (ali načrt okrevanja po katastrofi) precej birokratsko. Zgolj pač dokument, ki ga imamo, ker ga moramo imeti. Zabeležene so neke poti za obnovo, odgovorne osebe, nekaj tabel, nekaj kontrolnih seznamov. Enkrat letno se ga morda posodobi in shrani. Pika.
Disaster Recovery (DR) ne sme biti samo dokument. DR mora biti operativna sposobnost ekipe in sistema, da se po večji motnji povrne v delujoče stanje – hitro, varno in predvidljivo. Ta sposobnost pa se seveda ne gradi z branjem dokumentov, ampak s treningom, simulacijami in testiranjem.
Kaj spada pod Disaster Recovery?
Disaster Recovery pokriva celoten sklop aktivnosti, ki so potrebne za:
- Hitro ugotavljanje, da je prišlo do motnje (npr. izpad strežnika, napad z izsiljevalskim virusom, požar, naravna nesreča).
- Ocenjevanje škode in odločanje, ali je treba sprožiti DR postopke.
- Obnovo sistemov iz varnostnih kopij, alternativnih lokacij, rezervnih virov.
- Vzpostavitev poslovne kontinuitete, torej ponovno zagotavljanje osnovnih storitev in dostopa uporabnikov.
- Komunikacijo znotraj podjetja in navzven (npr. do strank, partnerjev).
Ključnega pomena pa je seveda dejstvo, da je hitrost in zanesljivost izvedbe teh korakov neposredno odvisna od tega, ali smo jih prej vadili.
Kje se stresni test in DR prepletata
Ob simuliranju izpada ključne infrastrukture se lahko takoj vidi, da stresni test ni le tehnični eksperiment, temveč je živ test Disaster Recovery plana.
Kaj lahko v praksi ugotovimo:
- Ko virtualni strežnik z bazo "pade", lahko preverimo, ali imamo dovolj svežo kopijo in ali jo lahko hitro obnovimo. Večkrat se namreč izkaže, da backup imamo, vendar sama lokacija backupa ni dokumentirana v DR načrtu.
- Pri simulaciji izpada DNS sistema lahko traja več kot 30 minut, da se vzpostavi alternativa. V DR dokumentaciji je sicer lahko zapisano "preklopimo na sekundarni DNS", vendar pa ni nujno, da bo odgovorna oseba točno vedela, kdo, kako in kdaj.
- Test komunikacije pokaže, da nekateri ključni kontakti (zunanji vzdrževalci, ponudniki oblačnih storitev) niso dosegljivi – imamo shranjene le službene e-maile, nimamo pa dežurnih številk, ...
Testiranje naredi več kot karkoli drugega: prisili nas, da naš DR načrt vzamemo resno, ga morda poenostavimo, posodobimo in začnemo nanj gledati kot na dinamičen sistem – ne le statičen dokument.
Kaj je dober Disaster Recovery načrt?
Na kratko? Preprost, konkreten, preizkušen.
Dober DR načrt ne vsebuje samo politik, ampak tudi:
- RTO (Recovery Time Objective) – kako hitro mora biti sistem spet aktiven.
- RPO (Recovery Point Objective) – koliko podatkov lahko "izgubimo", preden je vpliv izgube nesprejemljiv.
- Točno določene vloge – kdo je odgovoren za odločanje, obnovo, komunikacijo.
- Preverjene scenarije – ki so bili dejansko testirani v stresnem okolju.
- Enostaven dostop do ključnih informacij, tudi če so sistemi nedosegljivi (npr. papirna kopija DR plana ali varnostna kopija na ločenem sistemu).
Kaj se pogosto spremeni po stresnem testu?
Po stresnem testu naredimo naslednje konkretne korake:
- DR načrt razdelimo po vlogah in scenarijih – ne več 50 strani dokumentacije, ampak akcijski listi za posamezne incidente.
- Dobro je uvesti četrtletne mini vaje, kjer simuliramo delne izpade in sledimo protokolu.
- Dokumentacijo lahko preselimo tudi na offline dostopno mesto, ne le v intranet.
- Ekipe usposobimo, da ne le vedo, kaj piše v načrtu – ampak vedo, kako delovati v praksi.
Danes DR ni tema, o kateri razmišljamo samo med revizijami. DR načrt bi moral biti stalni del pogovorov, ko uvajamo nove sisteme, spremembe ali ob nadgradnjah.
Disaster Recovery načrt torej ni samo postopek za po nesreči. Je način razmišljanja. In če želimo, da bo podjetje resnično odpornejše, moramo ta način razmišljanja vaditi – z realnimi testi, simulacijami, vprašanji brez vnaprej pripravljenih odgovorov.
Je pa stresni test pogosto prvi korak, da sploh razumemo, zakaj je DR načrt tako pomemben.