Доступност критичних система

Zastoj u radu veb prodavnice nije samo informatički incident: narudžbine se prekidaju, skladište ne dobija zadatke, korisnička podrška nema podatke, a finansijski procesi kasnije se suočavaju sa greškama u usklađivanju. Dostupnost kritičnih sistema je pitanje kontinuiteta poslovanja. Ne radi se o stanju jednog servera, cloud usluge ili aplikacije, već o tome da li ceo proces može da funkcioniše u skladu sa očekivanjima kompanije.

U srednje velikim poslovnim okruženjima problem često ne počinje sa očiglednom greškom. U početku, ažuriranja zaliha kasne, integracija faktura povremeno zastaje, ili proizvodni sistem sporije počinje sa radom na početku smene. Ovi znakovi mogu ukazivati na to da je sistem dostigao svoje kapacitete, arhitektonska ili operativna ograničenja. Ako se rad povezanih sistema ne tretira kao celina, manji poremećaji lako mogu postati poslovni zastoji.

Šta zapravo znači dostupnost?

Dostupnost jednostavno pokazuje koliko dugo je neka usluga dostupna u određenom vremenskom periodu. Međutim, to samo po sebi nije dovoljno za donošenje menadžerskih odluka. ERP može biti tehnički dostupan, dok veb prodavnica ne može da prenese narudžbine do njega. Terminal u skladištu može raditi, ali ako osnovni podaci o artiklima pokazuju stanje od pre nekoliko sati, usluga se ne može smatrati potpuno funkcionalnom sa operativnog aspekta.

Zato dostupnost treba tumačiti po poslovnim uslugama. Različita očekivanja važe za unutrašnji izveštajni interfejs u odnosu na proces upravljanja narudžbinama, logistički ili proizvodni proces. U prvom slučaju, kratki, unapred dogovoreni period održavanja može biti prihvatljiv. U drugom slučaju, čak i nekoliko minuta zastoja može izazvati zagušenja, ručna rešenja i opterećenje u komunikaciji sa klijentima.

Dostupnost nije isto što i upotrebljivost

Tehničke provere često se fokusiraju na to da li server odgovara ili da li se veb stranica učitava. Ovo je korisna osnovna indikacija, ali ne dokazuje da poslovna funkcija radi. Zreli pristup monitoringu, na primer, ispituje i da li je narudžbina kreirana, preneta u ERP, faktura izrađena i da li skladište dobija zadatak za preuzimanje.

Provere iz perspektive korisnika zahtevaju više planiranja, ali zauzvrat ranije ukazuju na greške u integraciji, ovlašćenjima ili kvalitetu podataka. Posebno su važne tamo gde se povezuje više eksternih pružalaca usluga, API-ja, logističkih, dobavljačkih izvora podataka ili starih sistema.

Osnove dostupnosti kritičnih sistema

Veća dostupnost nije rezultat jednog proizvoda ili infrastrukturnog elementa. To je kombinacija arhitekture, operativne discipline i poslovnih prioriteta. Pravilna postavka zavisi od toga koji su procesi kritični, kakav zastoj je prihvatljiv i koji trošak je opravdan za upravljanje rizikom.

Četiri oblasti koje treba zajedno ispitati:

• Mapiranje zavisnosti: koji su podaci, integracije, mrežni elementi, sertifikati i eksterne usluge potrebni za funkcionisanje poslovnog procesa.
• Dizajn tolerantan na greške: gde je opravdano imati redundantne komponente, balansiranje opterećenja, izolovanu infrastrukturu ili automatsko preuzimanje u slučaju kvara.
• Posmatranje: koji poslovni i tehnički signali treba kontinuirano da se mere, ko dobija obaveštenja i koji eskalacioni protokol se prati za intervencije.
• Sposobnost oporavka: da li su dostupne rezervne kopije, konfiguracije, pristupi i dokumentovani koraci za oporavak usluge u potrebnom vremenskom roku.

Iz liste, redundancija obično dobija najviše pažnje, ali sama po sebi ne rešava sve. Dva aplikaciona servera neće pomoći ako su povezani na istu bazu podataka, ili ako istekli sertifikat učini oba neupotrebljivim. Pravi rizici moraju se ispitati duž celog lanca zavisnosti.

RTO i RPO: dva pitanja koja razjašnjavaju očekivanja

Cilj vremena oporavka, RTO, odgovara na pitanje koliko brzo usluga treba ponovo da postane dostupna. Cilj tačke oporavka, RPO, određuje koliko je gubitak podataka prihvatljiv. Na primer, očekivanja za sistem upravljanja narudžbinama mogu biti potpuno drugačija nego za dokumentacioni sistem.

