Procena rešenja za failover u preduzećima

Fakturacija funkcioniše, upravljanje narudžbinama funkcioniše, skladište takođe napreduje - sve dok centralni server, internet veza ili aplikacija ne prestanu da rade. Tada se otkriva ko još može da radi, koji podaci su dostupni i koji procesi potpuno staju. Evaluacija rešenja za prebacivanje u slučaju kvara u preduzeću stoga nije prvenstveno zadatak kupovine infrastrukture. To je ispitivanje koliko brzo tehnička greška postaje poslovni problem.

U preduzeću sa 20-500 zaposlenih, prekid rada retko je očigledan u prvom minutu. Prvo neko ne može da odštampa etiketu. Narudžbina iz internet prodavnice ne prelazi u poslovni sistem. Podaci potrebni za proizvodni plan nalaze se samo u deljenom folderu koji trenutno nije dostupan. Nekoliko sati kasnije, telefoni, e-mailovi i ručno vođene liste zamenjuju sisteme. Ovo nije samo gubitak prihoda: izaziva greške, kašnjenja, prekovremeni rad i nesigurne menadžerske odluke.

Šta zapravo treba proceniti?

Prebacivanje u slučaju kvara je rezervni operativni mehanizam koji zamenjuje neispravnu komponentu drugim resursom. To može biti sekundarni server, alternativna internet veza, rezervna mrežna oprema, replika baze podataka ili okruženje koje radi u oblaku. Tehnička definicija je, međutim, samo polazna tačka.

Menadžersko pitanje je pre ovo: ako ovaj sistem nije dostupan, šta tačno ne može da se dogodi u preduzeću? Ne zaslužuju svi sistemi isti nivo zaštite. Nekoliko sati prekida unutrašnjeg arhiva može biti prihvatljivo. Međutim, prekid obrade narudžbina, informacija o zalihama u skladištu, kontrole proizvodnje ili fakturisanja brzo može postati direktni poslovni rizik.

Dobra procena stoga ne počinje pitanjem da li su potrebna dva servera. Prvo treba prikazati kako narudžbina, radni nalog ili zahtev za isporuku prolazi kroz sisteme i ljude. Često se ovde vidi da najveća zavisnost nije ni aplikacija, već jedna integracija, zajedničko deljenje fajlova ili ručni zaobilazni put koji poznaje jedan zaposleni.

Prvi korak u proceni rešenja za prebacivanje u slučaju kvara u preduzeću: poslovni uticaj

Vredi raditi sa nekoliko konkretnih poslovnih scenarija, a ne sa opštim pitanjima. Šta se dešava, na primer, ako preduzeće ostane bez interneta na četiri sata u ponedeljak ujutru? Može li skladište da komisionira? Da li stižu narudžbine iz internet prodavnice? Da li prodavci mogu da pristupe podacima o klijentima? Može li finansijski sektor da izda fakturu ili proveri bankovne podatke?

Jednako je važno ispitati greške u aplikacijama. Ako je ERP dostupan, ali veza između internet prodavnice i ERP-a prestane da radi, da li tim to odmah primećuje? Da li se narudžbine gomilaju, gube ili zaposleni počinju da ih ponovo unose ručno? Ručno unošenje može kratkoročno izgledati kao pomoć, ali kasnije vodi do duplikata, pogrešnih zaliha i dodatnog rada na usklađivanju.

Pri proceni uticaja, preporučljivo je posebno razmotriti četiri perspektive:

• prihodi i usluga klijentima: da li se propušta narudžbina, isporuka ili fakturisanje;
• operacije: da li se zaustavlja skladište, proizvodnja, nabavka ili korisnička podrška;
• podaci i usklađenost: da li podaci mogu biti oštećeni, transakcije izgubljene, da li može biti narušena obaveza vođenja evidencije;
• ljudsko opterećenje: ko rešava grešku, ko može primeniti zaobilazni proces i koliko dugo se može održati ova situacija.

Na osnovu ovih faktora, već se može napraviti razlika između neprijatnog i neprihvatljivog prekida. Ova razlika određuje da li je za sistem dovoljna dokumentovana obnova ili je potrebna automatska prebacivanje.

RTO i RPO: dve vrednosti koje treba prevesti na poslovni jezik

U planiranju prebacivanja u slučaju kvara često se pojavljuju dve skraćenice. RTO, odnosno cilj vremena obnove, govori koliko brzo usluga mora ponovo postati upotrebljiva. RPO, odnosno cilj tačke obnove, označava koliko gubitka podataka je prihvatljivo.

Brojevi sami po sebi imaju malo značenja. To što je RTO sistema četiri sata ima smisla samo ako preduzeće zna šta se dešava tokom ta četiri sata. Ako to znači zaustavljanje isporuke iz skladišta između osam ujutru i podneva, cilj može biti previše labav. Ako se odnosi na retko korišćeno izveštajno okruženje, može biti opravdano.

Isto važi i za RPO. Gubitak podataka od jednog sata može biti prihvatljiv za određene dokumentacione arhive, ali ne i za sistem naručivanja ili proizvodnje gde se nove transakcije generišu svake minute. U takvim slučajevima noćna kopija nije dovoljna. Potrebna je replikacija, češće kopiranje ili aplikaciona logika koja osigurava povrat transakcija.

