Регламент обновлений: что ставить сразу, что через неделю, что не трогать

MAATRIX

«Обновления надо ставить» — с этим никто не спорит. Спор начинается на следующем шаге: когда именно, в каком порядке и кто отвечает за то, что что-то пойдёт не так. Без явного регламента команда либо откладывает всё подряд до ближайшего инцидента, либо накатывает всё подряд в день релиза и получает инцидент своими руками. Разберём, как разделить обновления на категории по срочности, сколько реально ждать перед установкой каждой и как оформить это в рабочий регламент, а не в устную договорённость, которую помнит только один человек в команде.

Почему один срок для всех обновлений — это ошибка

Самая частая причина хаоса вокруг обновлений — попытка применить к ним одно правило. Либо «ставим всё сразу, как вышло» — тогда сервер регулярно превращается в тестовый стенд для чужих регрессий. Либо «ставим раз в квартал по расписанию» — тогда критичная уязвимость безопасности неделями сидит на проде, потому что «ещё не подошёл срок».

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

• Патч безопасности закрывает конкретную уязвимость — здесь риск от промедления растёт со временем: чем дольше дыра открыта, тем выше шанс, что её просканируют и используют.
• Обычное обновление (минорная версия, багфикс, накопленный патч) — риск здесь в основном не в том, что вы промедлите, а в том, что вы поставите версию раньше, чем сообщество найдёт в ней регрессии.
• Мажорное обновление меняет поведение, API, конфигурацию по умолчанию — риск в первую очередь несовместимость, а не уязвимость, и его снимает не ожидание, а тестирование.

Применяя правило патчей безопасности к обновлению версии, вы держите открытую уязвимость там, где нужна скорость. Применяя правило мажорных релизов к патчу, вы тестируете в проде то, что должно было пройти через стейджинг. Регламент нужен, чтобы развести эти три сценария по разным дорожкам со своими сроками. Дальше — по каждой категории с конкретными числами и командами.

Критичные обновления безопасности: быстро, но не мгновенно

Патч, закрывающий активно эксплуатируемую уязвимость (RCE в демоне, смотрящем в сеть, критичный CVE в OpenSSL, sudo, systemd, ядре), — это единственная категория, где промедление само по себе увеличивает риск. Здесь логика «подождём подольше, пусть сообщество проверит» работает против вас: атакующие сканируют интернет на уязвимые версии быстрее, чем вы читаете changelog.

Но и установка «в ту же секунду» не всегда верна: у критичных патчей тоже бывают собственные баги — спешка вендора иногда сама порождает регрессию. Разумный компромисс — короткое окно ожидания, а не полный отказ от него.

Практический ориентир: 4–24 часа с момента выхода патча, в зависимости от серьёзности:

• Если уязвимость уже эксплуатируется в диком виде (об этом обычно прямо пишут в бюллетене вендора или CERT) — ставьте в течение нескольких часов, окно проверки минимальное.
• Если уязвимость критична по CVSS, но эксплойтов в публичном доступе пока не видно — можно подождать до суток, чтобы отследить первые сообщения в трекерах пакета и профильных каналах (списки рассылки дистрибутива, GitHub issues проекта).
• Если патч закрывает вектор, требующий локального доступа или специфичных условий — это уже не «критичный», а «обычный» патч по факту, даже если формально помечен security-обновлением.

Технически на Debian/Ubuntu критичные патчи безопасности разумно ставить автоматикой отдельно от остальных обновлений — именно security-репозиторий, без общего апдейта пакетов:

# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Автоматический ребут ядра лучше не включать бездумно — если сервис держит долгие соединения, внезапная перезагрузка среди дня создаёт свой инцидент. Разумнее ставить пакет автоматически, а перезагрузку — по отдельному регламенту в тихое окно (ночью, с уведомлением дежурного). Подробно про грабли этой настройки — в статье про частые ошибки автообновлений безопасности.

Для Docker-образов эквивалент — не «watchtower обновляет всё», а отдельный контур для security-тегов: pinned digest для стабильных образов плюс быстрая проверка CVE через trivy или docker scout на новый слой перед раскаткой.

Обычные обновления: дайте сообществу неделю-две на отлов багов

