Wsparcie Proxmox VE 24/7. Jak przygotować obsługę awarii?

Alarm z serwera przychodzi, gdy administrator jest poza biurem. Firma ma subskrypcję, ale nadal trzeba ustalić, kto odbierze powiadomienie, zbierze dane i podejmie decyzję o dalszych działaniach. Dobór wsparcia dla Proxmox Virtual Environment warto zacząć właśnie od takiej sytuacji. Zapowiedź rozszerzenia obsługi producenta jest dobrym momentem, żeby uporządkować własną procedurę.

Od kiedy wsparcie Proxmox ma działać całodobowo?

Od 19 października 2026 r. Proxmox uruchamia wsparcie 24/7 dla subskrypcji Premium. Standard ma zostać objęty nowym modelem w późniejszym terminie w IV kwartale 2026 r., a SLA dla Basic pozostaje bez zmian. We wrześniu trzeba więc dobierać usługę według obecnej umowy, z uwzględnieniem planowanej zmiany.

Wsparcie 24/7 ma wartość dopiero wtedy, gdy po stronie organizacji jest ktoś, kto zauważy awarię i potrafi z tego wsparcia skorzystać. Nawet przy dostępie do inżynierów producenta ktoś musi znać wpływ incydentu na biznes, mieć dostęp do środowiska i móc zatwierdzić zmianę. Jeśli te zadania spoczywają na jednej osobie, jej nieobecność pozostaje ograniczeniem całego procesu.

Dobierz wsparcie do godzin pracy usług

Zacznij od jednej usługi, której zatrzymanie byłoby dotkliwe dla firmy. Może to być system magazynowy, aplikacja finansowa albo zdalny dostęp dla pracowników. Zapisz, w jakich godzinach jest potrzebna i kto potrafi stwierdzić, że działa prawidłowo. „Serwer odpowiada” jest zbyt ogólnym kryterium, jeśli użytkownik nadal nie może wykonać swojej pracy.

Zanim ustalisz harmonogram dyżurów, sprawdź, czy alarm w ogóle trafi do właściwej osoby. Proxmox VE ma wbudowany system powiadomień (Centrum danych → Powiadomienia), w którym reguły (matchers) kierują zdarzenia z węzła do konkretnych kanałów — e-mail, Gotify albo webhook. Warto skonfigurować osobną regułę dla zdarzeń krytycznych, tak żeby trafiały poza standardową skrzynkę administratora, np. do kanału zespołowego albo systemu powiadomień obsługującego dyżur, a nie kończyły się na koncie osoby, która akurat jest nieobecna.

Następnie zestaw trzy informacje: godziny obsługi w umowie, dostępność własnego administratora oraz godziny pracy dostawcy aplikacji. Zrób to dla zwykłego dnia, weekendu i nieobecności głównej osoby. W każdym przypadku wskaż zastępcę i działający kanał kontaktu — jeśli dla któregoś scenariusza nie potrafisz go wskazać, to jest konkretna luka do zamknięcia przed zakupem szerszego wsparcia.

Proxmox VE ma cztery poziomy subskrypcji: Community, Basic, Standard i Premium. Community zapewnia dostęp do Enterprise Repository bez wsparcia zgłoszeniowego producenta. Wyższe poziomy różnią się zakresem obsługi, a nie odblokowaniem funkcji hiperwizora. Rozliczenie dotyczy zajętych fizycznych gniazd CPU, bez opłat per rdzeń, VM czy użytkownik.

Po zapisaniu potrzeb można porównać subskrypcje Proxmox. Premium nie naprawi procedury, w której alarm o 2:00 w nocy trafia wyłącznie na skrzynkę administratora śpiącego z wyciszonym telefonem. Najpierw trzeba wiedzieć, kto odbiera incydent i kto może podjąć działanie. Dopiero później ma sens wybór wariantu wsparcia producenta.

Co oznacza czas pierwszej odpowiedzi?

To czas do pierwszej reakcji wsparcia na zgłoszenie spełniające warunki umowy. Nie jest terminem przywrócenia aplikacji. Diagnoza może wymagać dodatkowych danych, a wykonanie zaleceń — zgody na zmianę lub pracy zespołu odpowiedzialnego za inną część infrastruktury.

Deklarowany czas odpowiedzi dotyczy zgłoszeń oznaczonych jako krytyczne lub związanych z przestojem produkcji — nie każdego ticketu w kolejce. Zgłoszenie sklasyfikowane niżej może czekać dłużej, nawet w najwyższym planie. Priorytet ustalasz przy zakładaniu sprawy w Customer Portalu, dlatego warto wcześniej wiedzieć, które objawy w Twoim środowisku kwalifikują się jako krytyczne, a które nie.

Własny czas obsługi warto rozłożyć na etapy. Zapisz moment alarmu, przejęcia sprawy przez administratora, wysłania kompletnego zgłoszenia i odzyskania usługi. Różnice między tymi znacznikami, liczone w minutach, pokażą, gdzie powstało opóźnienie. Warunki producenta oceniaj osobno według definicji w umowie; wewnętrzny pomiar nie zastępuje pomiaru SLA.

Jeżeli alarm czekał na odbiór, szersza subskrypcja nie usuwa przyczyny tego opóźnienia. Potrzebny jest odbiorca powiadomienia i zastępstwo. Jeśli zabrakło danych, popraw pakiet diagnostyczny. Jeżeli natomiast wąskim gardłem okazuje się etap kontaktu ze wsparciem producenta, wtedy warto ponownie sprawdzić, czy obecny poziom subskrypcji odpowiada krytyczności usług.

