Оновлення проти чистої інсталяції: що швидше та менше спричиняє помилок?

February 8, 2026 • February 8, 2026 • Читання: 4 хв • Views: 0

Було корисно?

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

Питання звучить просто — оновити на місці чи зробити чисту інсталяцію? — але відповідь здебільшого залежить від того, як ваша система лама була минулого разу, а не від того, що каже маркетингова сторінка постачальника.

Справжній компроміс: час у календарі проти часу в каналі інцидентів

«Швидше» — це не час CPU. Це час у календарі: скільки часу пройде, поки система безпечно повернеться в обслуговування з передбачуваною поведінкою. «Менш баговано» — це не менше помилок у upstream; це менше сюрпризів, спричинених вашим середовищем — старі конфіги, дрейф, покинуті пакунки, застарілі драйвери та та сама udev-правило, яке хтось написав у 2019 і забув.

Оновлення й чисті інсталяції ламаються по-різному:

Оновлення зберігають стан. Це і є їхня суть і їхня пастка. Вони зазвичай ламаються через краї сумісності: зміни формату конфігів, конфлікти залежностей, несумісність ABI, сторонні модулі ядра або «воно завантажується, але половина сервісів мовчки зламані».
Чисті інсталяції скидають стан. Вони зазвичай ламаються через відсутність стану: забуті конфіги, відсутні сертифікати, неправильні права, відсутні маунти або «воно працює, але це не ваша система».

Як SRE, скажу прямо: якщо ви не можете описати вашу систему як код (або принаймні як відтворюваний руківник), то оновлення на місці — це в основному археологія. Якщо ви можете її описати, то чисті інсталяції стають нудними, а нудне — найвища похвала в операціях.

Цитата, тому що це досі правильна ментальна модель: Надія — це не стратегія. (парафразована ідея, часто приписувана лідерам інженерії в операційних колах)

Що справді швидше (і коли)?

Коли оновлення швидше

Оновлення зазвичай швидші коли:

Машина зберігає стан і ви не можете легко перемістити дані (великі локальні дані, direct-attached storage без реплікації, спеціальні контролери обладнання).
Ви робите мажорне до мажорного або LTS→наступний LTS шлях, який постачальник реально підтримує. Підтримувані шляхи оновлення — це вимощені дороги; непідтримувані — лісові стежки.
Ваша площа конфігурацій велика і погано задокументована. Оновлення залишає ваш безлад недоторканим, що іноді кращий варіант у разі жорсткого дедлайну.
Вікно простою коротке і ви можете прийняти відкат до снапшоту/образу замість повторної поставки.

Але «швидко» оманливе. Оновлення на місці швидкі, поки раптом не стають такими, і тоді ви дебажите в найгіршому середовищі: напівзміненій системі, де логи й сервіси сперечаються, в якому столітті вони живуть.

Коли чисті інсталяції швидші

Чисті інсталяції частіше швидші коли:

Сервіс безстанний або може бути зроблений ефективно безстанним (дані винесені в керовані БД, репліковане сховище, object store або окремий том).
Ви маєте автоматизацію (PXE/Kickstart/Preseed, cloud-init, Terraform + конфігураційне управління, золоті образи).
Ви переходите через значні версії, де конфіги та значення за замовчуванням змінилися суттєво.
Ви накопичили дрейф — і є підстава вважати, що так сталося, що стосується більшості середовищ старших за рік.

Швидкість чистої інсталяції ґрунтується на паралелізмі: ви можете побудувати новий вузол, поки старий все ще обслуговує трафік, перевірити його, а потім переключити. Оновлення зазвичай серійні: потрібно торкатися живого вузла (або його клон) і чекати.

Моє однозначне правило

Якщо ви можете побудувати свіжий вузол і переключитися, не зачіпаючи plane даних ризикованими способами, чиста інсталяція перемагає за швидкістю й кількістю помилок у більшості реальних продакшн-середовищ. Якщо вузол — сніжинка з pet-даними на локальних дисках і невідомими обмеженнями, то ретельно поетапне оновлення часто безпечніше, ніж вдавати, що ви зможете реконструювати його з пам’яті.

Жарт №1: Оновлення на місці — як міняти шину, коли машина їде — іноді працює, і ви багато дізнаєтесь про фізику.

Що менш баговане (і чому «баг» зазвичай означає «невідомий стан»)?

