График обновления ОС на два года вперёд: чтобы не проснуться на мёртвой версии

MAATRIX

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

Почему у операционной системы есть срок годности

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

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

Есть и менее драматичный, но более частый сценарий: пакетные репозитории для устаревшей версии постепенно перестают обновляться, и однажды apt update или dnf update просто не находит зеркал. Нужный пакет новой версии приложения требует более свежей библиотеки, которой нет в репозитории старой ОС. Сборка контейнерного образа падает, потому что базовый образ для этой версии дистрибутива больше не публикуется. Каждая из этих мелочей по отдельности не выглядит критичной, но вместе они складываются в ситуацию, когда каждое следующее действие с сервером требует обходных путей.

Разница между «ещё работает» и «ещё поддерживается»

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

Практическое правило: для планирования графика имеет значение не то, запускается ли сервис сегодня, а то, сколько времени осталось до конца официальной поддержки установленной версии. Эту дату каждый вендор публикует заранее — обычно за несколько лет до самого события, в виде дорожной карты релизов. Задача администратора — не гадать на глазок, а один раз найти эту дату для каждой используемой версии ОС и зафиксировать её в своём собственном календаре обслуживания, а не полагаться на память.

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

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

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

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

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

Не ждать последнего момента: почему ранний старт дешевле

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

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

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

Практический ориентир: закладывайте начало подготовки к переходу минимум за четыре-шесть месяцев до конца поддержки текущей версии. Этого времени хватает и на тестирование, и на постепенный, а не аварийный, перевод продакшена.

Окно на тестирование совместимости — не опция, а обязательный этап

Самая частая причина, по которой переход ОС срывает сроки — недооценка тестирования. Смена версии дистрибутива — это не только новое ядро и новые пакеты по умолчанию, это ещё и изменившиеся версии системных библиотек, новый релиз интерпретаторов (PHP, Python, Node), иногда другие дефолтные настройки сервисов. Приложение, которое годами стабильно работало на одной версии, может повести себя иначе на новой — не обязательно сломаться полностью, но выдать edge-case, который никто не предвидел.

Рабочая последовательность для тестового окна:

1. Разверните копию рабочей нагрузки на новой версии ОС в тестовом окружении. Не «похожий стенд», а максимально близкая копия — те же версии зависимостей, тот же объём данных на репрезентативной выборке, та же конфигурация сервисов. Если у вас есть отдельный регламент тестового окружения и стейджа, используйте именно его вместо разового «поднимем VM и посмотрим».
2. Прогоните полный цикл: сборку, деплой, миграции, интеграционные тесты. Обновление ОС часто тянет за собой обновление менеджера пакетов, компилятора, рантайма — проверяйте не только «сервис запустился», но и «сборка из исходников всё ещё воспроизводима».
3. Дайте тестовому окружению поработать под нагрузкой, а не только пройти smoke-тест. Часть проблем (утечки памяти из-за другой версии аллокатора, разница в поведении планировщика ввода-вывода, изменившиеся дефолты systemd) проявляется только со временем или под реальным трафиком.
4. Заложите время на находки, а не только на сам прогон. Если тестирование покажет несовместимость — а на новой мажорной версии дистрибутива это скорее правило, чем исключение — нужен запас, чтобы адаптировать код или конфиги, а не переносить дату перехода в последний момент.

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

Порядок перехода: от некритичных систем к продакшену

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

• Внутренние и вспомогательные сервисы первыми. CI-раннеры, внутренние дашборды, стейджинг — здесь можно позволить себе споткнуться без последствий для клиентов.
• Один инстанс прод-нагрузки как пилот. Если у вас несколько одинаковых веб-серверов за балансировщиком, переведите один, оставив остальные на старой версии, и понаблюдайте за ним отдельно неделю-две прежде чем катить остальные.
• Постепенный перевод остального прода волнами, а не разом — это тот же принцип, что и в общем регламенте обновлений: что ставить сразу, а что можно отложить, просто применённый к обновлению всей ОС, а не отдельного пакета.
• Базы данных и статeful-сервисы — последними и с особой осторожностью. Здесь цена отката высока, поэтому перед переходом обязателен свежий проверенный бэкап и отдельно протестированный план отката.

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

Что зафиксировать в регламенте, чтобы график не превратился в благое намерение

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

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

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