Початок роботи 5 хв читання 10 листопада 2026 р. Автор Fred

Керування патчами для MSP: одна політика для всіх клієнтів

Керування патчами для 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, яким можна поділитися з клієнтом, і сповіщення, коли оцінка падає нижче встановленого вами порогу.

Сторінка функції керування патчами дає загальний огляд, а документація з керування патчами крок за кроком показує, як створити політику. Хочете запустити це на власних серверах? Посібник зі встановлення описує самостійний хостинг.

Використовуєте також 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.