Ako stabilizovať zdedenú infraštruktúru?

Pri pondelkovom rannom štarte opäť nereaguje starý server. Sklad nevidí objednávky, fakturácia čaká a zákaznícky servis sa snaží telefonicky zistiť, čo sa stalo. V takýchto prípadoch nie je otázkou, či je systém starý, ale ako stabilizovať zdedenú infraštruktúru tak, aby sa podnikanie nezastavilo a aby núdzová oprava nebola jedinou odpoveďou.

Zdedená infraštruktúra sa často stáva kritickou počas rokov. Predchádzajúca aplikácia beží len na konkrétnom serveri, rozšírenia siete sú nedokumentované, záloha existuje, ale obnovenie sa už dlho netestovalo. Medzitým firma rástla: viac objednávok, viac používateľov, viac integrácií a vyššie očakávania na rovnakom technickom základe.

Stabilizácia neznamená, že všetko treba okamžite vymeniť. V mnohých prípadoch je úplná výmena najväčším obchodným rizikom. Cieľom je najprv zabezpečiť, aby základná prevádzka bola predvídateľná, kontrolovateľná a obnoviteľná. Až potom je možné zodpovedne rozhodnúť o tempe modernizácie.

Ako stabilizovať zdedenú infraštruktúru z obchodného hľadiska?

Východiskovým bodom nie je zoznam serverov, ale mapovanie kritických obchodných procesov. Ktoré systémy sú nevyhnutné na prijímanie objednávok, spustenie výroby, vydávanie tovaru, fakturáciu alebo obsluhu zákazníkov? Ako dlho je možné tolerovať výpadok v jednotlivých oblastiach? Dvojhodinové meškanie správy môže byť nepríjemné, ale dvojhodinový výpadok skladu môže spôsobiť priamu stratu príjmov a dôvery.

Tento rozdiel určuje priority. Častou chybou je, že technický tím začína s tým, čo je najstaršie alebo najťažšie spravovateľné. Z obchodného hľadiska je však potrebné najprv chrániť to, ktorého porucha má najväčšie prevádzkové dôsledky.

Nezmapujte len systémy, ale aj závislosti

Obchodná aplikácia sa zriedka pokazí sama o sebe. Môže závisieť od databázy, súborového servera, sieťového pripojenia, licenčného servera, externého partnerského spojenia alebo jediného, už nepodporovaného klientského počítača. Webshop môže fungovať, ale ak sa informácie o zásobách nedostanú do ERP, predaj a sklad pracujú z odlišnej reality.

Preto by prieskum mal ukázať aj to, kde sú skryté jedinečné riešenia. Napríklad automatický prenos údajov v skutočnosti každé ráno spúšťa kolega. Alebo stará aplikácia funguje len preto, že niekto vie, ktorú službu treba reštartovať. Toto nie sú jednoduché IT riziká, ale osobne závislé prevádzkové riziká.

Je vhodné zaznamenať pre každú kritickú službu, aká je jej úloha, kde beží, s akými údajmi pracuje, na čo je napojená, kto je za ňu zodpovedný a čo sa stane v prípade jej výpadku. Nie je potrebné začať projekt dokumentácie, ktorý trvá mesiace. Ale na rozhodovanie je potrebný skutočný, spoločne prijatý obraz o súčasnom stave.

Najprv obnovte prevádzkovú kontrolu

Stabilná infraštruktúra neznamená, že sa nikdy nič nepokazí. Znamená to, že chyby sú včas zistené, ich vplyv je obmedzený a obnova nie je improvizáciou.

Prvým prvkom je pozorovateľnosť. Ak je úložisko, pamäť, sieťové pripojenie, stav služby alebo proces zálohovania viditeľný len vtedy, keď už prichádza sťažnosť, firma je neustále v omeškaní. Správne monitorovanie nie je technická dekorácia. Pomáha rozlíšiť spomaľujúci, nasýtený systém od neočakávanej poruchy a poskytuje základ pre plánovanie kapacity.

Druhým prvkom je riadenie zmien. Mnohé zdedené prostredia nie sú krehké kvôli jednej veľkej chybe, ale kvôli mnohým malým, nesledovaným zmenám. Nový používateľ, ručne zmenené oprávnenie, urgentná aktualizácia, dočasné pravidlo firewallu a potom zabudnutá výnimka. Ak nie je jasné, čo sa zmenilo, kto to schválil a ako sa dá vrátiť späť, každá intervencia zvyšuje riziko.

