ka sagatavot katastrofu atjaunosanas planu

Brīdī, kad uzņēmumam apstājas piekļuve failiem, nestrādā grāmatvedības sistēma vai nav pieejams e-pasts, jautājums vairs nav teorētisks. Tad kļūst skaidrs, kā sagatavot katastrofu atjaunošanas plānu tā, lai tas reāli pasargātu ieņēmumus, klientu apkalpošanu un ikdienas operācijas, nevis vienkārši izskatītos korekti auditā.

Daudziem vadītājiem katastrofu atjaunošanas plāns joprojām asociējas ar tehnisku dokumentu, ko sagatavo IT speciālisti un glabā mapē. Praksē tas ir vadības instruments. Tas nosaka, kuras sistēmas ir kritiskas, cik ilgi uzņēmums var atļauties dīkstāvi, kādā secībā jāatjauno pakalpojumi un kurš pieņem lēmumus spiediena apstākļos. Tieši tāpēc labs plāns nav tikai par serveriem un rezerves kopijām. Tas ir par uzņēmuma spēju turpināt darbu, kad kaut kas noiet greizi.

Kāpēc katastrofu atjaunošanas plāns bieži neiztur realitāti

Lielākā kļūda nav plāna neesamība. Lielākā kļūda ir plāns, kas balstīts pieņēmumos, nevis faktiskā uzņēmuma darbībā. Dokumentā var būt norādīts, ka dati tiek dublēti katru dienu, taču neviens nav pārbaudījis, cik ātri tos var atjaunot. Var būt definēts atbildīgais par incidentu vadību, bet viņš atrodas atvaļinājumā, un aizvietotājs nav noteikts.

Vēl viena izplatīta problēma ir pārāk tehnisks skatījums. Ja plāns neietver biznesa prioritātes, tas atjaunos nepareizās lietas nepareizā secībā. Piemēram, failu servera atjaunošana var būt mazāk steidzama nekā ERP, noliktavas sistēma vai attālinātās piekļuves vide. Bez šīs prioritizācijas uzņēmums zaudē laiku tieši tad, kad tas ir visdārgākais resurss.

Kā sagatavot katastrofu atjaunošanas plānu uzņēmuma vajadzībām

Saprātīgākais sākums nav tehnoloģiju saraksts, bet biznesa ietekmes izvērtējums. Vadībai kopā ar IT ir jāsaprot, kuras funkcijas nedrīkst apstāties un cik ilgi. Ražošanas uzņēmumam kritiska var būt piekļuve pasūtījumiem un iekārtu datiem. Pakalpojumu uzņēmumam - e-pasts, dokumentu vide, CRM un finanšu sistēmas. Šis posms nosaka, kas tieši ir jāglābj pirmajās stundās pēc incidenta.

Tālāk jādefinē divi pamatrādītāji - pieļaujamais dīkstāves laiks un pieļaujamais datu zudums. Citiem vārdiem, cik ātri sistēmai jāatgriežas darbībā un cik veci dati vēl ir pieņemami. Ja uzņēmums saka, ka grāmatvedība var stāvēt vienu dienu, bet klientu pasūtījumu sistēma tikai vienu stundu, rezerves kopēšanas un atjaunošanas modelim tas ir jāatspoguļo. Vienā gadījumā pietiks ar lēnāku atjaunošanu, otrā - vajadzēs augstākas pieejamības risinājumus.

Pēc tam jāizveido atkarību karte. Daudzas sistēmas nav autonomas. E-pasts var balstīties uz identitātes pārvaldību, ERP - uz datubāzi, attālināts darbs - uz VPN, ugunsmūri un interneta savienojumu. Ja atjauno tikai vienu komponenti, bet ignorē pārējās atkarības, sistēma tehniski var būt ieslēgta, taču biznesam tā joprojām nav lietojama.

Kas obligāti jāiekļauj plānā

Katastrofu atjaunošanas plānam nav jābūt apjomīgam, bet tam jābūt lietojamam. Tajā skaidri jābūt definētiem incidentu scenārijiem. Ne tikai pilnīga serveru telpas avārija, bet arī izspiedējvīruss, kļūdains atjauninājums, mākoņpakalpojuma nepieejamība, cilvēka kļūda vai interneta pakalpojuma pārtraukums. Ne visiem scenārijiem vajag identisku reakciju.

Svarīga ir lomu un atbildību sadaļa. Kurš aktivizē plānu, kurš pieņem biznesa lēmumus, kurš komunicē ar klientiem, kurš koordinē piegādātājus un kurš veic tehnisko atjaunošanu. Krīzes situācijā cilvēki nedrīkst improvizēt par to, kam jāzvana un kurš drīkst apstiprināt nākamos soļus.

Plānā jābūt arī precīzai sistēmu atjaunošanas secībai. Te rodas viena no būtiskākajām niansēm - ne vienmēr vajag atjaunot visu. Dažkārt pietiek sākotnēji atgriezt kritiskākās funkcijas ar pagaidu risinājumu un pilnu vidi atjaunot vēlāk. Tas samazina dīkstāvi, bet prasa iepriekš izstrādātu loģiku, nevis spontānus lēmumus.

Nedrīkst aizmirst par kontaktinformāciju, piekļuves glabāšanu un ārējiem piegādātājiem. Ja paroles, licences, administratīvās piekļuves vai atbalsta kontaktpersonas atrodas tikai vienā nepieejamā sistēmā, pats plāns kļūst neizpildāms. Praktiskā pieeja paredz šo informāciju uzturēt droši, bet pieejami arī ārpus primārās vides.

