Prekid rada poslovnog sustava rijetko počinje velikim kvarom. Češće se najprije pojavi spor pristup zajedničkim datotekama, povremeno gubljenje mrežne veze, upozorenje o popunjenom disku ili neuspješno sigurnosno kopiranje. Ako se takvi signali zanemare, problem se obično otkrije tek kada zaposlenici ne mogu izdavati račune, pristupiti poslovnoj aplikaciji ili poslati poruku klijentu. Pitanje kako smanjiti prekide poslovnih sustava zato nije samo tehničko pitanje, nego pitanje operativne kontrole i kontinuiteta poslovanja.
Za malu ili srednju tvrtku nekoliko sati nedostupnosti može značiti zaustavljenu prodaju, kašnjenje isporuka, ručni rad koji se poslije mora ispravljati i nepotreban pritisak na zaposlenike. Cilj nije obećati da se nijedan kvar nikada neće dogoditi. Cilj je smanjiti vjerojatnost prekida, ograničiti njegov doseg i omogućiti brz, provjeren povratak u rad.
Prekidi nisu samo kvar servera
Poslovni sustav čini više povezanih dijelova: mrežna oprema, poslužitelji ili cloud usluge, poslovne aplikacije, korisnička računala, identiteti korisnika, internetska veza te sigurnosne kopije. Prekid se može dogoditi na bilo kojoj od tih točaka, ali i na njihovom spoju.
Primjerice, računovodstvena aplikacija može biti potpuno ispravna, dok korisnici ipak ne mogu raditi jer je istekao certifikat, promijenjena mrežna postavka ili nema dovoljno prostora na disku poslužitelja. Slično tome, Microsoft 365 može biti dostupan, ali korisnik bez pravilno postavljenog višefaktorskog pristupa ostaje bez e-pošte u trenutku kada mu je potrebna.
Zato je pogrešno održavanje svesti na povremeno rješavanje prijavljenih problema. Reaktivna podrška vraća rad nakon prekida. Preventivno održavanje traži uvjete koji do prekida mogu dovesti prije nego što korisnici osjete posljedice.
Kako smanjiti prekide poslovnih sustava kroz nadzor
Nadzor sustava nije isto što i povremena provjera radi li sve u tom trenutku. Kvalitetno postavljen nadzor prati stanje ključnih komponenti i upozorava odgovornu osobu kada vrijednosti izlaze iz sigurnih okvira.
To u praksi uključuje dostupnost poslužitelja i mrežnih uređaja, iskorištenost procesora i memorije, slobodan prostor na diskovima, status sigurnosnih kopija, starost ažuriranja, stanje antivirusne zaštite i dostupnost važnih mrežnih servisa. Za organizacije koje ovise o jednoj poslovnoj aplikaciji smisleno je pratiti i dostupnost same aplikacije, a ne samo činjenicu da je poslužitelj uključen.
Nadzor mora biti prilagođen stvarnom radu tvrtke. Upozorenje da je disk popunjen 80 posto ne zahtijeva jednaku reakciju u svakom okruženju. Poslužitelj na kojem se svakodnevno stvaraju velike baze ili dokumenti može do kritične granice doći unutar nekoliko sati. S druge strane, prenisko postavljeni pragovi stvaraju previše obavijesti koje se s vremenom počnu ignorirati.
Dobar nadzor daje prioritet onome što izravno ugrožava poslovanje. To su, primjerice, neuspješan backup, istek sigurnosnog certifikata, nedostupnost internetske veze na lokaciji, kvar diskovnog polja ili pokušaji neovlaštenog pristupa administrativnim računima.
Upozorenje nema vrijednost bez odgovora
Obavijest o problemu nije rješenje ako nije jasno tko je prima, u kojem roku reagira i što treba provjeriti. Tvrtke često imaju alate koji šalju izvještaje, ali nitko redovito ne pregledava kritične poruke ili nema ovlasti intervenirati.
Potrebno je odrediti odgovornu osobu ili vanjskog IT partnera, način eskalacije i kontakt osobe za odluke koje mogu utjecati na rad korisnika. Primjer je planirana nadogradnja poslužitelja: tehnička intervencija može biti kratka, ali termin mora odgovarati poslovnom rasporedu, osobito ako se radi u smjenama ili se obrađuju narudžbe u određenom dijelu dana.
Održavanje smanjuje rizik nakupljenih problema
Velik dio prekida nastaje zbog malih, dugotrajno odgađanih obveza. Neinstalirana ažuriranja, zastarjeli firmware mrežnog uređaja, korisnički računi bivših zaposlenika, diskovi bez dovoljno slobodnog prostora i neprovjerene licence možda neće uzrokovati kvar odmah. Ipak, zajedno stvaraju okruženje u kojem jedan dodatni problem brzo prerasta u zastoj.
Redovito održavanje treba obuhvatiti operativne sustave, poslužitelje, mrežnu opremu, virtualizacijsku platformu i poslovne aplikacije. Ažuriranja se ne provode nasumično tijekom radnog dana. Prije promjene treba procijeniti utjecaj, provjeriti postoji li aktualna sigurnosna kopija, odrediti termin i imati plan povratka na prethodno stanje ako nadogradnja izazove poteškoće.
Ovdje postoji stvaran kompromis. Predugo odgađanje ažuriranja povećava sigurnosni i operativni rizik, dok nekontrolirano instaliranje svih promjena može izazvati nekompatibilnost aplikacija ili prekide rada. Zato je za kritične sustave razumno imati testno okruženje kada je ono opravdano, odnosno provoditi promjene postupno i uz dokumentiran postupak.
Dokumentacija ubrzava svaku intervenciju
Kada dođe do incidenta, vrijeme se najčešće ne gubi samo na popravak, nego na traženje osnovnih informacija: gdje se nalazi sustav, tko ima administratorski pristup, koji je uređaj povezan na koju mrežu, kada je zadnji put promijenjena konfiguracija i gdje se čuvaju podaci za oporavak.
Ažurna dokumentacija treba sadržavati barem pregled infrastrukture, popis ključnih sustava, odgovorne osobe, konfiguraciju mreže, postupke pristupa i zapis promjena. Ne mora biti opsežan dokument koji nitko neće otvoriti. Mora biti točna, dostupna ovlaštenim osobama i redovito ažurirana.
Posebnu pozornost zahtijeva upravljanje korisničkim računima. Pri zapošljavanju, promjeni radnog mjesta i odlasku zaposlenika potrebno je pravodobno dodijeliti, izmijeniti ili ukinuti pristupe. Time se smanjuje sigurnosni rizik, ali i mogućnost da poslovni proces stane jer samo jedna osoba zna lozinku ili ima pristup važnom sustavu.
Backup nije dovoljan bez provjerenog oporavka
Sigurnosna kopija ima vrijednost samo ako se može vratiti u prihvatljivom roku i ako sadržava podatke koji su stvarno potrebni za nastavak rada. Poruka da je backup uspješan ne potvrđuje automatski da je moguće obnoviti cijeli poslužitelj, bazu podataka ili pojedinačnu datoteku.
Plan sigurnosnog kopiranja treba odgovoriti na konkretna pitanja: koji se podaci kopiraju, koliko često, koliko se dugo čuvaju, gdje se kopije nalaze i tko može pokrenuti oporavak. Za većinu poslovnih okruženja opravdano je imati kopije odvojene od primarnog sustava. Ako se incident dogodi na lokaciji ili zahvati korisničke račune, kopija koja je dostupna istim pristupima može biti jednako ugrožena kao i izvorni podaci.
Jednako je važno odrediti ciljeve oporavka. Koliki gubitak podataka tvrtka može prihvatiti? Koliko dugo poslovna aplikacija smije biti nedostupna? Odgovor za arhivu dokumenata neće nužno biti isti kao za sustav za izdavanje računa ili proizvodnju. Takve odluke trebaju donijeti odgovorne poslovne osobe zajedno s IT-om, jer određuju potrebnu razinu zaštite i trošak infrastrukture.
Test oporavka otkriva stvarno stanje
Testiranje povrata podataka treba planirati, a ne čekati incident. U kontroliranom postupku može se provjeriti može li se vratiti pojedinačna datoteka, baza poslovne aplikacije ili cijeli virtualni poslužitelj. Test također pokazuje koliko oporavak traje i nedostaju li koraci u dokumentaciji.
Tvrtka koja nikada nije testirala obnovu ne zna ima li backup, nego se nada da ga ima. Ta je razlika posebno vidljiva kada treba brzo donijeti odluku pod pritiskom prekida rada.
Mreža i sigurnost treba projektirati za stvarni način rada
Mrežna infrastruktura često se širi postupno: doda se novi pristupnik, preklopnik, bežična mreža ili udaljena lokacija. Ako promjene nisu planske, s vremenom nastaju nejasne konfiguracije, uska grla i pojedinačne točke kvara.
Za kritične dijelove poslovanja treba procijeniti ima li smisla uvesti redundanciju. To može biti pričuvni internetski pristup, redundantno napajanje, zamjenski mrežni uređaj ili virtualizacijska arhitektura koja olakšava povrat sustava. Nije svaka redundancija opravdana za svaku tvrtku. Trošak mora biti razmjeran šteti koju bi prekid uzrokovao.
Sigurnosne mjere također izravno utječu na dostupnost. Višefaktorska autentifikacija, ograničavanje administratorskih ovlasti, segmentacija mreže, zaštita krajnjih uređaja i redovito uklanjanje zastarjelih računa smanjuju vjerojatnost incidenta koji može zaustaviti rad većeg dijela organizacije. Pri tome sigurnost ne treba postaviti tako da korisnici traže zaobilazna rješenja. Pravila moraju biti dovoljno stroga za zaštitu sustava, ali provediva u svakodnevnom radu.
Plan prekida mora biti razumljiv i provediv
Kada je sustav nedostupan, zaposlenicima ne treba tehnički elaborat nego jasna uputa: kome prijaviti problem, kako nastaviti s nužnim poslom, tko komunicira s korisnicima i kada se očekuje nova obavijest. Plan kontinuiteta poslovanja treba biti kratak, usmjeren na najvažnije procese i poznat osobama koje ga trebaju primijeniti.
U njemu vrijedi definirati prioritetne sustave, kontaktni lanac, alternativne postupke rada i redoslijed oporavka. Ako je e-pošta nedostupna, možda je potrebno prvo osposobiti alternativni kanal komunikacije. Ako ne radi poslovna aplikacija, prioritet može biti vraćanje baze podataka prije pristupa manjim pomoćnim servisima.
Vanjski IT partner u takvom planu ima smisla kada preuzima jasno definiranu odgovornost za nadzor, održavanje, sigurnosne kopije i intervencije. CarPen Rebuild u praksi pristupa infrastrukturi kroz pregled stvarnih ovisnosti sustava, a ne samo kroz popis uređaja. Time se lakše prepoznaje gdje prekid može nastati i koje mjere donose najveće smanjenje rizika.
Pouzdano poslovanje ne nastaje kupnjom jednog alata ni jednokratnim projektom. Nastaje redovitim nadzorom, disciplinom održavanja, provjerenim oporavkom i jasnim dogovorom tko reagira kada nešto odstupi od normalnog rada. Najbolje vrijeme za provjeru tih temelja je dok sustavi rade bez poteškoća.