Disaster recovery plāns uzņēmumam

Pulksten 10.17 grāmatvedības sistēma vairs nav pieejama, faili neatveras, un darbinieki sāk rakstīt viens otram, vai problēma ir tikai viņiem. Līdz 10.40 kļūst skaidrs, ka tas nav atsevišķs traucējums. Tieši šādā brīdī disaster recovery plāns no teorētiska dokumenta pārvēršas par biznesa izdzīvošanas instrumentu.

Daudzi vadītāji joprojām pieņem, ka rezerves kopijas pašas par sevi atrisina atjaunošanas jautājumu. Tās neatrisina. Rezerves kopija pasaka, ka dati kaut kur ir saglabāti. Disaster recovery plāns nosaka, kādā secībā, cik ātri un ar kādu atbildību uzņēmums atjauno kritiskās sistēmas, procesus un piekļuves. Tie ir divi saistīti, bet atšķirīgi jautājumi.

Kas ir disaster recovery plāns praksē

Vienkārši sakot, disaster recovery plāns ir iepriekš definēta rīcība IT traucējumu, kiberdrošības incidenta vai infrastruktūras bojājuma gadījumā. Tas apraksta, kas tiek atjaunots vispirms, no kādiem avotiem, kas pieņem lēmumus un kā tiek uzturēta uzņēmuma darbība līdz pilnai atkopšanai.

Mazajiem un vidējiem uzņēmumiem šis plāns parasti nav sarežģīts tāpēc, ka vide būtu liela. Tas kļūst sarežģīts tāpēc, ka sistēmas gadiem ilgi veidojušās pa daļām - viens piegādātājs uztur serveri, cits e-pastu, trešais uzstādījis biznesa lietotni, bet nevienam nav pilna priekšstata par prioritātēm. Incidenta laikā šāds modelis rada kavēšanos, nevis kontroli.

Labs plāns nav rakstīts tikai IT komandai. Tas ir vadības instruments. Tas palīdz vadītājiem saprast, cik ilgs dīkstāves laiks ir pieņemams, kuras funkcijas jāatjauno pirmajās stundās un cik liels risks uzņēmumam rodas, ja kāda sistēma nav pieejama vienu dienu, trīs dienas vai nedēļu.

Kāpēc disaster recovery plāns nav tikai IT jautājums

Ja nestrādā ERP sistēma, cieš ne tikai IT vide. Apstājas noliktava, kavējas rēķinu izrakstīšana, klientu serviss strādā ar nepilnu informāciju, un vadība pieņem lēmumus bez aktuāliem datiem. Tāpēc atjaunošanas prioritātes nevar noteikt tikai pēc tehniskā principa - svarīgākais serveris ne vienmēr ir svarīgākais biznesa process.

Tieši šeit parādās biežākā kļūda. Uzņēmums domā sistēmu līmenī, bet ne procesu līmenī. Piemēram, failu serveris var šķist kritisks, tomēr pārdošanas komanda īslaicīgi var strādāt arī ar ierobežotu piekļuvi. Savukārt klientu pasūtījumu platformas dīkstāve pat uz dažām stundām var radīt tiešus ieņēmumu zaudējumus. Bez skaidras kartes starp tehnoloģiju un biznesa ietekmi atjaunošana bieži notiek nepareizā secībā.

Disaster recovery plāns tāpēc sākas nevis ar tehnoloģiju sarakstu, bet ar jautājumu - kas uzņēmumam ir jāsaglabā funkcionējošs jebkuros apstākļos. Atbilde var būt finanšu uzskaite, klientu apkalpošana, ražošanas vadība, attālināta piekļuve komandai vai noteikta datu bāze. Tikai pēc tam var pieņemt saprātīgus tehniskos lēmumus.

Ko šāds plāns ietver

Praktiski izmantojams plāns parasti sastāv no vairākām savstarpēji saistītām daļām. Pirmā ir kritisko sistēmu un pakalpojumu inventarizācija. Nevis vispārīgs saraksts, bet skaidri norādīts, kuras platformas, serveri, lietotnes un datu kopas ir tieši saistītas ar biznesa nepārtrauktību.

Otrā daļa ir atjaunošanas prioritātes. Šeit būtiski definēt pieļaujamo dīkstāvi un pieļaujamo datu zudumu katrai sistēmai. Ja e-pasta darbību var atjaunot dažu stundu laikā, bet pasūtījumu sistēmai vajadzīgs gandrīz nepārtraukts režīms, šīm atšķirībām jābūt skaidri dokumentētām. Pretējā gadījumā visi incidenta laikā pieprasa visu atjaunot uzreiz, kas praksē nav reāli.

Trešā daļa ir atbildības sadalījums. Kurš aktivizē plānu, kurš sazinās ar piegādātājiem, kurš informē vadību, kurš pieņem lēmumu par pāreju uz rezerves vidi. Ja šie jautājumi nav atrisināti iepriekš, incidenta laikā pazūd stundas, nevis minūtes.

Ceturtā daļa ir tehniskā atkopšana. Tajā jābūt aprakstītiem rezerves kopiju avotiem, atjaunošanas secībai, piekļuves atslēgām, alternatīvai infrastruktūrai, mākoņpakalpojumu lomai un atkarībām starp sistēmām. Ļoti bieži uzņēmumi atklāj, ka datus teorētiski var atjaunot, bet nav pieejama licence, autentifikācijas serviss vai tīkla konfigurācija, bez kuras atjaunotā vide nav lietojama.

Biežākās kļūdas, kas sadārdzina incidentu

