Hodnotenie podnikových failover riešení

Fakturácia funguje, správa objednávok funguje, sklad tiež napreduje - až kým nevypadne centrálny server, internetové pripojenie alebo aplikácia. Vtedy sa ukáže, kto ešte môže pracovať, ktoré údaje sú dostupné a ktoré procesy sa úplne zastavia. Hodnotenie podnikových failover riešení preto nie je primárne úlohou nákupu infraštruktúry. Ide o skúmanie, ako rýchlo sa technická chyba môže stať obchodným problémom.

V podniku s 20-500 zamestnancami je výpadok zriedka viditeľný v prvej minúte. Najprv niekto nemôže vytlačiť štítok. Objednávka z e-shopu sa neprenesie do obchodného systému. Údaje potrebné na výrobný plán sú len v zdieľanom priečinku, ktorý práve nie je dostupný. Po niekoľkých hodinách už telefóny, e-maily a ručne vedené zoznamy nahrádzajú systémy. To nielenže spôsobuje stratu príjmu, ale aj chyby, oneskorenia, nadčasy a neisté manažérske rozhodnutia.

Čo je potrebné skutočne hodnotiť?

Failover je záložný prevádzkový mechanizmus, ktorý nahrádza zlyhanú súčasť iným zdrojom. Môže to byť sekundárny server, alternatívne internetové pripojenie, záložné sieťové zariadenie, replika databázy alebo prostredie bežiace v cloude. Technická definícia je však len východiskovým bodom.

Manažérska otázka je skôr táto: ak tento systém nie je dostupný, čo presne sa nemôže stať v podniku? Nie každý systém si zaslúži rovnakú úroveň ochrany. Niekoľkohodinový výpadok interného archívu môže byť zvládnuteľný. Výpadok spracovania objednávok, informácií o skladových zásobách, riadenia výroby alebo fakturačných spojení sa však rýchlo môže stať priamym obchodným rizikom.

Dobrý hodnotiaci proces teda nezačína otázkou, či sú potrebné dva servery. Najprv je potrebné načrtnúť, ako prechádza objednávka, pracovný list alebo požiadavka na dodanie cez systémy a ľudí. Často sa tu ukáže, že najväčšia závislosť nie je ani tak aplikácia, ale jediná integrácia, spoločné zdieľanie súborov alebo ručný obchvat, ktorý pozná zamestnanec.

Prvým krokom hodnotenia podnikových failover riešení je: obchodný dopad

Stojí za to pracovať s niekoľkými konkrétnymi obchodnými scenármi, nie s všeobecnými otázkami. Čo sa stane napríklad, ak podnikové internetové pripojenie vypadne na štyri hodiny v pondelok ráno? Môže sklad kompletizovať objednávky? Prichádzajú objednávky z e-shopu? Majú obchodníci prístup k údajom o zákazníkoch? Môže finančné oddelenie vystaviť faktúru alebo overiť bankové údaje?

Rovnako dôležité je preskúmanie aplikačných chýb. Ak je ERP dostupné, ale spojenie medzi e-shopom a ERP je prerušené, všimne si to tím okamžite? Stoja objednávky v rade, strácajú sa, alebo ich kolegovia začínajú ručne znova zaznamenávať? Ručné zaznamenávanie sa môže krátkodobo zdať ako pomoc, ale neskôr vedie k duplikáciám, chybným zásobám a potrebe zosúladenia.

Pri hodnotení dopadu je vhodné oddeliť štyri perspektívy:

• príjmy a zákaznícky servis: chýba objednávka, dodávka alebo fakturácia;
• prevádzka: zastaví sa sklad, výroba, nákup alebo zákaznícky servis;
• údaje a súlad: môžu byť poškodené údaje, stratené transakcie, poškodené povinnosti záznamov;
• ľudské zaťaženie: kto rieši chybu, kto môže použiť obchádzkový proces a ako dlho môže táto situácia trvať.

Na základe toho je možné rozlíšiť medzi nepríjemným a neprijateľným výpadkom. Tento rozdiel určuje, či je pre systém postačujúca dokumentovaná obnova alebo je potrebný automatický prechod.

RTO a RPO: dve hodnoty, ktoré je potrebné preložiť do obchodného jazyka

V plánovaní failoveru sa často objavujú dve skratky. RTO, teda cieľ obnovy, určuje, za aký čas musí byť služba opäť použiteľná. RPO, teda cieľ obnovy bodu, označuje, koľko straty dát je akceptovateľné.

Samotné čísla majú malú hodnotu. To, že systém má RTO štyri hodiny, je zmysluplné len vtedy, ak podnik vie, čo sa počas tých štyroch hodín deje. Ak to znamená zastavenie skladovej expedície medzi ôsmou ráno a poludním, cieľ môže byť príliš voľný. Ak sa týka zriedkavo používaného reportovacieho prostredia, môže byť aj opodstatnený.

Pri RPO je to rovnaké. Hodinová strata dát môže byť prijateľná pre niektoré dokumentové úložiská, ale nie pre objednávkový alebo výrobný systém, kde každú minútu vznikajú nové transakcie. V takýchto prípadoch nestačí nočné zálohovanie. Môže byť potrebná replikácia, častejšie zálohovanie alebo aplikačná logika, ktorá zabezpečí obnoviteľnosť transakcií.