Co przygotować przed zgłoszeniem?

Przygotuj krótką kartę środowiska dostępną dla osób obsługujących incydent. Powinna łączyć objaw z usługą biznesową: czego użytkownik nie może zrobić, od kiedy i czy problem obejmuje całą firmę. Dalej zapisz dotknięte węzły i maszyny, wersje pakietów, ostatnią zmianę oraz dokładny komunikat błędu z czasem i strefą czasową.

Wersje pakietów odczytasz poleceniem pveversion -v na dotkniętym węźle — ono pokazuje dokładne numery wersji jądra i kluczowych komponentów PVE, nie tylko ogólną wersję systemu. Sam komunikat błędu i czas zdarzenia znajdziesz w historii zadań (zakładka Task History w GUI węzła) albo w dzienniku systemowym (journalctl). Porównaj identyfikator hosta w zgłoszeniu z tym w pobranym materiale — wartość pola jest użyteczna dla wsparcia dopiero wtedy, gdy da się wskazać, z którego dokładnie węzła i zadania pochodzi.

Osobno zapisz, co już wykonano i jaki był rezultat. „Zrestartowano usługę o 10:14, błąd wystąpił ponownie przy kolejnym uruchomieniu zadania” daje więcej niż „próbowaliśmy restartu”. Nie wykonuj dodatkowych zmian tylko po to, żeby uzupełnić opis. Przy awarii potrzebna jest czytelna historia działań.

Zgłoszenia producenta obsługuje Proxmox Customer Portal. Dane przekazuj kanałem właściwym dla umowy. Przed dołączeniem konfiguracji lub logów sprawdź obecność haseł, tokenów i danych klientów; usuń zbędne informacje, zachowując oryginał w kontrolowanym miejscu. Opis powinien wystarczyć do rozpoczęcia diagnozy bez udostępniania całej dokumentacji firmy.

Ćwiczenie eskalacji bez wyłączania produkcji

Nie trzeba wyłączać klastra, żeby sprawdzić procedurę. Wystarczy krótka symulacja przy biurku — bez zatrzymywania hosta i bez wysyłania pozornego zgłoszenia krytycznego do producenta.

Wybierz jedną usługę i załóż prosty scenariusz: jest sobota, główny administrator jest niedostępny, a użytkownicy tracą dostęp do aplikacji mimo działającego panelu wirtualizacji.

Kto dostaje alarm? Kto może zalogować się do środowiska? Kto może podjąć decyzję o zmianie? Czy ta osoba ma dostęp do Customer Portalu? Czy potrafi zebrać wynik pveversion -v, znaleźć właściwe zdarzenie w historii zadań lub logach i przygotować czytelne zgłoszenie?

Przy okazji sprawdź, czy reguła w Centrum danych → Powiadomienia rzeczywiście kieruje ten typ zdarzenia do zastępcy, a nie tylko na konto nieobecnego administratora. Zweryfikuj też dostęp do dokumentacji i konta zgłoszeniowego przez zwykłe, uprawnione logowanie. Nie wysyłaj testowego incydentu bez wcześniejszego uzgodnienia.

Warto zmierzyć czas od rozpoczęcia takiej próby do momentu, w którym kompletne zgłoszenie byłoby gotowe do wysłania. Wynik bywa ciekawszy niż sama tabela SLA producenta, bo pokazuje opóźnienia powstające wewnątrz organizacji.

Po ćwiczeniu zapisz braki i przypisz osoby odpowiedzialne za ich usunięcie. Jeżeli zabrakło danych, popraw kartę środowiska. Jeżeli problemem był dostęp albo niejasny podział ról, popraw procedurę. Po zmianach powtórz ten sam scenariusz. Czas takiej symulacji nie jest czasem odtworzenia produkcji — mierzy gotowość zespołu do rozpoczęcia eskalacji.

Wsparcie producenta to nie obsługa środowiska

To rozróżnienie warto ustalić jeszcze przed wyborem subskrypcji. Wsparcie producenta dotyczy problemów związanych z oprogramowaniem Proxmox i eskalacji prowadzonej w ramach warunków subskrypcji. Nie oznacza przejęcia bieżącej administracji środowiskiem ani reagowania za klienta na każdy alarm z jego infrastruktury.

Zespół organizacji lub uzgodniony dostawca usług nadal odpowiada za czynności przypisane mu w umowie: odebranie alarmu, dostęp do środowiska, zebranie danych, wykonanie zmian, kontakt z użytkownikami czy współpracę z dostawcą aplikacji.

I wtedy może się okazać, że problemem wcale nie jest poziom subskrypcji. Brakuje zastępstwa administratora. Albo dokumentacji. Albo kogoś, kto może wykonać zmianę o 3:00 w nocy. To trzy zupełnie różne problemy i każdy wymaga innego rozwiązania.

Przy kolejnej rozmowie o utrzymaniu infrastruktury połóż na stole wynik ćwiczenia. Łatwiej wtedy ustalić, czy potrzebujesz szerszej obsługi producenta, zastępstwa dla administratora, uporządkowania dokumentacji czy osobnej umowy na działania poza godzinami pracy.

Dokumentacja i źródła

Proxmox — zapowiedź rozszerzenia wsparcia 24/7

Proxmox — poziomy i warunki subskrypcji Proxmox VE

Proxmox — wsparcie i Customer Portal