Първи стъпки 6 мин четене 10 ноември 2026 г. От Fred

Управление на корекции (patch management) за MSP: една политика за всички клиенти

Управление на корекции (patch management) за MSP: една политика за всички клиенти, със забавяния по тип устройство, пръстени за актуализации, приложения на трети страни, прозорци за сървъри и месечен отчет.

Вие управлявате MSP. При трима клиенти инсталирането на корекции е навик във вторник вечер: знаете на кой сървър работи счетоводната програма, чий е лаптопът на управителя и на кого да се обадите, когато актуализация блокира принтера. При десетия клиент този навик спира да работи. Всеки клиент има своите изключения, всеки техник одобрява актуализациите малко по-различно, а когато клиент попита „актуални ли сме?“, отговорът ви отнема цял следобед.

Тази статия е за собственици и технически ръководители на MSP, които искат една политика за корекции за всички клиенти: какво да одобряват автоматично, как да внедряват на пръстени, как да подхождат към приложенията на трети страни и сървърите и как да покажат на клиента докъде е стигнал. Накрая ще видите как го правим в Xcellerate RMM.

Накратко

Напишете политиката веднъж, по тип устройство: работните станции, сървърите и критичните сървъри получават собствено забавяне за одобрение, прозорец за инсталация и правило за рестарт.

Внедрявайте на пръстени: първо собствените тестови устройства, после вътрешните машини, след това пилотни клиенти, накрая всички.

Обновявайте приложенията на трети страни със същия процес като операционната система и никога не рестартирайте автоматично сървър извън прозорец за поддръжка.

Давайте на всеки клиент месечен отчет: състояние на корекциите по устройство, какво е инсталирано, какво не е успяло и какво сте отложили нарочно.

Защо корекциите се объркват при десетия клиент

Корекциите рядко се провалят, защото техникът не знае как. Провалят се, защото правилата са в главите на хората. Един техник одобрява всичко в сряда, друг чака седмица, трети пропуска сървъра на клиента, който миналата година се оплака от рестарт. Нищо не е записано, значи нищо не е последователно и никой не може да покаже какво всъщност се е случило.

Политиката за корекции решава това. Тя е кратък документ, а в идеалния случай и настройка във вашия RMM, който отговаря на четири въпроса за всяко устройство: кои актуализации се одобряват автоматично, след колко дни, в какъв времеви прозорец и може ли устройството да се рестартира само. Щом отговорите са записани, корекциите стават процес, който можете да проверите, а не навик, на който се надявате.

Политиката в една таблица

Започнете от типовете устройства, не от клиентите. Повечето MSP имат нужда от три. Числата по-долу са пример, който да адаптирате, а не правило:

Тип устройство	Критични актуализации	Други актуализации	Прозорец за инсталация	Рестарт
Работни станции	Автоматично след 3 дни	Автоматично след 7 дни	Обедна почивка или края на работния ден	Автоматичен, с 15-минутно предупреждение към потребителя
Сървъри	Автоматично след 3–5 дни	Ръчно одобрение	Прозорец за поддръжка, напр. неделя 02:00–05:00	Само в прозореца
Критични сървъри (бизнес приложения, домейн контролери, хостове)	Ръчно след тест	Ръчно одобрение	Прозорец, договорен с всеки клиент	Ръчен, с наличен човек

Защо изобщо забавяне? Няколко дни дават време на общността да съобщи за дефектна актуализация, преди тя да стигне до клиентите ви. Защо различни прозорци? Работните станции е най-добре да се обновяват, когато хората са в почивка, а сървърите, когато никой не работи.

След това добавете изключения по клиент, а не по устройство: клиент с нощни смени получава друг прозорец за работните станции; клиент с чувствително бизнес приложение получава сървъра си в критичния клас. Записвайте всяко изключение заедно с причината.

Пръстени: първо собствените устройства

Пръстенът за актуализации е група устройства, която получава актуализации на един и същ етап. Простата схема за MSP има четири:

Тестов пръстен: няколко ваши устройства, които получават всяка актуализация първи.
Вътрешен пръстен: останалата част от собствения ви офис.
Пилотен пръстен: един или двама клиенти, които са търпеливи, добре документирани и знаят, че са пилот.
Общ пръстен: всички останали.

Всеки пръстен изчаква предишния. Ако актуализация счупи нещо в тестовия или вътрешния пръстен, я блокирате, преди да стигне до клиент. Пръстените ви дават и ясен отговор, когато клиент пита защо не е получил актуализация в първия ден: това е умишлено.

Приложенията на трети страни са истинската пролука

Актуализациите на операционната система са лесната част: Windows, macOS и Linux имат собствен механизъм, а повечето RMM ги поддържат. Пролуката е във всичко останало: браузъри, PDF четци, Java, Zoom и другите приложения, които потребителите инсталират и никой не обновява.

Третирайте ги като операционната система: същите правила за одобрение, същите пръстени, същите прозорци. Водете за всеки клиент списък на поддържаните приложения на трети страни и решете какво става с останалите (премахване или оставяне на клиента с писмена бележка).

Сървъри: никога рестарт без прозорец

Най-бързият начин да загубите доверието на клиент е непланиран рестарт посред бял ден на сървъра, на който работи бизнес приложението му. Три правила:

Никакви автоматични рестарти на сървъри извън договорен прозорец за поддръжка.
Договорете прозореца писмено с клиента, в неговата часова зона.
За критичните сървъри осигурете човек по време на прозореца, който да провери услугите след това.

Доказателството: отчетът, който клиентът вижда

Политиката печели доверие едва когато клиентът види, че работи. Веднъж месечно изпращайте на всеки клиент кратък отчет за корекциите:

Състояние на корекциите по устройство: делът на приложимите актуализации, които са инсталирани.
Какво е инсталирано през последния месец и какво не е успяло.
Какво сте отложили или блокирали нарочно, и защо.
Устройства, които изискват внимание: офлайн от седмици, чакащи рестарт или без поддръжка.

Обсъждайте го на месечния или тримесечния преглед. Така корекциите престават да са невидим разход и стават услуга, която клиентът вижда.

Как го правим в Xcellerate RMM

Xcellerate RMM е нашият RMM: source-available под лиценза FSL, на собствените ви сървъри или в нашия облак в ЕС. Управлението на корекции е част от source-available ядрото. Ето как политиката по-горе се пренася в него:

Операционни системи и приложения на трети страни: Windows Update, apt/yum в Linux и softwareupdate в macOS, плюс каталог с популярни приложения на трети страни, които следват същия процес на одобрение и планиране.
Политики за корекции по група: автоматично одобрение, периоди на отлагане, прозорци за поддръжка и поведение при рестарт, настроени веднъж и свързани с група. Именувани стратегии за корекции със собствени графици и правила се прикачват към всеки агент или група.
Одобряване, отлагане или блокиране на партиди: прегледайте чакащите корекции в целия парк и сменете статуса им с една операция.
Пръстени за актуализации: изберете кой пръстен следва всеки tenant, за да стоят ранните версии далеч от клиентите в продукция.
Детайли и история по устройство: какво е инсталирано, чакащо или неуспешно на всяко устройство и дневник на всяка инсталация с резултат и час.
Оценка на съответствие и отчети: процентът инсталирани приложими корекции по устройство или група, експортируем compliance report за споделяне с клиента и известие, когато оценката падне под зададен от вас праг.

Страницата за управление на корекции дава общия поглед, а документацията за patch management (на английски) показва стъпка по стъпка как се създава политика. Искате да го пуснете на собствени сървъри? Ръководството за инсталация (на английски) описва инсталацията със самостоятелен хостинг.

Използвате ли и PSA до своя RMM? Xcellerate RMM и Xcellerate OPS са два отделни продукта и готова връзка между тях все още няма. Всичко в едно RMM + PSA или best-of-breed ще ви помогне да решите от какво има нужда вашият стек.

Изпробвайте политиката на собствения си парк: безплатно завинаги на собствени сървъри или 14-дневен пробен период в Cloud. Започнете безплатно

Често задавани въпроси

Колко често един MSP трябва да инсталира корекции на работни станции и сървъри?

Повечето MSP сканират ежедневно и инсталират по фиксиран ритъм: работните станции до около седмица след издаването, критичните актуализации след кратко забавяне от няколко дни, а сървърите в договорен седмичен или месечен прозорец за поддръжка. Съобразете забавянията с риска при всеки клиент и ги запишете в политиката си.

Трябва ли корекциите да се одобряват автоматично?

При работните станции обикновено да, след няколко дни забавяне, за да излязат първо наяве проблемите, за които съобщават други. При сървърите одобрявайте автоматично само критичните актуализации и само в прозорец за поддръжка. Критичните сървъри оставете на ръчно одобрение след тест. Блокирайте проблемните актуализации и запишете причината.

Какво са пръстените за актуализации?

Групи устройства, които получават актуализации на етапи: първо вашите тестови устройства, после вътрешните ви машини, след това няколко пилотни клиенти и накрая всички останали. Всеки пръстен изчаква предишния, така че дефектна актуализация се спира, преди да стигне до повечето ви клиенти.

Как да покажа на клиент състоянието на корекциите му?

Изпращайте на всеки клиент месечен отчет с дела на инсталираните актуализации по устройство, какво е инсталирано, какво не е успяло и какво сте отложили нарочно. Обсъждайте го на редовната си среща. В Xcellerate RMM можете да експортирате за целта compliance report и да го споделите с клиента.

#Xcellerate RMM #Автоматизация #Самостоятелен хостинг

Източници: Xcellerate RMM patch management feature page (strategies, batch approve/defer/block, per-device drill-down, update rings per tenant, included in the source-available core, free self-hosted or 14-day Cloud trial): https://rmmlabs.io/en/products/rmm/features/patch-management (last updated 11 October 2026, checked 10 November 2026). Xcellerate RMM documentation, Patch management (Windows Update, apt/yum, softwareupdate; third-party patch catalogue; daily scan; group patch policies with auto-approval, deferral, maintenance windows, reboot behaviour; example policy 3/7 days, Sundays 02:00-05:00, 15-minute reboot warning; history; compliance score and exportable compliance report; alert via Monitoring & alerting): https://docs.rmmlabs.io/en/docs/xcellerate-rmm/core-features/patch-management (checked 10 November 2026). Licence (FSL, source-available) and Cloud hosting in the EU: https://rmmlabs.io/en/pricing. OPS and RMM are separate products without a ready-made connection: https://rmmlabs.io/en/solutions/msps. Policy table values are an example, not a benchmark.