Evaluarea soluțiilor de failover corporative

Facturarea funcționează, gestionarea comenzilor funcționează, depozitul avansează - până când un server central, o conexiune la internet sau o aplicație cade. Atunci se dezvăluie cine mai poate lucra, ce date sunt accesibile și care procese se opresc complet. Evaluarea soluțiilor de failover corporative nu este, așadar, în primul rând o sarcină de achiziție a infrastructurii. Este vorba despre examinarea cât de rapid o eroare tehnică devine o problemă de afaceri.

Într-o companie cu 20-500 de angajați, oprirea rar este spectaculoasă în primul minut. La început, cineva nu poate imprima o etichetă. Comanda din magazinul online nu ajunge în sistemul de management. Datele necesare pentru planul de producție sunt disponibile doar într-un dosar partajat care nu este accesibil. După câteva ore, telefoanele, e-mailurile și listele manuale înlocuiesc sistemele. Aceasta nu este doar o pierdere de venituri: cauzează erori, întârzieri, ore suplimentare și decizii manageriale incerte.

Ce trebuie evaluat de fapt?

Failover-ul este un mecanism de operare de rezervă care pune în funcțiune o altă resursă în locul unui component defect. Poate fi un server secundar, o conexiune alternativă la internet, un dispozitiv de rețea de rezervă, o replică a bazei de date sau un mediu care rulează în cloud. Definiția tehnică este însă doar punctul de plecare.

Întrebarea managerială este mai degrabă aceasta: dacă acest sistem nu este accesibil, ce anume nu se poate întâmpla în companie? Nu toate sistemele merită același nivel de protecție. O întrerupere de câteva ore a unui arhiv intern poate fi gestionabilă. În schimb, întreruperea procesării comenzilor, a informațiilor despre stocuri, a controlului producției sau a conexiunii de facturare poate deveni rapid un risc de afaceri direct.

O evaluare bună nu începe cu întrebarea dacă sunt necesare două servere. Mai întâi trebuie să se schițeze cum trece o comandă, un ordin de lucru sau o cerere de livrare prin sisteme și oameni. Adesea, aici se observă că cea mai mare dependență nu este aplicația, ci o singură integrare, un dosar partajat comun sau o soluție manuală cunoscută de un angajat.

Primul pas în evaluarea soluțiilor de failover corporative: impactul asupra afacerii

Este recomandabil să se lucreze cu câteva scenarii de afaceri concrete, nu cu întrebări generale. Ce se întâmplă, de exemplu, dacă internetul companiei cade timp de patru ore într-o dimineață de luni? Poate depozitul să pregătească comenzi? Ajung comenzile din magazinul online? Accesează vânzătorii datele clienților? Poate departamentul financiar să emită facturi sau să verifice datele bancare?

La fel de importantă este examinarea erorilor aplicației. Dacă ERP-ul este accesibil, dar conexiunea dintre magazinul online și ERP se oprește, echipa observă acest lucru imediat? Comenzile sunt puse în așteptare, se pierd sau colegii încep să le înregistreze manual? Înregistrarea manuală poate părea o soluție pe termen scurt, dar ulterior duce la duplicare, stocuri incorecte și muncă de reconciliere.

La evaluarea impactului, este recomandabil să se trateze separat patru perspective:

• venituri și servicii pentru clienți: se pierd comenzi, livrări sau facturări;
• operațiuni: se opresc depozitul, producția, achizițiile sau serviciul clienți;
• date și conformitate: pot fi compromise datele, se pot pierde tranzacții, pot fi afectate obligațiile de înregistrare;
• încărcare umană: cine gestionează eroarea, cine poate aplica un proces de evitare și cât timp poate fi menținută această situație.

Pe baza acestora, se poate face diferența între o întrerupere neplăcută și una inacceptabilă. Această diferență determină dacă un sistem are nevoie doar de o documentare a recuperării sau de o tranziție automată.

RTO și RPO: două valori care trebuie traduse în limbaj de afaceri

În planificarea failover-ului apar adesea două abrevieri. RTO, sau obiectivul de timp de recuperare, indică cât timp trebuie să dureze până când un serviciu devine din nou utilizabil. RPO, sau obiectivul de punct de recuperare, indică câtă pierdere de date este acceptabilă.

Cifrele în sine au puțină valoare. Faptul că un sistem are un RTO de patru ore este interpretabil doar dacă compania știe ce se întâmplă în acele patru ore. Dacă între orele opt dimineața și prânz aceasta înseamnă oprirea livrărilor din depozit, obiectivul poate fi prea relaxat. Dacă afectează un mediu de raportare rar utilizat, ar putea fi justificat.

Același lucru este valabil și pentru RPO. O pierdere de date de o oră poate fi acceptabilă pentru anumite arhive de documente, dar nu într-un sistem de comandă sau producție unde apar noi tranzacții în fiecare minut. În astfel de cazuri, nu este suficientă o copie de rezervă nocturnă. Poate fi necesară replicarea, backup-uri mai frecvente sau o logică de aplicație care să asigure restaurabilitatea tranzacțiilor.

