Антипаттерн: обновлять всё разом раз в год

MAATRIX

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

Как это выглядит на практике

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

apt update && apt full-upgrade -y
composer update
npm update
pip install -U -r requirements.txt

За один заход система получает новую версию ядра, десятки обновлённых системных пакетов, новый минор или мажор PHP/Node/Python, обновлённые библиотеки приложения и, часто, новую версию Docker или панели управления заодно — если и её давно не трогали. Логика простая: раз уж мы сегодня всё равно останавливаем сервис для обновления, лучше сделать это один раз и закрыть вопрос на год вперёд.

Проблема начинается сразу после apt full-upgrade: сервис не поднимается, либо поднимается, но отдаёт 500-е на части запросов, либо работает внешне нормально, а через два дня падает по памяти. И вот тут начинается настоящая цена подхода — не в том, что что-то сломалось (это бывает при любом обновлении), а в том, что непонятно, что именно.

Проблема 1: накопленный разрыв версий увеличивает риск скачка

Когда обновление откладывается на год, вы не откладываете один шаг — вы копите десяток шагов и потом проходите их все разом. Пакетный менеджер не видит промежуточных версий: apt full-upgrade после года простоя молча тянет то, что стало актуальным сегодня, включая все мажорные переходы, которые случились за это время у зависимых пакетов. То же с зависимостями приложения: composer update без ограничений версий в composer.json или npm update без lock-файла, застрявшего на старых версиях, подтягивает не следующий патч, а всё, что вышло за год — с любым количеством breaking changes, которые авторы библиотек посчитали нужным внести за это время.

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

Отдельно достаётся связкам компонентов, которые должны быть совместимы между собой: версия PHP и версии расширений, версия Node и версии нативных модулей, драйвер СУБД и версия самой СУБД. При регулярных обновлениях вы двигаете эти пары синхронно, небольшими шагами, и несовместимость видна сразу. При годовом скачке разные части стека могут «уехать» на разное расстояние от точки старта, и получившаяся комбинация версий может оказаться такой, которую никто из мейнтейнеров вообще не тестировал вместе.

Проблема 2: невозможно понять, что именно сломалось

Это главная практическая боль годового обновления, и именно она отнимает больше всего времени у инженера, а не сама поломка. Когда вы меняете одну переменную — например, обновляете только nginx с 1.24 до 1.25 — и после этого сервис ведёт себя иначе, причина очевидна: смотрите changelog именно этой версии, ищете там нужный пункт. Диагностика занимает минуты.

Когда за один прогон обновились ядро, systemd, PHP, три системные библиотеки, ORM в приложении и драйвер базы данных — а сервис после этого отдаёт периодические 500-е — расследование превращается в перебор гипотез вслепую. Вы не можете просто «посмотреть логи и понять» — логи покажут симптом (например, исключение в ORM), но не скажут, вызвано ли оно изменением поведения ORM, новой версией PHP, изменившимся системным лимитом на файловые дескрипторы после апдейта ядра или обновлённой версией расширения pdo_mysql. Единственный надёжный способ найти причину — откатывать компоненты по одному и проверять, на каком шаге проблема исчезает. Это ровно та работа, которую вы могли бы не делать, если бы обновляли по одному компоненту с самого начала и видели эффект каждого шага сразу.

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

Проблема 3: месяцы без критичных патчей безопасности

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

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

Здесь стоит явно развести два типа обновлений, которые в схеме «раз в год» ошибочно смешаны в одну задачу. Патч безопасности внутри той же версии (например, openssl или nginx с исправлением уязвимости без смены минорной ветки) — низкорисковая операция, которая почти никогда не ломает поведение приложения, потому что API и формат данных не меняются. Мажорный переход версии — совсем другая по риску операция, требующая тестирования. Годовой цикл обновления объединяет обе задачи в одну ежегодную операцию и тем самым откладывает низкорисковые, срочные патчи до момента, когда придётся разбираться заодно с высокорисковыми мажорными переходами — и то и другое от этого не выигрывает.

Правильный подход: регулярный цикл вместо годового марафона

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

Автоматизируйте патчи безопасности отдельно от остального. Для Ubuntu/Debian это unattended-upgrades, настроенный на security-репозиторий:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

В /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 "03:00";

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

Отделите зависимости приложения от «когда-нибудь потом». Для composer.json и package.json держите разумные диапазоны версий (^1.4, а не жёсткую фиксацию без причины) и раз в одну-две недели прогоняйте composer outdated / npm outdated, чтобы видеть накопление отставания на ранней стадии, а не через год разом.

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

Зафиксируйте расписание, а не «когда будет время». Патчи безопасности — по мере выхода, автоматически или еженедельной проверкой вручную. Минорные обновления приложения и системных пакетов — раз в месяц, коротким плановым окном. Мажорные переходы (версия ОС, мажор СУБД, мажор рантайма) — раз в квартал или полугодие, с отдельным тестовым циклом под каждый. Расписание в календаре с большей вероятностью случится, чем ожидание «спокойной недели», которая на практике наступает реже, чем кажется.

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

Сравнение подходов на практике

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

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