«Баги» після зміни зазвичай належать до одного з цих випадків:

Колізії дрейфу конфігурацій: ваші старі оверрайди конфліктують з новими значеннями за замовчуванням. Система «працює», але не так, як ви думаєте.
Неконтрольовані графи залежностей: старі пакунки фіксують версії, сторонні репозиторії підкидають сюрпризи, або зміна ABI бібліотеки ламає бінарник.
Несумісність драйверів/ядра: GPU, NIC offload, HBA сховища або DKMS-модулі не збираються після підняття ядра.
Трансформації формату стану: оновлення формату на диску БД, прапорці можливостей файлових систем, зміни завантажувача.
Прогалини в спостережуваності: ви не знаєте, що змінилося, бо не зафіксували попередній стан, тому не можете довести причинно-наслідковий зв’язок.

Оновлення: менше роботи спочатку, більше ризику на швах

Оновлення зберігає ваш відомо-робочий базовий стан — плюс ваш невідомо-поганий мотлох. Якщо ваша система чиста й добре керована, оновлення підходять. Якщо це довго живучий сервер з ручними правками, агентами продавця й «тимчасовими» обхідними шляхами, оновлення підсилюють невизначеність. Система завантажується, але як експонат у музеї.

Чисті інсталяції: більше роботи спочатку, менше ентропії

Чиста інсталяція примушує вас знову оголосити намір: пакунки, конфіги, сервіси, маунти, користувачі, секрети, параметри ядра, налаштування. Це дратує рівно один раз. Потім це повторюваний рецепт. Більшість «зменшення багів» після чистих інсталяцій — це просто видалення старого стану, який ви вже не пам’ятаєте, що додали.

Жарт №2: Чиста інсталяція чудова, бо вона видаляє всі ваші проблеми — допоки вона не видалить ту єдину конфігурацію, яка вам справді потрібна.

Цікаві факти та історичний контекст (коротко й по суті)

Оновлення на місці стали мейнстримом для флотів лише після того, як надійне управління пакунками й ідеї транзакційних оновлень дозріли; ранні Unix-шопи часто перебудовували з носіїв, бо оновлення були рулеткою.
Windows «repair install» та пізніші інструменти оновлення створювалися, щоб зберегти стан користувача, бо десктопний світ трактує втрату даних як смертний гріх, а фрикцію перевстановлення — як витрати служби підтримки.
Дистрибутиви Linux історично віддавали перевагу чистим інсталяціям при великих стрибках, бо змінювалися системи ініціалізації, розкладки файлових систем і демони за замовчуванням; концепція «підтримуваного шляху оновлення» затверділа з часом.
ZFS і сучасні файлові системи ввели прапорці можливостей, які можна вмикати після оновлення; після вмикання відкат до старіших версій ускладнюється або стає неможливим без ретельного планування.
UEFI замінив legacy BIOS; оновлення, що торкаються завантажувачів, можуть падати новими способами (неправильні EFI-записи, відсутні маунти ESP), які чисті інсталяції частіше обходять послідовно.
Системи управління конфігурацією (CFEngine, Puppet, Chef, Ansible) зрушили індустрію до rebuild-and-replace, бо зменшили залежність від «племінних знань».
Непорушні підходи з образами (golden images, AMI, образи контейнерів) зробили «чисту інсталяцію» ефективно типовою у cloud-native організаціях, бо новий інстанс дешевший, ніж дебажити старий.
Екосистеми модулів ядра (DKMS, драйвери вендорів) розширилися; оновлення більш крихкі, коли ви залежите від модулів поза деревом ядра, особливо для сховища й мережі.
Поява systemd змінила управління сервісами й очікування щодо логування; оновлення через цю межу були печально відомі «воно стартує, але не так, як раніше».

Три корпоративні міні-історії (бо теорія бреше)

Міні-історія 1: Інцидент через неправильне припущення

У них був невеликий кластер аплікейшн-серверів, про який у планувальному документі значилося «він нічого важливого локально не зберігає». Це речення жило там роками й набирало авторитету, як викопний експонат у музеї.

Під час напруженого кварталу вони обрали чисті інсталяції заради швидкості. Нові образи, нові ядра, усе нове. План відключення був простим: зілити трафік, термінувати старий вузол, підняти новий, повторити. Все йшло добре — поки перший вузол не почав повертати 500 на невелику частку запитів.