Obiectivele prea stricte au un cost. Tranziția imediată, capacitatea menținută în mai multe locații și sincronizarea continuă a datelor necesită investiții semnificative și disciplină operațională. Scopul nu este de a proiecta fiecare sistem pentru disponibilitate la nivel bancar. Scopul este ca protecția să fie proporțională cu consecințele reale de afaceri ale întreruperii.

Nu este suficient un server de rezervă dacă dependențele rămân într-un singur loc

Multe organizații au backup-uri, poate chiar și un server secundar, dar totuși rămâne un singur punct de eșec în funcționare. Mediul secundar este inutil dacă folosește aceeași conexiune la internet, se bazează pe același serviciu de autentificare sau aceeași integrare conectează sistemele.

Prin urmare, examinarea trebuie să acopere întregul lanț: rețea, alimentare, DNS, gestionarea identității, baze de date, aplicații, furnizori externi și integrări. De exemplu, un magazin online poate fi accesibil, în timp ce serviciul de plată, informațiile despre stocuri sau conexiunea cu transportatorul nu funcționează. Din punct de vedere al afacerii, aceasta este o întrerupere parțială, dar foarte reală.

Procesele manuale reprezintă, de asemenea, o dependență. Dacă un angajat exportă un fișier în fiecare după-amiază și apoi îl încarcă într-un sistem partener, absența persoanei respective și eroarea de partajare a fișierelor pot cauza o oprire. Aici, failover-ul este parțial o problemă tehnică, parțial o reproiectare a procesului. Poate că răspunsul corect nu este un mediu scump cu disponibilitate ridicată, ci eliminarea transferului manual și asigurarea verificabilității integrării. tétele.

Tranziție automată sau manuală?

Failover-ul automat este mai rapid, dar mai complex. Este util atunci când întreruperea cauzează daune de afaceri măsurabile în câteva minute și starea serviciului poate fi verificată în siguranță. De exemplu, poate fi justificat pentru un serviciu online utilizat direct de clienți sau pentru o conexiune de date de producție continuă.

Tranziția manuală este mai lentă, dar în multe cazuri mai simplă, mai ieftină și mai controlabilă. Pentru o aplicație de afaceri internă, a cărei recuperare de câteva ore este acceptabilă, cu documentație adecvată și responsabili desemnați, aceasta poate fi decizia rațională. Cheia este ca procesul să fie cu adevărat realizabil sub presiune, nu doar să existe într-o descriere tehnică veche.

Între cele două modele există și soluții hibride. Conexiunea la internet poate trece automat la o linie de rezervă, în timp ce recuperarea unui sistem de afaceri mai puțin critic rămâne supusă aprobării și inițierii manuale. Aceasta se potrivește adesea mai bine cu riscurile reale decât forțarea tranziției automate peste tot.

Testul este cea mai importantă parte a evaluării

Failover-ul netestat este mai mult o presupunere decât o funcționalitate. Despre backup se află că este utilizabil doar atunci când datele sunt efectiv restaurate din el. Același lucru este valabil și pentru planurile de tranziție: mediul secundar poate porni, dar utilizatorii pot să nu se poată conecta, o relație de parteneriat poate bloca noua adresă IP sau sistemul poate afișa un statut de date mai vechi.

Testul trebuie să urmeze un scenariu de afaceri. Nu este suficient să se demonstreze că o mașină virtuală a pornit. Trebuie verificat dacă comanda este creată, transferată în următorul sistem, apare în depozit, documentul este generat și raportarea este restaurată. Abaterile care apar în timpul testului sunt deosebit de valoroase, deoarece dezvăluie acele dependențe ascunse pe care desenele sistemului nu le conțin adesea.

Testarea trebuie să aibă un responsabil, un proces-verbal și o listă de corecții. Dacă un pas critic există doar în mintea unui expert extern sau accesul este legat de un singur angajat, atunci nu s-a dezvoltat o adevărată continuitate a afacerii..

Ce indică dacă tranziția este prea complicată?

Dacă pentru restaurarea unui serviciu sunt necesare multe tabele, apeluri telefonice și improvizație, aceasta nu este adesea doar o problemă de infrastructură. Poate indica faptul că procesul trece prin prea multe sisteme, integrările nu sunt supravegheate sau responsabilitățile nu sunt clare. Evaluarea failover-ului este, așadar, o bună ocazie pentru companie să revadă de ce informațiile se mișcă pe acest traseu.

O soluție bine proiectată nu este neapărat spectaculoasă. De multe ori se manifestă prin faptul că, în caz de eroare, angajații știu ce se întâmplă, ce trebuie să facă și care date sunt considerate autentice. Acest control reduce panica, munca manuală inutilă și riscul asumat față de clienți.

Următoarea întrerupere nu este un moment bun pentru a afla dacă soluția de rezervă funcționează cu adevărat. Este recomandabil să se parcurgă procesele critice atunci când încă există timp pentru a întreba: ce se oprește, cine este afectat, ce poate fi înlocuit și ce nu are o soluție alternativă acceptabilă.