Pierwsze kroki6 lis 2026
Prowadzisz MSP. Przy trzech klientach instalowanie poprawek to wtorkowy wieczorny nawyk: wiesz, na którym serwerze działa program księgowy, czyj jest laptop prezesa i do kogo zadzwonić, gdy aktualizacja zablokuje drukarkę. Przy dziesiątym kliencie ten nawyk przestaje się skalować. Każdy klient ma swoje wyjątki, każdy technik zatwierdza aktualizacje trochę inaczej, a gdy klient pyta „czy jesteśmy aktualni?”, odpowiedź zajmuje całe popołudnie.
Ten artykuł jest dla właścicieli i liderów technicznych firm MSP, którzy chcą jednej polityki poprawek dla wszystkich klientów: co zatwierdzać automatycznie, jak wdrażać w pierścieniach, jak traktować aplikacje firm trzecich i serwery oraz jak pokazać klientowi, na jakim etapie jest. Na końcu pokazujemy, jak robimy to w Xcellerate RMM.
W skrócie
- Napisz politykę raz, dla każdego typu urządzeń: stacje robocze, serwery i serwery krytyczne mają własne opóźnienie zatwierdzania, okno instalacji i regułę restartu.
- Wdrażaj w pierścieniach: najpierw własne urządzenia testowe, potem wewnętrzne komputery, następnie klienci pilotażowi, na końcu wszyscy.
- Aktualizuj aplikacje firm trzecich tym samym procesem co system operacyjny i nigdy nie restartuj automatycznie serwera poza oknem serwisowym.
- Dawaj każdemu klientowi miesięczny raport: stan poprawek na urządzenie, co zainstalowano, co się nie powiodło i co celowo odłożono.
Dlaczego poprawki wymykają się spod kontroli przy dziesiątym kliencie
Poprawki rzadko zawodzą dlatego, że technik nie wie, jak je zainstalować. Zawodzą, bo reguły są w głowach ludzi. Jeden technik zatwierdza wszystko w środę, drugi czeka tydzień, trzeci pomija serwer klienta, który w zeszłym roku skarżył się na restart. Nic nie jest zapisane, więc nic nie jest spójne i nikt nie potrafi pokazać, co naprawdę się wydarzyło.
Polityka poprawek to rozwiązuje. To krótki dokument, a najlepiej ustawienie w Twoim RMM, który dla każdego urządzenia odpowiada na cztery pytania: które aktualizacje są zatwierdzane automatycznie, po ilu dniach, w jakim przedziale czasu i czy urządzenie może samo się zrestartować. Gdy odpowiedzi są zapisane, instalowanie poprawek staje się procesem, który można sprawdzić, a nie nawykiem, na który się liczy.
Polityka w jednej tabeli
Zacznij od typów urządzeń, nie od klientów. Większość MSP potrzebuje trzech. Poniższe liczby to przykład do dostosowania, nie reguła:
| Typ urządzenia | Aktualizacje krytyczne | Pozostałe aktualizacje | Okno instalacji | Restart |
|---|---|---|---|---|
| Stacje robocze | Automatycznie po 3 dniach | Automatycznie po 7 dniach | Przerwa obiadowa lub koniec dnia pracy | Automatyczny, z 15-minutowym ostrzeżeniem dla użytkownika |
| Serwery | Automatycznie po 3–5 dniach | Ręczne zatwierdzenie | Okno serwisowe, np. niedziela 02:00–05:00 | Tylko w oknie |
| Serwery krytyczne (aplikacje biznesowe, kontrolery domeny, hosty) | Ręcznie po teście | Ręczne zatwierdzenie | Okno uzgodnione z klientem | Ręczny, z kimś pod telefonem |
Po co w ogóle opóźnienie? Kilka dni daje społeczności czas na zgłoszenie wadliwej aktualizacji, zanim trafi do Twoich klientów. Po co różne okna? Stacje robocze najlepiej aktualizować, gdy ludzie mają przerwę, serwery, gdy nikt nie pracuje.
Następnie dodaj wyjątki dla klientów, a nie dla urządzeń: klient pracujący na nocne zmiany dostaje inne okno dla stacji roboczych; klient z wrażliwą aplikacją biznesową ma serwer w klasie krytycznej. Zapisuj każdy wyjątek wraz z powodem.
Pierścienie: najpierw własne urządzenia
Pierścień aktualizacji to grupa urządzeń, która otrzymuje aktualizacje na tym samym etapie. Prosta konfiguracja dla MSP ma cztery:
- Pierścień testowy: kilka własnych urządzeń, które dostają każdą aktualizację jako pierwsze.
- Pierścień wewnętrzny: reszta Twojego biura.
- Pierścień pilotażowy: jeden lub dwóch klientów, którzy są wyrozumiali, dobrze udokumentowani i wiedzą, że są pilotem.
- Pierścień ogólny: wszyscy pozostali.
Każdy pierścień czeka na poprzedni. Jeśli aktualizacja coś zepsuje w pierścieniu testowym lub wewnętrznym, blokujesz ją, zanim trafi do klienta. Pierścienie dają też jasną odpowiedź, gdy klient pyta, dlaczego nie dostał aktualizacji pierwszego dnia: to celowe.
Aplikacje firm trzecich to prawdziwa luka
Aktualizacje systemu operacyjnego to łatwa część: Windows, macOS i Linux mają własne mechanizmy aktualizacji, a większość RMM je obsługuje. Luka to wszystko inne: przeglądarki, czytniki PDF, Java, Zoom i inne aplikacje, które instalują użytkownicy, a których nikt nie aktualizuje.
Traktuj je jak system operacyjny: te same reguły zatwierdzania, te same pierścienie, te same okna. Prowadź dla każdego klienta listę obsługiwanych aplikacji firm trzecich i zdecyduj, co z resztą (usunąć albo zostawić klientowi z pisemną notatką).
Serwery: nigdy restartu bez okna
Najszybszy sposób na utratę zaufania klienta to nieplanowany restart, w środku dnia, serwera, na którym działa jego aplikacja biznesowa. Trzy zasady:
- Żadnych automatycznych restartów serwerów poza uzgodnionym oknem serwisowym.
- Uzgodnij okno z klientem na piśmie, w strefie czasowej klienta.
- Przy serwerach krytycznych zapewnij, że w trakcie okna ktoś będzie dostępny, by potem sprawdzić usługi.
Dowód: raport, który widzi klient
Polityka buduje zaufanie dopiero wtedy, gdy klient widzi, że działa. Raz w miesiącu wysyłaj każdemu klientowi krótki raport poprawek:
- Stan poprawek na urządzenie: odsetek zainstalowanych mających zastosowanie aktualizacji.
- Co zainstalowano w ostatnim miesiącu i co się nie powiodło.
- Co celowo odłożono lub zablokowano, i dlaczego.
- Urządzenia wymagające uwagi: offline od tygodni, czekające na restart lub bez wsparcia.
Omów go na comiesięcznym lub kwartalnym przeglądzie. Dzięki temu poprawki przestają być niewidocznym kosztem i stają się usługą, którą klient widzi.
Jak robimy to w Xcellerate RMM
Xcellerate RMM to nasz RMM: source-available na licencji FSL, na Twoich własnych serwerach lub w naszej chmurze w UE. Zarządzanie poprawkami jest częścią rdzenia source-available. Tak przekłada się na niego powyższa polityka:
- Systemy operacyjne i aplikacje firm trzecich: Windows Update, apt/yum w Linuksie i softwareupdate w macOS oraz katalog popularnych aplikacji firm trzecich, które podlegają temu samemu procesowi zatwierdzania i planowania.
- Polityki poprawek dla grup: automatyczne zatwierdzanie, okresy odroczenia, okna serwisowe i zachowanie przy restarcie, ustawione raz i przypisane do grupy. Nazwane strategie poprawek z własnymi harmonogramami i regułami przypiszesz do dowolnego agenta lub grupy.
- Zatwierdzanie, odraczanie lub blokowanie zbiorczo: przejrzyj oczekujące poprawki w całej flocie i zmień ich status jedną operacją.
- Pierścienie aktualizacji: wybierz, którym pierścieniem podąża każdy tenant, aby wczesne wersje nie trafiały do klientów produkcyjnych.
- Szczegóły i historia dla urządzenia: co jest zainstalowane, oczekujące lub nieudane na każdym urządzeniu oraz dziennik każdej instalacji z wynikiem i czasem.
- Wskaźnik zgodności i raporty: odsetek zainstalowanych poprawek mających zastosowanie dla urządzenia lub grupy, eksportowany compliance report do udostępnienia klientowi i alert, gdy wskaźnik spadnie poniżej ustalonego przez Ciebie progu.
Strona funkcji zarządzania poprawkami daje ogólny obraz, a dokumentacja zarządzania poprawkami krok po kroku pokazuje, jak utworzyć politykę. Chcesz uruchomić to na własnych serwerach? Przewodnik instalacji opisuje instalację self-hosted.
Używasz też PSA obok RMM? Xcellerate RMM i Xcellerate OPS to dwa osobne produkty, a gotowego połączenia między nimi jeszcze nie ma. RMM + PSA wszystko w jednym czy best-of-breed pomoże Ci zdecydować, czego potrzebuje Twój stack.
Wypróbuj politykę na własnej flocie: za darmo na zawsze na własnych serwerach albo 14-dniowy okres próbny Cloud. Zacznij za darmo
