Чому продакшн на Oracle Linux Server ламається після оновлень
Планове оновлення — найчастіша причина збою на продакшн-сервері, і винен не патч, а те, що він тягне за собою.
Ядро переходить на свіжу гілку, а зібрані поза деревом модулі — драйвери дискової корзини, шифрування, файлової системи, засоби захисту — залишаються під попередню версію.
Пакетний менеджер цього не бачить: залежності виконані, оновлення проходить без попереджень. Проявляється все на перезавантаженні — завантажувач вибирає нове ядро, набір драйверів в образі ініціалізації неповний, і монтування тому або старт сервісу впирається у відсутній модуль. Якщо модуль критичний для кореня, система піднімається в аварійному режимі.
Найдорожче обходиться пошук. Поки черговий дивиться логи додатка і перезапускає сервіс, причина лежить у виводі ядра: повідомлення про непідписаний або несумісний модуль, позначка про забруднення ядра, відмова SELinux.
Кожне таке перезавантаження скорочує варіанти відкату — за замовчуванням старі ядра вичищаються, і повернутися до робочої гілки вже нічим.
Простій вважають з моменту алерту, хоча фактично він триває з нічного оновлення, а відновлення впирається в перезбирання модулів і ручне редагування параметрів завантажувача.
Розбираємо, як налаштування Oracle Linux Server закриває цей клас відмов: політика оновлень, підпис модулів, набір збережених ядер і перевірки до перезавантаження.
Що йде з продакшну: класи відмов і час робіт
Відмова в продакшні майже ніколи не виглядає як «сервер зламався». Це несумісний модуль після оновлення ядра, втрачений доступ після зміни політики безпеки, забитий розділ під логи або неузгоджена конфігурація між вузлами. Кожен такий випадок коштує годин простою і нічної роботи чергового.
Налаштований за чек-листом Oracle Linux знімає не окремі симптоми, а цілі класи відмов:
- оновлення ядра — нове ядро лежить поруч, перемикання і відкат виконуються перезавантаженням у відомий робочий стан;
- паніка ядра — збір дампа налаштований і перевірений заздалегідь, розбір іде за готовим слідом, а не пошуком причини навмання;
- втрата доступу — правила мандатного контролю і фільтрації описані в конфігурації, а не виставлені руками на живому сервері;
- переповнення розділів — ротація логів, ліміти і оповіщення спрацьовують до того, як сервіс встане;
- розходження вузлів — встановлення ідемпотентне і повторюване, дрейф між серверами зникає;
- незапущені сервіси після перезавантаження — цільові стани перевірені, а не «увімкнемо потім».
Практичний ефект вимірний: час відновлення сервісу скорочується з годин ручного розбору до хвилин — відкат ядра, перезапуск, зняття обмеження.
Частка ручних операцій при розгортанні падає приблизно на дві третини, бо процедура описана і відтворюється однаково на будь-якому вузлі, а не збирається з пам'яті.
Це і є стабільність продакшну: менше нічних викликів, передбачувана поведінка після оновлень і зрозумілий порядок дій у чергового.
Варіанти розгортання і режими роботи ядра сервера
Вибір схеми розгортання визначає, скільки коштує кожне оновлення ядра. На одному сервері ядро і модулі змінюються «на місці», але зміна гілки ядра вимагає перезавантаження — і весь цей час сервіс недоступний.
Відмовостійкий кластер linux на двох вузлах знімає це обмеження: вузли по черзі виводяться з балансування, оновлюються і повертаються, простій скорочується до часу перемикання.
Плата за це — арбітр для кворуму, синхронізація стану і окрема перевірка, що після зміни ядра піднімаються потрібні модулі.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Один сервер (мінімальний набір) | внутрішній сервіс, передбачуване навантаження, допустимі вікна обслуговування | оновлення без простою неможливе: зміна ядра — перезавантаження; немає запасу при відмові вузла або диска |
| Відмовостійка пара (кластер) | прод з вимогами до доступності: платежі, інтеграції, особистий кабінет | потрібен арбітр і синхронізація даних; вищі вимоги до моніторингу і дисципліни почергового оновлення |
| Прод-пара плюс стенд | оновлення ядра і конфігурацій потрібно перевіряти до викочування на прод | більше вузлів; без автоматизації налаштування стенда і прода розходяться |
| Гібрид: прод на парі, важкі перевірки на стенді | рідкісні релізи ядра, але жорсткі вимоги до відкату | стенд вимагає окремого місця і копій даних, інакше перевірка безглузда |
Режим роботи ядра фіксується окремо: перемикання між основною і сумісною гілкою спочатку проганяється на стенді, і тільки потім розкочується на пару.
На одиночному вузлі розумніше тримати одну перевірену гілку і планувати вікна — інакше будь-яка правка ядра перетворюється на незапланований простій.
Порядок робіт: від аудиту конфігурації до передачі в експлуатацію
Порядок робіт однаковий для одиночного сервера і для парку з десятків машин — різниться тільки глибина аудиту. Спочатку ми фіксуємо фактичний стан: цільову конфігурацію ніхто не погоджує з пам'яті, а розходження зручніше зловити до перенесення навантаження.
Налаштування Oracle Linux на стенді йде окремим етапом, щоб зміни не приїжджали в продакшн «з коліс».
- Аудит конфігурації сервера. Знімаємо поточний стан: схема розділів і вільне місце, активний набір репозиторіїв і модулів, режим SELinux, правила фільтрації трафіку, профіль продуктивності, мережеві профілі, завдання за розкладом, стан служб. Результат — перелік розходжень з еталоном і ризиків, відсортований за критичністю.
- Цільова схема. Погоджуємо призначення вузла, схему дисків і точок монтування, склад служб, політику оновлень і межі доступу. Схема лягає в документ, за яким розгортається стенд і який потім живе поруч із сервером.
- Налаштування на стенді. Повторюємо цільовий стан на тестовому вузлі: профіль продуктивності, розмітка, служби, правила SELinux у робочому режимі, збір аварійних дампів, ротація журналів. Усі дії виконуємо через версіоновані сценарії, а не вручну, — тоді продакшн повторюється один в один.
- Перевірка на стенді і сценарії відмови. Проганяємо штатні операції і аварійні: відмова диска і мережевого інтерфейсу, заповнення розділу під журнали, оновлення ядра, перезавантаження під навантаженням. Дивимося, чи відновлюється вузол сам і скільки часу це займає.
- Переведення в експлуатацію. Виділяємо вікно, знімаємо точку відкату, переносимо навантаження і залишаємося на зв'язку до стабілізації метрик. Регламент оновлень фіксує, що можна ставити автоматично, а що — тільки у вікно з перевіркою.
- Передача з навчанням. Віддаємо інструкції з типових операцій і розбору інцидентів, розбираємо з командою доступи і права, показуємо, де дивитися журнали. Виїжджаємо, коли черговий інженер закриває базові завдання без нас.
Конфігурації, схеми і регламенти, які залишаються у вас
Роботу ми закінчуємо не фактом «сервер запущений», а комплектом артефактів, за якими ваша команда зможе супроводжувати його без нас. Конфігурації тримаємо в репозиторії, схеми і регламенти — текстом поруч із ними, щоб правка сервера і правка документа йшли однією зміною.
- Файли конфігурації — параметри ядра, ліміти, розмітка дисків, налаштування служб і журналювання з коментарями: що змінено щодо базової поставки Oracle Linux Server і чому.
- Політики доступу — ролі, способи входу, порядок видачі та відкликання ключів, обмеження за адресами, що обов'язково потрапляє в журнал аудиту.
- Схема інфраструктури — які служби працюють, як пов'язані, де точки відмови, як проходить трафік і що залежить від зовнішніх систем.
- Регламент оновлень і відкату — вікна робіт, порядок перевірки після оновлення, критерії, за яких відкочуємося, і спосіб повернути попередній стан.
- Інструкції для чергової зміни — типові збої, перші дії, які журнали дивитися, кого підключати і коли.
- Документація по серверу — призначення, власник, залежності, порядок перезапуску і перевірки після нього.
- Чек-ліст приймання — як за кілька хвилин переконатися, що оточення відповідає описаному стану.
Кейс: продакшн, що перестав падати після оновлень ядра
Замовник тримає цілодобовий сервіс на Oracle Linux Server. Оновлення ядра йшли за регламентом, але кожне третє закінчувалося збоєм: після перезавантаження частина вузлів не піднімала мережеві інтерфейси, і сервіси поверталися в стрій тільки після ручного втручання. Черговий інженер прокидався вночі частіше, ніж раз на місяць.
Що було до змін
Інвентаризація показала, що продакшн оновлювався тим самим способом, що і тестовий контур, — відразу на всіх вузлах, а автоматичне встановлення оновлень ядра не було вимкнене.
Попереднє ядро видалялося при чищенні, тому відкат означав відновлення вузла з образу, а не повернення на попередній завантажувальний запис.
Що змінили і що вийшло
Оновлення перевели на хвилі: спочатку один вузол, потім групи, кожна з перевіркою живучості та навантаження. Попереднє ядро зберігається в завантажувачі, і вузол, що не підтвердив готовність, сам повертається на нього. Автоматичні оновлення на продакшні вимкнені — вони залишилися тільки на передпродуктивному контурі.
| Показник | До | Після |
|---|---|---|
| Оновлення з ручним відкатом | кожне третє | жодного |
| Відновлення вузла | 40-90 хвилин | 4-6 хвилин |
| Нічні виклики чергового | 12-15 на рік | 0 |
| Вікно регламентних робіт | весь вихідний | один короткий інтервал |
Нічні підйоми припинилися, відновлення більше не залежить від того, хто чергує, а вікно робіт стиснулося. Оновлення ядра перестало бути подією з ризиком і стало плановим завданням.
Чим UEK відрізняється від стандартного ядра Linux?
Різниця не в назві пакета, а в гілці ядра і в тому, який бінарний інтерфейс модулів ядро гарантує. Oracle Linux постачає два варіанти: UEK — власна збірка на більш свіжій основній гілці, і RHCK — перезбірка, сумісна з Red Hat на рівні завантажуваних модулів.
UEK іде попереду за версією гілки, тому в ньому раніше з'являються драйвери під нові мережеві і дискові контролери, підтримка свіжих наборів інструкцій процесора, доопрацьовані планувальник і підсистема пам'яті.
На новому залізі це прибирає класичний біль: не доводиться шукати зовнішній модуль або чекати, поки виробник оновить комплект під попереднє ядро.
Платою йде сумісність модулів. Зібрані під RHCK драйвери на UEK не завантажаться без перезбирання, а вбудовані модулі СУБД і систем резервного копіювання часто сертифіковані саме під RHEL-сумісне ядро.
Якщо виробник ПЗ вимагає RHEL-ядро або в парку є вузли із зовнішніми модулями, розумніше залишити RHCK і не ламати підтримку.
Обслуговування теж різниться. UEK допускає накладення виправлень безпеки на працююче ядро без перезавантаження — вікно простою при закритті критичних уразливостей зникає.
Виправлення обидві гілки отримують в одному циклі, але на RHCK оновлення ядра майже завжди означає плановий рестарт.
Для продакшну вибір простий: UEK за замовчуванням, якщо немає вимог виробника ПЗ і зовнішніх модулів; RHCK — коли важливіша сумісність, а не свіжість заліза.
Перевіряється це на тестовому стенді: завантажитися з кожного ядра, підняти модулі, зняти метрики під навантаженням і зафіксувати, що і де відвалюється.
Технічні сумніви: безпека, оновлення, сумісність
Перед стартом майже кожна команда ставить одні і ті самі питання: що робити з уже працюючим сервером, чи не зламають оновлення додатки, як влаштоване розмежування прав. Нижче — короткі відповіді по суті, щоб рішення приймалося на фактах, а не на припущеннях.
У нас уже налаштований сервер — невже все переробляти?
Ні. Спочатку інвентаризація: пакети, служби, правила міжмережевого екрана, політики SELinux, завдання в планувальнику.
Далі поточний стан переноситься в опис — ролі Ansible або сценарій автоматичного встановлення, — і сервер починає відтворюватися з коду, а не «налаштовуватися руками з пам'яті». Роботи йдуть поверх живого контуру, перезавантаження плануються в узгоджені вікна.
Оновлення linux не зламають додатки?
Оновлення проходять два контури: спочатку тестовий, де проганяються ваші додатки і перевіряється сумісність додатків за залежностями, потім робочий. Ядро тримаємо в підтримуваній гілці UEK з правками безпеки, які застосовуються на льоту — перезавантаження для них не потрібне.
Відкат передбачений заздалегідь: знімок перед оновленням і попереднє ядро залишаються доступні в завантажувачі.
Як буде влаштовано розмежування прав?
Кожен сервіс працює під окремим системним користувачем без входу в оболонку, підвищення прав — за іменованими правилами, прямий вхід під root закритий, автентифікація тільки за ключами.
SELinux залишається в робочому режимі, а не вимикається: політики дописуються під ваші додатки. Адміністративний доступ іде через окремий вузол, дії фіксуються в журналі.
Обговоримо задачу: що надіслати для оцінки і плану робіт
Щоб оцінка робіт з налаштування спиралася на факти, а не на припущення, нам потрібен мінімальний склад вихідних даних. Надсилати вивантаження і доступи відразу не потрібно — достатньо опису.
- інвентар: скільки серверів, їхні ролі, фізичні чи віртуальні, де розміщені;
- поточний стан: що вже встановлено, гілка Oracle Linux Server, чи використовується UEK, чи є локальне дзеркало пакетів;
- вимоги безпеки: режим SELinux, шифрування розділів, інтеграція з каталогом користувачів, правила аудиту;
- схема дисків і мережі: розмітка томів, файлові системи і точки монтування, доступ по SSH, проміжні вузли, сегментація підмереж;
- оновлення та експлуатація: як плануються вікна обслуговування, чи потрібні автоматичні оновлення за розкладом, як виконується відкат;
- суміжні системи: моніторинг, збір журналів, резервне копіювання, уже застосовувані сценарії автоматизації конфігурації;
- обмеження: неприпустимий простій, терміни, регуляторні вимоги до захисту даних.
З цим набором ми повернемося з планом робіт — порядком етапів, переліком змін на кожному й оцінкою термінів. Якщо частина даних відсутня, обговорення задачі все одно має сенс: прогалини закриємо уточнювальними питаннями.