Неправильне припущення: на локальному диску була важлива інформація. Не дані клієнтів, а кеш попередньо обчислених шаблонів та набір per-node TLS клієнтських сертифікатів для взаємної аутентифікації зі спадковим даунстрімом. Ці сертифікати були видані роками раніше, вручну скопійовані й ніколи не ротовані, бо «потім виправимо». Нові вузли їх не мали.

Аутейдж не був драматичним. Він був гіршим: періодичним. Тільки запити, що йшли певними шляхами, зачіпали зламану залежність, і тільки деякі нові вузли були уражені в будь-який момент під час розгортання.

Виправлення: вони призупинили rollout, витягли відсутній стан зі старого вузла, встановили його на нові вузли, і — що важливо — перемістили ці сертифікати в нормальний механізм розподілу секретів, щоб наступна перебудова не залежала від археології.

Міні-історія 2: Оптимізація, що повернулася бумерангом

Інша компанія хотіла «оновлення без простою» на репліках бази даних. Вони побудували розумний пайплайн: знімок VM, виконати оновлення ОС на знімку, завантажити його в ізоляції, потім підмінити. Розумно, правда?

В основному так. Оптимізація полягала в пропуску глибокої перевірки сховища, бо «це уповільнює пайплайн». Вони не запускали scrub файлової системи й не перевіряли SMART; вважали, що знімок — безпечна точка.

Після кількох циклів вони натрапили на неприємний режим відмови: оновлена репліка працювала добре кілька годин, а потім панікувала під навантаженням I/O. Це не було через ОС. Підлегле сховище мало проблемний SSD, який виправляв помилки, що перейшли у невиправні під тривалими записами, і новий планувальник I/O ядра виявив цю слабкість швидше.

Спочатку палилися звинувачення: пайплайн, потім ОС, потім команда зберігання опинилася на виклику о 3:00. Корінна причина була прозаїчна: вони оптимізували геть нудні перевірки, які показали б, що пристрій деградує.

Виправлення: вони повернули попередні ворота по здоров’ю (SMART, mdadm, ZFS pool status, вік scrub) і «швидкий пайплайн» знову став швидким, бо перестав продукувати зламані артефакти.

Міні-історія 3: Нудна, але правильна практика, що врятувала ситуацію

SaaS-організація мала змішаний флот: деякі вузли були старі «пет», деякі — нові «кевелрі». Потрібен був великий стрибок ОС плюс оновлення ядра для відповідності безпеці. Усі очікували болю.

Але одна команда мала нудну звичку: перед будь-якою зміною вони фіксували «контракт системи» — список пакунків, увімкнені сервіси, слухаючі порти, таблицю маунтів, відхилення sysctl і набір простих smoke-тестів. Вони зберігали це поруч із запитом на зміну. Нічого модного, просто послідовно.

Вони вибрали шлях чистої інсталяції для більшості вузлів. Під час валідації помітили одну невідповідність: нові вузли не монтували додатковий том з аудит-логами. Сервіс працював, але відповідність вимогам — ні. Завдяки контрактному артефакту вони помітили відсутній маунт за кілька хвилин, а не після запитання від аудитора.

Виправили провізіювання, щоб том монтувався й правильно маркувався, перезапустили збірку й рухалися далі. Без героїчних вчинків. Жодних північних вгадувань. Просто доказ.

Плейбук швидкої діагностики: знайдіть вузьке місце перед зміною плану

Якщо ви вже в процесі оновлення (або перебудови) і воно йде не за планом, не бийтеся. Діагностуйте у послідовності, яка швидко звужує проблему.

Перше: це рівень завантаження/ОС, конфігурація сервісу чи шлях даних?

Рівень завантаження/ОС: ядро, initramfs, завантажувач, драйвери. Симптоми: не завантажується, падає в initramfs, відсутня коренева FS, kernel panic.
Рівень сервісу: systemd-юнити, конфіги, права, секрети. Симптоми: завантажується нормально, але сервіси не стартують, помилки бинду, помилки автентифікації.
Шлях даних: маунти сховища, цілісність FS, маршрути мережі, DNS, балансувальник. Симптоми: сервіси стартують, але таймаутять, висока латентність, періодичні помилки.

Друге: класифікуйте відмову як детерміністичну або «хайзенбаг»

