Миф: обновления ломают больше, чем чинят

MAATRIX

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

Зерно правды: обновления действительно ломают

Начнём с честного признания: страх обоснован. Обновление ядра меняет ABI, и проприетарный драйвер видеокарты перестаёт собираться. Мажорный апгрейд PHP убирает функцию, которую использует легаси-код десятилетней давности, и сайт падает с white screen. Обновление Docker Engine меняет дефолтный network driver, и контейнеры теряют друг друга по имени. Патч OpenSSL или systemd иногда действительно приводит к регрессии, которую разработчики сами не заметили при тестировании — баги в патчах не редкость, это факт, а не паранойя.

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

Риск известной уязвимости против риска гипотетической регрессии

Вот где расходится ощущение и статистика. Когда вы откладываете обновление безопасности, вы не откладываете риск на потом — вы меняете один тип риска на другой, и эти типы риска несимметричны.

Непропатченная уязвимость — это не гипотеза. Как только патч безопасности выходит, CVE публикуется в открытых базах (NVD, Vulners), а вместе с ним нередко появляется PoC-эксплойт на GitHub в течение суток-двух. Автоматизированные сканеры (massscan, Shodan-боты, ботнеты вроде Mirai-подобных) прочёсывают весь IPv4-диапазон и находят непропатченные хосты не целенаправленно, а по расписанию — просто потому, что ваш IP ответил на пробный запрос. Log4Shell (CVE-2021-44228) начали массово эксплуатировать в первые сутки после публикации. EternalBlue лежал в основе WannaCry ещё через месяцы после выхода патча MS17-010 — пострадали именно те, кто не обновился. Это не редкие исключения, это типичный жизненный цикл критической уязвимости: публикация → эксплойт в открытом доступе → массовое автоматическое сканирование.

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

Отдельно о неочевидном: отказ от обновления не устраняет риск падения сервиса — он его переносит на будущее и увеличивает. Это подводит к следующему пункту.

Почему отложенное обновление становится тяжелее, а не легче

Интуиция подсказывает: подождём, пока патч «обкатается» на других. На практике для системы, которую вы уже отложили один раз, это не разовое решение — это накопительный долг. Чем дольше вы не обновляетесь, тем больше разрыв между текущей и целевой версией, и тем рискованнее становится неизбежное будущее обновление — потому что рано или поздно обновиться придётся: либо когда текущая версия дойдёт до конца поддержки (EOL) и патчи безопасности вообще перестанут выходить, либо когда накопившаяся несовместимость с остальным стеком заставит обновляться экстренно.

Разница масштаба хорошо видна на примере: обновление Debian 12.5 → 12.6 внутри одной мажорной ветки почти всегда проходит гладко — правки точечные, ABI стабилен, changelog короткий. А вот прыжок с Debian 9 (Stretch, EOL с 2022 года) сразу на Debian 12 — это одновременная замена init-системы поведения, PHP 7.0 → 8.2, MySQL 5.7 → MariaDB 10.11, десятков системных библиотек разом. Чем больше версий пропущено, тем больше breaking changes наложились друг на друга, и тем сложнее понять, какое именно изменение сломало что. При регулярных небольших шагах вы меняете одну переменную за раз и откатить/продиагностировать легко; при редком масштабном скачке — вы меняете десятки переменных одновременно, и диагностика превращается в расследование на дни.

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

Тестовое окружение: где ловить регрессию до того, как она долетит до прода

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

Если это VPS общего назначения — берите отдельный сервер под staging, клонируйте туда конфиги, БД (дамп, не продовые данные с PII, если это публично доступный стенд) и версии пакетов перед обновлением прода:

# на staging: синхронизируем версии с продом перед тестом
apt list --installed > prod-packages.txt
# на staging сверяем и подтягиваем те же версии, что сейчас стоят на проде

Дальше — сам прогон обновления на staging с чек-листом: стартуют ли все службы, отвечает ли health-check эндпоинт, проходят ли smoke-тесты основных сценариев (логин, оформление заказа, отправка формы — что критично именно для вашего сервиса), не появились ли новые записи об ошибках в логах в первые 10-15 минут после рестарта.

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

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

План отката: путь назад готовится ДО обновления, а не во время инцидента

Второй практический рычаг — не пытаться предотвратить любую регрессию (это невозможно), а гарантировать быстрый путь назад, если она случилась. Разница между «обновление сломало что-то и мы откатились за 5 минут» и «обновление сломало что-то и мы разбираемся 6 часов» — это разница между управляемым риском и инцидентом с простоем.

Для файловой системы и виртуалок — снапшот перед обновлением, это не обсуждается:

# LVM: снапшот тома перед обновлением системы
lvcreate --size 5G --snapshot --name pre-update-snap /dev/vg0/root

# если что-то пошло не так — откат к снапшоту
lvconvert --merge vg0/pre-update-snap

Для Proxmox-нод то же самое делается снапшотом VM/контейнера перед апдейтом гипервизора или гостевой системы. Для Docker — никогда не тяните latest в проде: фиксируйте тег образа, и откат — это смена тега обратно в docker-compose и docker compose up -d, а не археология.

Для баз данных — дамп непосредственно перед обновлением, отдельно от регулярных бэкапов по расписанию:

pg_dump -Fc mydb > /backups/pre-update-$(date +%F-%H%M).dump

И держите под рукой пошаговый план: что именно откатывать, в каком порядке, кто принимает решение об откате и по какому критерию (например: «если health-check не зелёный через 15 минут после апдейта — откат без обсуждений»). Разбор реального кейса, когда обновление всё же положило прод и как из этого выходили, — в статье обновление положило прод: как откатиться. Если у вас есть такой план и снапшот — сама регрессия перестаёт быть катастрофой и становится рутинной, пусть и неприятной, операцией на 10-20 минут.

Поэтапное применение: не всё сразу и не на самое важное первым

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

Практическая последовательность для инфраструктуры из нескольких серверов:

1. Dev/staging — как описано выше, первая проверка.
2. Наименее критичный прод-сервер (например, второстепенный регион или сервис с низкой нагрузкой) — реальная нагрузка, но ограниченный blast radius, если что-то не так.
3. Через день-два наблюдения — на основной прод, в окно с наименьшей нагрузкой, с кем-то на дежурстве.

Для автоматических обновлений безопасности (unattended-upgrades на Debian/Ubuntu, dnf-automatic на AlmaLinux) тот же принцип применяется через задержку и мониторинг, а не полное отключение автообновлений — иначе вы теряете именно то преимущество (быструю реакцию на CVE), ради которого обновления вообще существуют:

# /etc/apt/apt.conf.d/50unattended-upgrades — только security-репозиторий,
# не тянуть произвольные апдейты пакетов автоматически
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "false";

Отдельная (частая) грабля с автообновлениями — они молча падают из-за конфликта пакетов или занятого lock-файла, и админ узнаёт об этом только когда CVE уже месяц как не пропатчен. Поэтому статус unattended-upgrades стоит проверять мониторингом с алертом, а не считать настроенным и забытым.

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

Похожий миф и практический итог

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

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

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