Red Hat расширила коммерческую поддержку промежуточных релизов RHEL до 6 лет, фактически удлинив жизненный цикл корпоративных систем и снизив частоту вынужденных обновлений в критично важных инфраструктурах.
Новый формат поддержки: до 14 лет жизни одного релиза
Компания запустила программу расширенного платного сопровождения Extended Life Cycle, Premium, в рамках которой выпускам Red Hat Enterprise Linux 8, 9 и 10 гарантируется до 14 лет поддержки:
- Первые 5 лет - стандартная фаза: полный поток обновлений, исправления ошибок, патчи безопасности, поддержка нового оборудования, иногда - новые возможности.
- Следующие 5 лет - продлённая базовая поддержка: выходят исправления серьёзных уязвимостей и критичных багов, но без внедрения новшеств и расширения аппаратной поддержки.
- Ещё 4 года - платный этап Extended Life Cycle, Premium: выпускаются только патчи для критических проблем и наиболее опасных дыр в безопасности, ориентированные на клиентов с подпиской.
Ранее схожая четырёхлетняя надстройка действовала для RHEL 7, теперь же Red Hat формализовала и распространила эту модель на поколения RHEL 8, 9 и 10.
Главная новость: промежуточные релизы получают до 6 лет жизни
Ключевое изменение касается не только общей "длины жизни" ветки, а именно промежуточных релизов (subreleases) - таких как RHEL 10.1, 10.2, 10.3 и т.д.
Red Hat меняет схему:
- Раньше:
- 2 года Extended Update Support для субрелиза;
- затем ещё до 2 лет по отдельной подписке Extended Extended Update.
Фактически - около 4 лет продлённой доступности обновлений для конкретной точки (например, 8.6 или 9.2).
- Теперь:
- обновления безопасности для уязвимостей с уровнем опасности CVSS 7+, а также исправления серьёзных ошибок для выбранного промежуточного релиза будут выходить до 6 лет.
Это важное изменение для компаний, в которых есть кластеры и системы, обслуживающие непрерывно работающие критически важные сервисы: базы данных, биллинговые платформы, промышленные системы, критическую телеком-инфраструктуру и т.д. Возможность дольше оставаться на одном субрелизе уменьшает количество изменений, а значит - снижает риски сбоев при частых обновлениях.
Как это будет работать на практике
Расширенная поддержка субрелизов реализуется "через релиз", то есть не все промежуточные версии будут жить одинаково долго. Приведён пример для RHEL 10:
- майский RHEL 10.2 - будет получать расширенные обновления до мая 2032 года;
- ноябрьский RHEL 10.3 - лишь до мая 2027 года;
- следующий майский RHEL 10.4 - до мая 2033 года.
Таким образом, Red Hat явно делает ставку на "опорные" релизы - те, на которые компании могут ориентироваться как на стабильную основу на долгие годы.
При этом:
- ветка RHEL 10 в целом будет поддерживаться до 2039 года;
- RHEL 9 - до 2036 года;
- RHEL 8 - до 2033 года.
Это даёт крупным организациям предсказуемый горизонт планирования - вплоть до 10-15 лет.
Как это выглядит на фоне других дистрибутивов
На рынке корпоративных Linux-систем длительность поддержки стала ключевым конкурентным параметром:
- SUSE Linux Enterprise - до 16 лет сопровождения;
- Ubuntu (серверные LTS-релизы) - до 15 лет при использовании платных опций расширенной поддержки;
- Debian GNU/Linux - около 10 лет (5 лет LTS + до 5 лет Extended LTS);
- openSUSE - примерно 2 года поддержки стабильной версии;
- Fedora Linux - около 13 месяцев для каждого релиза.
На этом фоне Red Hat предлагает сбалансированный вариант: долгий жизненный цикл RHEL с усиленным вниманием к корпоративным сценариям и платной доводкой поддержки на заключительных этапах.
Логичный вопрос: стоит ли платить за "частичное исправление уязвимостей"?
Скепсис понятен: на поздних этапах поддержки не обновляются библиотеки "до свежака", не появляются новые фичи, не добавляется поддержка нового "железа". Зачастую речь идёт только о критичных патчах безопасности и исправлении особо серьёзных ошибок.
Отсюда возникают сомнения:
платить за то, что закрывают только часть уязвимостей и не развивают систему - оправдано ли это?
Ответ зависит от трёх факторов:
1. Критичность сервисов: можно ли остановить систему ради миграции?
2. Стоимость простоя: сколько денег компания теряет за час/день недоступности?
3. Стоимость миграции и тестирования: сколько ресурсов уйдёт на переход к новому релизу (работа админов, DevOps, разработчиков, тестировщиков, риски ошибок)?
Для крупных организаций решения о покупке Extended Life Cycle почти всегда считаются в цифрах: если расширенная поддержка стоит меньше, чем потенциальный ущерб от форсированного апгрейда или от инцидента с безопасностью, - её приобретают.
Почему "частичная" безопасность всё равно лучше, чем "никакая"
Важно понимать, что в рамках расширенного цикла Red Hat закрывает именно наиболее опасные уязвимости - с высоким и критическим рейтингом CVSS (7+). Это те дыры, через которые:
- можно удалённо исполнить код;
- легко повысить привилегии до root;
- получить несанкционированный доступ к данным;
- нарушить целостность системы без физического доступа.
То есть речь идёт о тех проблемах, которыми реально пользуются атакующие. Мелкие логические баги или специфичные редкие кейсы могут и не попадать в зону расширенных патчей, но основные "ворота" в систему будут закрыты.
В ситуации, когда:
- апгрейд невозможен из-за старого критичного ПО;
- инфраструктура огромная, сложная и взаимосвязанная;
- бизнес не готов идти на риск масштабной миграции,
- платная частичная защита всё равно на порядок лучше полного отсутствия обновлений, когда система просто "замирает" в момент, когда основной срок поддержки закончился.
Контейнер - не панацея от старого и небезопасного окружения
Распространённый аргумент: "зачем продлённая поддержка, если всё можно упаковать в контейнер?" На деле контейнеры не решают проблем безопасности сами по себе.
Если:
- в контейнер образован на основе старого дистрибутива с уязвимыми библиотеками;
- внутри него остались десятки давно известных дыр (в тех же libtiff, libpng, openssl, glibc и т.п.);
- в прикладном коде никто не исправлял уязвимости,
то факт, что это работает "в контейнере", не делает систему безопасной. Уязвимости в библиотеках обработки изображений, архивах, сетевых компонентах и т.п. остаются эксплуатируемыми - а данные пользователей внутри такой среды по-прежнему под угрозой.
Контейнеры - это удобный инструмент упаковки и доставки приложений, но не гарантия того, что:
- зависимости обновлены;
- ОС внутри образа поддерживается;
- уязвимости закрыты.
Если внутри лежит древний RHEL 6 с давно прекращённой поддержкой, он остаётся "дырявым" и после контейнеризации.
Основная сложность - не контейнеры, а зависимость от старых библиотек
Корневая проблема - в том, что многие корпоративные приложения:
- жёстко завязаны на конкретные версии библиотек и системных компонентов;
- с трудом переносят переход на новые версии glibc, OpenSSL, драйверов и т.п.;
- изначально писались без ориентации на долгосрочное сопровождение и совместимость.
В результате обновление ОС - это не просто "поднять версию", а:
- переработать часть кода;
- пересобрать приложение;
- заново пройти полный цикл тестирования;
- иногда - модифицировать архитектуру всего решения.
Это одинаково сложно и с контейнерами, и без них: если приложение "намертво" привязано к старым зависимостям, контейнер лишь удобнее упакует этот легаси, но не облегчит его рефакторинг.
И в этом контексте Extended Life Cycle даёт компаниям время:
- планомерно переписать критичные компоненты;
- провести миграцию с минимальными рисками;
- не действовать в режиме паники, когда поддержка закончилась, а бизнес-процессы завязаны на старую платформу.
Когда Extended Life Cycle точно имеет смысл
Оплата расширенной поддержки оправдана, если совпадают несколько условий:
1. Система - критически важная
Банкинг, страхование, энергосети, промышленная автоматизация, медицина, крупный e-commerce, авиаперевозки - там простой системы может стоить миллионы или даже жизни.
2. Простои недопустимы или крайне дороги
Если каждый час простоя - это существенные прямые убытки и репутационный ущерб, любые обновления превращаются в рискованный проект.
3. Приложения сильно завязаны на окружение
Старые версии СУБД, специализированное ПО, вендорские решения, которые сложно (или дорого) обновить.
4. Миграция требует месяцев подготовки
Нужно: стенды, тестирование, пилот, документация, обучение персонала. А срок основной поддержки подходит к концу.
В таких случаях покупка Extended Life Cycle становится не "переплатой за воздух", а страховкой от:
- критичных инцидентов безопасности;
- вынужденной "гонки" по миграции;
- парализующих инфраструктуру ошибок после не до конца протестированного апгрейда.
Когда можно обойтись без платного продления
Есть и обратная ситуация, когда Extended Life Cycle может быть излишним:
- инфраструктура относительно небольшая и гибкая;
- все ключевые приложения активно развиваются и поддерживаются разработчиками;
- есть DevOps-практики, CI/CD, автоматизированное тестирование;
- обновление до следующего минорного или мажорного релиза уже отлажено и занимает приемлемые сроки.
В таком случае компания может:
- работать в рамках стандартного цикла поддержки;
- планово переходить на новые релизы каждые несколько лет;
- не оплачивать дополнительные 4 года "дотягивания" жизненного цикла.
Итог: платная продлённая поддержка - не "побор", а инструмент управления рисками
Увеличение платного срока сопровождения промежуточных веток RHEL до 6 лет и ввод 14‑летнего цикла для RHEL 8/9/10 - это шаг, рассчитанный прежде всего на крупные и консервативные инфраструктуры:
- он снижает частоту обновлений для ключевых субрелизов;
- позволяет дольше держать критичные сервисы на проверенной конфигурации;
- даёт дополнительные годы для безопасной, а не авральной миграции.
Платить за это или нет - зависит не от "правильности" самого подхода, а от того, сколько стоит риск:
если цена сбоя, взлома или неудачного обновления выше стоимости подписки на Extended Life Cycle, то ответ "да, стоит". Если же инфраструктура легко обновляется и не критична - можно обойтись базовым сроком поддержки.
