Како планирати отпорну корпоративну инфраструктуру

Kada sistem za upravljanje skladištem bude van funkcije 20 minuta, to ne mora uvek značiti gubitak od 20 minuta. Može doći do zaustavljanja komisioniranja, nagomilavanja transportnih zadataka, pogrešnih informacija o zalihama koje ulaze u prodajne kanale, a nakon ponovnog pokretanja može početi višesatna ručna korekcija. Stoga, pitanje nije samo kako dizajnirati infrastrukturu otporanu na greške u preduzeću, već i koji poslovni procesi moraju dokazano funkcionisati čak i kada dođe do kvara komponente, lokacije ili čak provajdera.

Otpornost na greške nije jedan tehnološki proizvod niti dupliranje servera. To je disciplina dizajna: usklađivanje poslovnih prioriteta, zavisnosti sistema, konzistentnosti podataka, operativnih procedura i sposobnosti vraćanja. U kritičnom okruženju, arhitektura se može smatrati funkcionalnom samo ako u scenarijima kvara može dokazano ispuniti dogovoreni nivo usluge.

Kako dizajnirati infrastrukturu otporanu na greške na poslovnoj osnovi?

Prvi korak u dizajnu nije topologija klastera, već analiza poslovnog uticaja. Potrebno je odrediti koje usluge direktno podržavaju proizvodnju, transport, finansijsko zatvaranje, korisničku podršku ili usklađenost sa propisima. ERP modul, sistem za izvršenje proizvodnje, sloj integracije i sistem za upravljanje narudžbinama u e-trgovini mogu imati različite posledice kvara, čak i ako tehnički rade na istoj platformi.

Za svaku kritičnu uslugu potrebno je odrediti dve vrednosti. Ciljano vreme oporavka, RTO, govori koliko brzo usluga mora ponovo postati upotrebljiva. Ciljana tačka oporavka, RPO, određuje koliki gubitak podataka je prihvatljiv. RPO od jednog minuta i RTO od četiri sata zahtevaju potpuno drugačiji model replikacije, bekapa i operacija od arhivskog sistema koji se može vratiti iz dnevnog bekapa.

Ove ciljne vrednosti ne smeju biti odobrene samo sa IT strane. Menadžer proizvodnje, logistički menadžment, finansije, odgovorni za usklađenost i vlasnik sistema zajednički odlučuju o tome koji je nivo kvara prihvatljiv. Tek nakon toga tehnologija se može prevesti u konkretne zahteve za dostupnost.

Redundancija ima vrednost samo ako eliminiše zajedničku tačku kvara

Česta greška je instaliranje dva aplikaciona servera iza istog skladišta, mrežnog uređaja, servisa imenika ili fizičke lokacije. Ovo izgleda kao visoka dostupnost, ali zapravo jedna zajednička tačka kvara i dalje može zaustaviti celu uslugu. Zadatak dizajna otpornog na greške nije povećanje broja instanci, već svesno razdvajanje domena kvara.

Za poslovno kritičnu uslugu potrebno je posebno ispitati računarsku snagu, skladište, mrežu, napajanje, razrešavanje imena, upravljanje identitetom i spoljne zavisnosti. Na primer, ako obrada narudžbina radi na više aplikacionih instanci, ali nedostupnost jedne baze podataka, VPN veze ili usluge posredovanja poruka može je zaustaviti, otpornost sistema na greške je samo delimična.

Rad sa više lokacija ili više zona dostupnosti može pružiti dodatnu zaštitu, ali nije opravdan za svako opterećenje. Kod sinhrone replikacije baza podataka, kašnjenje i stabilnost mreže mogu ograničiti performanse. Asinhrona replikacija može smanjiti ovaj efekat, ali RPO neće biti nula. Ispravna odluka uvek zavisi od poslovne vrednosti, transakcione prirode i zahteva za konzistentnošću određenog toka podataka.

Konzistentnost podataka može biti važnija od brze tranzicije

Pogrešan failover može biti opasniji od kratkog, kontrolisanog zastoja. Ovo je posebno tačno za sisteme upravljanja zalihama, finansijske, proizvodne i narudžbine sisteme, gde ista transakcija ne sme biti obrađena dvaput i ne sme se izgubiti između dva sistema.