Príliš prísne ciele majú svoju cenu. Okamžitý prechod, kapacita udržiavaná na viacerých miestach a nepretržitá synchronizácia dát vyžadujú značné investície a prevádzkovú disciplínu. Nie je cieľom navrhnúť všetky systémy na bankovú úroveň dostupnosti. Cieľom je, aby ochrana bola úmerná skutočným obchodným dôsledkom výpadku.

Záložný server nestačí, ak závislosti zostávajú na jednom mieste

Mnohé organizácie majú zálohy, prípadne aj sekundárny server, ale stále zostáva jediný bod zlyhania v prevádzke. Sekundárne prostredie sa môže spustiť, ale ak používa rovnaké internetové pripojenie, spolieha sa na rovnakú autentifikačnú službu alebo rovnaká integračná služba spája systémy, je to zbytočné.

Preto musí skúmanie pokrývať celý reťazec: sieť, napájanie, DNS, správu identity, databázu, aplikácie, externých poskytovateľov a integrácie. Napríklad e-shop môže byť dostupný, zatiaľ čo platobná služba, informácie o zásobách alebo prepravné spojenie nefungujú. Z obchodného hľadiska je to čiastočný, ale veľmi reálny výpadok.

Manuálne procesy tiež predstavujú závislosť. Ak zamestnanec každý deň popoludní exportuje súbor a potom ho nahráva do systému partnera, jeho neprítomnosť a chyba zdieľania súborov môžu spôsobiť výpadok. Tu je failover čiastočne technickou otázkou, čiastočne otázkou prepracovania procesu. Možno správnou odpoveďou nie je drahé prostredie s vysokou dostupnosťou, ale odstránenie ručného prenosu a zabezpečenie overiteľnosti integrácie .

Automatický alebo ručný prechod?

Automatický failover je rýchlejší, ale zložitejší. Je užitočný, ak výpadok spôsobuje obchodnú škodu merateľnú v minútach a stav služby je možné bezpečne overiť. Napríklad pri online službe používanou priamo zákazníkmi alebo pri nepretržitom výrobnom dátovom spojení môže byť opodstatnený.

Ručný prechod je pomalší, ale v mnohých prípadoch jednoduchší, lacnejší a lepšie kontrolovateľný. Pri interných obchodných aplikáciách, ktorých niekoľkohodinová obnova je prijateľná, s vhodnou dokumentáciou a určenými zodpovednými osobami môže byť toto racionálne rozhodnutie. Kľúčom je, aby bol proces skutočne vykonateľný aj pod tlakom, nielen existoval v starom technickom popise.

Medzi týmito dvoma modelmi existujú aj hybridné riešenia. Internetové pripojenie môže automaticky prejsť na záložnú linku, zatiaľ čo obnova menej kritického obchodného systému je stále podmienená schválením a ručným spustením. To často lepšie zodpovedá skutočným rizikám než nútenie automatického prechodu všade.

Test je najdôležitejšou časťou hodnotenia

Netestovaný failover je skôr predpoklad než funkčnosť. Aj o zálohe sa zistí, že je použiteľná, až keď sa z nej skutočne obnovia údaje. To isté platí pre plány prechodu: sekundárne prostredie sa môže spustiť, ale môže sa stať, že používatelia sa nemôžu prihlásiť, partnerské spojenie blokuje novú IP adresu alebo systém zobrazuje starší stav údajov.

Test by mal sledovať obchodný scenár. Nestačí len potvrdiť, že sa spustil virtuálny stroj. Treba overiť, či sa objednávka vytvorí, prejde do ďalšieho systému, objaví sa v sklade, vytvorí sa doklad a obnoví sa reportovanie. Odchýlky, ktoré vzniknú počas testu, sú obzvlášť cenné, pretože odhaľujú skryté závislosti, ktoré často nie sú zahrnuté v systémových schémach.

Testovanie by malo mať zodpovednú osobu, protokol a zoznam opráv. Ak je kritický krok len v hlave externého odborníka alebo je prístup viazaný na jediného zamestnanca, potom nevznikla skutočná kontinuita podnikania.

Na čo poukazuje, ak je prechod príliš zložitý?

Ak obnova služby vyžaduje veľa tabuliek, telefonátov a improvizácie, často to nie je len problém infraštruktúry. Môže to naznačovať, že proces prechádza cez príliš veľa systémov, integrácie nie sú monitorované alebo zodpovednosti nie sú jasné. Hodnotenie failoveru je preto tiež dobrou príležitosťou pre podnik, aby sa znova pozrel na to, prečo informácie prechádzajú touto cestou.

Dobre navrhnuté riešenie nemusí byť nevyhnutne nápadné. Často sa prejavuje tým, že v prípade chyby zamestnanci vedia, čo sa deje, čo majú robiť a ktoré údaje sú považované za dôveryhodné. Táto kontrola znižuje paniku, zbytočnú ručnú prácu a riziko voči zákazníkom.

Ďalší výpadok nie je vhodným časom na zistenie, či záložné riešenie skutočne funguje. Je vhodné prejsť si kritické procesy, keď je ešte čas sa opýtať: čo sa zastaví, kto je ovplyvnený, čo je nahraditeľné a čo nemá prijateľnú obchádzku.