Детермінована: відмовляє кожного разу, та ж сама рядок у логах. Зазвичай це конфіг, відсутня залежність, невірний шлях файлу, несумісний модуль.
Хайзенбаг: періодична, залежна від навантаження. Зазвичай ліміти ресурсів, зміни поведінки ядра/драйвера, латентні апаратні проблеми, гонки, виявлені різницею в таймінгах.

Третє: вирішіть — відкат, пауза чи продовжити

Відкат якщо: ви не можете пояснити режим відмови протягом однієї години, або виправлення — «пробувати випадкові пакунки».
Пауза і клон якщо: потрібен час на судово-технічний аналіз. Зробіть снапшот/клон диска/VM, дебажте офлайн, тримайте продакшн стабільним.
Продовжити якщо: помилка чітко обмежена, ви можете валідовати тестами і маєте можливість відкотитися.

Практичні завдання: команди, вивід і рішення, яке ви приймаєте

Ось перевірки, які я реально виконую. Не тому, що люблю друкувати. Бо гадання — дороге.

Завдання 1: Підтвердіть, що саме ви зараз запускаєте (ядро + ОС)

cr0x@server:~$ uname -r
6.5.0-21-generic
cr0x@server:~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.4 LTS"
VERSION_ID="22.04"

Що це означає: Ви дебажите не «Linux» загалом. Ви дебажите це ядро і цей дистр.

Рішення: Якщо ціль оновлення стрибатиме через мажорні версії, припускайте, що конфіги й значення за замовчуванням змінилися. Віддавайте перевагу чистій інсталяції, якщо у вас немає перевіреного runbook для оновлення.

Завдання 2: Подивіться, що змінилося недавно (пакунки)

cr0x@server:~$ grep " install \| upgrade " /var/log/dpkg.log | tail -n 5
2026-02-03 10:14:22 upgrade openssl:amd64 3.0.2-0ubuntu1.15 3.0.2-0ubuntu1.16
2026-02-03 10:14:28 upgrade systemd:amd64 249.11-0ubuntu3.12 249.11-0ubuntu3.13
2026-02-03 10:14:31 upgrade linux-image-6.5.0-21-generic:amd64 6.5.0-21.21~22.04.1 6.5.0-21.21~22.04.2

Що це означає: Регіcтрація регресії «після оновлення» зазвичай корелює з коротким списком підозрюваних. Це ваш список підозрюваних.

Рішення: Якщо змінився критичний компонент (ядро/systemd/openssl), явно провалідуйте сервіси й драйвери. Не припускайте, що «все гаразд».

Завдання 3: Швидко перевірте упавші сервіси

cr0x@server:~$ systemctl --failed
  UNIT                LOAD   ACTIVE SUB    DESCRIPTION
● nginx.service       loaded failed failed  A high performance web server and a reverse proxy server
● myapp.service       loaded failed failed  MyApp API Service

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state.
SUB    = The low-level unit activation state.

Що це означає: Якщо systemd каже, що юніт впав, перестаньте сперечатися про архітектуру. Читайте логи.

Рішення: Якщо після оновлення впало кілька нерелевантних сервісів, підозрюйте відсутні маунти, права або поломку бібліотек; розгляньте відкат або перехід до чистої інсталяції з правильним захопленням конфігів.

Завдання 4: Витягніть логи сервісу з корисними межами

cr0x@server:~$ journalctl -u nginx.service -b --no-pager | tail -n 12
Feb 03 10:16:02 server nginx[1123]: nginx: [emerg] cannot load certificate "/etc/nginx/tls/api.pem": BIO_new_file() failed
Feb 03 10:16:02 server systemd[1]: nginx.service: Failed with result 'exit-code'.
Feb 03 10:16:02 server systemd[1]: Failed to start A high performance web server and a reverse proxy server.

Що це означає: ОС в порядку; відсутній стан, потрібний додатку (сертифікат) або змінилися права.

Рішення: Виявлено режим відмови чистої інсталяції: відсутні секрети/конфіг. Виправте провізіювання/розподіл секретів, не копіюйте вручну як «лише цього разу».

Завдання 5: Перевірте маунти і правильність fstab

