Eskalacja na hostingu, gdy sklep nie sprzedaje
Opselis
L1 czyta skrypt. L2 ma dostęp do węzła. Zgłoszenie czeka w kolejce razem z resetem hasła. RTO z umowy i własny monitoring, nie obietnica wsparcia na stronie oferty.
Popularny hosting sprzedaje pakiet i kolejkę zgłoszeń. Pierwsza linia sprawdza, czy domena wskazuje na serwer, czy PHP jest włączone, czy konto nie przekroczyło limitu. Awaria sklepu w szczycie to inny problem: baza nie odpowiada, dysk hosta ma wysoki await, sąsiad zjadł I/O, certyfikat wygasł, kolejka poczty zablokowała cron. Do osoby z dostępem do hiperwizora zgłoszenie idzie przez tę samą kolejkę. W tym czasie checkout zwraca 502, reklama nadal się kręci, zamówienia z marketplace wpadają w błąd. Narzędziem po Twojej stronie jest umowa (RTO, kanał, nazwisko) i monitoring, który stoi u Ciebie, nie hasło „wsparcie całą dobę” na stronie oferty.
Do czego służy eskalacja
Eskalacja ma skrócić czas od „sklep nie sprzedaje” do osoby z uprawnieniem. Na hostingu masowym kupujesz czas pierwszej odpowiedzi L1, nie czas naprawy. SLA 99,9 procent w miesiącu dopuszcza około 43 minut niedostępności. Przy pikie to utracona kampania, nie incydent w normie. Odpowiedź w 15 minut bywa autoresponderem. Restart MySQL, przeniesienie konta na inny node i restore nie są w tym samym zdaniu umowy.
Nie masz root. Nie zrestartujesz php-fpm, nie zrobisz failover, nie włączysz własnej strony statusu. Panel sprzedawcy bywa niedostępny razem z hostem. Infolinia nie łączy z administratorem węzła.
Jak działa kolejka przy awarii
Zgłoszenie wpada do worka razem z resetem hasła i prośbą o instalację WordPress. Priorytet „sklep stoi” ustawia L1. Jeśli skrypt mówi „limit CPU, dokup pakiet”, sprawa nie idzie dalej, choć przyczyną jest chory dysk hosta. L2 pracuje na dziesiątkach węzłów. Twój ticket czeka za cudzym restore. W Black Friday kolejka jest wspólna dla wszystkich klientów oferty „sklep”.
Komunikacja idzie mailem. Zrzutu z `vmstat` często nie masz, bo nie ma root. Proszą o wykres z Resource Usage, który sam nie wstaje. Brak nazwanego inżyniera: każda zmiana zmiany czyta historię od zera.
Skutek jest mierzalny. Koszyk nie domyka płatności. Bramka dostaje timeout i dubluje albo gubi zamówienie. Stan marketplace rozjeżdża się z magazynem. Marketing płaci za klik, który kończy się 502. Czas eskalacji liczy się od utraty przychodu, nie od numeru ticketu.
Jak ustawić dyżur zanim kupisz pakiet
W umowie, nie w FAQ: RTO na checkout (na przykład 30 minut do przywrócenia płatności), kanał poza kolejką WWW, kto ma uprawnienie do restartu usługi i przeniesienia VM. Pytanie o maintenance: czy dostajesz okno, czy restart node jest bez zapowiedzi. Pytanie o kopię: RPO, test restore, czy kopia jest na tym samym hoście.
Zanim zdasz się na sprzedawcę: sonda HTTP na koszyk, nie tylko na homepage. Alert do Was. Cloudflare przed originem. Log, który zostaje u Ciebie. Gdy host milczy, i tak wiesz, która warstwa padła.
Jeśli odpowiedzią na awarię ma być ticket L1, ten model nie trzyma sklepu. Wtedy VM z root, dyżur z playbookiem i jeden kanał: administracja IT. Opieka Magento i PrestaShop: ecommerce. Zasoby konta współdzielonego: hosting współdzielony.