Aplikacije stoga moraju upravljati ponovljenim porukama, idempotentnim operacijama, odloženom obradom i ponovnim pokušajima neuspelih integracija. Infrastruktura sama po sebi ne može garantovati ispravnost poslovnih transakcija. Ako WMS, ERP i integracija sa prevoznicima ostanu u različitim stanjima nakon tranzicije, operativni tim mora vratiti ne samo sistem, već i poslovni tok podataka.

Arhitektura oporavka je poseban zadatak dizajna sistema

Bekap nije strategija oporavka. Bez bekapa nema povratka, ali samo postojanje bekapa ne dokazuje da se aplikacija, baza podataka, konfiguracija i model pristupa mogu vratiti u potrebnom vremenu. Tokom oporavka, usko grlo često nije datoteka podataka, već nedostajući ključ za upravljanje tajnama, nedokumentovano pravilo mreže, istekli sertifikat ili zaboravljena spoljna integracija.

Plan oporavka mora sadržati redosled zavisnosti. Prvo moraju biti dostupne osnovne usluge identiteta i mreže, zatim platforme podataka, a na kraju aplikacije i integracije. Redosled se razlikuje od organizacije do organizacije, ali ne sme ostati u glavama iskusnih sistem administratora. Potrebna je verzionisana, odobrena i u praksi sprovedena procedura.

Bekapove treba odvojiti od proizvodnog okruženja sa pravima pristupa. U slučaju ransomware-a ili kompromitovanog administratorskog naloga, napadač često cilja i lanac bekapa. Neizmenjiva ili odvojena kopija, razdvajanje prava pristupa za oporavak i redovne provere integriteta su deo kontinuiteta, a ne samo sigurnosni dodatak.

Posmatranje je operativna strana otpornosti na greške

Visoka dostupnost ne može čekati na prijave korisnika. Monitoring ne sme meriti samo upotrebu CPU-a, memorije i diska, već i poslovne transakcije. Da li narudžbina stiže? Da li rezervacija zaliha stiže do ERP-a? Da li se odgovor za štampanje etiketa vraća? Da li je prenos fakturisanih podataka uspešan?

Povezivanje tehničkih i poslovnih metrika ubrzava prepoznavanje grešaka i odvaja simptom od uzroka. Povećano vreme odgovora može biti posledica opterećenja baze podataka, neuspešnog pokušaja ponovne integracije ili zagušenja mreže. Odgovarajuće logovanje, distribuirano praćenje i praćenje kapaciteta omogućavaju operacijama da intervenišu na osnovu dokaza.

Upozorenja moraju ostati upravljiva. Ako se svako upozorenje kvalifikuje kao trenutni incident, tim gubi prave prioritete. Redosled upozorenja treba povezati sa nivoima usluge, poslovnim vremenskim okvirima i jasnim odgovornostima za eskalaciju.

Dokaz otpornosti na greške je testirana funkcionalnost

Failover, oporavak iz bekapa i režim rada u vanrednim situacijama ne mogu se smatrati spremnim dok se ne testiraju u realnim uslovima. Test mora obuhvatiti planirano održavanje, gubitak aplikacione instance, grešku baze podataka, segmentaciju mreže, gubitak usluge provajdera i probleme sa pravima pristupa. Nije svaki scenario potrebno izvoditi istom učestalošću, ali najveći poslovni rizici moraju se redovno meriti.

Rezultat prakse nije samo uspešna tehnička tranzicija. Potrebno je dokumentovati stvarni RTO i RPO, razlike u podacima, ručne korake, pogođene poslovne procese i tačke odluke gde je bila potrebna ljudska intervencija. Na osnovu toga se gradi operativno znanje koje smanjuje nesigurnost tokom incidenta.

Konačna vrednost infrastrukture otporne na greške meri se time da li kompanija ostaje upravljiva čak i kada se tehnička pretpostavka pokaže pogrešnom. Pre sledeće arhitektonske odluke, stoga, ne pitajte koliko komponenti će biti redundantno, već: koju poslovnu uslugu možemo vratiti u određenom vremenskom okviru, sa kontrolisanim podacima i određenom odgovornošću?