Visdārgāk parasti maksā nevis pati avārija, bet slikti sagatavota atkopšana. Klasisks piemērs ir situācija, kad rezerves kopijas tiek veidotas, bet netiek testētas. Uz papīra viss izskatās korekti, taču incidenta dienā izrādās, ka kopija ir bojāta, nepilnīga vai atjaunojama tikai ar manuālu iejaukšanos, par kuru neviens nav domājis.

Otra izplatīta kļūda ir pārliecība, ka mākoņpakalpojums automātiski nozīmē pilnu atkopšanas gatavību. Tas ir atkarīgs no konkrētā risinājuma. Dažos gadījumos pakalpojuma sniedzējs nodrošina platformas pieejamību, bet ne jūsu datu granularitāti, versiju atjaunošanu vai konfigurācijas elastību. Mākoņvide samazina daļu risku, bet neatceļ vajadzību pēc plāna.

Trešā kļūda ir dokumenta izveide auditam, nevis reālai lietošanai. Ja disaster recovery plāns ir pārāk vispārīgs, pilns ar novecojušu kontaktinformāciju vai rakstīts tā, it kā to neviens nekad neatvērtu stresa situācijā, tas nepalīdzēs. Labs plāns ir skaidrs, īss tur, kur tas drīkst būt īss, un pietiekami detalizēts tur, kur bez detaļām nevar iztikt.

Kā noteikt pareizo atkopšanas līmeni

Ne katram uzņēmumam vajadzīga dārga augstas pieejamības arhitektūra. Taču gandrīz katram uzņēmumam vajadzīga skaidrība par to, kas notiek, ja svarīga sistēma nav pieejama. Pareizais atkopšanas līmenis vienmēr ir kompromiss starp risku, izmaksām un biznesa toleranci pret dīkstāvi.

Ja uzņēmums strādā ar salīdzinoši nelielu darījumu intensitāti un var droši izturēt vienu darba dienu bez noteiktas sistēmas, pietiek ar vienkāršāku modeli. Ja katra stunda tieši ietekmē ieņēmumus, klientu apkalpošanu vai līgumsaistības, vajadzīgs daudz ātrāks atjaunošanas mehānisms. Šeit nav universālas receptes. Pareizā pieeja rodas no biznesa realitātes, nevis no tā, kas tehniski izklausās iespaidīgi.

Tāpēc vadībai jāuzdod sev neērti, bet nepieciešami jautājumi. Cik maksā viena dīkstāves stunda? Cik daudz datu uzņēmums var atļauties zaudēt? Vai kritiskās sistēmas ir atkarīgas no viena cilvēka zināšanām? Vai ir skaidrs, kā rīkoties arī tad, ja incidents notiek ārpus darba laika? Šīs atbildes veido plāna kvalitāti vairāk nekā jebkura viena tehnoloģija.

Disaster recovery plāns ir jātestē, nevis tikai jāuzglabā

Plāns bez pārbaudes ir pieņēmums. Testēšana nav formalitāte, bet veids, kā atklāt vājās vietas, kamēr tās vēl nav kļuvušas par biznesa problēmu. Nereti tieši testā atklājas, ka atjaunošanas secība nav loģiska, piekļuves nav aktuālas vai noteikta sistēma aizņem daudz vairāk laika, nekā sākotnēji pieņemts.

Testam nav obligāti jābūt pilna mēroga simulācijai katru mēnesi. Dažiem uzņēmumiem pietiek ar regulāru atjaunošanas scenāriju pārbaudi, daļēju sistēmu testiem un vadības līmeņa galda simulācijām. Svarīgi, lai plāns būtu dzīvs un saistīts ar reālo vidi. Ja uzņēmums nomaina infrastruktūru, ievieš jaunu biznesa lietotni vai pārceļ daļu sistēmu uz mākoni, plāns jāatjaunina uzreiz, nevis pēc gada.

Šeit bieži lielāko vērtību dod ārējs skatījums. Nevis tāpēc, ka iekšējā komanda nespētu saprast savu vidi, bet tāpēc, ka ikdienas darbā grūti pamanīt pieņēmumus un neredzamos riskus. Tāpēc uzņēmumi arvien biežāk izvēlas disaster recovery plāna auditu vai pārskatīšanu kopā ar partneri, kurš vienlaikus saprot tehnisko infrastruktūru un biznesa prioritātes. KSK IT šādos gadījumos strādā tieši šajā krustpunktā - starp operatīvu izpildi un vadības līmeņa kontroli.

Kad ir īstais brīdis izveidot vai pārskatīt plānu

Parasti negaida līdz incidentam, taču praksē tieši incidents bieži kļūst par impulsu. Gudrāka pieeja ir rīkoties agrāk - pirms biroja pārcelšanās, pirms jaunas ERP ieviešanas, pēc uzņēmuma iegādes, straujas izaugsmes laikā vai tad, kad IT vide kļuvusi pārāk atkarīga no atsevišķiem cilvēkiem un vēsturiskiem risinājumiem.

Ja uzņēmumam nav skaidras atbildes uz jautājumu, cik ātri iespējams atjaunot kritiskās sistēmas, tas jau ir pietiekams signāls pārskatīšanai. Tas pats attiecas uz situācijām, kad rezerves kopijas tiek uzturētas, bet neviens nav dokumentējis pilnu atkopšanas secību. Šāds modelis var darboties līdz pirmajam nopietnajam traucējumam. Pēc tam tas kļūst dārgs.

Spēcīgs disaster recovery plāns nedod garantiju, ka incidents nenotiks. Tas dod ko citu - paredzamību, atbildību un daudz labāku iespēju saglabāt uzņēmuma darbību brīdī, kad apstākļi ir nelabvēlīgi. Tieši tāpēc šo darbu ir vērts paveikt pirms steigas, pirms zaudējumiem un pirms kāds vadības sanāksmē ir spiests atbildēt, kāpēc neviens īsti nezināja, ko darīt.