Previše strogi ciljevi imaju svoju cenu. Trenutno prebacivanje, kapacitet održavan na više lokacija i kontinuirana sinhronizacija podataka zahtevaju značajnu investiciju i operativnu disciplinu. Nije cilj projektovati svaki sistem za bankarski nivo dostupnosti. Cilj je da zaštita bude u skladu sa stvarnim poslovnim posledicama prekida.

Rezervni server nije dovoljan ako zavisnosti ostaju na jednom mestu

Mnoge organizacije imaju rezervne kopije, možda čak i sekundarni server, ali i dalje postoji jedna tačka kvara u radu. Sekundarno okruženje može da se pokrene, ali ako koristi istu internet vezu, oslanja se na istu uslugu autentifikacije ili isti integracioni servis povezuje sisteme, problem ostaje.

Ispitivanje stoga mora obuhvatiti ceo lanac: mrežu, napajanje, DNS, upravljanje identitetima, bazu podataka, aplikacije, spoljne pružaoce usluga i integracije. Na primer, internet prodavnica može biti dostupna, dok usluga plaćanja, informacije o zalihama ili veza sa prevoznikom ne funkcionišu. Sa poslovne tačke gledišta, ovo je delimičan, ali vrlo stvaran prekid.

Ručni procesi takođe predstavljaju zavisnost. Ako zaposleni svakog popodneva izvozi fajl, a zatim ga učitava u partnerski sistem, odsustvo te osobe i greška u deljenju fajlova mogu izazvati prekid. Ovde je prebacivanje delimično tehničko pitanje, a delimično redizajn procesa. Možda je ispravan odgovor ne skupo okruženje sa visokom dostupnošću, već ukidanje ručnog prenosa i učiniti integraciju proverljivom .

Automatsko ili ručno prebacivanje?

Automatsko prebacivanje je brže, ali složenije. Korisno je kada prekid u roku od nekoliko minuta može izazvati poslovnu štetu, a status usluge se može sigurno proveriti. Na primer, može biti opravdano za online uslugu koju direktno koriste klijenti ili za kontinuiranu proizvodnu vezu.

Ručno prebacivanje je sporije, ali u mnogim slučajevima jednostavnije, jeftinije i lakše se kontroliše. Za internu poslovnu aplikaciju, čija je obnova u roku od nekoliko sati prihvatljiva, uz odgovarajuću dokumentaciju i određene odgovorne osobe, ovo može biti racionalna odluka. Ključ je da proces zaista može biti sproveden i pod pritiskom, a ne da postoji samo u starom tehničkom opisu.

Postoje i hibridna rešenja između dva modela. Internet veza može automatski preći na rezervnu liniju, dok obnova manje kritičnog poslovnog sistema i dalje zahteva odobrenje i ručno pokretanje. Ovo često bolje odgovara stvarnim rizicima nego forsiranje automatskog prebacivanja svuda.

Test je najvažniji deo procene

Neprevereno prebacivanje u slučaju kvara je više pretpostavka nego funkcionalnost. O rezervnoj kopiji se saznaje da je upotrebljiva tek kada se iz nje stvarno povrate podaci. Isto važi i za planove prebacivanja: sekundarno okruženje može da se pokrene, ali korisnici možda ne mogu da se prijave, partnerska veza blokira novu IP adresu ili sistem prikazuje starije stanje podataka.

Test mora slediti poslovni scenario. Nije dovoljno potvrditi da je virtuelna mašina pokrenuta. Treba proveriti da li je narudžbina kreirana, da li prelazi u sledeći sistem, da li se pojavljuje u skladištu, da li je dokumentacija završena i da li je izveštavanje obnovljeno. Odstupanja koja se pojave tokom testa su posebno vredna, jer otkrivaju skrivene zavisnosti koje sistemski dijagrami često ne sadrže.

Testiranje treba da ima odgovornu osobu, zapisnik i listu za ispravke. Ako je kritični korak poznat samo spoljnom stručnjaku ili je pristup vezan za jednog zaposlenog, tada nije uspostavljen pravi kontinuitet poslovanja.

Na šta ukazuje ako je prebacivanje previše složeno?

Ako je za obnovu usluge potrebno mnogo tabela, telefonskih poziva i improvizacije, to često nije samo problem infrastrukture. Može ukazivati na to da proces prolazi kroz previše sistema, da integracije nisu nadgledane ili da odgovornosti nisu jasne. Evaluacija prebacivanja u slučaju kvara je stoga dobra prilika da preduzeće ponovo pogleda zašto informacije teku ovim putem.

Dobro osmišljeno rešenje nije nužno upadljivo. Često se pokazuje u tome što zaposleni znaju šta se dešava u slučaju greške, šta treba da rade i koji podaci se smatraju pouzdanim. Ova kontrola smanjuje paniku, nepotrebni ručni rad i rizik prema klijentima.

Sledeći prekid nije dobar trenutak da se otkrije da li rezervno rešenje zaista funkcioniše. Vredi proći kroz kritične procese dok još ima vremena da se postavi pitanje: šta se zaustavlja, ko je pogođen, šta se može nadoknaditi i šta nema prihvatljiv zaobilazni put.