Rezerves kopijas nav tas pats, kas atjaunošanas plāns

Šī atšķirība uzņēmumos joprojām tiek jaukta. Rezerves kopijas ir nepieciešamas, taču pašas par sevi tās negarantē darbības atjaunošanu. Ja dublējumi tiek veidoti, bet neviens nezina, kādā secībā atjaunot sistēmas, kā pārbaudīt datu integritāti un cik ilgu laiku tas prasīs, uzņēmumam nav katastrofu atjaunošanas plāna. Tam ir tikai cerība, ka dublējumi palīdzēs.

Te ir arī svarīgs kompromiss starp izmaksām un pieejamību. Ne katram uzņēmumam vajag sekundāru datu centru vai gandrīz tūlītēju pārslēgšanos uz rezerves vidi. Taču gandrīz katram uzņēmumam vajag pārbaudītu, reāli izmantojamu atjaunošanas procesu. Mazam un vidējam uzņēmumam bieži labāka ir vienkārša, regulāri testēta pieeja nekā dārga arhitektūra, kuru neviens nav izmēģinājis stresa apstākļos.

Testēšana ir vieta, kur plāns kļūst par realitāti

Ja plāns nav testēts, tas nav gatavs. Tas ir tikai pieņēmumu kopums. Testēšanai nav obligāti jānozīmē pilns katastrofas scenārijs ražošanas vidē. Var sākt ar galda vingrinājumiem, kuros vadība un atbildīgie speciālisti iziet cauri konkrētam incidentam un pārbauda, vai lēmumu ķēde ir skaidra.

Nākamais līmenis ir tehniska atjaunošanas pārbaude. Tiek testēts, vai no rezerves kopijām tiešām iespējams atjaunot konkrētas sistēmas, vai datubāzes ir izmantojamas, vai lietotāji var pieslēgties un vai kritiskās integrācijas strādā. Tieši šeit parasti atklājas neatjauninātas instrukcijas, nepareizas piekļuves un pārāk optimistiski laika pieņēmumi.

Testēšanas biežums ir atkarīgs no vides izmaiņu tempa. Ja uzņēmums aktīvi ievieš jaunus mākoņpakalpojumus, pārceļ sistēmas vai maina procesus, plāns jāatjaunina biežāk. Ja vide ir stabilāka, pietiek ar regulāriem periodiskiem testiem un pārskatīšanu pēc būtiskām izmaiņām.

Vadības loma katastrofu atjaunošanas plāna sagatavošanā

Katastrofu atjaunošana nav tikai IT atbildība. Vadībai ir jānosaka pieļaujamais risks, pieejamais budžets un prioritārās biznesa funkcijas. Bez šiem lēmumiem IT komanda nevar pieņemt pareizus arhitektūras un atjaunošanas lēmumus. Tehnoloģija var izpildīt tikai to uzdevumu, ko bizness ir skaidri definējis.

Tieši vadības līmenī jāatbild uz neērtajiem jautājumiem. Vai uzņēmums pieņem vairāku stundu dīkstāvi? Vai kritiskie darbinieki var strādāt attālināti avārijas laikā? Vai klientiem ir jāsaņem paziņojums pirmajā stundā? Vai piegādātāji ir iekļauti incidentu ķēdē? Šie nav tehniski sīkumi. Tie ir darbības nepārtrauktības lēmumi ar tiešu ietekmi uz reputāciju un ieņēmumiem.

Daudzos gadījumos vērtīgi ir piesaistīt ārēju partneri, kas plānu izvērtē no malas. Nevis tāpēc, ka iekšējā komanda būtu vāja, bet tāpēc, ka ikdienas vidē ir viegli nepamanīt atkarības un pieņēmumus. KSK IT tipa pieeja šeit ir praktiska - nevis radīt formālu dokumentu dokumenta pēc, bet saskaņot tehnisko izpildi ar vadības prasībām, audita vajadzībām un reālu atjaunošanas spēju.

Biežākie signāli, ka plāns ir novecojis

Ja uzņēmums pēdējā gada laikā ir pārgājis uz jaunu ERP, ieviesis Microsoft 365, pārcēlis daļu sistēmu uz mākoni, atvēris jaunu biroju vai mainījis ārējo IT pakalpojumu sniedzēju, vecais plāns, visticamāk, vairs nav pietiekams. Tas pats attiecas uz situācijām, kad uzņēmumā mainījušies atbildīgie darbinieki vai drošības prasības.

Novecojušu plānu parasti atpazīst pēc viena simptoma - tas izskatās kārtīgs, bet neviens nav pārliecināts, vai tas joprojām atbilst realitātei. Ja nav skaidras atbildes uz jautājumu, cik ātri tiks atjaunota konkrēta sistēma un kas tieši to darīs, plāns jāatver no jauna.

Labs katastrofu atjaunošanas plāns nerada ilūziju, ka krīze būs vienkārša. Tas rada skaidrību par to, kas notiks pirmajās minūtēs, pirmajās stundās un pirmajā diennaktī. Uzņēmumiem, kas grib augt stabili, ar to pilnībā pietiek kā sākuma punktu - nevis gaidīt ideālu brīdi, bet pieņemt praktiskus lēmumus, pirms tie kļūst steidzami.