Tretím prvkom je usporiadanie prístupov. Všeobecné administrátorské účty, zdieľané heslá a aktívne oprávnenia bývalých zamestnancov sú naraz bezpečnostnými a prevádzkovými problémami. Pri vyšetrovaní chyby nie je možné zistiť, kto čo urobil. Oprávnenia by mali byť viazané na pracovnú pozíciu a zodpovednosť a kritické prístupy by mali byť pravidelne prehodnocované.

Záloha má hodnotu len vtedy, ak je možné ju obnoviť

Mnohé organizácie sa uspokoja s tým, že záloha sa vykonáva denne. To je málo. Skutočné otázky sú iné: je záloha neporušená, je oddelená od produkčného prostredia, koľko údajov by sa stratilo pri obnove a ako rýchlo sa môžu kritické procesy opäť spustiť?

Pre výrobné alebo obchodné spoločnosti nie je jedno, či obnova databázy trvá tri hodiny alebo tri dni. Ani to, či fungujú integrácie, oprávnenia a zdieľania súborov spojené s obnoveným systémom. Plán zálohovania by sa preto nemal považovať za administratívnu zhodu, ale ako nástroj pre kontinuitu podnikania.

Pravidelná skúška obnovy zvyčajne rýchlo odhalí skryté nedostatky: chýbajúci šifrovací kľúč, nedokumentovanú konfiguráciu, vyčerpané úložisko alebo závislosť, o ktorej nikto nevedel. Toto je nepríjemné zistenie, ale v kontrolovanej situácii je oveľa lacnejšie ako počas ostrého incidentu.

Nezačínajte s úplnou výmenou ako prvým projektom

Pri modernizácii zdedenej infraštruktúry je reakcia „vymeniť všetko“ často pochopiteľná, ale zriedka dobrý prvý krok. Veľká migrácia súčasne ovplyvňuje aplikácie, údaje, integrácie, používateľské zvyky a prevádzkové procesy. Ak tieto nie sú preskúmané, projekt len presúva neistotu na novú platformu.

Postupný prístup zvyčajne znamená menšie riziko. Najprv sa môže oddeliť alebo chrániť najkritickejšia súčasť, usporiadať zálohovanie a prístupy, zdokumentovať konfiguráciu a potom modernizovať zastarané prvky v samostatných etapách. To môže byť virtualizácia serverov, segmentácia siete, prechod na podporovaný operačný systém, zavedenie cloudovej služby alebo nahradenie aplikácie. Správna cesta závisí od toho, aký obchodný proces daný prvok podporuje a ako je prepojený s inými systémami.

Niekedy je opodstatnené ponechať starú, ale stabilnú aplikáciu, pretože jej výmena by spôsobila príliš veľkú zmenu procesu. V takom prípade je potrebné zabezpečiť jej prostredie, regulovať jej spojenia a pripraviť plán na jej nahradenie v budúcnosti. Inokedy je práve dočasné rozhranie alebo ručný export vytvorený pre starý systém väčším rizikom ako samotná aplikácia.

Technická stabilita je aj ľudskou zodpovednosťou

Ak len jedna osoba vie, ako reštartovať firemný systém, potom nie je stabilná prevádzka. Ak finančné oddelenie opravuje údaje vo vlastnej tabuľke, pretože nedôveruje centrálnemu systému, problém infraštruktúry už ovplyvňuje aj podporu rozhodovania. Technická neistota rýchlo vytvára ručné obchádzky, paralelné záznamy a frustráciu.

Preto je súčasťou stabilizácie jednoduchý, použiteľný prevádzkový poriadok: kto prijíma upozornenia, kto rozhoduje v prípade incidentu, kde je dokumentácia, ako prebieha eskalácia a kedy sa prehodnocujú riziká. Nie každá firma potrebuje 24-hodinovú vnútornú pohotovosť alebo zložitý firemný pravidelný systém. Ale každá kritická prevádzka potrebuje určenú zodpovednosť a vyskúšaný postup.

Na konci dobrého stabilizačného programu nemusí byť technológia viditeľne nová. Skôr je prevádzka tichšia: menej neočakávaných výpadkov, rýchlejšie riešenie problémov, spoľahlivejšie údaje a prevádzka nezávisí na pamäti jediného kolegu. Odtiaľ je možné rozvíjať nie z núdze, ale podľa plánu.