Piątek, 16:02. W 40 sklepach trwa popołudniowy szczyt. Magazyn kompletuje kilka tysięcy zamówień online. Wtedy centralna baza obsługująca wymianę danych z WMS przestaje odpowiadać.
Pierwsze objawy nie wyglądają groźnie. Część kas nie pobiera aktualnych stanów i promocji. W magazynie znikają nowe zadania kompletacyjne. E-commerce nadal przyjmuje zamówienia, choć dostępność produktów przestaje odpowiadać rzeczywistości.
Po kilkunastu minutach problem przestaje dotyczyć infrastruktury IT. Uderza w sprzedaż, magazyn i obsługę klientów.
Z każdą minutą przybywa transakcji do weryfikacji, zaległych paczek i klientów czekających na rozwiązanie problemu.
Jak jedna awaria zaczyna zatrzymywać sprzedaż?
Centralna baza nie musi od razu wyłączyć wszystkich kas. Groźniejsza bywa częściowa niedostępność. Systemy nadal pracują, ale korzystają z niepełnych albo niespójnych danych.
POS działa, ale nie ma danych, którym można zaufać
W jednym sklepie transakcja przechodzi prawidłowo. W drugim pojawia się błąd. W trzecim sprzedawca ręcznie sprawdza cenę produktu.
Personel nie wie jeszcze, czy problem dotyczy salonu, całej sieci czy systemu centralnego. Helpdesk dostaje pierwsze zgłoszenia. Sprzedaż zwalnia.
Przy kasach rosną kolejki. Część klientów rezygnuje z zakupów. Ręczne obejścia generują błędy, które trzeba będzie później wyjaśnić.
WMS zatrzymuje realizację zamówień
Równolegle WMS przestaje otrzymywać dane albo nie może zapisywać zmian.
Operatorzy magazynu nie dostają kolejnych zadań kompletacyjnych. Zamówienia z e-commerce wpływają, lecz nie przechodzą do realizacji.
Po kilkunastu minutach sklep internetowy może sprzedawać produkty, których nie ma już w magazynie lub salonach. Aktualny zapas nie dociera do kanału online.
Problem jednego komponentu obejmuje POS, WMS, e-commerce i ERP.
W omnichannel awaria szybko wychodzi poza system, w którym pojawił się pierwszy błąd. Zatrzymuje cały łańcuch sprzedaży i realizacji zamówień.
Kiedy incydent IT staje się problemem operacyjnym?
Po pół godzinie COO nie potrzebuje już informacji, który serwer zgłosił błąd. Liczą się skutki.
- sklepy obsługują klientów wolniej,
- magazyn nie realizuje nowych zleceń,
- stany w e-commerce są nieaktualne,
- contact center nie może potwierdzić części zamówień,
- rośnie liczba transakcji wymagających późniejszej kontroli.
Koszt nie kończy się na utraconym obrocie.
Po przywróceniu systemów pozostają niekompletne transakcje, błędne rezerwacje, anulowania i zaległości magazynowe. Im dłuższy przestój, tym więcej pracy po jego zakończeniu.
Godzina niedostępności POS lub WMS może więc obciążać operacje długo po wznowieniu sprzedaży.
Backup istnieje. Czy pozwoli szybko wrócić do sprzedaży?
Kopia zapasowa nie przesądza o tym, jak szybko wrócą POS, WMS i ERP.
Administratorzy znajdują ostatnią poprawną kopię bazy. Pochodzi sprzed godziny.
Jej przywrócenie cofa środowisko do wcześniejszego stanu. Trzeba ustalić, które zamówienia opłacono, które produkty wydano i jakie stany powinny widnieć w systemie.
RPO i RTO odpowiadają na dwa różne problemy
| Wskaźnik | Na jakie pytanie odpowiada? | Skutek biznesowy |
| RPO | Ile danych firma może utracić? | Określa, jak duża część transakcji, zamówień lub zmian stanów może wymagać odtworzenia |
| RTO | Jak szybko system musi wrócić do działania? | Wyznacza maksymalny czas niedostępności procesu sprzedażowego lub operacyjnego |
Godzinne RPO może wystarczyć dla systemu raportowego. Dla bazy zamówień lub płatności godzina oznacza już setki operacji wymagających weryfikacji.
POS obsługujący bieżącą sprzedaż może potrzebować znacznie krótszego RTO niż system raportowy. WMS blokujący magazyn również wymaga priorytetu adekwatnego do skutków przestoju.
RPO i RTO powinny więc wynikać z wpływu awarii na sprzedaż, logistykę i obsługę klienta. Nie z domyślnej konfiguracji backupu.
Backup mówi, czy istnieje kopia danych. Disaster Recovery określa, jak przywrócić sprzedaż w wymaganym czasie.
Jak Disaster Recovery zmienia przebieg awarii?
Przygotowany Disaster Recovery ogranicza czas przestoju i liczbę decyzji podejmowanych pod presją.
Monitoring infrastruktury Zespół zna zależności między systemami i kolejność ich odtwarzania.
Uszkodzony komponent zostaje odizolowany. Usługi mogą zostać przełączone do środowiska zapasowego albo odtworzone z odpowiednio świeżej repliki.
Proces recovery powinien przebiegać według ustalonej kolejności:
- przywrócenie warstwy danych i usług bazowych,
- uruchomienie systemów zależnych,
- wznowienie integracji,
- przywrócenie POS i kanałów sprzedażowych,
- kontrola spójności transakcji, zapasów i zamówień.
Dobrze zaprojektowane odtwarzanie po awarii i kopie zapasowe obejmują replikację, ustaloną kolejność recovery, failover, odizolowane kopie i regularne testy.
IT nie tworzy wtedy procedury podczas incydentu. Realizuje plan sprawdzony wcześniej.
Co trzeba ustalić przed kolejną awarią?
Priorytety systemów, dopuszczalny przestój i akceptowalna utrata danych muszą wynikać z wpływu awarii na operacje.
POS obsługuje sprzedaż. WMS steruje magazynem. ERP zasila wiele procesów. Integracje odpowiadają za przepływ danych pomiędzy kanałami.
Każdy z tych elementów może potrzebować innego RTO, RPO i sposobu odtworzenia.
Kolejność odtwarzania musi wynikać z zależności biznesowych
Zespół powinien wcześniej wiedzieć, które usługi uruchamiać jako pierwsze i od czego zależą kolejne.
Restart aplikacji nie pomoże, jeśli baza pozostaje niespójna albo integracja nie przekazuje stanów do sklepów.
Priorytety recovery powinny odpowiadać kolejności przywracania sprzedaży.
Plan Disaster Recovery trzeba regularnie testować
Dokument nie potwierdza, że założone RTO jest osiągalne.
Test powinien sprawdzić:
- czy backup można rzeczywiście odtworzyć,
- ile trwa uruchomienie krytycznych systemów,
- czy failover działa zgodnie z planem,
- czy monitoring wykrywa problem odpowiednio wcześnie,
- czy zespół zna kolejność działań,
- czy po odtworzeniu dane pozostają spójne.
Scenariusze testowe, takie jak audyty infrastruktury, powinny obejmować awarie infrastruktury, błędy ludzkie, niedostępność usług chmurowych i ransomware, które może objąć również lokalne kopie.
Ciągłość sprzedaży zaczyna się przed awarią
Najdroższym momentem na ustalanie kolejności odtwarzania POS, WMS i ERP jest chwila, gdy systemy już nie obsługują biznesu.
Business Continuity w handlu wymaga wspólnych decyzji operacji i IT. COO określa, jak długo proces może być niedostępny. IT przekłada ten limit na architekturę, RTO, RPO, backup, monitoring i procedury recovery.
Dobrze przygotowana organizacja zna odpowiedzi jeszcze przed incydentem: które systemy mają wrócić jako pierwsze, ile danych może utracić i jak długo sprzedaż może działać w trybie ograniczonym.
Odporności infrastruktury nie potwierdza dokument ani sam fakt posiadania backupu. Potwierdza ją dopiero sprawdzony scenariusz, w którym krytyczne procesy wracają do pracy w zakładanym czasie.