Минорные версии, накопленные багфиксы, обновления пакетов без прямой пометки security — это основная масса того, что прилетает через apt update && apt list --upgradable или через Dependabot/Renovate в приложении. Здесь логика противоположная патчам безопасности: спешка не снижает риск, а увеличивает его, потому что вы тестируете релиз одновременно с остальным миром, только без страховки в виде их отчётов о багах.

Практический ориентир: 7–14 дней с даты релиза перед установкой на прод — этого времени обычно достаточно, чтобы:

• в issue-трекере проекта появились первые «после обновления сломалось X» с конкретикой;
• майнтейнеры дистрибутива откатили или зафиксили регрессию, если она была массовой;
• в профильных каналах прошла первая волна обсуждения, если релиз оказался проблемным.

На практике это не значит «ждать и следить руками». Это значит развести каналы обновлений по времени:

# staging получает всё сразу
0 3 * * * root apt update && apt -y upgrade >> /var/log/apt-staging.log 2>&1

# прод получает то же самое, но с задержкой 10 дней —
# практический способ: staging тестирует релиз N, 
# прод в это время накатывает релиз N-1 (предыдущий цикл)

Простой и рабочий вариант без сложной инфраструктуры — держать staging-копию сайта или сервиса и обновлять её на неделю раньше прода, чтобы регрессия проявилась там, а не у пользователей. Как поднять такую копию — в статье про настройку staging-копии сайта.

Для пакетных менеджеров языков (npm, pip, composer) тот же принцип реализуется через lock-файлы и пиннинг: не ^1.2.0 в манифесте с автоматическим подтягиванием последнего патча при каждой сборке, а фиксированная версия в lock-файле, которую вы поднимаете руками раз в 1–2 недели после проверки changelog, а не автоматически при каждом npm install.

Отдельно про псевдо-срочные обновления — те, что помечены как security, но по сути закрывают низкоприоритетный вектор (локальный DoS, требующий особых условий). Их разумно считать обычными, а не критичными: маркировка вендора не всегда отражает реальную срочность для вашей конфигурации.

Мажорные обновления: отдельный тестовый прогон обязателен

Мажорная версия — переход между релизами дистрибутива (Ubuntu 22.04 → 24.04), major-версия рантайма (PHP 7 → 8, Node 18 → 20), мажорный апгрейд СУБД (PostgreSQL 14 → 16), смена major-ветки Docker Engine или Kubernetes. Здесь риск принципиально другой: дело не в скрытых багах, а в задокументированных breaking changes, которые сломают ваш код предсказуемо, если вы их не учли.

Правило для этой категории простое: никогда не ставить мажорное обновление в день релиза на прод, и никогда не ставить его без отдельного тестового прогона — вне зависимости от того, сколько раз до этого мажорные обновления проходили гладко.

Практический процесс:

1. Читаете changelog и migration guide целиком, а не по диагонали — именно там перечислены breaking changes, которые не покажет ни один автотест, если вы не знаете, что искать.
2. Разворачиваете копию окружения (staging, отдельный VPS, контейнер с тем же стеком) и накатываете мажорное обновление там первым.
3. Прогоняете реальные сценарии, а не только «сервис запустился» — CRUD-операции, миграции схемы, интеграции с внешними API, специфичные для вашего проекта edge-кейсы.
4. Даёте выдержку — даже после успешного теста на staging разумно подождать несколько недель после релиза мажорной версии, прежде чем катить в прод: у крупных проектов вроде PostgreSQL или PHP серьёзные баги мажорных релизов чаще всего всплывают и фиксятся в первых point-релизах (14.0 → 14.1 → 14.2).
5. Готовите путь назад заранее — снимок диска или бэкап базы перед миграцией, зафиксированная версия старого пакета в кеше apt или архиве образов, чтобы откат был операцией на минуты, а не на часы. Как выглядит такой откат, если что-то пошло не так уже после наката, разобрано в статье про откат прода после неудачного обновления.

Для мажорного апгрейда СУБД отдельно стоит проверить план на несовместимые изменения типов данных и синтаксиса запросов:

