Како стабилизовати наслеђену инфраструктуру?

Na ponedeljak ujutru, stari server ponovo ne odgovara. Skladište ne vidi narudžbine, fakturisanje čeka, a korisnička podrška pokušava telefonom da sastavi šta se dogodilo. U ovakvim situacijama pitanje nije da li je sistem star, već kako stabilizovati nasleđenu infrastrukturu tako da posao ne stane i da hitna popravka ne bude jedini odgovor.

Nasleđena infrastruktura često postaje kritična tokom godina. Prethodna aplikacija radi samo na određenom serveru, proširenja mreže nisu dokumentovana, bekap postoji, ali obnova nije testirana dugo vremena. U međuvremenu, kompanija je rasla: više narudžbina, više korisnika, više integracija i veća očekivanja su stavljena na istu tehničku osnovu.

Stabilizacija ne znači da sve treba odmah zameniti. U mnogim slučajevima, potpuna zamena stvara najveći poslovni rizik. Cilj je prvo da osnovno funkcionisanje postane predvidljivo, kontrolisano i obnovljivo. Tek tada se može odgovorno odlučiti o tempu modernizacije.

Kako stabilizovati nasleđenu infrastrukturu iz poslovne perspektive?

Polazna tačka nije lista servera, već mapiranje kritičnih poslovnih procesa. Koji sistemi su neophodni za primanje narudžbina, pokretanje proizvodnje, izdavanje robe, fakturisanje ili usluživanje klijenata? Koliko dugo se može tolerisati prekid u različitim oblastima? Kašnjenje izveštaja od dva sata može biti neprijatno, ali dvostani prekid u skladištu može izazvati direktan gubitak prihoda i poverenja.

Ova razlika određuje prioritete. Česta greška je da tehnički tim počinje sa onim što je najstarije ili najteže za upravljanje. Iz poslovne perspektive, prvo treba zaštititi ono čiji kvar ima najveće operativne posledice.

Ne mapirajte samo sisteme, već i zavisnosti

Poslovna aplikacija retko se kvari sama od sebe. Može zavisiti od baze podataka, fajl servera, mrežne veze, servera licenci, spoljnog partnerskog odnosa ili jednog, više nepodržanog klijentskog računara. Webshop može raditi, ali ako informacije o zalihama ne stignu do ERP-a, prodaja i skladište rade iz različitih stvarnosti.

Zato procena treba da pokaže i gde postoje skrivena individualna rešenja. Na primer, automatski prenos podataka zapravo pokreće kolega svako jutro. Ili stara aplikacija radi samo zato što neko zna koji servis treba ponovo pokrenuti. Ovo nisu jednostavni IT rizici, već operativni rizici zavisni od ljudi.

Vredi zabeležiti za svaku kritičnu uslugu koja je njena uloga, gde radi, sa kojim podacima radi, na šta je povezana, ko je odgovoran za nju i šta se dešava u slučaju njenog pada. Nije potrebno pokretati višemesečni dokumentacioni projekat. Ali za donošenje odluka potreban je stvaran, zajednički prihvaćen prikaz trenutnog stanja.

Prvo obnovite operativnu kontrolu

Stabilna infrastruktura ne znači da se nikada ništa ne kvari. To znači da se kvarovi otkrivaju na vreme, njihov uticaj je ograničen, a obnova nije improvizacija.

Prvi element je posmatranje. Ako skladište, memorija, mrežna veza, status usluge ili proces bekapa postanu vidljivi tek kada stigne pritužba, kompanija je stalno u zaostatku. Pravilno nadgledanje nije tehnička dekoracija. Pomaže razlikovati usporavanje, zasićenje sistema od neočekivanog kvara i pruža osnovu za planiranje kapaciteta.

Drugi element je upravljanje promenama. Mnoge nasleđene okoline ne postaju krhke zbog jednog velikog kvara, već zbog mnogih malih, neproverenih promena. Novi korisnik, ručno promenjena dozvola, hitno ažuriranje, privremeno pravilo vatrozida, pa zaboravljeni izuzetak. Ako nije jasno šta je promenjeno, ko je odobrio i kako se može vratiti, svaka intervencija povećava rizik.