Ove vrednosti ne treba određivati isključivo sa IT strane. Poslovni lideri treba da odluče koji zastoj i gubitak podataka još uvek predstavljaju upravljivo operativno opterećenje, a IT tim treba da planira realna tehnička i operativna rešenja za to. Previše strogi ciljevi mogu rezultirati nepotrebno skupim sistemima, dok previše labava očekivanja otkrivaju nedostatke tek tokom stvarnog incidenta.

Rezervna kopija je vredna samo ako se može vratiti

Mnoge organizacije imaju zadatke za pravljenje rezervnih kopija, ali malo njih može dokazati da se kritična usluga zaista može vratiti iz njih u datom vremenskom roku. Rezervna kopija baze podataka može biti neispravna, mogu nedostajati ključevi za šifrovanje, ili konfiguracije aplikacija i opisi infrastrukture potrebni za vraćanje možda nisu dostupni.

Zato strategija rezervnih kopija ne završava se kopiranjem fajlova. Treba da pokrije baze podataka, aplikacione kodove, konfiguracije, opise virtuelnih mašina ili kontejnera, modele ovlašćenja i dokumentaciju potrebnih eksternih veza. Tokom testa vraćanja, ne treba samo proveriti da li se sistem pokreće, već i da li poslovni proces funkcioniše do kraja.

Redovno testiranje nosi troškove i organizacione zahteve. Međutim, ovde kontinuitet na papiru postaje operativna sposobnost. Rezultati testova često otkrivaju skrivene zavisnosti koje nisu vidljive tokom normalnog rada.

Monitoring: nije samo alarmi, već osnova za donošenje odluka

Previše alarma brzo gubi značaj. Ako operater svakodnevno prima desetine nehitnih obaveštenja, lako može prevideti pravi problem. Zato monitoring treba razvijati prema prioritetima, poslovnom uticaju i jasnim odgovornostima.

Korisni sistem prati dostupnost, vreme odziva, iskorišćenost resursa, stope grešaka, završetak rezervnih kopija i stanje integracionih redova. Takođe pokazuje trendove. Postepeno povećanje vremena odziva baze podataka ili korišćenja prostora za skladištenje ne mora odmah biti incident, ali bez odgovarajućeg planiranja kapaciteta kasnije može postati.

Menadžerski prikaz ne mora sadržavati sve tehničke metrike. Mnogo je korisnije ako pokazuje koje usluge su pogođene, na koje poslovne procese utiče greška, koji je očekivani put oporavka i da li je potrebna operativna odluka. Ovaj pristup smanjuje nesporazume između IT i poslovnih oblasti.

Upravljanje promenama je deo dostupnosti

Većina okruženja nije statična. Nove funkcije veb prodavnice, ažuriranja verzija ERP-a, API veze, migracije infrastrukture ili promene ovlašćenja stalno oblikuju okruženje rizika. Nekontrolisane promene su čest uzrok neočekivanih zastoja usluga, čak i kada se sama promena isprva čini beznačajnom.

Upravljanje promenama ne mora biti teška birokratija. Međutim, za kritične sisteme potrebna je procena uticaja, planiranje oporavka, testiranje i jasno odobrenje. Posebno je važno kod integracija znati da promena polja, vremenskog rasporeda ili metode autentifikacije može uticati na koje dodatne sisteme.

Periodi održavanja su takođe deo svesne dostupnosti. Unapred komunicirano, kontrolisano ažuriranje često predstavlja manji poslovni rizik nego hitna intervencija proizašla iz odložene popravke. Cilj je da promena bude predvidiva i da postoji mogućnost povratka u slučaju greške.

Sistemska odgovornost u složenim okruženjima

Veb prodavnica, ERP, WMS, fakturisanje, proizvodni sistem i logistički partner retko imaju jedan izvor greške ili jedan odgovorni tim. Zato je neophodno jasno definisati granice sistema, odgovornosti za usluge i puteve eskalacije. Tokom incidenta ne treba otkriti ko ima pristup logovima, ko može da menja konfiguracije ili ko koordinira sa eksternim pružaocem usluga.

U CGAT pristupu, razvoj aplikacija, integracija i operativno upravljanje infrastrukturom ne mogu se veštački odvojiti ako služe istom poslovnom procesu. Dostupnost se značajno poboljšava tamo gde se greške ne posmatraju kao izolovani simptomi, već kao deo funkcionisanja celog sistema.

Vredi početi identifikovanjem tri do pet poslovnih procesa čiji zastoj najbrže izaziva operativni poremećaj. Za njih se mogu postaviti realni ciljevi dostupnosti, očekivanja oporavka i merljive operativne kontrole. Ovo je mnogo korisnija polazna tačka od opšteg obećanja da svi sistemi uvek moraju raditi.