„ERP nie wystawia dokumentów sprzedaży” zgłasza użytkownik. Service desk prosi o komunikat z ekranu, ostatnią poprawną operację i informację o obejściu. Cała rozmowa pozostaje pod jednym numerem, a jedna osoba prowadzi komunikację. Dyżurny od razu ocenia wpływ awarii na sprzedaż, magazyn i dane. Runbook podpowiada mu próg eskalacji oraz kolejny kontakt. Po przekazaniu ERP osoba na dyżurze on-call korzysta z tego zapisu, dostępu diagnostycznego i scenariusza odtworzenia, a pracę nad aplikacją oddziela od wsparcia infrastruktury.
Co naprawdę zatrzymało pracę
Przy takim zgłoszeniu najpierw ustal, co nadal działa. Jeśli użytkownik otwiera kartotekę i widzi magazyn, problem ma węższy zasięg niż całkowita niedostępność ERP. Zapisz ostatni poprawnie wystawiony dokument, treść błędu, liczbę osób z tym samym objawem i możliwość pracy inną drogą. Wszystko zostaje pod jednym numerem do zamknięcia sprawy.
Nazwy klas mogą odpowiadać lokalnemu modelowi. Ich znaczenie pozostaje biznesowe. Incydent ma najwyższą klasę, gdy sprzedaż stoi i nie ma bezpiecznego obejścia. Problem kilku osób ma niższy poziom, jeśli reszta firmy może bezpiecznie pracować. Opóźniony raport ma mniejszy wpływ niż przerwana wymiana dokumentów z systemem zewnętrznym.
Dyżurny nie musi czekać, aż kilka osób potwierdzi ten sam skutek. Eskaluje sprawę, gdy awaria obejmuje kolejne oddziały, pojawia się podejrzenie niespójności danych, zbliża się zamknięcie okresu albo przestaje działać obejście. Osoba prowadząca informuje jednym kanałem i wzywa wykonawcę właściwego dla objawu. Użytkownik nie szuka kontaktów na własną rękę.
Co dyżurny robi z tym zgłoszeniem
Gotowość on-call buduje się przed pierwszym telefonem. Sprawdź, czy lista kontaktów uwzględnia zastępstwa, osoby dyżurujące mają dostęp do systemu zgłoszeń i logów, a identyfikatory usług są pod ręką. Przed pierwszym incydentem ustal też, które procesy ERP obejmuje dyżur i jaki materiał trzeba zebrać do eskalacji. W runbooku zapisz, kto po stronie klienta może poza zwykłymi godzinami zatwierdzić obejście, wstrzymanie wymiany lub rozpoczęcie odtworzenia.
Przy zmianie dyżuru nie zakładaj nowej sprawy. Kolejna osoba dostaje pod tym samym numerem opis bieżącego wpływu, klasę incydentu, ostatnią czynność, odrzucone hipotezy i najbliższy próg eskalacji. Przekazanie wskazuje też, kto od tej chwili prowadzi komunikację we wspólnym kanale. Dyżur klienta lub software house'u nie poszerza zakresu usługi NSIX; zasady kontaktu ze wsparciem infrastruktury wynikają z wcześniejszych ustaleń.
Kiedy sprawa trafia do kolejnej osoby
Użytkownik ma opisać skutek, nie diagnozować system. IT klienta uzupełnia kontekst: ostatnie zmiany, zasięg błędu, działanie na innym stanowisku i dostępność pozostałych funkcji. Na tej podstawie uprawniona osoba po stronie klienta wybiera bezpieczne obejście i treść komunikatu do biznesu.
Jeśli zapis dokumentu zatrzymał się w ERP, software house sprawdza kod, konfigurację modułu i zdarzenia aplikacyjne w zakresie swojej umowy. Gdy dokument opuścił ERP, a nie dotarł do systemu docelowego, integrator bada mapowanie, kolejkę i odpowiedź odbiorcy. Stan bazy SQL i spójność danych sprawdza osoba wskazana w architekturze klienta, często po stronie wykonawcy aplikacji lub integratora. Każde ustalenie wraca pod ten sam numer.
Objaw może też wskazać na infrastrukturę. G2E może dostarczać prywatne środowisko serwerów wirtualnych i sieci dla ERP oraz SQL. Gdy ślad prowadzi do serwera lub sieci, zgłoszenie dla NSIX zawiera nazwę usługi, czas wystąpienia, wpływ na pracę i zebrany materiał techniczny. NSIX wykonuje prace w uzgodnionym zakresie wsparcia; kod ERP, integracje, konta i decyzje biznesowe pozostają po stronie klienta oraz właściwych wykonawców.
Jak cele SLA, RTO i RPO pomagają w wyborze
Gdy sprzedaż staje, trzy skróty przestają być dodatkiem do umowy. SLA określa uzgodnione warunki obsługi incydentu. RTO opisuje docelowy czas przywrócenia procesu, a RPO dopuszczalną utratę danych wyrażoną czasem. Te cele zależą od krytyczności procesu, architektury i umów z wykonawcami. Sam serwer wirtualny ich nie gwarantuje.
Połącz cele z klasyfikacją incydentu. Gdy dokumentów nie da się wystawić i nie ma obejścia, prowadzący uruchamia eskalację, a uprawniona osoba decyduje o odtworzeniu. Opóźniony raport może poczekać na spokojną diagnozę, o ile nie zatrzymuje krytycznego procesu. Te trzy cele pomagają dyżurnemu wybrać dalsze działanie.
Odtworzenie kończy użytkownik, nie serwer
Jeśli diagnoza prowadzi do odtworzenia, dyżurny musi wiedzieć, w jakiej kolejności uruchamiać usługi. Najpierw wybiera się uzgodniony stan bazy SQL i odtwarza dane, potem uruchamia ERP oraz jego połączenie z bazą, a na końcu włącza integracje w kontrolowany sposób. Inna architektura może wymagać innej sekwencji, którą runbook opisuje przed incydentem.
Standardowy backup VM w G2E obejmuje maszynę wirtualną. Nie zastępuje kopii SQL przygotowanych dla danej aplikacji, kontroli spójności danych ani instrukcji uruchomienia ERP. Klient i wykonawcy aplikacji wybierają źródło odtworzenia oraz ustalają, co zrobić z transakcjami, które mogły pozostać między systemami.
Zielony status serwera nie zamyka sprawy. Po uruchomieniu SQL, ERP i integracji użytkownik otwiera kartotekę i wykonuje zwykłą operację na dokumencie sprzedaży. IT sprawdza, czy zapis trafił do SQL i czy wymiana dotarła do celu. Jeżeli operacja się nie uda, sprawa zachowuje numer i osobę prowadzącą.
Runbook ma pomóc człowiekowi, który przyjmuje zgłoszenie i wybiera kolejne działanie. Daje mu opis wpływu, próg eskalacji i kolejność od bazy SQL do operacji użytkownika. Firma otrzymuje jedną odpowiedź i wie, kiedy awaria rzeczywiście przestała blokować sprzedaż.