Veiklos tęstinumo planas aprašo, kaip organizacija palaikys svarbiausius procesus, kai įprasti ištekliai nepasiekiami. Jis prasideda nuo paslaugos ir jos naudotojų poreikio. Atsarginė serverio kopija gali būti būtina, tačiau ji nepasako, kas priims užsakymą ar suteiks pagalbą, kol sistema neveikia.
Planą rengia procesų savininkai kartu su IT ir vadovybe. Sistemų žemėlapis parodo priklausomybes, IT atkūrimo planas aprašo techninį grąžinimą į darbą, o informacijos saugumo politika nustato sprendimų atsakomybes.
Įvertinkite poveikį veiklai
Pasirinkite vieną procesą ir aprašykite, kam jis reikalingas, kada jo neveikimas tampa nepriimtinas ir kokios alternatyvos galimos. Įvertinkite poveikį žmonėms, sutartiniams įsipareigojimams, finansams ir kitiems priklausomiems procesams. Vien pajamų dydis neparodo, kurio proceso sutrikimas pavojingiausias.
| Procesas | Sutrikimo poveikis | Priklausomybė | Laikina darbo eiga | Sprendimo savininkas |
|---|---|---|---|---|
| Užsakymo priėmimas | Nepriimami klientų užsakymai | Portalas, tapatybės sistema | Patvirtintas alternatyvus kanalas | Pardavimo vadovas |
| Kliento pagalba | Neatsakoma į skubias užklausas | Telefonija, aptarnavimo byla | Alternatyvus kontaktų ir bilietų registras | Aptarnavimo vadovas |
| Darbo užmokesčio parengimas | Vėluoja būtini skaičiavimai | Personalo ir apskaitos sistemos | Iš anksto patikrinta minimali duomenų ištrauka | Finansų vadovas |
Tai hipotetinis pavyzdys. Įrašykite savo procesus ir skirtingus sutrikimo laikotarpius. Atkūrimo laiko tikslas ir priimtinas duomenų praradimo intervalas turi kilti iš veiklos poreikio bei techninių galimybių, o ne būti pasirinkti dėl patrauklaus skaičiaus plane.
Sukurkite kelis tikėtinus scenarijus
Atskirai apsvarstykite sistemos nepasiekiamumą, patalpų praradimą, svarbaus tiekėjo sutrikimą ir darbuotojų neprieinamumą. Kibernetinė ataka gali paveikti ir pagrindinę sistemą, ir prie jos prijungtas kopijas. Todėl alternatyva turi būti pakankamai nepriklausoma nuo numanomos gedimo priežasties.
Kiekviename scenarijuje aprašykite plano aktyvavimo kriterijų, sprendimą priimantį asmenį, komandą ir susisiekimo būdą. Kontaktai, saugomi tik neveikiančioje sistemoje, nebus naudingi. Kontaktų ištrauka taip pat yra asmens duomenys: ribokite prieigą ir peržiūrėkite, ar joje neliko išėjusių darbuotojų.
SGDSN veiklos tęstinumo metodinis vadovas padeda struktūruoti poveikio analizę ir pratybas. BDAR 32 straipsnis apima gebėjimą laiku atkurti asmens duomenų prieinamumą. Konkrečių sektorių pareigas vertinkite atskirai; šis planas nenustato vienodo privalomo atkūrimo laiko visoms įmonėms.
Hipotetinis užsakymų scenarijus
Tarkime, užsakymų portalas nepasiekiamas, tačiau sandėlis gali dirbti. Laikinoje eigoje paskirti darbuotojai priima tik būtinus užsakymo duomenis patvirtintu kanalu, suteikia laikiną identifikatorių ir užrašo veiksmų laiką. Draudžiama siųsti visą klientų bazę asmeniniais el. pašto adresais vien todėl, kad įprasta sistema neveikia.
Atkūrus portalą laikini įrašai perkeliami kontroliuojamai: tikrinami dublikatai, sumos, pristatymo būsenos ir neatitikimai. Laikinos kopijos pašalinamos pagal trynimo koncepciją. Procesas laikomas atkurtu tik tada, kai savininkas patvirtina duomenų sutikrinimą, o ne vien tada, kai serveris vėl atsako.
Pratybų protokolas
Pratyboms nustatykite saugią apimtį ir nekurkite tikro paslaugos sutrikimo be įgaliojimo. Galima pradėti nuo stalo pratybų: komandai pateikiamas scenarijus ir stebima, kokius sprendimus ji priima. Toliau tikrinami konkretūs komponentai, pavyzdžiui, kontaktų prieinamumas ir vienos kopijos atkūrimas.
Protokole fiksuokite scenarijų, dalyvius, numatytą ir faktinį laiką, nepavykusius veiksmus bei taisymo savininkus. Jei darbuotojai nežino, kas leidžia naudoti alternatyvų kanalą, tai plano spraga. Jei kopija atkuriama, bet trūksta šifravimo rakto, spraga priklauso raktų valdymui.
Po incidento ar reikšmingo proceso pakeitimo peržiūrėkite prielaidas. Tiekėjo pažadas dėl paslaugos prieinamumo nepakeičia jūsų pačių patikrintos alternatyvos. Galutinį rinkinį sudaro poveikio lentelė, aktyvavimo taisyklė, laikinos darbo eigos, atkūrimo nuorodos ir pratybose nustatytų darbų sąrašas.
Atkūrimo prioritetai ir laiko tikslai
Poveikio analizėje atskirkite ilgiausią pakeliamą proceso sutrikimą nuo techninio sistemos atkūrimo tikslo. Procesui gali reikėti atsinaujinti anksčiau, negu įmanoma atkurti visą sistemą, todėl būtina laikina darbo eiga. Taip pat atskirkite, kiek duomenų galima prarasti laiko prasme: paskutinės kopijos amžius ir sistemos atkūrimo trukmė sprendžia skirtingas problemas.
Tikslus tvirtinkite su proceso savininku. Jeigu jis nurodo, kad negalimas joks sutrikimas ir joks duomenų praradimas, paprašykite aprašyti pasekmes bei realią alternatyvą. Absoliutus reikalavimas gali reikšti labai kitokį techninį sprendimą ir kaštus. Vadovybei pateikite pasirinkimus su jų ribomis, užuot įrašę neįgyvendinamą pažadą plane.
Vertinkite skirtingą laiką: darbo dienos pradžią, mėnesio uždarymą, sezoninį piką ar laikotarpį, kai vykdomi svarbūs mokėjimai. Tas pats dviejų valandų sutrikimas gali turėti kitokį poveikį skirtingą dieną. Plane aprašykite, kurie prioritetai keičiasi ir kas gali priimti sprendimą dėl perskirstymo.
Priklausomybės už IT ribų
Paslauga priklauso ne tik nuo programų. Gali reikėti konkrečių darbuotojų žinių, patalpų, elektros, ryšio, dokumentų ar partnerio patvirtinimo. Pavyzdžiui, alternatyvi darbo vieta nepadės, jeigu prieiga prie svarbios paslaugos leidžiama tik iš nepasiekiamo biuro tinklo. Kontaktų sąrašas nepadės, jeigu vienintelis sprendimą priimantis asmuo neprieinamas.
Kiekvienai kritinei priklausomybei nurodykite alternatyvą ir patikros būdą. Pavaduotojas turi ne tik būti įrašytas, bet ir turėti reikalingą įgaliojimą bei informaciją. Išorinio tiekėjo atveju patikrinkite, ar sutartyje ir pagalbos plane numatyta reakcija atitinka jūsų scenarijų. Bendras paslaugos prieinamumo rodiklis nepasako, ar konkreti duomenų ištrauka bus atkurta laiku.
Krizės komandos sprendimų žurnalas
Aktyvavus planą paskirkite sprendimų registruotoją. Jis fiksuoja faktus, sprendimą, tvirtintoją, laiką ir kitą peržiūros tašką. Tai padeda išvengti situacijos, kai skirtingos komandos vykdo nesuderinamas instrukcijas. Žurnalas turėtų būti pasiekiamas numatytu alternatyviu būdu, jeigu pagrindinė bendradarbiavimo platforma neveikia.
Sprendime atskirkite, kas žinoma, kas dar tikrinama ir kokią prielaidą laikinai naudojate. Pavyzdžiui, „duomenų bazė nepasiekiama“ neįrodo, kad ji sunaikinta. Kol techninė komanda tiria priežastį, proceso savininkas gali aktyvinti ribotą alternatyvą. Tokia lygiagreti veikla turi būti suderinta, kad nepablogintų įrodymų išsaugojimo ar atkūrimo.
Bendravimas su klientais ir darbuotojais
Paruoškite pranešimų karkasus, kuriuos būtų galima greitai pritaikyti patikrintiems faktams. Nurodykite, kokia paslauga paveikta, koks alternatyvus kanalas ir kada tikimasi kito atnaujinimo. Nežadėkite tikslaus atkūrimo laiko, kol komanda neturi tam pagrindo. Pernelyg ankstyvas pažadas gali trukdyti priimti saugų sprendimą.
Vidaus instrukcijoje aiškiai pasakykite, kokių veiksmų darbuotojai turi vengti. Pavyzdžiui, prašykite nekurti savarankiškų klientų duomenų kopijų asmeninėse paskyrose ir neplatinti nepatikrintų techninių versijų. Kartu pateikite realų leidžiamą sprendimą, nes vien draudimai nepadeda tęsti būtinos veiklos.
Grįžimas į įprastą veiklą
Atkūrimas turi turėti priėmimo kriterijus. Sistemos savininkas patvirtina techninį veikimą, o proceso savininkas – kad galima saugiai vykdyti svarbiausias užduotis. Prieš grįžtant sutikrinkite laikinus įrašus, neįvykdytus veiksmus, dublikatus ir neteisingas būsenas. Jei dalies informacijos patvirtinti nepavyksta, ją reikia pažymėti ir spręsti atskirai.
Laikinas procesas gali sukurti naujų kopijų ir prieigos teisių. Uždarant planą peržiūrėkite šias teises, atšaukite nebereikalingas paskyras ir sutvarkykite laikinus registrus. Nuspręskite, kurie sprendimų bei pratybų įrodymai turi likti ir kiek laiko. Grįžimas nėra baigtas, jei paslauga veikia, bet žmonių duomenys išsibarstę nevaldomose vietose.
Pratybų lygiai ir rezultatų vertinimas
Stalo pratybos tikrina sprendimų logiką ir komunikaciją. Atskiro komponento bandymas tikrina techninę galimybę, pavyzdžiui, kopijos atkūrimą. Platesnės pratybos gali tikrinti kelių komandų sąveiką ir laikinos darbo eigos perkėlimą. Kiekvienam lygiui reikia aiškios apimties, leidimo ir apsaugos, kad pratybos nesukeltų neplanuotos realios žalos.
Neapsiribokite žyma „pratybos atliktos“. Palyginkite tikslą su rezultatu, aprašykite, ką iš tikrųjų bandėte ir ko nebandėte. Jei pratybose nebuvo išorinio tiekėjo, išvada apie jo reakciją lieka nepatikrinta. Jei naudotas sumažintas duomenų rinkinys, pažymėkite, kad pilnos apimties atkūrimo laikas gali skirtis.
Taisymo darbui nustatykite konkretų užbaigimo kriterijų. „Pagerinti komunikaciją“ pakeiskite veiksmu, pavyzdžiui, atnaujinti alternatyvius kontaktus ir patikrinti dviejų pavaduotojų pasiekiamumą. Kitose pratybose pakartokite būtent neveikusį scenarijų. Taip planas tobulėja pagal stebėtą rezultatą, o ne vien pagal dokumento datą.
Tiekėjo dalyvavimo patikros klausimai
Su svarbiu tiekėju iš anksto aptarkite, kokią informaciją jis pateiks sutrikimo metu ir kas gali patvirtinti atkūrimo eigą. Pranešimas „paslauga atkurta“ gali reikšti tik techninį pasiekiamumą, todėl paklauskite, ar patikrintas duomenų vientisumas, užstrigusios užduotys ir suplanuoti siuntimai. Sutarkite dėl kito atnaujinimo, kai priežastis dar nežinoma.
Patikrinkite, ar jūsų atsarginis sprendimas nepriklauso nuo to paties tiekėjo bendros infrastruktūros. Dvi skirtingai pavadintos paslaugos gali turėti bendrą tapatybės, tinklo ar duomenų saugyklos priklausomybę. Žemėlapyje pažymėta priklausomybė padeda išvengti tariamos alternatyvos, kuri sutrinka kartu su pagrindiniu sprendimu.
Jei tiekėjas nedalyvauja pratybose, paprašykite tinkamos apimties atkūrimo įrodymų ir įvertinkite jų ribas. Ataskaita apie kitą paslaugą ar kitą laikotarpį nepatvirtina jūsų konkretaus scenarijaus. Šias ribas įtraukite į likusios rizikos vertinimą ir vadovybės sprendimą dėl tolesnių darbų.