Elementerne i forretnings kontinuitetsplanlægning

Gendannelse fra en forretningskontinuitetshændelse (BCE) kræver system-for-system-planlægning med grundig forståelse af, hvordan hver computer og netværkskomponent påvirker kritiske forretningsresultater. Derfor skal forretnings kontinuitetsplanlægning (BCP) omfatte flere dokumenterede, testede og øvede sæt opgaver, der understøtter:

  • Kortlægning af systemafhængighed
  • Maksimal tolerable perioder med forstyrrelse (MTPOD)
  • Gennemsnitlig reparationstid (MTTR)
  • Mål for genopretningstid (RTO)

Forkert analyse af et eller flere af disse BCP-mål vil sandsynligvis resultere i uoprettelig skade på din organisation, hvis en kritisk forretningsproces mislykkes.

Kortlægning af systemafhængighed

Et system står sjældent alene; de fleste systemer er en del af et sæt tekniske komponenter, der yder support til en eller flere forretningsprocesser. De fungerer som en intern it-forsyningskæde. Figur A viser et sæt systemer (S n ), der giver ordreindgang (S1), ordrebehandling (S2), fakturering (S3) og forsendelse (S4). Bestillinger, der indtastes i S1, afsluttes af S2. S2 feeds derefter S3, hvor fakturering forekommer, og lagerbilletbilleder genereres af S4. Hvert system skal fungere som forventet for at nå det resultat, kunden forventer: levering af produktet som lovet. Derfor er det første trin i BCP for en kritisk proces at forstå alle understøttende systemer.

Figur A

Intern systemforsyningskæde

På grund af pladsbegrænsningerne i en blogartikel har jeg ikke inkluderet netværkskomponenter i denne grafik. Imidlertid findes mellem hvert af systemerne kabling, switches, routere, IPS / IDS osv. Derudover er cloud-tjenester, der leverer et komplet system eller systemkomponent, også vigtige elementer i din interne IT-forsyningskæde. Medtag alle netværk og sky-tjenester i din supply chain-grafik. Din grafik vil sandsynligvis være meget større end min.

Maksimal tolerabel periode med forstyrrelse

MTPOD, nogle gange kaldet maksimal acceptabel nedetid, er den samlede tid, en forretningsproces kan være inaktiv, før en virksomhed lider uoprettelig skade. MTPOD inkluderer den samlede MTTR og procescyklustid. Cyklustid repræsenterer den periode, der er nødvendig for at gennemføre en enkelt iteration af den berørte forretningsproces fra fiasko. Hvis f.eks. S3 (figur A) mislykkedes, er cyklustiden den periode, der kræves for at behandle al input fra S2 og skibsprodukt.

Gennemsnitstid til reparation

Mens MTPOD henviser til den berørte proces, gælder MTTR for individuelle komponenter (system- og netværksenheder). Det er den gennemsnitlige tid, der kræves for at returnere et mislykket trin i en proces til normal drift. Samlet MTTR er den gennemsnitlige tid, der kræves for at gendanne alle mislykkede systemer eller komponenter under en udbredt begivenhed med forretningskontinuitet. MTTR påvirkes af mange variabler, herunder:

  • Typen af ​​fiasko . En kabelfejl er meget lettere at reparere end en strømforsyningsfejl.
  • Tilgængelighed af reservedele . Mange organisationer holder reservedele til rådighed til kritiske komponenter, herunder kabling. Hvis dele skal bestilles eller installeres af leverandører, er ledetider, rejsetider osv. En nødvendig del af MTTR.
  • Intern overvågningskapacitet og færdigheder . Hvor lang tid tager det et IT-team at identificere en fiasko og bestemme dens årsag? Korrekt personaleuddannelse og vedligeholdelse af ajourført system- og netværksdokumentation yder kritisk støtte til denne indsats.
  • Tilgængelighed af interne nøglepersoner l. Tid på dagen, meddelelsesprocesser og korrekt time-off-styring påvirker ankomsten af ​​personale, der er nødvendigt for at styre en forretningskontinuitetshændelse.
  • Vedligeholdelse på plads . Den tid det tager for sælgers respons og levering af reservedele påvirkes direkte af formelle aftaler og SLA'er.
  • Effektiviteten af ​​BCP, inklusive katastrofebetjening.

