Jau žinote, kad BC/DR yra esminis organizacijos sėkmės komponentas. Ir mes žinome, kad reikia metrikų, kad būtų galima įvertinti pastangų efektyvumą. Pirmas žingsnis – suprasti veiklos tęstinumo ir atkūrimo po nelaimių planavimo metriką, apie kurią būtent šis straipsnis ir bus skirtas. Jums taip pat reikės įrankio, kad galėtumėte rinkti ir teikti ataskaitas apie šias metrikas. Atsižvelgiant į jūsų organizacijos dydį ir BC/DR programos brandos lygį, tai gali būti nuo Excel šablono iki galingos automatizuotos programinės įrangos.
Yra 7 svarbūs BC / DR rodikliai, kuriuos reikia stebėti, kad būtų galima plėtoti ir įvertinti atkūrimo planus:
Nors yra daug kitų metrikų, kurias reikia stebėti, šios metrikos yra pagrindinė programos apžvalga ir parodo, kaip iš tikrųjų esate pasirengę spręsti blokavimo problemą.
Pirmosios dvi svarbios BC/DR metrikos yra atkūrimo laiko tikslai (RTO) ir atkūrimo taško tikslai (RPO). RTO yra didžiausias priimtinas laikas, per kurį elementas gali būti nenaudojamas. RPO nustato, kiek senų duomenų galite sau leisti prarasti ir ar jūsų atsarginės kopijos išsaugos likusius. Pavyzdžiui, jei galite sau leisti prarasti valandą duomenų, atsargines kopijas turėsite daryti bent kas valandą.
Atsarginės kopijos kūrimo ir atkūrimo procedūros yra gero BC/DR plano pagrindas, todėl turite atsižvelgti ir į RTO, ir į RPO, kad nustatytumėte geriausius atsarginių kopijų kūrimo ir atkūrimo įrankius darbui. Pavyzdžiui, jei generuojate nuolatines operacijas, kurių apimtis ir vertė yra vidutinė arba didelė, kiek operacijos minučių galėtumėte sau leisti prarasti? Kiek laiko galėtumėte sau leisti nedirbti? Tokiai programai gali būti naudingos labai dažnos bloko lygio atsarginės kopijos, galimos naudojant nuolatinę duomenų apsaugą (CDP), bet jūs to nežinotumėte, nebent pažvelgtumėte į RTO ir RPO.
Galiausiai reikia išmatuoti planų, apimančių kiekvieną verslo procesą, skaičius , taip pat laikas, praėjęs nuo kiekvieno plano atnaujinimo . Pagrindiniai našumo rodikliai (KPI) yra programos veikimo matas, kurio negalima ignoruoti. Galite nustatyti KPI, kaip dažnai peržiūrite ir atnaujinate savo planus (pavyzdžiui, kas mėnesį, 6 mėnesius ar metus) ir kiek verslo funkcijų apima atkūrimo planas su veiksmų planu, kad būtų pasiekta 100 % aprėpties. Jei trūksta laiko ir išteklių, pradėkite nuo svarbiausių verslo procesų.
Įmonės gali turėti nuo šimtų iki tūkstančių procesų, o be plano neįmanoma atkurti proceso. Pagrindinė BC/DR planavimo metrika yra procesų, kuriems gresia potenciali nelaimė, skaičius .
Turėtumėte pradėti nuo rizikos analizės ir poveikio verslui analizės, kad:
Tada galite sukurti planus, kaip apsaugoti šiuos procesus ir sumažinti trikdžius įvykus nelaimei.
Tačiau statiški planai gali sustingti. Negalite atšaukti procesų, nebent periodiškai atnaujinate savo planus, kad atsižvelgtumėte į programų, duomenų, aplinkos, darbuotojų ir rizikos pokyčius. Turėtumėte nustatyti sau priminimus, kad atitinkamuose ciklo taškuose paraginti planą peržiūrėti. Tobulame pasaulyje iš įvairių padalinių vadovų gautumėte patvirtinimą, kad jie peržiūrėjo ir atnaujino savo planus, bet būkime atviri: tų planų peržiūra ir atnaujinimas yra didžiulis vargas, ir būtų beveik stebuklinga, jei jie tai padarys laiku. Programinės įrangos naudojimas gali sumažinti šį skausmą: galite automatizuoti priminimus el. paštu įvairiems planų savininkams ir stebėti jų eigą programinėje įrangoje – nereikia jokių pasyvių agresyvių el. laiškų! Programinė įranga taip pat pašalina daugelį varginančių užduočių, susijusių su pokyčių valdymu. Pavyzdžiui, automatizuotas duomenų integravimas automatiškai atnaujins duomenis, kai pasikeičia kitos programos. Jei vienas kontaktas naudojamas 100 planų ir pasikeičia jų telefono numeris, integruota sistema įtrauks šį pakeitimą į jūsų veiklos tęstinumo ir kritinių situacijų valdymo planus.
Vienas iš paprasčiausių būdų nustatyti, kaip verslo funkcijos yra tarpusavyje susijusios, yra naudoti priklausomybės modeliavimo įrankį. Tai padės įsivaizduoti, ar programos priklausomybės leidžia atitikti RTO ir SLA.
Pavyzdžiui, jei jums reikia susigrąžinti mokėtinų sumų paslaugą per 12 valandų, bet tai priklauso nuo finansinės programinės įrangos, kurios atkūrimas gali užtrukti iki 24 valandų, mokėtinos sumos negali atitikti 12 valandų SLA. Priklausomybės modeliavimo priemonė šiuos priklausomus ryšius iliustruoja dinamiškai ir kada bei kaip dėl to planas žlugs.
Turėtum išmatuoti faktinis laikas, kurio reikia verslo procesui atkurti . Galite išbandyti atkūrimo procedūras naudodami BC/DR įrankį, kad stebėtumėte, kiek laiko užtrunka kiekvienas veiksmas.
Arba galite naudoti senosios mokyklos metodą kiekvienam žingsniui nustatyti rankiniu būdu. Šie testai padės nustatyti, ar jūsų žmonės ir procesai gali atitikti RTO, naudodami esamą planą. Turėtumėte sugebėti atlikti atkūrimo užduotis per planą, o jei negalite, turite peržiūrėti savo planą, kad jis būtų realus ir pasiekiamas.
Galiausiai, paskutinė šiame šaltinyje aprašyta metrika yra skirtumas tarp tikrojo ir numatomo atkūrimo laiko , taip pat žinomas kaip spragų analizė. Galite patikrinti, ar nėra spragų, perkrovos ir atkūrimo testavimą, įmonės lygio BC/DR testavimą ir spragų analizę. Radę planų spragų, galite nustatyti KPI ir naudoti juos planavimo procese.
BC/DR programinės įrangos surinkti duomenys turi būti „švarūs“, kad būtų užtikrintas tikslus ataskaitų teikimas ir planavimas. Norėdami užtikrinti gerą duomenų higieną, būtinai standartizuokite duomenų įvedimą naudodami išskleidžiamuosius meniu, pasirinkimo sąrašus, teksto formatavimą ir duomenų patvirtinimą. Pavyzdžiui, jei į planą įtraukiame darbuotojų telefono numerius, rekomenduojame patikrinti, ar tie telefonų numeriai apima srities kodą ir ar jie lieka naudojami.
Dubliavimo panaikinimas ir tapatybės bei prieigos valdymas (IAM) gali padėti sukurti elegantiškus duomenis. Galite naudoti dubliavimo panaikinimą, kad pašalintumėte kelis tų pačių įrašų aspektus. Galite naudoti kredencialus (autentikacija) kartu su leidimais (įgaliojimas), kad įrašus ir pagrindinius duomenis įvestų tik kvalifikuoti vartotojai. Taip pat sutaupysite daug laiko ir rūpesčių integravę BC/DR sistemą su kitomis programomis (pvz., HR sistema), kad išvengtumėte įrašų dubliavimo ir klaidų.
Naudodami santykių modeliavimo įrankį nustatykite svarbiausias verslo funkcijas ir kaip jos priklauso viena nuo kitos.
Toliau, naudodami RTO ir RPO metriką, nustatome priimtiną prastovos slenkstį. Bandome planus, kad pamatytume, ar artėjame prie tų slenksčių, ar juos viršijame. Po to peržiūrėkime planus ir išbandykime dar kartą. Turėtume nustatyti KPI, kad įvertintume, kaip dažnai planai atnaujinami ir tikrinami, ir atlikti spragų analizę, kad palygintume planuojamą ir faktinį atkūrimo laiką.
Galiausiai įsitikinkite, kad duomenys yra „higieniški“, kad būtų teikiamos tikslios ataskaitos. BC/DR metrika yra visiškai nenaudinga, jei duomenys netikslūs. Gali atrodyti, kad tai niekam tikęs, tačiau stebėtina, kiek daug įmonių užliūliuoja klaidingą saugumo jausmą su pranešimais, kuriuose klaidingai pateikiami jų SLA. Visada geriausia būti realistu, net jei tai reiškia, kad reikia priimti su tuo susijusią riziką.
Ercole Palmeri
Lavindami smulkiosios motorikos įgūdžius dažydami, vaikai paruošiami sudėtingesniems įgūdžiams, pavyzdžiui, rašymui. Norėdami nuspalvinti…
Karinio jūrų laivyno sektorius yra tikra pasaulinė ekonominė galia, kuri pasiekė 150 mlrd.
Praėjusį pirmadienį „Financial Times“ paskelbė apie susitarimą su „OpenAI“. FT licencijuoja savo pasaulinio lygio žurnalistiką…
Milijonai žmonių moka už srautinio perdavimo paslaugas, mokėdami mėnesinius abonentinius mokesčius. Paplitusi nuomonė, kad jūs…
