Hej alla, mitt namn är Igor Tyukachev och jag är en affärskontinuitetskonsult. I dagens inlägg kommer vi att ha en lång och tråkig diskussion om vanliga sanningar. Jag vill dela med mig av min erfarenhet och prata om de största misstagen som företag gör när de utvecklar en affärskontinuitetsplan.
1. RTO och RPO slumpmässigt
Det viktigaste misstaget jag sett är att återhämtningstiden (RTO) tas ur luften. Tja, ur tomma luften - det finns till exempel några siffror från två år sedan från SLA som någon tog med sig från sin tidigare arbetsplats. Varför gör de detta? När allt kommer omkring, enligt alla metoder, måste du först analysera konsekvenserna för affärsprocesser, och baserat på denna analys, beräkna målåterställningstiden och acceptabel dataförlust. Men att göra en sådan analys tar ibland lång tid, ibland är det dyrt, ibland är det inte särskilt tydligt hur – betona vad som behöver göras. Och det första som kommer att tänka på för många är: ”Vi är alla vuxna och förstår hur affärer fungerar. Låt oss inte slösa tid och pengar! Låt oss ta plus eller minus som det ska vara. Ut ur ditt huvud, med proletär uppfinningsrikedom! Låt RTO vara två timmar.”
Vad leder detta till? När du kommer till ledningen för pengar för aktiviteter för att säkerställa erforderlig RTO/RPO med vissa siffror, kräver det alltid motivering. Om det inte finns någon motivering, då uppstår frågan: var fick du det ifrån? Och det finns inget att svara på. Som ett resultat tappar förtroendet för ditt arbete.
Dessutom kostar dessa två timmars återhämtning ibland en miljon dollar. Och att motivera RTO:s varaktighet är en fråga om pengar, och mycket stora sådana.
Och slutligen, när du tar med din BCP- och/eller DR-plan till artisterna (som faktiskt kommer att springa och vifta med armarna i ögonblicket för olyckan), kommer de att ställa en liknande fråga: var kom dessa två timmar ifrån? Och om du inte kan förklara detta tydligt, kommer de inte att ha förtroende för varken dig eller ditt dokument.
Det visar sig vara ett papper för en papperslapps skull, en avanmälan. Förresten, vissa gör detta medvetet, helt enkelt för att tillgodose regulatorns krav.
Du har det
2. Botemedlet mot allt
Vissa människor tror att en BCP-plan är utvecklad för att skydda alla affärsprocesser från alla hot. Nyligen ställdes frågan "Vad vill vi skydda oss från?" Jag hörde svaret: "Allt och mer."
Men faktum är att planen endast är avsedd att skydda specifika viktiga affärsprocesser i företaget från specifika hot. Därför, innan du utvecklar en plan, är det nödvändigt att bedöma förekomsten av risker och analysera deras konsekvenser för verksamheten. Riskbedömning behövs för att förstå vilka hot företaget är rädd för. Vid byggnadsförstöring kommer det att finnas en kontinuitetsplan, vid sanktionstryck - en annan, vid översvämning - en tredje. Även två identiska platser i olika städer kan ha väsentligt olika planer.
Det är omöjligt att skydda ett helt företag med en BCP, särskilt en stor. Till exempel började den enorma X5 Retail Group säkerställa kontinuitet med två viktiga affärsprocesser (vi skrev om detta ). Och det är helt enkelt orealistiskt att innesluta hela företaget med en plan, det här är från kategorin "kollektivt ansvar", när alla är ansvariga och ingen är ansvarig.
ISO 22301-standarden innehåller konceptet med en policy, med vilken i själva verket kontinuitetsprocessen i företaget börjar. Den beskriver vad vi ska skydda och från vad. Om folk kommer springande och ber att få lägga till det och det, till exempel:
— Låt oss lägga till BCP risken att vi blir hackade?
Eller
— Nyligen, under regnet, översvämmades vår översta våning - låt oss lägga till ett scenario om vad vi ska göra i händelse av översvämning?
Hänvisa dem sedan omedelbart till denna policy och säg att vi skyddar specifika företagstillgångar och endast från specifika, i förväg överenskomna hot, eftersom de är prioritet nu.
Och även om förslag till förändringar verkligen är lämpliga, erbjud dig att ta hänsyn till dem i nästa version av policyn. För att skydda ett företag kostar mycket pengar. Så alla ändringar av BCP-planen måste gå igenom budgetkommittén och planeringen. Vi rekommenderar att du ser över företagets policy för affärskontinuitet en gång per år eller omedelbart efter betydande förändringar i företagets struktur eller externa förutsättningar (må läsarna förlåta att jag säger det).
3. Fantasier och verklighet
Det händer ofta att författarna när de utarbetar en BCP-plan beskriver en idealbild av världen. Till exempel, "vi har inte ett andra datacenter, men vi kommer att skriva en plan som om vi hade." Eller så har verksamheten ännu inte någon del av infrastrukturen, men anställda kommer ändå att lägga till den i planen i hopp om att den ska dyka upp i framtiden. Och sedan kommer företaget att sträcka ut verkligheten på planen: bygga ett andra datacenter, beskriva andra förändringar.
Till vänster finns den infrastruktur som motsvarar BCP, till höger är den verkliga infrastrukturen
Allt detta är ett misstag. Att skriva en BCP-plan innebär att spendera pengar. Om du skriver en plan som inte fungerar just nu, kommer du att betala för mycket dyra papper. Det är omöjligt att återhämta sig från det, det är omöjligt att testa det. Det visar sig vara arbete för arbetets skull.
Du kan skriva en plan ganska snabbt, men att bygga en backup-infrastruktur och lägga pengar på alla skyddslösningar är långt och dyrt. Detta kan ta mer än ett år. Och det kan visa sig att du redan har en plan, och infrastrukturen för den kommer att dyka upp om två år. Varför behövs en sådan plan? Vad kommer det att skydda dig från?
Det är också en fantasi när BCP:s utvecklingsteam börjar ta reda på för experterna vad de ska göra och i vilken tid. Det kommer från kategorin: ”När du ser en björn i taigan måste du vända i motsatt riktning från björnen och springa med en hastighet som överstiger björnens hastighet. Under vintermånaderna måste du täcka dina spår.”
4. Toppar och rötter
Det fjärde viktigaste misstaget är att göra planen för ytlig eller för detaljerad. Vi behöver en gyllene medelväg. Planen ska inte vara för detaljerad för idioter, men den ska inte vara för allmän så att något sånt här hamnar:
På lätt i allmänhet
5. Till Caesar - vad är Caesars, för mekanikern - vad är mekanikerns.
Nästa misstag härrör från det föregående: en plan kan inte rymma alla åtgärder för alla ledningsnivåer. BCP-planer utvecklas vanligtvis för stora företag med stora finansiella flöden (förresten, enligt vår I genomsnitt råkade 48 % av de stora ryska företagen i nödsituationer som medförde betydande ekonomiska förluster) och ett ledningssystem på flera nivåer. För sådana företag är det inte värt att försöka få ihop allt i ett dokument. Om företaget är stort och strukturerat bör planen ha tre separata nivåer:
- strategisk nivå - för högsta ledningen;
- taktisk nivå - för mellanchefer;
- och den operativa nivån - för de som är direkt involverade i fältet.
Om vi till exempel pratar om att återställa en misslyckad infrastruktur, så fattas på strategisk nivå beslutet att aktivera återhämtningsplanen, på taktisk nivå kan processprocedurerna beskrivas och på operativ nivå finns instruktioner för idrifttagning av specifika utrustning.
BCP utan budget
Alla ser sitt ansvarsområde och kopplingar till andra medarbetare. I ögonblicket för en olycka öppnar alla en plan, hittar snabbt sin del och följer den. Helst måste du komma ihåg utantill vilka sidor du ska öppna, för ibland räknas minuterna.
6. Rollspel
Ett annat misstag när man upprättar en BCP-plan: det finns inget behov av att inkludera specifika namn, e-postadresser och annan kontaktinformation i planen. I själva dokumentets text bör endast opersonliga roller anges, och dessa roller bör tilldelas namnen på de ansvariga för specifika uppgifter och deras kontakter bör anges i bilagan till planen.
Varför?
Idag byter de flesta jobb vartannat till vart tredje år. Och om du skriver ner alla ansvariga och deras kontakter i plantexten, då måste den hela tiden ändras. Och i stora företag, och särskilt statliga, kräver varje ändring av alla dokument massor av godkännanden.
För att inte tala om att om en nödsituation inträffar och du frenetiskt måste bläddra igenom planen och leta efter rätt kontakt så kommer du att förlora dyrbar tid.
Life hack: när du ändrar en applikation behöver du ofta inte ens godkänna den. Ett annat tips: du kan använda automatiseringssystem för planuppdatering.
7. Brist på versionshantering
Vanligtvis skapar de en planversion 1.0 och gör sedan alla ändringar utan redigeringsläge och utan att ändra filnamnet. Samtidigt är det ofta oklart vad som har förändrats jämfört med den tidigare versionen. I avsaknad av versionering lever planen sitt eget liv, som inte spåras på något sätt. Den andra sidan av en BCP-plan bör ange versionen, författaren till ändringarna och en lista över själva ändringarna.
Ingen kan komma på det längre
8. Vem ska jag fråga?
Ofta har företag ingen ansvarig för BCP-planen och det finns ingen separat avdelning som ansvarar för kontinuiteten i verksamheten. Detta hedervärda ansvar tilldelas CIO, hans ställföreträdare, eller enligt principen "du sysslar med informationssäkerhet, så här är BCP i tillägg." Som ett resultat är planen utvecklad, överenskommen och godkänd, uppifrån och ner.
Vem är ansvarig för att lagra planen, uppdatera och revidera informationen i den? Detta får inte föreskrivas. Att anställa en separat anställd för detta är slöseri, men att ladda en av de befintliga med ytterligare arbetsuppgifter är naturligtvis möjligt, eftersom alla nu strävar efter effektivitet: "Låt oss hänga en lykta på honom så att han kan klippa på natten," men är det nödvändigt?
Vi söker ansvariga för BCP två år efter dess tillkomst
Därför händer det ofta så här: en plan togs fram och lades i en lång låda för att bli täckt av damm. Ingen testar det eller upprätthåller dess relevans. Den vanligaste frasen jag hör när jag kommer till en kund är: "Det finns en plan, men den utvecklades för länge sedan, om den testades är okänt, det finns en misstanke om att den inte fungerar."
9. För mycket vatten
Det finns planer där inledningen är fem sidor lång, inklusive en beskrivning av förutsättningarna och tack till alla deltagare i projektet, med information om vad företaget gör. När du scrollar ner till den tionde sidan, där det finns användbar information, har ditt datacenter redan översvämmats.
När du försöker läsa upp till nu, vad ska du göra om ditt datacenter är översvämmat?
Placera allt företags "vatten" i ett separat dokument. Själva planen måste vara extremt specifik: den som ansvarar för denna uppgift gör detta osv.
10. På vems bekostnad är banketten?
Ofta har planskapare inte stöd från företagets högsta ledning. Men det finns stöd från mellancheferna som inte klarar eller inte har den nödvändiga budgeten och resurserna för att hantera affärskontinuiteten. Till exempel skapar IT-avdelningen sin BCP-plan inom sin budget, men CIO:n ser inte hela företagsbilden. Mitt favoritexempel är videokonferenser. När vd:ns videokonferenser inte fungerar, vem ska han urskilja? CIO som "inte gav." Därför, ur CIO:s synvinkel, vad är det viktigaste i företaget? Vad folk alltid "älskar" honom för: videokonferenser, som omedelbart förvandlas till ett affärskritiskt system. Och ur affärssynpunkt - ja, ingen VKS, tänk bara, vi pratar i telefon, som under Brezhnev ...
Dessutom brukar IT-avdelningen tycka att dess huvuduppgift i händelse av en katastrof är att återställa driften av företagens IT-system. Men ibland behöver du inte göra det här! Om det finns en affärsprocess i form av att skriva ut pappersbitar på en fruktansvärt dyr skrivare, bör du inte köpa en andra sådan skrivare som reserv och placera den bredvid den i händelse av ett haveri. Det kan räcka med att tillfälligt färglägga pappersbitarna för hand.
Om vi bygger ett kontinuerligt skydd inom IT måste vi anlita stöd från ledande befattningshavare och företagsrepresentanter. Annars kan du, efter att ha förpuppat sig inne på IT-avdelningen, lösa ett visst antal problem, men inte alla nödvändiga.
Så här ser läget ut när bara IT-avdelningen har DR-planer
10. Ingen testning
Om det finns en plan måste den testas. För de som inte är bekanta med standarderna är detta inte alls självklart. Du har till exempel "nödutgångsskyltar" hängande överallt. Men säg mig, var är din eldhink, krok och spade? Var är brandposten? Var ska brandsläckaren sitta? Men alla borde veta detta. Det verkar inte alls logiskt för oss att hitta en brandsläckare när vi går in på ett kontor.
Kanske borde behovet av att testa planen nämnas i själva planen, men detta är ett kontroversiellt beslut. En plan kan i alla fall anses fungera endast om den har testats minst en gång. Som nämnts ovan får jag väldigt ofta höra: ”Det finns en plan, all infrastruktur är förberedd, men det är inte ett faktum att allt kommer att fungera som det står i planen. För de testade det inte. Aldrig".
Sammanfattningsvis
Vissa företag kan analysera sin historia för att förstå vilken typ av problem som sannolikt kommer att hända och hur troliga de är. Forskning och erfarenhet tyder på att vi inte kan skydda oss från allt. Skit, förr eller senare, händer vilket företag som helst. En annan sak är hur förberedd du kommer att vara för denna eller liknande situation och om du kommer att kunna återställa din verksamhet i tid.
En del tror att kontinuitet handlar om hur man eliminerar alla möjliga risker så att de inte förverkligas. Nej, poängen är att risker kommer att materialiseras, och vi kommer att vara redo för detta. Soldater är tränade att inte tänka i strid, utan att agera. Det är samma sak med en BCP-plan: den gör att du kan återställa din verksamhet så snabbt som möjligt.
Den enda utrustningen som inte kräver BCP
Igor Tyukachev,
Affärskontinuitetskonsult
Centrum för design av datorsystem
"Jet Infosystems"
Källa: will.com