Окно обновлений (patch window)

Почему здесь предсказуемость важнее скорости

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

Баланс между окнами обновлений и критическими исправлениями

Запланированное еженедельное или ежемесячное окно обновлений подходит для рутинных обновлений, но критическое исправление безопасности, особенно уже активно эксплуатируемое, обычно оправдывает нарушение обычного графика, а не ожидание следующего запланированного окна.

Как планировать окна обновлений с учётом реальных требований к доступности, см. здесь: руководство по управлению патчами сервера.

Проведение окна на VPS: до, во время и после

Окно лучше всего работает как короткий повторяемый чек-лист. На Debian или Ubuntu он может выглядеть так:

sudo apt update
sudo apt-get -s upgrade      # simulate, changes nothing
sudo apt upgrade
sudo needrestart -r l        # services still on old libraries
systemctl --failed           # units that did not come back

Перед началом убедитесь, что есть свежая резервная копия или снимок (что хранить, описано в руководстве по резервным копиям 3-2-1), и прочитайте результат имитации, чтобы сюрприз вроде пакета базы данных или ядра не застал вас посреди окна. Страница руководства apt-get подтверждает, что -s выполняет имитацию, не изменяя систему. После обновления перезапустите то, что требует перезапуска, перезагрузите сервер, если существует /var/run/reboot-required, один раз откройте сайт или API как быстрый тест и некоторое время наблюдайте за журналами, пользуясь руководством по мониторингу.

Если включён unattended-upgrades, он работает по своим таймерам. Команда systemctl list-timers 'apt-daily*' покажет, когда именно, а Unattended-Upgrade::Automatic-Reboot-Time стоит выставить на тот же тихий час, что и окно, чтобы перезагрузка не случалась в случайный момент.

Когда нарушать расписание и как нагонять пропущенное

NIST SP 800-40 Rev. 4 считает экстренную установку патчей тем же процессом, что и плановую, только по сильно ускоренному графику. Даже в экстренной ситуации документ советует сначала проверить патч на небольшом числе пробных систем (canary), от нескольких минут до нескольких часов, а широкое развёртывание проводить в течение часов или дней в зависимости от срочности. Для небольшой компании это может означать просто сначала обновить наименее важный сервер.

Хорошие поводы для внеплановой установки: критическая рекомендация вендора для ПО, которое вы используете, или новая запись в каталоге CISA KEV, подходящая вашему стеку. Если исправления ещё нет, тот же документ описывает экстренную защиту как временную меру; как это выглядит, показано в статье zero-day эксплойт.

Обратная проблема менее заметна: пропущенные окна. NIST рекомендует допускать гибкость по срокам, но принудительно устанавливать обновления по окончании льготного периода. Записывайте каждое отложенное окно с датой и считайте второй подряд пропуск поводом действовать, потому что растущий хвост усложняет следующий экстренный случай.

Связанные термины: Управление обновлениями, unattended-upgrades, Live patching ядра, N-day эксплойт.