cr0x@server:~$ findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS | head
TARGET  SOURCE        FSTYPE OPTIONS
/       /dev/sda2     ext4   rw,relatime
/boot   /dev/sda1     vfat   rw,relatime,fmask=0022,dmask=0022
/data   /dev/sdb1     ext4   rw,relatime

Що це означає: Точковий том змонтовано там, де сервіси очікують.

Рішення: Якщо очікувані маунти відсутні, зупиніться. Виправте проблеми зі сховищем/маунтами перед діагностикою помилок додатків.

Завдання 6: Підтвердіть стан файлової системи та блокових пристроїв (SMART)

cr0x@server:~$ sudo smartctl -H /dev/sda
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-6.5.0-21-generic] (local build)
SMART overall-health self-assessment test result: PASSED

Що це означає: «PASSED» — це не гарантія, але «FAILED» — це пожежа.

Рішення: Якщо SMART падає або показує помилки носія, не продовжуйте оновлення/перебудову, поки не виправите апарат. Інакше ви будете приписувати корупцію даних змінам ОС.

Завдання 7: Якщо ви використовуєте mdadm RAID, переконайтеся, що масиви чисті

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda3[0] sdb3[1]
      976630336 blocks super 1.2 [2/2] [UU]

unused devices: <none>

Що це означає: [UU] означає, що обидва члени в строю. Інше — означає деградований масив.

Рішення: Якщо масив деградований, уникайте великих змін. Відремонтуйте масив спочатку, або ви перетворите «онвлення» на «відновлення з бекапу».

Завдання 8: Якщо ви використовуєте ZFS, перевірте стан pool і прапорці можливостей

cr0x@server:~$ sudo zpool status
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 00:12:11 with 0 errors on Sun Feb  2 01:10:33 2026
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          sdc       ONLINE       0     0     0
          sdd       ONLINE       0     0     0

errors: No known data errors

Що це означає: Останній scrub, без помилок. Хороша базова лінія.

Рішення: Якщо scrub старий або є помилки, зробіть scrub і усуньте проблеми перед будь-якою роботою з ОС. Проблеми зі сховищем маскуватимуться під регресії оновлення.

Завдання 9: Порівняйте відхилення sysctl (щоб вловити сюрпризи в продуктивності)

cr0x@server:~$ sysctl -a 2>/dev/null | grep -E 'net.core.somaxconn|vm.swappiness'
net.core.somaxconn = 4096
vm.swappiness = 10

Що це означає: Ці значення впливають на черги й поведінку пам’яті. Оновлення можуть скинути кастомні налаштування.

Рішення: Якщо значення повернулися до дефолту (або відрізняються від вашої бази), заносьте налаштування через конфігураційне управління, а не правки вручну.

Завдання 10: Виявте конфлікт залежностей до того, як він вас спалить

cr0x@server:~$ sudo apt-get -s dist-upgrade | tail -n 12
The following packages will be REMOVED:
  vendor-agent dkms-nvidia
The following packages will be upgraded:
  libc6 openssl systemd
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.

Що це означає: Симуляція показує видалення. Видалення модулів ядра або вендорських агентів може зламати мережу/сховище або відповідність.

Рішення: Якщо оновлення хоче видалити критичні модулі/агенти, зупиніться і сплануйте: зафіксуйте версії, оновіть вендорський репо або оберіть чисту інсталяцію з підтримуваними драйверами в образі.

Завдання 11: Перевірка завантажувача/EFI (поширена пастка при оновленнях)

cr0x@server:~$ mount | grep -E ' /boot | /boot/efi '
/dev/sda1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022)
/dev/sda2 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077)

Що це означає: Розділ EFI змонтовано. Оновлення завантажувача можуть писати туди.

Рішення: Якщо /boot/efi не змонтовано під час оновлення, що оновлює grub/systemd-boot, ризикуєте отримати систему, що оновиться, але не завантажиться. Змонтуйте його й повторіть кроки оновлення завантажувача.

Завдання 12: Перевірте мережеву ідентичність і маршрути (класика після перевстановлення)

cr0x@server:~$ ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens160           UP             10.20.30.41/24
cr0x@server:~$ ip route
default via 10.20.30.1 dev ens160
10.20.30.0/24 dev ens160 proto kernel scope link src 10.20.30.41

Що це означає: Імена інтерфейсів і маршрути збігаються з очікуваннями. Чисті інсталяції іноді переназивають NIC або пропускають VLAN.