Treći element je sređivanje pristupa. Opšti administratorski nalozi, deljeni lozinke i aktivne dozvole bivših zaposlenih predstavljaju istovremeno sigurnosne i operativne probleme. Kada se istražuje greška, ne može se utvrditi ko je šta uradio. Dozvole treba da budu povezane sa radnim mestom i odgovornošću, a kritične pristupe treba redovno pregledati.

Bekap je vredan samo ako se može obnoviti

Mnoge organizacije se smiruju činjenicom da se bekap obavlja svakodnevno. To je nedovoljno. Prava pitanja su drugačija: da li je bekap neoštećen, da li je odvojen od produkcionog okruženja, koliko podataka bi se izgubilo prilikom obnove i koliko vremena bi trebalo da se kritični proces ponovo pokrene?

Za proizvođačku ili trgovačku kompaniju nije svejedno da li obnova baze podataka traje tri sata ili tri dana. Takođe, da li povezane integracije, dozvole i deljenja fajlova funkcionišu nakon obnove. Plan bekapa treba tretirati kao alat za kontinuitet poslovanja, a ne kao administrativnu usklađenost.

Redovno testiranje obnove obično brzo otkriva skrivene nedostatke: nedostajući šifrovni ključ, nedokumentovanu konfiguraciju, nedostatak prostora za skladištenje ili zavisnost o kojoj niko nije znao. Ovo je neprijatno otkriće, ali u kontrolisanoj situaciji mnogo je jeftinije nego tokom stvarnog incidenta.

Ne pravite potpunu zamenu prvim projektom

Kod modernizacije nasleđene infrastrukture, „zamenimo sve“ često je razumljiva reakcija, ali retko dobar prvi korak. Velika tranzicija istovremeno utiče na aplikacije, podatke, integracije, korisničke navike i operativne procese. Ako nisu istraženi, projekat samo prenosi nesigurnost na novu platformu.

Postepeni pristup obično nosi manji rizik. Prvo se može odvojiti ili zaštititi najkritičnija komponenta, srediti bekap i pristup, dokumentovati konfiguracija, a zatim modernizovati zastareli elementi u različitim fazama. To može biti virtualizacija servera, segmentacija mreže, prelazak na podržani operativni sistem, uvođenje cloud usluga ili zamena aplikacije. Pravi put zavisi od toga koji poslovni proces podržava određeni element i koliko je povezan sa drugim sistemima.

Postoje situacije kada je opravdano zadržati staru, ali stabilnu aplikaciju jer bi njena zamena izazvala prevelike promene u procesu. U tom slučaju, potrebno je učiniti njeno okruženje sigurnijim, regulisati njene veze i pripremiti plan za kasniju zamenu. Ponekad privremeni interfejs ili ručni izvoz za stari sistem predstavljaju veći rizik nego sama aplikacija.

Tehnička stabilnost je i ljudska odgovornost

Ako samo jedna osoba zna kako ponovo pokrenuti korporativni sistem, nema stabilnog održavanja. Ako finansije ispravljaju podatke u sopstvenim tabelama jer ne veruju centralnom sistemu, problem infrastrukture već utiče na podršku odlučivanju. Tehnička nesigurnost brzo stvara ručne zaobilaznice, paralelne evidencije i frustracije.

Zato je deo stabilizacije jednostavan, upotrebljiv operativni režim: ko prima upozorenja, ko odlučuje u slučaju incidenta, gde je dokumentacija, kako se odvija eskalacija i kada se rizici preispituju. Nije svakoj kompaniji potrebna 24-časovna interna dežurstva ili složeni korporativni pravilnici. Ali za svaku kritičnu operaciju potrebna je određena odgovornost i isprobana procedura.

Na kraju dobrog programa stabilizacije tehnologija nije nužno spektakularno nova. Pre je rad tiši: manje je neočekivanih zastoja, brže se rešavaju problemi, podaci su pouzdaniji, a rad ne zavisi od sećanja jednog zaposlenog. Odavde se može razvijati ne iz nužde, već prema planu.