Hej alle sammen, mit navn er Igor Tyukachev og jeg er en forretningskontinuitetskonsulent. I dagens indlæg vil vi have en lang og kedelig diskussion af fælles sandheder. Jeg vil gerne dele min erfaring og tale om de vigtigste fejl, som virksomheder begår, når de udvikler en forretningskontinuitetsplan.
1. RTO og RPO tilfældigt
Den vigtigste fejl, jeg har set, er, at recovery time (RTO) er taget ud af den blå luft. Nå, ud af den blå luft – for eksempel er der nogle tal fra to år siden fra SLA, som nogen havde med fra deres tidligere arbejdsplads. Hvorfor gør de dette? Når alt kommer til alt, skal du ifølge alle metoder først analysere konsekvenserne for forretningsprocesser, og baseret på denne analyse beregne den målrettede genopretningstid og acceptabelt datatab. Men at lave en sådan analyse tager nogle gange lang tid, nogle gange er det dyrt, nogle gange er det ikke helt klart hvordan - understreg hvad der skal gøres. Og det første, der kommer til at tænke på for mange, er: ”Vi er alle voksne og forstår, hvordan forretning fungerer. Lad os ikke spilde tid og penge! Lad os tage plus eller minus, som det skal være. Ud af dit hoved, ved at bruge proletarisk opfindsomhed! Lad RTO være to timer."
Hvad fører dette til? Når du kommer til ledelsen for penge til aktiviteter for at sikre den nødvendige RTO/RPO med bestemte tal, kræver det altid begrundelse. Hvis der ikke er nogen begrundelse, opstår spørgsmålet: hvor har du det fra? Og der er ikke noget at svare på. Som et resultat er tilliden til dit arbejde tabt.
Desuden koster de to timers bedring nogle gange en million dollars. Og retfærdiggørelse af RTO'ens varighed er et spørgsmål om penge, og det er meget store.
Og endelig, når du bringer din BCP- og/eller DR-plan til de optrædende (som faktisk vil løbe og vifte med armene i ulykkesøjeblikket), vil de stille et lignende spørgsmål: hvor kom disse to timer fra? Og hvis du ikke kan forklare dette klart, så vil de ikke have tillid til hverken dig eller dit dokument.
Det viser sig at være et stykke papir for et stykke papirs skyld, en afmelding. I øvrigt gør nogle dette bevidst, simpelthen for at opfylde regulatorens krav.
godt du forstår
2. Kuren mod alt
Nogle mennesker tror, at en BCP-plan er udviklet for at beskytte alle forretningsprocesser mod eventuelle trusler. For nylig er spørgsmålet "Hvad vil vi beskytte os mod?" Jeg hørte svaret: "Alt og mere."
Men faktum er, at planen kun er beregnet til at beskytte bestemt centrale forretningsprocesser i virksomheden fra bestemt trusler. Derfor er det nødvendigt at vurdere forekomsten af risici, før man udvikler en plan, og analysere deres konsekvenser for virksomheden. Risikovurdering er nødvendig for at forstå, hvilke trusler virksomheden er bange for. I tilfælde af ødelæggelse af bygninger vil der være én kontinuitetsplan, i tilfælde af sanktionspres - en anden, i tilfælde af oversvømmelse - en tredje. Selv to identiske steder i forskellige byer kan have væsentligt forskellige planer.
Det er umuligt at beskytte en hel virksomhed med én BCP, især en stor. For eksempel begyndte den enorme X5 Retail Group at sikre kontinuitet med to vigtige forretningsprocesser (vi skrev om dette ). Og det er simpelthen urealistisk at omslutte hele virksomheden med én plan, det er fra kategorien "kollektivt ansvar", når alle er ansvarlige og ingen er ansvarlige.
ISO 22301-standarden indeholder konceptet om en politik, hvormed kontinuitetsprocessen i virksomheden faktisk starter. Den beskriver, hvad vi vil beskytte og mod hvad. Hvis folk kommer løbende og beder om at tilføje dit og dat, for eksempel:
— Lad os tilføje BCP risikoen for, at vi bliver hacket?
eller
— For nylig, under regnen, blev vores øverste etage oversvømmet - lad os tilføje et scenarie for, hvad vi skal gøre i tilfælde af oversvømmelse?
Henvis dem derefter straks til denne politik og sig, at vi beskytter specifikke virksomhedsaktiver og kun mod specifikke, på forhånd aftalte trusler, fordi de er prioriteret nu.
Og selvom forslag til ændringer faktisk er passende, så tilbud at tage hensyn til dem i den næste version af politikken. Fordi det koster mange penge at beskytte en virksomhed. Så alle ændringer af BCP-planen skal gå gennem budgetudvalget og planlægningen. Vi anbefaler at gennemgå virksomhedens forretningskontinuitetspolitik en gang om året eller umiddelbart efter væsentlige ændringer i virksomhedens struktur eller eksterne forhold (må læserne tilgive mig at sige det).
3. Fantasier og virkelighed
Det sker ofte, at forfatterne, når de udarbejder en BCP-plan, beskriver et eller andet idealbillede af verden. For eksempel, "vi har ikke et andet datacenter, men vi vil skrive en plan, som om vi havde." Eller virksomheden har endnu ikke en del af infrastrukturen, men medarbejderne vil stadig tilføje den til planen i håb om, at den dukker op i fremtiden. Og så vil virksomheden strække virkeligheden ind på planen: Byg et andet datacenter, beskriv andre ændringer.
Til venstre er infrastrukturen svarende til BCP, til højre er den rigtige infrastruktur
Det hele er en fejl. At skrive en BCP-plan betyder at bruge penge. Hvis du skriver en plan, der ikke virker lige nu, kommer du til at betale for meget dyrt papir. Det er umuligt at komme sig fra det, det er umuligt at teste det. Det viser sig at være arbejde for arbejdets skyld.
Du kan skrive en plan ret hurtigt, men at bygge en backup-infrastruktur og bruge penge på alle beskyttelsesløsninger er lang og dyrt. Dette kan tage mere end et år. Og det kan vise sig, at man allerede har en plan, og infrastrukturen til den dukker op om to år. Hvorfor er sådan en plan nødvendig? Hvad vil det beskytte dig mod?
Det er også en fantasi, når BCP-udviklingsteamet begynder at finde ud af for eksperterne, hvad de skal gøre og på hvilket tidspunkt. Det kommer fra kategorien: ”Når du ser en bjørn i taigaen, skal du dreje i den modsatte retning fra bjørnen og løbe med en hastighed, der overstiger bjørnens hastighed. I vintermånederne skal du dække dine spor."
4. Toppe og rødder
Den fjerde vigtigste fejl er at gøre planen enten for overfladisk eller for detaljeret. Vi har brug for en gylden middelvej. Planen skal ikke være for detaljeret for idioter, men den bør ikke være for generel, så sådan noget ender med:
På let generelt
5. Til Cæsar - hvad er Cæsars, til mekanikeren - hvad er mekanikers.
Den næste fejl stammer fra den forrige: én plan kan ikke rumme alle handlinger for alle ledelsesniveauer. BCP-planer udvikles normalt til store virksomheder med store finansielle strømme (i øvrigt ifølge vores 48 % af de store russiske virksomheder stødte i gennemsnit på nødsituationer, der medførte betydelige økonomiske tab) og et multi-level management system. For sådanne virksomheder er det ikke værd at prøve at passe alt ind i ét dokument. Hvis virksomheden er stor og struktureret, skal planen have tre separate niveauer:
- strategisk niveau - for den øverste ledelse;
- taktisk niveau - for mellemledere;
- og det operationelle niveau - for de direkte involverede i felten.
For eksempel, hvis vi taler om at genoprette en svigtet infrastruktur, så træffes beslutningen på det strategiske niveau om at aktivere genopretningsplanen, på det taktiske niveau kan procesprocedurerne beskrives, og på det operationelle niveau er der instruktioner til idriftsættelse af specifikke udstyrsstykker.
BCP uden budget
Alle ser deres ansvarsområde og forbindelser til andre medarbejdere. I ulykkesøjeblikket åbner alle en plan, finder hurtigt deres del og følger den. Ideelt set skal du huske udenad, hvilke sider du skal åbne, for nogle gange tæller minutterne.
6. Rollespil
En anden fejl ved udarbejdelsen af en BCP-plan: Der er ingen grund til at inkludere specifikke navne, e-mailadresser og andre kontaktoplysninger i planen. I selve dokumentets tekst bør kun upersonlige roller angives, og disse roller bør tildeles navnene på de ansvarlige for specifikke opgaver, og deres kontakter bør være anført i bilaget til planen.
Hvorfor?
I dag skifter de fleste job hvert andet til tredje år. Og hvis du skriver alle de ansvarlige og deres kontakter ned i teksten til planen, så skal det hele tiden ændres. Og i store virksomheder, og især offentlige, kræver enhver ændring af et dokument et væld af godkendelser.
For ikke at nævne, at hvis en nødsituation opstår, og du febrilsk skal bladre i planen og lede efter den rigtige kontakt, vil du miste kostbar tid.
Life hack: Når du ændrer en applikation, behøver du ofte ikke engang at godkende den. Et andet tip: du kan bruge automatiseringssystemer til planopdatering.
7. Manglende versionering
Normalt opretter de en plan version 1.0 og laver derefter alle ændringer uden redigeringstilstand og uden at ændre filnavnet. Samtidig er det ofte uklart, hvad der er ændret i forhold til den tidligere version. I mangel af versionering lever planen sit eget liv, som ikke spores på nogen måde. Den anden side af enhver BCP-plan skal angive versionen, forfatteren til ændringerne og en liste over selve ændringerne.
Ingen kan finde ud af det længere
8. Hvem skal jeg spørge?
Ofte har virksomheder ikke en person, der er ansvarlig for BCP-planen, og der er ingen separat afdeling, der er ansvarlig for forretningskontinuitet. Dette ærefulde ansvar er tildelt CIO'en, hans stedfortræder, eller ifølge princippet "du beskæftiger dig med informationssikkerhed, så her er BCP i tillæg." Som følge heraf er planen udviklet, vedtaget og godkendt fra top til bund.
Hvem er ansvarlig for at opbevare planen, opdatere og revidere oplysningerne i den? Dette kan ikke ordineres. Det er spild at ansætte en separat medarbejder til dette, men at belaste en af de eksisterende med ekstra opgaver er selvfølgelig muligt, fordi alle nu stræber efter effektivitet: "Lad os hænge en lanterne på ham, så han kan klippe om natten," men er det nødvendigt?
Vi søger ansvarlige for BCP to år efter dets oprettelse
Derfor sker det ofte sådan: en plan blev udviklet og lagt i en lang kasse for at blive dækket af støv. Ingen tester det eller fastholder dets relevans. Den mest almindelige sætning, jeg hører, når jeg kommer til en kunde, er: "Der er en plan, men den er udviklet for længe siden, om den er testet er ukendt, der er en mistanke om, at den ikke virker."
9. For meget vand
Der er planer, hvor introduktionen er på fem sider, herunder en beskrivelse af forudsætningerne og tak til alle deltagere i projektet, med information om, hvad virksomheden laver. Når du scroller ned til den tiende side, hvor der er brugbar information, er dit datacenter allerede blevet oversvømmet.
Når du forsøger at læse op til øjeblikket, hvad skal du så gøre, hvis dit datacenter er oversvømmet?
Anbring alt virksomhedens "vand" i et separat dokument. Selve planen skal være yderst specifik: den person, der er ansvarlig for denne opgave, gør dette, og så videre.
10. For hvis regning er banketten?
Ofte har planskabere ikke støtte fra virksomhedens øverste ledelse. Men der er opbakning fra mellemledelsen, som ikke administrerer eller ikke har det nødvendige budget og ressourcer til at styre forretningskontinuiteten. For eksempel opretter it-afdelingen sin BCP-plan inden for sit budget, men CIO'en ser ikke hele virksomhedens billede. Mit foretrukne eksempel er videokonferencer. Når den administrerende direktørs videokonferencer ikke fungerer, hvem vil han så fjerne indvoldene? CIO'en, der "ikke leverede." Derfor, set fra CIO'ens synspunkt, hvad er det vigtigste i virksomheden? Hvad folk altid "elsker" ham for: videokonferencer, som straks bliver til et forretningskritisk system. Og fra et forretningsmæssigt synspunkt - ja, ingen VKS, tænk bare, vi taler i telefon, som under Brezhnev ...
Derudover mener it-afdelingen normalt, at dens hovedopgave i tilfælde af en katastrofe er at genoprette driften af virksomhedens it-systemer. Men nogle gange behøver du ikke at gøre dette! Hvis der er en forretningsproces i form af at udskrive stykker papir på en frygtelig dyr printer, bør du ikke købe en anden sådan printer som reserve og placere den ved siden af den i tilfælde af et sammenbrud. Det kan være nok midlertidigt at farve papirstykkerne i hånden.
Hvis vi bygger kontinuerlig beskyttelse inden for IT, skal vi søge støtte fra topledelsen og forretningsrepræsentanter. Ellers kan du, efter at have forpuppet dig inde i IT-afdelingen, løse en række problemer, men ikke alle de nødvendige.
Sådan ser situationen ud, når kun it-afdelingen har DR-planer
10. Ingen test
Hvis der er en plan, skal den testes. For dem, der ikke er bekendt med standarderne, er dette slet ikke indlysende. For eksempel har du "nødudgangsskilte" hængende overalt. Men fortæl mig, hvor er din brandspand, krog og skovl? Hvor er brandhanen? Hvor skal ildslukkeren placeres? Men alle burde vide dette. Det forekommer os slet ikke logisk at finde en ildslukker, når vi går ind på et kontor.
Måske skal behovet for at teste planen nævnes i selve planen, men det er en kontroversiel beslutning. Under alle omstændigheder kan en plan kun anses for at fungere, hvis den er blevet testet mindst én gang. Som nævnt ovenfor hører jeg meget ofte: ”Der er en plan, al infrastruktur er forberedt, men det er ikke en kendsgerning, at alt kommer til at fungere som skrevet i planen. For de testede det ikke. Aldrig".
Afslutningsvis
Nogle virksomheder kan analysere deres historie for at forstå, hvilken slags problemer der sandsynligvis vil ske, og hvor sandsynlige de er. Forskning og erfaringer tyder på, at vi ikke kan beskytte os mod alt. Shit, før eller siden, sker for enhver virksomhed. En anden ting er, hvor forberedt du vil være på denne eller en lignende situation, og om du vil være i stand til at genoprette din virksomhed i tide.
Nogle mennesker tror, at kontinuitet handler om, hvordan man fjerner alle mulige risici, så de ikke bliver til noget. Nej, pointen er, at risici vil materialisere sig, og det vil vi være klar til. Soldater er trænet til ikke at tænke i kamp, men til at handle. Det er det samme med en BCP-plan: den giver dig mulighed for at genoprette din virksomhed så hurtigt som muligt.
Det eneste udstyr, der ikke kræver BCP
Igor Tyukachev,
Forretningskontinuitetskonsulent
Center for Design af Computersystemer
"Jet infosystemer"
Kilde: www.habr.com