Рішення: Якщо IP/підмережа/дефолтний маршрут відрізняються від бази, виправте мережеву конфігурацію перед тим, як звинувачувати додаток.

Завдання 13: Підтвердіть DNS і поведінку резолвера (бо все — це «мережа»)

cr0x@server:~$ resolvectl status | sed -n '1,20p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53 10.20.0.54

Що це означає: Ви використовуєте systemd-resolved у режимі stub з очікуваними DNS-серверами.

Рішення: Якщо режим резолвера змінився (поширено після оновлень), відкоригуйте базовий образ і моніторинг. Регресії DNS виглядають як таймаути додатків.

Завдання 14: Порівняйте відкриті порти і слухачі (функціональний контракт)

cr0x@server:~$ sudo ss -lntp | head -n 10
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      511    0.0.0.0:80         0.0.0.0:*     users:(("nginx",pid=1201,fd=6))
LISTEN 0      4096   127.0.0.1:5432     0.0.0.0:*     users:(("postgres",pid=1302,fd=5))

Що це означає: Сервіси слухають там, де ви очікуєте. Після зміни «він up» має означати «приймає з’єднання».

Рішення: Якщо слухачі відсутні або зв’язуються лише з localhost, виправте конфіги сервісів, фаєрволи або systemd-override.

Завдання 15: Виявте дрейф прав/власності в директоріях стану

cr0x@server:~$ sudo namei -l /var/lib/myapp
f: /var/lib/myapp
drwxr-xr-x root  root  /
drwxr-xr-x root  root  var
drwxr-xr-x root  root  lib
drwx------ root  root  myapp

Що це означає: Директорія належить root з правами 0700. Якщо сервіс працює як myapp, він не зможе писати сюди.

Рішення: Виправте власність/права в процесі провіжнінгу (systemd tmpfiles, postinst пакунку або конфігураційне управління). Не робіть chmod навмання під тиском.

Завдання 16: Саніті перевірка продуктивності: CPU, пам’ять чи I/O?

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 521124  80340 942112    0    0    15    38  210  480  3  1 95  1  0
 2  0      0 498300  80344 951020    0    0    12  2100  320  620  5  2 70 23  0

Що це означає: Високий wa (I/O wait) вказує на вузьке місце зі сховищем. Після оновлення ядра і драйверів поведінка I/O може змінитися.

Рішення: Якщо I/O wait зростає, інспектуйте латентність дисків і налаштування планувальника перед тим, як звинувачувати додаток.

Типові помилки: симптом → корінна причина → виправлення

1) «Оновлення завершилось, але сервіси не стартують»

Симптоми: systemctl показує помилки; логи згадують відсутні файли, невідомі директиви або permission denied.

Корінна причина: зміни формату конфігів, видалені модулі або директорії стану з неправильними правами після зміни пакунків.

Виправлення: Порівняйте конфіг з vendor-версією; запустіть інструменти валідації конфігів (наприклад, nginx -t); забезпечте права директорій через провізіювання. Якщо більше двох критичних сервісів впали, розгляньте відкат і rebuild з контрольованим конфігуруванням.

2) «Чиста інсталяція працює, але дивні інтермітентні помилки авторизації»

Симптоми: деякі запити падають mTLS, API-токени недійсні, даунстрім відкидає лише певні вузли.

Корінна причина: секрети розподілені неправильно, відсутні клієнтські сертифікати/ключі, неправильний синхрон часу або невідповідність ідентичності хоста.

Виправлення: Перевірте інжекцію секретів і синхронізацію часу; переконайтесь, що імена хостів і SAN у сертифікатах співпадають; припиніть ручне копіювання і використайте єдиний механізм розподілу.

3) «Після оновлення продуктивність диска погіршилась»

Симптоми: вища латентність, зростання I/O wait, база даних зависає, fsync сповільнився.

Корінна причина: зміни планувальника I/O в ядрі, відмінності драйверів, політика кешування записів або латентна апаратна проблема, виявлена новими шаблонами використання.

Виправлення: Порівняйте налаштування планувальника і черги; перевірте SMART/ZFS/mdadm; запустіть цілеспрямовані бенчмарки на тому ж навантаженні; якщо апаратна частина на межі, замініть її до налаштування.

4) «Система не завантажується після оновлення»

