Разведите уровни поддержки
Kernel.org публикует активные longterm-ветки и ориентировочные сроки их сопровождения, но дистрибутив может дольше поддерживать собственный пакет через backport исправлений. Производитель оборудования отдельно определяет совместимость драйвера, прошивки и HBA, а поставщик приложения — поддерживаемые версии ОС и библиотек.
Поэтому «ядро старое» не всегда означает уязвимость, а «ядро новое» не гарантирует поддержку всей системы.
Ведите матрицу фактического парка
Для каждого класса узлов фиксируйте дистрибутив и канал, пакет ядра, критические модули, прошивки, Secure Boot, средства резервного копирования, мониторинга и защиты. Добавьте дату окончания сопровождения каждого поставщика и владельца решения о переходе.
Автоматический инвентарь полезнее таблицы, обновляемой перед аудитом. Он должен показывать не только версию, но и отклонение от утверждённого базового образа.
Проверяйте backport, а не только номер CVE
Дистрибутивы часто переносят исправление в старую ветку без изменения основного номера версии. Проверяйте бюллетень и сборку пакета, а не делайте вывод по upstream-версии. Для стороннего модуля убедитесь, что обновление ядра не ломает загрузку, сеть, хранилище или агент безопасности.
Тестовый контур должен воспроизводить драйверы и профиль нагрузки, а не только запускать виртуальную машину с чистой ОС.
Планируйте переход как сервисное изменение
Выберите целевую поддерживаемую ветку, проверьте приложения и оборудование, подготовьте резервную загрузочную запись и проверенный откат. Обновляйте партиями, начиная с низкорисковых узлов, и измеряйте ошибки, производительность и время восстановления.
Наличие LTS не отменяет регулярные обновления. Оно даёт предсказуемую основу, но ответственность за доставку пакетов, тестирование и перезагрузку остаётся у операционной команды.