Du vet allerede at BC/DR er en kritisk komponent for en organisasjons suksess. Og vi vet at det er behov for beregninger for å måle effektiviteten av innsatsen. Det første trinnet er å forstå beregningene som betyr noe i forretningskontinuitet og planlegging av katastrofegjenoppretting, som er nøyaktig hva denne artikkelen vil handle om. Du trenger også et verktøy for å samle inn og rapportere om disse beregningene. Avhengig av størrelsen på organisasjonen og modenhetsnivået til BC/DR-programmet ditt, kan dette variere fra en Excel-mal til kraftig automatisert programvare.
Det er 7 viktige BC/DR-målinger å overvåke for å vokse og måle utvinningsplaner:
Selv om det er mange andre beregninger å overvåke, fungerer disse målingene som en grunnleggende programgjennomgang og indikerer hvor godt forberedt du virkelig er til å takle et blokkeringsproblem.
De to første viktige BC/DR-målene er Recovery Time Objectives (RTO) og Recovery Point Objectives (RPO). RTO er den maksimale akseptable tiden varen kan være inaktiv. RPOer bestemmer hvor gamle dataene du har råd til å miste og om sikkerhetskopiene dine vil lagre resten. For eksempel, hvis du har råd til å miste en time med data, må du ta sikkerhetskopier minst hver time.
Sikkerhetskopiering og gjenopprettingsprosedyrer er kjernen i en god BC/DR-plan, så du må vurdere både RTOer og RPOer for å finne de beste sikkerhetskopierings- og gjenopprettingsverktøyene for jobben. For eksempel, hvis du genererer kontinuerlige transaksjoner med moderat til høyt volum og verdi, hvor mange transaksjonsminutter har du råd til å tape? Hvor lenge hadde du råd til å være fri? En slik applikasjon kan dra nytte av de svært hyppige sikkerhetskopieringene på blokknivå som er mulig med kontinuerlig databeskyttelse (CDP), men du ville ikke vite det med mindre du ser på både RTO-ene og RPO-ene.
Til slutt må du måle antall planer som dekker hver forretningsprosess , i tillegg til tiden som har gått siden hver plan ble oppdatert . Key Performance Indicators (KPIer) er et mål på hvor godt et program fungerer, og en du ikke kan ignorere. Du kan angi KPIer for hvor ofte du gjennomgår og oppdaterer planene dine (for eksempel månedlig, 6 måneder eller årlig) og hvor mange forretningsfunksjoner som dekkes av en gjenopprettingsplan, med en handlingsplan for å oppnå 100 % dekning. Hvis du har lite tid og ressurser, start med de mest kritiske forretningsprosessene dine.
Bedrifter kan ha hundrevis til tusenvis av prosesser, og det er ikke mulig å gjenopprette en prosess uten en plan. En nøkkelberegning for BC/DR-planlegging er antall prosesser truet av en potensiell katastrofe .
Du bør starte med en risikoanalyse og forretningskonsekvensanalyse for å:
Deretter kan du lage planer for å beskytte disse prosessene og minimere forstyrrelser i tilfelle en katastrofe.
Men statiske planer kan stagnere. Du kan ikke rulle tilbake prosesser med mindre du periodisk oppdaterer planene dine for å ta hensyn til endringer i applikasjoner, data, miljøer, ansatte og risikoer. Du bør angi påminnelser for deg selv om å be om plangjennomganger på passende punkter i syklusen. I en perfekt verden vil du få bekreftelse fra ledere for ulike avdelinger at de har gjennomgått og oppdatert planene sine, men la oss være ærlige: Å gjennomgå og oppdatere disse planene er et stort problem, og det er nesten mirakuløst hvis de får det gjort i tide. Bruk av programvaren kan lindre dette smertepunktet: Du kan automatisere e-postpåminnelser til ulike planeiere og spore fremdriften deres i programvaren – ingen passive aggressive e-poster er nødvendig! Programvaren fjerner også mange av de kjedelige oppgavene knyttet til endringshåndtering. For eksempel vil automatiserte dataintegrasjoner holde dataene dine oppdatert automatisk etter hvert som dataendringer i andre applikasjoner. Hvis en enkelt kontakt brukes på tvers av 100 planer og deres telefonnummer endres, vil et integrert system også presse denne endringen inn i forretningskontinuitets- og beredskapsplanene dine.
En av de enkleste måtene å finne ut hvordan forretningsfunksjoner er gjensidig avhengige er å bruke et avhengighetsmodelleringsverktøy. Dette vil hjelpe deg med å visualisere om applikasjonens avhengigheter lar deg møte RTOer og SLAer.
For eksempel, hvis du trenger å gjenopprette en leverandørreskontrotjeneste på 12 timer, men dette avhenger av finansiell programvare som kan ta opptil 24 timer å gjenopprette, kan ikke leverandørgjeld oppfylle en 12-timers SLA. En avhengighetsmodeller illustrerer disse avhengige relasjonene dynamisk og når og hvordan en plan vil bryte sammen som et resultat.
Du bør måle den faktiske tiden det tar å gjenopprette en forretningsprosess . Du kan teste gjenopprettingsprosedyrer ved å bruke et BC/DR-verktøy for å spore hvor lang tid hvert trinn tar.
Alternativt kan du bruke den gamle metoden for å time hvert trinn manuelt. Disse testene vil hjelpe deg å finne ut om dine folk og prosesser kan møte RTOer ved å bruke din eksisterende plan. Du bør være i stand til å fullføre gjenopprettingsoppgaver på den tiden planen tillater, og hvis du ikke kan det, må du revidere planen slik at den er realistisk og oppnåelig.
Til slutt er den siste beregningen som dekkes i denne ressursen forskjellen mellom faktisk og forventet restitusjonstid , også kjent som gapanalyse. Du kan teste for hull med, failover- og gjenopprettingstesting, BC/DR-testing på bedriftsnivå og gapanalyse. Når du finner hull i planene dine, kan du angi KPIer og bruke dem i planleggingsprosessen.
Dataene som samles inn av BC/DR-programvaren må være "rene" for å sikre nøyaktig rapportering og planlegging. For god datahygiene, sørg for å standardisere dataregistrering med rullegardinmenyer, valglister, tekstformatering og datavalidering. Hvis vi for eksempel legger ansattes telefonnumre inn i en plan, anbefaler vi å sjekke om disse telefonnumrene inneholder et retningsnummer og forblir i bruk.
De-duplisering og identitets- og tilgangsadministrasjon (IAM) kan bidra til å produsere elegante data. Du kan bruke de-duplisering for å eliminere flere aspekter ved de samme oppføringene. Du kan bruke legitimasjon (autentisering) sammen med tillatelser (autorisasjon) for å sikre at kun kvalifiserte brukere legger inn poster og stamdata. Du vil også spare mye tid og bryderi ved å integrere BC/DR-systemet med andre applikasjoner (for eksempel HR-systemet) for å unngå duplisering av poster og enhver mulighet for feil.
Bestem kritiske forretningsfunksjoner og hvordan de er avhengige av hverandre ved hjelp av et relasjonsmodelleringsverktøy.
Deretter satte vi en akseptabel nedetidsterskel ved å bruke RTO- og RPO-målinger. Vi tester planer for å se om vi nærmer oss eller overskrider disse tersklene. Etter det, la oss gjennomgå planene og teste dem på nytt. Vi bør sette KPIer for å måle hvor ofte planer oppdateres og testes, og gjennomføre gapanalyse for å sammenligne planlagt versus faktisk restitusjonstid.
Til slutt, sørg for at du holder data "hygieniske" for nøyaktig rapportering. BC/DR-beregninger er helt ubrukelige hvis dataene er unøyaktige. Det kan virke som en uklarhet, men det er overraskende hvor mange selskaper som lurer seg inn i en falsk følelse av sikkerhet med rapporter som gir en feilaktig fremstilling av SLAene deres. Det er alltid best å være realistisk, selv om det betyr å akseptere risikoen som er involvert.
Ercole Palmeri
Sist mandag kunngjorde Financial Times en avtale med OpenAI. FT lisensierer sin journalistikk i verdensklasse...
Millioner av mennesker betaler for strømmetjenester og betaler månedlige abonnementsavgifter. Det er vanlig oppfatning at du...
Coveware by Veeam vil fortsette å tilby responstjenester for cyberutpressing. Coveware vil tilby kriminaltekniske og utbedringsmuligheter...
Prediktivt vedlikehold revolusjonerer olje- og gasssektoren, med en innovativ og proaktiv tilnærming til anleggsledelse...