Симптоми: падає в initramfs, не знаходить root, grub rescue, відсутня EFI-запис.

Корінна причина: відсутні драйвери сховища в initramfs, /boot або ESP не змонтовані під час оновлення завантажувача, зміни UUID, або невірний fstab.

Виправлення: Переконайтесь, що /boot і /boot/efi змонтовані під час оновлення; згенеруйте initramfs заново; перевірте UUID; тримайте відомий робочий запис ядра; тестуйте перезавантаження в вікні обслуговування, не о 14:00.

5) «Оновлення видалило вендорський драйвер/агент»

Симптоми: DKMS-модуль не збирається, NIC offload зникає, шляхи сховища змінюються, агент відповідності відсутній.

Корінна причина: непідтримуваний сторонній репо, конфлікти пакунків, стрибок ABI ядра ламає збірку модуля.

Виправлення: Підлаштуйте вендорське репо під цільову ОС; зафіксуйте версії; або оберіть чисту інсталяцію з вендор-підтримуваною версією драйвера в образі.

6) «Чиста інсталяція зайняла більше часу, ніж оновлення… бо ми забули половину системи»

Симптоми: затримки під час cutover, відсутні cron job-и, відсутній logrotate, відсутні sysctl, невірні ulimits.

Корінна причина: відсутність захоплення базової конфігурації; конфіг існував як племінне знання й незареєстровані правки.

Виправлення: Створіть контракт системи: список пакунків, сервіси, маунти, порти, sysctl, cron, користувачі/групи, правила фаєрволу, сертифікати. Використовуйте його як критерій приймання.

Чеклісти / покроковий план

Чекліст для рішення: оновлення чи чиста інсталяція?

Локалізація даних: Чи знаходяться критичні дані на локальному диску без надійної реплікації/снапшотів? Якщо так, тяжійте до оновлення (або сплануйте ретельну міграцію даних перед цим).
Зрілість автоматизації: Чи можете ви поставити новий вузол до «готовності» за менше години з мінімумом ручних кроків? Якщо так, тяжійте до чистої інсталяції.
Підтримка шляху оновлення: Чи підтримує ваш вендор/дистрибутив ваш стрибок версій? Якщо ні, тяжійте до чистої інсталяції.
Сторонні модулі ядра: Чи залежите ви від DKMS/модулів поза деревом (сховище/NIC/GPU)? Якщо так, тестуйте агресивно; чиста інсталяція з перевіреними драйверами часто перемагає.
Можливість відкату: Чи можете ви швидко зробити снапшот/відкат? Якщо так, ризик оновлення знижується. Якщо ні, віддавайте перевагу rebuild і cutover.
Дрейф конфігурацій: Чи підозрюєте ви роки ручних правок? Якщо так, чиста інсталяція виплатить технічний борг — за умови, що ви можете відтворити потрібний стан.

Покроково: безпечне оновлення на місці (продакшн-орієнтоване)

Захопіть базу: ОС/ядро, список пакунків, маунти, слухачі, статус сервісів, відхилення sysctl.
Гейти здоров’я: стан сховища (SMART/ZFS/mdadm), вільне місце на файлових системах, тиск пам’яті, журнали помилок.
Симулюйте оновлення: dry-run операції пакунків; зафіксуйте видалення й переходи мажорних версій.
Прогніть на клоні: снапшот VM/диска; зробіть оновлення на клоні; відрепетируйте перезавантаження.
Валідація: старт сервісів, порти, функціональні smoke-тести, перевірка логів, базова латентність.
Виконання у вікні: оновіть продакшн, перезавантажте, швидко провалідуйте, потім моніторьте принаймні один цикл навантаження.
Критерії відкату: визначте жорсткий тайм-ліміт і конкретні помилки, що запускають відкат.

Покроково: чиста інсталяція з cutover (підхід «нудьга — це добре»)

Інвентар стану: що має зберігатися (томи даних, секрети, сертифікати, ідентичність хоста, правила фаєрволу).
Побудуйте образ: базова ОС, пакунки, ядро, драйвери, моніторинг/агенти.
Застосуйте конфігурацію: з коду або суворого runbook; уникайте «просто залогініться по ssh і зробіть».
Прикрутіть/змонтируйте дані: переконайтесь у коректних мітках/UUID; валідовує права.
Функціональний тест: health endpoint, підключення до БД, фонові задачі, TLS handshake, потоки автентифікації.
Тіньовий трафік (якщо можливо): дзеркальте read-only запити або запустіть канарку.
Cutover: переключіть за балансувальником/DNS; тримайте старий вузол для швидкого бекауту.
Аудит після cutover: порівняйте слухачі, логи, метрики й шум алертів; потім виведіть старий вузол з експлуатації.

