Prekid rada poslovnih sustava rijetko pogađa samo IT odjel. Kada nisu dostupni poslovni program, e-pošta, dokumentacija, mreža ili podaci o kupcima, posljedice se vide u prodaji, računovodstvu, proizvodnji, komunikaciji s partnerima i rokovima prema klijentima. Dobar vodič za plan kontinuiteta poslovanja zato ne počinje kupnjom dodatne opreme, nego jasnim odgovorom na pitanje: koje procese tvrtka mora nastaviti obavljati, čak i kada dio sustava nije dostupan?
Plan kontinuiteta poslovanja, često označen kraticom BCP prema engleskom nazivu Business Continuity Plan, opisuje kako organizacija održava kritične aktivnosti tijekom poremećaja. To može biti kvar servera, prekid internetske veze, ransomware, nedostupnost poslovne lokacije, pogrešno obrisani podaci ili nedostupnost ključnog dobavljača. IT je važan dio takvog plana, ali plan mora uključiti i ljude, poslovne procese, odgovornosti te način donošenja odluka pod pritiskom.
Vodič za plan kontinuiteta poslovanja počinje poslovnim procesima
Česta je pogreška krenuti od tehnologije: napraviti popis servera, licenci i mrežne opreme, a zatim pretpostaviti da je to plan kontinuiteta. Takav popis jest potreban, ali ne govori što je poslovanju zaista prioritet.
Za početak odredite procese bez kojih tvrtka ne može raditi ili ne može ispuniti ugovorene obveze. Primjerice, distributer može privremeno funkcionirati bez pojedinog internog izvještaja, ali ne i bez sustava za zaprimanje narudžbi, skladišnih podataka i izdavanja otpremnica. Računovodstveni servis možda može odgoditi dio administrativnih aktivnosti, ali pristup dokumentaciji i aplikaciji za obračun u određenim rokovima mora ostati moguć.
Za svaki proces korisno je utvrditi četiri stvari: tko je poslovni vlasnik procesa, koje aplikacije i podatke koristi, o kojim osobama ili vanjskim dobavljačima ovisi te koliko dugo smije biti nedostupan. Razgovor s voditeljima odjela ovdje vrijedi više od pretpostavki IT tima. Tehnički sustav može djelovati sporedno, a zapravo biti preduvjet za nekoliko ključnih aktivnosti.
Odredite prihvatljivo vrijeme prekida
Dva pojma pomažu pretvoriti općenite zahtjeve u provediv plan. RTO, odnosno ciljano vrijeme oporavka, određuje koliko brzo sustav mora ponovno raditi. RPO, odnosno ciljna točka oporavka, određuje koliko podataka organizacija smije izgubiti.
Ako je RTO za sustav narudžbi četiri sata, postupak oporavka mora realno omogućiti rad unutar tog vremena. Ako je RPO jedan sat, sigurnosna kopija napravljena jednom dnevno nije dovoljna. Za neke sustave prihvatljiv je povrat podataka od prethodne noći. Za druge, poput aktivne baze narudžbi, takav bi gubitak stvorio dodatni ručni rad, neslaganja i poslovni rizik.
Ne postoji univerzalna vrijednost RTO-a i RPO-a. Ona ovisi o djelatnosti, ugovornim obvezama, opsegu transakcija i mogućnosti privremenog ručnog rada. Važno je da odluku potvrdi poslovna odgovorna osoba, a ne da ostane neizrečena pretpostavka IT-a.
Procijenite scenarije koji mogu zaustaviti rad
Plan ne mora sadržavati desetke teorijskih scenarija. Treba obraditi one koji imaju smisla za vašu organizaciju i infrastrukturu. U praksi se često pojavljuju prekidi uzrokovani kvarom fizičke ili virtualne infrastrukture, nedostupnošću interneta, sigurnosnim incidentom, pogrešnom konfiguracijom, ljudskom pogreškom ili problemom kod cloud pružatelja usluge.
Kod svakog scenarija potrebno je razlikovati kratki operativni prekid od ozbiljnijeg incidenta. Ako je problem ograničen na jedan mrežni uređaj, cilj je vratiti uslugu prema uobičajenoj proceduri održavanja. Ako postoji sumnja na kompromitaciju korisničkih računa ili širenje zlonamjernog koda, prioritet se mijenja: prvo treba ograničiti štetu i sačuvati mogućnost sigurnog oporavka, a tek zatim vraćati sustave u rad.
Zato plan mora navesti tko ima ovlast proglasiti incident, tko koordinira tehnički odgovor i tko komunicira prema zaposlenicima, klijentima i dobavljačima. U manjim tvrtkama jedna osoba može imati više uloga, ali zamjena mora biti unaprijed određena. Plan koji ovisi o nedostupnom direktoru ili jedinom administratoru nije potpuni plan.
Backup nije isto što i oporavak
Sigurnosne kopije podataka temelj su kontinuiteta, no sama činjenica da backup postoji ne potvrđuje da će oporavak uspjeti. Potrebno je znati gdje se kopije nalaze, koliko su stare, jesu li zaštićene od neovlaštene izmjene i može li se iz njih vratiti cijeli sustav, a ne samo pojedinačna datoteka.
U poslovnim okruženjima treba obuhvatiti više od datoteka na serveru. To često uključuje virtualne poslužitelje, baze podataka, konfiguracije mrežne opreme, Microsoft 365 sadržaj, poslovne aplikacije, korisničke podatke i dokumentaciju potrebnu za ponovnu instalaciju. Ovisno o rješenju, dio podataka može biti u lokalnoj infrastrukturi, a dio u cloudu. Svaka od tih lokacija ima vlastite mogućnosti i ograničenja oporavka.
Praktična pravila za backup trebaju odgovoriti na sljedeća pitanja:
- koliko često se izrađuju kopije i koliko se dugo čuvaju
- postoji li kopija izvan primarne lokacije ili odvojena od produkcijskog okruženja
- tko prima obavijesti o neuspješnom backupu i kako se problem rješava
- kada je posljednji put provjeren povrat podataka ili cijelog sustava
Posebnu pažnju zahtijeva zaštita administratorskih računa i pristupa backup sustavu. Ako napadač kompromitira iste vjerodajnice koje upravljaju produkcijom i sigurnosnim kopijama, oporavak može postati znatno složeniji. Segmentacija pristupa, višefaktorska autentifikacija i odvojeni administratorski računi ovdje nisu administrativni višak, nego dio zaštite poslovne mogućnosti oporavka.
Dokumentirajte redoslijed oporavka
Nakon prekida nije dovoljno reći da treba vratiti servere. Sustavi imaju ovisnosti. Aplikacija možda ne može raditi bez baze podataka, baza bez identitetskog sustava, a pristup korisnika bez mreže, DNS-a ili VPN-a. Redoslijed oporavka mora biti dokumentiran i provjerljiv.
Za svaku ključnu uslugu dokumentacija treba sadržavati osnovni opis, lokaciju ili platformu na kojoj radi, tehničkog vlasnika, potrebne pristupe, ovisnosti, postupak vraćanja te provjeru uspješnosti. Provjera je važna jer podignut server nije nužno i funkcionalna poslovna usluga. Potrebno je provjeriti prijavu korisnika, pristup podacima, izvršavanje ključne transakcije i povezivanje s drugim sustavima.
Dokumentacija mora biti dostupna i kada primarni sustavi nisu. Ako su lozinke, kontakti dobavljača i tehničke upute spremljeni isključivo na nedostupnom mrežnom disku, tim ih neće moći koristiti u trenutku kada su najpotrebniji. Osjetljivi podaci pritom moraju ostati primjereno zaštićeni, uz kontroliran pristup osobama koje sudjeluju u oporavku.
Predvidite privremeni način rada
Neki procesi mogu kratko raditi bez pune automatizacije. Tvrtka može zaprimati narudžbe prema unaprijed pripremljenom obrascu, voditi evidenciju u kontroliranoj privremenoj tablici ili koristiti alternativni komunikacijski kanal. Takve mjere nisu zamjena za oporavak sustava, ali mogu smanjiti poslovni zastoj.
Privremeni rad mora imati jasna pravila. Treba znati tko smije unositi podatke, gdje se evidentiraju promjene i kako će se one kasnije uskladiti s poslovnim sustavom. Bez toga se nakon oporavka često pojavljuju duplikati, izgubljene narudžbe ili pogrešni podaci o zalihama.
Testiranje pokazuje stvarno stanje plana
Plan kontinuiteta koji se nije testirao više je dokument nego operativna zaštita. Test ne mora odmah značiti potpuno gašenje produkcijskog sustava. Može početi provjerom kontakata i odgovornosti, simulacijom incidenta za upravljački tim, povratom odabrane datoteke ili oporavkom virtualnog servera u izoliranom okruženju.
S vremenom treba provjeriti i složenije scenarije: oporavak poslovne aplikacije zajedno s bazom podataka, rad s rezervne lokacije ili postupanje u slučaju nedostupnosti pojedinog vanjskog pružatelja usluge. Cilj testa nije dokazati da je plan savršen. Cilj je otkriti nedostaju li pristupi, jesu li rokovi realni i razumiju li odgovorne osobe svoje zadatke.
Nakon svakog testa ili stvarnog incidenta zabilježite što je funkcioniralo, gdje je nastalo čekanje i koje mjere treba provesti. Promjena verzije aplikacije, migracija u cloud, nova mrežna oprema ili promjena ključnih zaposlenika mogu plan učiniti zastarjelim brže nego što se očekuje.
Kontinuitet je dio redovitog upravljanja IT-om
Za mala i srednja poduzeća najčešći problem nije nedostatak svijesti o riziku, nego ograničeno vrijeme i nedostatak specijaliziranih resursa. U takvim okolnostima vanjski IT partner može pomoći u snimanju stvarnog stanja, postavljanju backup i recovery postupaka, dokumentiranju infrastrukture te periodičnom testiranju. CarPen Rebuild u takvim angažmanima polazi od poslovnih prioriteta i stvarnih tehničkih ovisnosti, a ne od generičkog popisa kontrola.
Dobar plan kontinuiteta ne mora biti opsežan dokument koji stoji neotvoren. Mora biti dovoljno jasan da odgovorne osobe pod pritiskom znaju što učiniti, koga nazvati i kojim redoslijedom vratiti poslovanje u rad. Najkorisniji prvi korak je odabrati nekoliko procesa čiji prekid tvrtka najmanje može podnijeti i za njih ovaj mjesec provjeriti postoji li stvaran, testiran put do oporavka.