Hver komponent har en MTTR unik for din organisation. Justering af SLA'er, dokumentation og øvelse af hændelsesrespons og sikring af nøgelpersonale er på vagt er eksempler på forhold, der kan forkorte MTTR.

Mål for genopretningstid

RTO er det punkt, hvor mislykkede enheder skal være operationelle, givet procescyklustid (se figur B. ). Den samlede MTTR kan ikke overstige RTO. Hvis det sker, vil tiden til at producere den krævede output strække sig ud over MTPOD. Øvelser med bedring af katastrofe er et godt eksempel på test af RTO. Hvis procesgendannelsesperioden strækker sig ud over RTO, er MTTR-justeringer nødvendige for en eller flere gendannede proceskomponenter.

Figur B

Cloud-tjenester påvirker MTPOD

Det er relativt let at kontrollere begivenhedsplanlægning af forretningskontinuitet, når alle komponenter er i en organisations eget datacenter. Imidlertid kan der opstå vanskeligheder, hvis der ikke udøves due diligence under valg af cloud-udbyder og kontraktforhandlinger. Figur C viser, hvordan vores eksempelproces kan se ud, hvis ordreregistrering flyttes til en udbyder. Organisationen har ikke længere direkte kontrol over den infrastruktur, platforme eller software, der kræves for at opretholde proceskontinuitet.

Fig

At flytte et eller flere systemer til skyen giver en betydelig fordel for organisationen: indeslutning af katastrofale begivenhedseffekter. For eksempel kræver tabet af denne organisations datacenter gendannelse af S2, S3 og S4. Den eneste gendannelsesaktivitet for S1 er imidlertid gendannelse af forbindelse til S2. Dette tjener til at gøre det meget lettere at nå den definerede RTO.

Problemer kan opstå, når fejlen er på udbyderens websted. SLA'er, sanktioner, kunderevisioner og kontraktlige forpligtelser kontrollerer og overvåger MTTR for S1 i vores eksempel. Udbyderens omdømme, understøttet af diskussioner med eksisterende kunder, er et godt mål for udbyderens vilje og evne til at komme sig inden for den forventede MTTR. Under alle omstændigheder er en udbyder, der ikke kan gendanne inden for RTO'er for berørte forretningsprocesser, sandsynligvis ikke den rigtige løsning til din virksomhed.

Det sidste ord

Gendannelse fra begivenheder i forretningskontinuitet, de situationer, hvor forretningsprocesser mislykkes, kræver MTPOD nøje opmærksomhed. Justering af MTTR for alle system- og netværkskomponenter hjælper med at opnå RTO-elementet i MTPOD. Det er afhængig af flere faktorer, herunder hurtig påvisning af rodårsager samt tilgængelighed og kapacitet for genoprettelsespersonale.

Cyklustid er en anden afgørende faktor, når man beregner MTPOD. Den periode, der er nødvendig for at producere det første sæt af resultater, når holdene genopretter en proces, kan ikke overstige den resterende periode mellem RTO og MTPOD-endepunktet. Hvis det sker, er den sandsynlige løsning justeringer af samlet MTTR.

At flytte en eller flere proceskomponenter til skyen kan hjælpe med at reducere den samlede MTTR, når der sker en katastrofal begivenhed. Den rigtige udbyder, der styres af fair, men aggressiv kundeovervågning af SLA'er og kontraktmæssige krav, kan gøre opsving lettere. Den forkerte udbyder kan køre cloud-hostet komponent MTTR ud over RTO'er. Vælg klogt.

© Copyright 2020 | mobilegn.com