FAQ

1) Чи завжди чиста інсталяція менш багована?

Ні. Вона менш багована якщо ви можете правильно відтворити потрібний стан. Інакше це чиста інсталяція зламаного дизайну, яка ефективно і швидко провалюється.

2) Чи завжди оновлення на місці ризиковані?

Не завжди. Вони прийнятні для підтримуваних шляхів оновлення на добре керованих системах з мінімальним дрейфом і хорошим відкатом. Ризик зростає з сторонніми модулями, довго живучими серверами і невідомими ручними правками.

3) А як щодо «переінсталювати, але зберегти /home» (або збереження розділів даних)?

Це гібрид і він може добре працювати. Ви отримуєте чистий шар ОС, зберігаючи дані. Гостра межа — це права, відповідність UID/GID і очікування маунтів. Перевірте це явно.

4) Для баз даних: оновлювати чи перебудовувати?

Віддавайте перевагу rebuild реплік і контрольованому failover замість оновлення первинного вузла на місці. Для одновузлових БД оновлення може бути прийнятним, але лише за наявності перевірених бекапів і тестованого плану відкату.

5) Який найбільший прихований поглинач часу?

Секрети й ідентичність: сертифікати, API-ключі, хостова автентифікація і випадковий файл у /etc, який робить вашу систему «спеціальною». Помістіть це в керований механізм, або перебудови будуть повільні й помилкові.

6) Як вирішити: відкат чи продовжувати дебаг?

Якщо ви не можете сформувати фальсифікуючу гіпотезу з логів і diff-ів протягом години, відкатуйте. Дебаг напівоновленої системи під тиском — шлях до створення фольклору замість реальних виправлень.

7) Чи змінює контейнеризація відповідь?

Так. Якщо додаток працює в контейнерах, а хост — лише субстрат, чиста інсталяція (або незмінна заміна хоста) стає типовою. Оновлення хоста все одно важливі для ядра, сховища й мережі, але стан додатка менш переплетений.

8) Що якщо проблеми — з драйверами обладнання?

Тоді вам потрібен план сумісності більше, ніж філософська дискусія. Для HBA сховища і NIC валідируйте підтримку драйверів для цільової ОС/ядра; якщо підтримка сирувата, чиста інсталяція не врятує вас.

9) Який найбезпечніший спосіб обробки великих стрибків версій?

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

10) Як не допустити, щоб чисті інсталяції стали повільними?

Опишіть систему: управління конфігурацією, пайплайни образів і артефакт контракту системи для валідації. Перший раз — це робота; другий раз — швидкість.

Наступні кроки, які можна зробити цього тижня

Якщо ви хочете швидкості і менше багів, припиніть ставитися до оновлень і перевстановлень як до ритуалів. Ставтесь до них як до контрольованих переходів стану.

Створіть скрипт захоплення бази, який фіксує ОС/ядро, список пакунків, впавші сервіси, маунти, слухачі і ключові sysctl. Зберігайте його з запитами на зміну.
Додайте гейти здоров’я перед будь-якою великою зміною: перевірки SMART/ZFS/mdadm і вимоги «свіжий scrub».
Оберіть один сервіс і зробіть його відновлюваним end-to-end з мінімумом ручних кроків. Виміряйте час. Виправте три основні джерела тертя (зазвичай секрети, маунти і ідентичність).
Визначте критерії відкату для оновлень: тайм-ліміти, бюджет помилок і що означає «завершено» в метриках, а не в відчуттях.
Для stateful систем, спроектуйте наступну архітектуру так, щоб перевстановлення було простим: винесіть стан, реплікуйте дані і тримайте хости одноразовими.

Моя остаточна думка: якщо ваше середовище це підтримує, за замовчуванням обирайте чисту інсталяцію з cutover. Залишайте оновлення на місці для справді складного для міграції стану або для щільно підтримуваних, добре протестованих шляхів. Продакшн не винагороджує хоробрість; він винагороджує відтворюваність.