# PostgreSQL: сухой прогон перед реальным апгрейдом
pg_upgrade --check \
  --old-datadir=/var/lib/postgresql/14/main \
  --new-datadir=/var/lib/postgresql/16/main \
  --old-bindir=/usr/lib/postgresql/14/bin \
  --new-bindir=/usr/lib/postgresql/16/bin

Флаг --check не трогает данные, только проверяет совместимость. Для мажорных апгрейдов ОС (do-release-upgrade на Ubuntu) — тот же порядок: сначала копия, потом прод, и никогда в пятницу вечером.

Матрица принятия решений

Свести всё в одну таблицу, которую можно приклеить в runbook команды:

Таблица — стартовая точка, а не догма: сроки стоит подстроить под профиль риска проекта. У сервиса с высокой посещаемостью и жёстким SLA сроки ожидания для мажорных обновлений разумно увеличить; у внутреннего инструмента с одним пользователем — сократить, если цена простоя низкая.

Как реализовать регламент технически, а не только на бумаге

Регламент, который живёт только в голове DevOps-инженера, перестаёт работать в его отпуск. Чтобы он пережил конкретного человека, нужны три вещи: разделение каналов обновлений, видимость того, что происходит, и явная точка принятия решения для мажорных апгрейдов.

Разделение каналов. На уровне apt это разные источники в конфиге unattended-upgrades (показано выше). На уровне Docker — отдельные политики для базовых образов (автоматически по digest с проверкой CVE) и версий приложения (осознанно, по релизам). На уровне CI/CD — отдельные пайплайны для патчей зависимостей (авто-мердж только для patch-версий) и для минорных/мажорных апдейтов (PR с ручным ревью).

# renovate.json — пример разделения по типу апдейта
{
  "packageRules": [
    {
      "matchUpdateTypes": ["patch"],
      "automerge": true
    },
    {
      "matchUpdateTypes": ["minor"],
      "automerge": false,
      "minimumReleaseAge": "10 days"
    },
    {
      "matchUpdateTypes": ["major"],
      "automerge": false,
      "minimumReleaseAge": "28 days"
    }
  ]
}

Параметр minimumReleaseAge — механическая реализация принципа «дать сообществу время найти баги»: Renovate не предложит обновление, пока не пройдёт указанный срок с релиза.

Видимость. Ведите журнал обновлений — не в голове, а в файле или тикет-системе: что, когда, кем поставлено, откатывалось ли. Без него расследование инцидента после обновления превращается в археологию: непонятно, что вообще поменялось за последние две недели. Экономику такого отставания разбирает статья про цену отложенного обновления и технический долг инфраструктуры.

Точка принятия решения. Для критичных патчей решение может принимать дежурный инженер без согласования — цена промедления выше цены ошибки. Для мажорных обновлений решение должен подтверждать тот, кто видел результат тестового прогона — это страховка от ситуации «релиз вышел, все заняты, кто-то один решил накатить в обед, потому что заскучал».

Что зафиксировать в письменном регламенте

Регламент, который стоит того, чтобы называться регламентом, — это не абзац в вики, который никто не читал полгода, а короткий документ на одну страницу с конкретными правилами:

• Список категорий обновлений с примерами (как в таблице выше), адаптированный под ваш стек — какие пакеты и сервисы у вас критичны, а какие второстепенны.
• Сроки ожидания для каждой категории — в часах и днях, а не «побыстрее» и «не к спеху».
• Кто отвечает за установку каждой категории — конкретная роль, а не «кто первый увидит».
• Технические окна — когда можно перезагружать сервер, когда нельзя (часы пиковой нагрузки, релизные окна продукта).
• Процедура отката — где лежит бэкап/снапшот перед мажорным апгрейдом, кто и как его накатывает обратно.
• Исключения — сервисы, которые вообще не обновляются автоматически (legacy-система, которую страшно трогать) — с явным указанием, почему и до какого момента это временно, а не навсегда.

Последний пункт стоит воспринимать серьёзно: «не трогать» без даты пересмотра — не решение, а отложенная катастрофа. Без явной даты пересмотра легаси-компонент без обновлений безопасности три года — типичный итог, а не редкость.

Частые вопросы