Ера кнопки скидання: найчесніше рішення в обчислювальній техніці

Чому скидання здається чесним (і чому воно все одно брешe)

Скидання — це чисте розривання причинно-наслідкового зв’язку. Ви перестаєте намагатися домовлятися з пошкодженим рантаймом і починаєте заново з відомих добрих шляхів ініціалізації: завантаження ядра, ініціалізація драйверів, запуск сервісів, завантаження конфігурації, «прогрів» кешів. Для великої кількості відмов — утечок пам’яті, дедлоків, завислого I/O, заклинених драйверів — код ініціалізації перевірявся тисячі разів.

Ось чесна частина. Нечесна частина — скидання часто знищує докази. Воно чистить місце злочину, викидає трасування стеків і обнуляє лічильники, які якраз показували, наскільки все погано ставало.

Тож ставтеся до скидання так само, як до знеболювального після травми. Використовуйте його, щоб функціонувати, звісно. Але якщо ви продовжуєте приймати його без діагностики, ви не «круті», ви просто літаєте навмання.

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

Жарт №1: Перезавантаження — найщиріше вибачення, яке може запропонувати комп’ютер: воно не може пояснити, що сталося, але обіцяє стати кращим.

Коли скидання — правильне рішення

• Активне порушення SLO і у вас є відомі безпечні процедури відкату або перезапуску.
• Стан вже підозрілий (помилки файлової системи, попередження ядра, скидання NIC, сигнали корупції алокатора).
• Не вдається відтворити під спостереженням і потрібна стабільна база для збору кращих даних наступного разу.
• Контейнмент радіусу ураження: ізолюйте вузол, злийте навантаження, перезавантажте, поверніть у кластер.

Коли скидання — це халатність

• Ви не зібрали базову криміналістику (логи, dmesg, основні споживачі) і зараз їх зітрете.
• Перезавантаження спровокує реконструкцію (RAID, ZFS resilver, відновлення БД), що підвищує ризик.
• Проблема явно зовнішня (залежність вгорі, мережевий розділ, протермінований сертифікат). Перезавантаження нічого не змінить.
• Ви використовуєте перезавантаження, щоб уникнути визнання відсутності спостережуваності.

Є перефразована ідея від Werner Vogels (CTO Amazon), яка має бути на стіні кожної операційної команди: ви будуєте під відмови, бо все рано чи пізно відмовляє. Ера кнопки скидання — це те, що відбувається, коли ви сприймаєте це буквально і робите операційну практику: відмови трапляються; питання в тому, чи ваші скидання контрольовані й інформативні — чи хаотичні й забуті.

Факти та історія: як ми сюди дійшли

Скидання не є моральним провалом; це наслідок складності. Кілька конкретних моментів пояснюють, чому перезавантаження залишалося релевантним десятиліттями:

1. Ранні мікрокомп’ютери нормалізували жорсткі скидання. Багато домашніх систем заохочували вимикання/вмикання як рутинне відновлення, бо персистентний стан та журналювання не були стандартом.
2. «Трипальцеве вітання» стало культурною пам’яттю. Скидання з клавіатури на ранніх ПК зробило «reset» користувацьким фіксом, а не інженерним.
3. Таймери watchdog існували задовго до хмари. Вбудовані системи використовували апаратні watchdog, щоб перезавантажуватися автоматично, коли софт припиняв «пестити» собаку.
4. Журналювальні файлові системи зменшили—але не усунули—біль від скидань. Вони зробили відновлення після збою швидшим і безпечнішим, що парадоксально зробило скидання більш прийнятним у продакшені.
5. Віртуалізація зробила перезавантаження дешевшим. Коли «сервер» — це VM, його перезавантаження здається менш драматичним, ніж возити фізичний стелаж у дата-центрі.
6. Контейнери знову нормалізували рестарт. Перезапуск пода — планована подія; системи оркестрації трактують процеси як скороплинні.
7. Сучасні системи залежать від кешів скрізь. DNS-кеші, page cache, connection pools, JIT-кеші, таблиці маршрутизації. Скидання їх очищує — іноді покращує, іноді спричиняє «гарматний гуркіт» при одночасному відновленні.
8. Оновлення прошивки і мікрокоду розмили межу між «пофіксити софтом» і «потрібен reboot». Патч безпеки може потребувати перезавантаження, бо змінилися рукопотискання між ядром і апаратурою.
9. Стеки зберігання стали багаторівневими. RAID/прошивка HBA, multipath, файлові системи, менеджер томів, шифрування, додаток. Скидання може виправити заклинений шар, але треба зрозуміти, який саме.

Зверніть увагу на закономірність: скидання ставали простішими, і «простота» змінила культуру. Небезпека в тому, що простота стає за замовчуванням, а замовчування — доктриною.

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

1) Пам’ять процесу та стан алокатора

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

2) Стан ядра та драйверів

Баги ядра рідкісні, поки не трапляються. Перезавантаження відкидає структури ядра: таблиці сторінок, черги планувальника, стан TCP, машини станів драйверів. Якщо драйвер заклинив — часто з NIC, HBA, GPU або віртуальними пристроями — перезавантаження є грубим, але ефективним способом змусити повторну ініціалізацію.

3) Кеші зберігання та черги I/O

У зберігання два види стану: дані на диску та операційний стан (в польоті). Скидання знищує операційний стан: невиконані I/O, глибини черг, рішення multipath, контроль заторів. Це може «полагодити» спіраль затримок, але також може запустити rebuild, rescan або переключення контролера у найгірший момент.

4) Мережеві сесії та «прилипання» балансувальника навантаження

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

5) Час: тихий залежник

Багато багів залежать від часу: прострочені сертифікати, логіка оновлення токенів, cron-завдання, ротація логів, лічильники, що досягли порогу, safepoint JVM під навантаженням heap. Перезавантаження може «вирішити» симптом, обнуливши годинники й лічильники в користувацькому просторі, тоді як фундаментальна умова продовжує рух до наступного обриву.

Перезапуск vs перезавантаження vs power-cycle: оберіть найменший молоток, що спрацює

Перезапуск сервісу

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

Перезавантаження вузла

Використовуйте коли підозрілі шари — ядро або орієнтовані на апаратний рівень: повторювані скидання драйверів, незнищувані процеси в стані D, блокування I/O файлової системи, флапання NIC, сильний зсув годинника або потреба застосувати оновлення ядра.

Power-cycle (жорстке скидання)

Застосовуйте коли система не відповідає на чисте перезавантаження або плейн керування показує заклинання апаратури (BMC-події, проблеми PCIe, HBA заблокований). Це опція «потрібно, щоб електрони перестали і знову пішли». Вона може бути необхідною. Вона ніколи не легка.

Жарт №2: Power-cycle — це як вимкнути та ввімкнути колегу: ефективно, але HR захоче постмортем.

Правило прийняття рішень під тиском

Починайте з верхівки стеку і спускайтеся вниз лише якщо докази штовхають вас:

• Якщо дивно поводиться один сервіс — перезапустіть сервіс.
• Якщо багато сервісів поводяться погано на одному вузлі — перезавантажте вузол (після дренування, якщо можливо).
• Якщо вузол не може перезавантажитися або апарат заклинив — зробіть power-cycle.

І незалежно від вибору: зафіксуйте достатньо доказів, щоб наступний інцидент став коротшим.

Швидкий план діагностики: знайдіть вузьке місце перед тим, як «виправляти»

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

Перш за все: це одна машина, один сервіс чи весь кластер?

• Перевірте, чи симптом корелює з вузлом, AZ/шафою, релізом або залежністю.
• Якщо кілька вузлів показують ідентичні симптоми одночасно, перезавантаження часто — шум. Шукайте спільні залежності (DNS, auth, бекенд зберігання, мережа).

Друге: CPU, пам’ять, I/O чи мережа?

• CPU-bound: високі навантаження, довга черга на виконання, невеликий iowait, top показує гарячі потоки.
• Тиск пам’яті: активність swap, зупинки reclaim, OOM kills, зростання RSS.
• I/O-bound: високий iowait, зростання затримки диска, заблоковані задачі, попередження файлової системи.
• Мережеве: ретрансмісії, втрати пакетів, насичення conntrack, DNS timeouts.

Третє: сигнали ядра та апаратні повідомлення

• dmesg/journal показує скидання пристроїв, link down/up, помилки файлової системи, завислі завдання.
• SMART-помилки, деградація пулу ZFS, флапання multipath.

Четверте: оберіть найменше пом’якшення, що відновить сервіс

• Перезапустіть сервіс, якщо вузол виглядає здоровим.
• Злити та перезавантажити, якщо стан вузла підозрілий.
• Фейловерити, якщо шлях зберігання/мережі нестабільний.

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

• Запишіть, що змінилося після скидання: затримка, рівень помилок, покажчики ядра, коефіцієнти влучань кешу.
• Створіть гіпотезу, яку можна протестувати до наступного інциденту.

Практичні завдання: команди, виводи та рішення (12+)

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

1) Uptime і load: це повільна смерть чи раптова відмова?

cr0x@server:~$ uptime
 14:22:10 up 87 days,  3:41,  2 users,  load average: 18.44, 17.90, 16.72

Значення виводу: 87 днів без перезавантаження; середні навантаження високі і стійкі (не короткий сплеск).

Рішення: Якщо це один вузол і load ненормальний — переходьте до поділу на CPU vs I/O. Ще не перезавантажуйте; зберіть причину високого навантаження.

2) Снімок top: CPU vs iowait vs процеси-збійники

cr0x@server:~$ top -b -n 1 | head -n 20
top - 14:22:25 up 87 days,  3:41,  2 users,  load average: 18.44, 17.90, 16.72
Tasks: 312 total,   2 running, 310 sleeping,   0 stopped,   0 zombie
%Cpu(s):  8.3 us,  2.1 sy,  0.0 ni, 21.7 id, 67.6 wa,  0.0 hi,  0.3 si,  0.0 st
MiB Mem :  64049.2 total,   1800.5 free,  51221.4 used,  11027.3 buff/cache
MiB Swap:   8192.0 total,   8120.0 free,     72.0 used.  10341.8 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
18342 postgres  20   0 12.1g  9.2g  9120 S  120.0  14.7  36:12.44 postgres

Значення виводу: iowait величезний (67.6% wa). CPU в основному чекає на диск, а не виконує роботу.

Рішення: Не перезавантажуйте базу даних через очікування диска; знайдіть вузьке місце в зберіганні. Перезавантаження може погіршити час відновлення і спричинити I/O-шторм.

3) Ідентифікувати заблоковані задачі (класична пастка «перезавантаження це фіксить»)

cr0x@server:~$ ps -eo pid,state,comm,wchan:32 | awk '$2 ~ /^D/ {print}'
21991 D kworker/u96:2      nvme_poll
18342 D postgres           io_schedule

Значення виводу: Процеси в незмінному сні (стан D), чекають на I/O-шляхи.

Рішення: Перезапуск сервісу не допоможе. Досліджуйте шляхи зберігання/NVMe/HBA/multipath. Якщо шлях I/O заклинює і ви можете переключитися на інший шлях, зробіть failover; інакше плануйте перезавантаження після зняття доказів.

4) Повідомлення ядра про збої зберігання або драйверів

cr0x@server:~$ sudo dmesg -T | tail -n 20
[Mon Jan 21 13:58:12 2026] nvme nvme0: I/O 47 QID 4 timeout, aborting
[Mon Jan 21 13:58:12 2026] nvme nvme0: Abort status: 0x371
[Mon Jan 21 13:58:13 2026] nvme nvme0: resetting controller
[Mon Jan 21 13:58:18 2026] nvme nvme0: failed to set APST feature (-19)

Значення виводу: Таймаути NVMe і скидання контролера; ядро повідомляє, що пристрій ненадійний.

Рішення: Перезавантаження може тимчасово відновити пристрій, але трактуйте це як апаратну/прошивну/драйверну роботу. Плануйте заміну або оновлення прошивки; не нормалізуйте щотижневі «сонні NVMe».

5) Затримки диска та насичення з iostat

cr0x@server:~$ iostat -x 1 3
Linux 6.5.0-21-generic (server) 	01/21/2026 	_x86_64_	(32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          7.89    0.00    2.34   66.85    0.00   22.92

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
nvme0n1         12.0   420.0   512.0  8752.0     43.1    198.4   451.2     9.8   462.5    2.1  99.7

Значення виводу: %util ~99.7 і await ~451ms: пристрій насичений і затримки жахливі.

Рішення: Перестаньте звинувачувати додаток. Зменшіть навантаження на запис, перемістіть «гарячі» дані або додайте IOPS-можливостей. Перезавантаження не змінить фізику.

6) Знайти, які файлові системи заповнені (старий міф «перезавантаження це вирішує»)

cr0x@server:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  220G  219G  1.2G 100% /
tmpfs            32G  1.2G   31G   4% /run

Значення виводу: Коренева FS фактично повна. Багато сервісів працюють дивно, коли не можуть писати логи або тимчасові файли.

Рішення: Негайно звільніть місце (логи, дампи пам’яті, старі артефакти). Перезавантаження не створить місця; воно лише може відкласти запис до ще гіршого моменту.

7) Швидко знайти великі директорії

cr0x@server:~$ sudo du -xhd1 /var | sort -h | tail -n 10
1.1G	/var/cache
2.9G	/var/lib
4.8G	/var/crash
58G	/var/log

Значення виводу: /var/log величезний; /var/crash вказує на повторні збої або core dumps.

Рішення: Ротувати/стиснути логи, перемістити їх за межі вузла, виправити цикл падінь. Розгляньте обмеження core dumps. Не перезавантажуйте, поки не зупините ріст.

8) Перевірка тиску пам’яті: чи ядро саме себе вбиває через reclaim?

cr0x@server:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:           64049       59721         811         922        3516        1920
Swap:           8192        6130        2062

Значення виводу: Низький available memory і значна активність swap. Машина, ймовірно, трешиться.

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

9) Хто зараз споживає пам’ять?

cr0x@server:~$ ps -eo pid,comm,rss --sort=-rss | head -n 10
  PID COMMAND           RSS
18342 postgres      9654320
22107 java          8421000
 9821 node          1320040

Значення виводу: Кілька процесів домінують у пам’яті. Це добра новина: цілеспрямований перезапуск може виправити без перезавантаження.

Рішення: Перезапустіть або переробіть топ-винуватця після підтвердження, що його безпечно перезапускати (HA, rolling restart, draining).

10) Стан systemd-сервісів та недавні збої

cr0x@server:~$ systemctl --failed
  UNIT                 LOAD   ACTIVE SUB    DESCRIPTION
● app-worker.service   loaded failed failed Background worker
● nginx.service        loaded failed failed A high performance web server

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

Значення виводу: Конкретні сервіси впали; це не обов’язково збій вузла.

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

11) Журнали systemd у вікні помилки

cr0x@server:~$ sudo journalctl -u nginx.service -S "10 minutes ago" --no-pager | tail -n 20
Jan 21 14:13:41 server nginx[29110]: nginx: [emerg] open() "/var/log/nginx/access.log" failed (28: No space left on device)
Jan 21 14:13:41 server systemd[1]: nginx.service: Main process exited, code=exited, status=1/FAILURE

Значення виводу: Явна причина: немає вільного місця на пристрої.

Рішення: Звільніть дисковий простір, потім перезапустіть nginx. Перезавантаження — марна трата часу і, швидше за все, нічого не змінить.

12) Мережеві пропуски та помилки (лічильники інтерфейсу)

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes  packets  errors  dropped  missed  mcast
    9876543210  12345678  0       48219    0       0
    TX:  bytes  packets  errors  dropped  carrier collsns
    8765432109  11223344  0       0        0       0

Значення виводу: RX drops високі. Це може означати проблеми з драйвером, ліміти кільця або завантаження вышестоячого комутатора.

Рішення: Досліджуйте налаштування NIC offload, розміри буферів, конкуренцію CPU на хості або перевантаження upstream-комутатора. Перезавантаження може обнулити лічильники і тимчасово «полагодити» заклинений драйвер, але вам потрібна причинність.

13) Саніті-перевірка DNS (швидка перевірка для «все зламалося»)

cr0x@server:~$ resolvectl query api.internal
api.internal: resolve call failed: Timeout was reached

Значення виводу: Таймаути DNS. Це часто маскується під відмову додатка в багатьох сервісах.

Рішення: Не перезавантажуйте світ. Виправте DNS або шлях резолвера. Розгляньте локальний кеш резолвера або резервні резолвери.

14) Стан файлової системи: помилки ext4 в логах

cr0x@server:~$ sudo dmesg -T | grep -E "EXT4-fs error|I/O error|Buffer I/O" | tail -n 5
[Mon Jan 21 14:01:12 2026] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1587: inode #131081: comm nginx: reading directory lblock 0
[Mon Jan 21 14:01:12 2026] Buffer I/O error on dev nvme0n1p2, logical block 9123456, lost async page write

Значення виводу: Реальні помилки файлової системи та I/O. Це не баг додатка.

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

15) Стан пулу ZFS (якщо ви використовуєте ZFS — дивіться обов’язково)

cr0x@server:~$ sudo zpool status -x
pool 'tank' is degraded
One or more devices could not be used because the label is missing or invalid.

Значення виводу: Пул деградований; зменшена надлишковість.

Рішення: Не перезавантажуйте необачно. Перезавантаження може запустити resilvering і піки I/O. Замініть/виправте відсутній пристрій або заплануйте контрольоване технічне вікно з обмеженнями I/O.

16) Multipath flapping (SAN-середовища люблять «вилікуватися» після reboot)

cr0x@server:~$ sudo multipath -ll | head -n 25
mpatha (3600508b400105e210000900000490000) dm-2 DELL,MD36xxi
size=2.0T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 3:0:0:1 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 4:0:0:1 sdc 8:32 active ready running

Значення виводу: Шляхи існують з різними пріоритетами (ALUA). Якщо ви бачите «failed faulty running» або шляхи переключаються — у вас проблема з fabric/контролером.

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

17) Перед перезавантаженням: збережіть легкий інцидентний бандл

cr0x@server:~$ sudo sh -c 'date; uname -a; uptime; free -m; df -h; dmesg -T | tail -n 200' > /var/tmp/pre-reboot-triage.txt

Значення виводу: Ви зберегли базовий стан, який перезавантаження зітре (особливо хвіст dmesg і знімки ресурсів).

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

Три корпоративні міні-історії з ери кнопки скидання

Міні-історія 1: Інцидент через хибне припущення

Команда мала кластер application-серверів за балансувальником. Кожен вузол мав локальний NVMe для епемерного кешування, а реальна система запису була віддаленою базою даних. Ментальна модель була: «локальний диск — лише кеш; якщо він помре, ми перезавантажимо і все повернеться».

Одного дня рівень помилок піднявся чистою діагоналлю. Затримка зросла, але лише для підмножини запитів. On-call перезапустив сервіс. Без змін. Перезавантажили вузол. Він швидко повернувся і виглядав здоровим п’ять хвилин, потім знову деградував. Перезавантажили ще два вузли. Та сама історія, але тепер з більше видимим для клієнтів тряском.

Хибне припущення було тонке: локальний NVMe не був просто кешем. Він містив журнал write-ahead для вихідних подій, призначений витримувати перезапуски процесу та короткі мережеві збої. Перезавантаження стерло журнал, бо він лежав у tmpfs, що був «тимчасовим за дизайном». На практиці — тимчасовим випадково.

Коли upstream колектор подій сповільнився, журнал заповнився і додаток застосував backpressure. Це було правильна поведінка. Але перезавантаження стерло журнал і створило ілюзію відновлення — поки повільний шлях не заповнив його знову. Тим часом стертий журнал означав втрачені події, які викликали повторні спроби пізніше і продовжили хвіст інциденту.

Вони вирішили це, перемістивши журнал на персистентне сховище (з чіткими правилами життєвого циклу), додавши алерти на глибину журналу і змінивши рунибуки: «ніколи не перезавантажувати, щоб очистити backpressure, якщо ви не погоджуєтесь на втрату даних». Кнопка скидання не спричинила вузьке місце. Вона зробила вузьке місце нечесним.

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

Група платформ вирішила зменшити час перезавантаження для флоту вузлів. Швидші перезавантаження означали швидші патчі, швидші евакуації і менший ризик простоїв. Тому вони оптимізували завантаження: паралелізували старт, зменшили логування, обрізали «повільні» перевірки і вимкнули сканування зберігання, яке «ніколи нічого не знаходило».

Тижнями це виглядало як перемога. Час перезавантаження впав з хвилин до менше хвилини. Вікна змін стали коротшими. Люди перестали боятися оновлень ядра. Кнопка скидання стала безпечнішою, отже її вживали частіше.

Потім один вузол перезавантажився під час рутинного патчу і повернувся з деградованим дзеркалом зберігання. Ніхто не помітив, бо сканування, яке б про це «закричало», було вимкнене. Вузол повернувся в пул і поновив робоче навантаження. Під навантаженням залишившийся диск почав кидати періодичні помилки. Рівні додатка бачили таймаути і робили повторні спроби. Повторні спроби створили більше навантаження. Класична позитивна петля зворотного зв’язку.

Коли хтось перевірив здоров’я зберігання, вузол був у спіралі відмов: обробка помилок породжувала більше I/O, ніж робота. Вони видалили вузол з ротації і вивчили історію апаратури. «Повільне» сканування ловило ранні ознаки проблем дисків. Вони обміняли надійність на кращий показник секундоміра.

Виправлення не полягало у відмові від оптимізації; воно полягало в розумінні того, що вони вимкнули. Вони відновили перевірки здоров’я, зробили їх асинхронними де можливо і заблокували приєднання вузла до кластера, поки він не пройде їх. Швидке перезавантаження — це добре. Швидке перезавантаження в зламане зберігання — це просто швидший спосіб нашкодити собі.

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

Інша компанія, інша культура. Команда платформи мала ритуал, який називала «знімки перед померевністю». Це було не модно: перед будь-яким руйнівним пом’якшенням (перезавантаження, failover, rolling restart) вони запускали невеликий набір команд і кидали вивід у тікет інциденту.

Під час інциденту один вузол почав скидати запити без очевидного шаблону. CPU був у нормі. Пам’ять — нормальна. Логи сервісу не допомагали. Всі хотіли перезавантажити, бо це був найшвидший спосіб припинити біль.

On-call все одно дотримався нудної практики. Він зібрав хвіст dmesg, iostat і лічильники інтерфейсу. dmesg показав випадкові скидання NIC. Лічильники інтерфейсу — зростання RX drops. iostat був чистий. Ця доказова база змінила рішення: замість безлічі перезавантажень вони злили вузол і замінили конфігурацію NIC (віртуальна функція в цьому випадку). Також налаштували affinity переривань на хості.

Вузол повернувся в сервіс без жодного перезавантаження. Більш того, команда не витратила години на «виліковування» мережевої проблеми скиданнями, які тимчасово очищали лічильники і скидають стан драйвера. Звичка робити нудні знімки не лише врятувала день; вона зберегла оповідання. Постмортем мав докази, а не фольклор.

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

1) «Перезавантаження виправило» стає заголовком тікета

Симптом: Інцидент завершується після перезавантаження; подальші дії відсутні.

Корінна причина: Докази знищені; організаційна амнезія. Система залишається крихкою.

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

2) Перезапуски сервісів у зацикленні

Симптом: systemd показує флап сервісу; він перезапускається кожні кілька секунд.

Корінна причина: Зовнішня залежність впала (DNS, БД, диск повний), помилка конфігурації або права доступу.

Виправлення: Використовуйте journalctl -u, щоб знайти першу помилку; виправте залежність. Перезапуски — не відновлення, якщо причина детермінована.

3) «Це CPU», бо зросла load average

Симптом: Load average піднімається; інженери вважають, що обчислювальні ресурси вичерпані.

Корінна причина: Load включає runnable та uninterruptible tasks. I/O waits можуть надути load при низькому використанні CPU.

Виправлення: Перевірте iowait в top/iostat і шукайте процеси в стані D. Якщо iowait високий — трактуйте як проблему шляху зберігання.

4) Перезавантаження бази даних під час I/O-інциденту

Симптом: Затримки бази даних зростають; перезавантаження «допомагає» недовго; потім гірше.

Корінна причина: Насичення зберігання або помилки пристрою; перезавантаження тригерить відновлення, відтворює WAL, «гріє» кеш з нуля і збільшує I/O.

Виправлення: Зменшіть write amplification, зупиніть важкі джоби, перемістіть «гарячі» дані, обмежте compaction/checkpoint, виправте зберігання. Перезавантажуйте лише після containment.

5) Power-cycle ховає диск, що відмирає

Симптом: Періодичні I/O-завіси; power-cycle відновлює сервіс на дні.

Корінна причина: Баг прошивки контролера або деградуюча поверхня диска; скидання очищає стан помилок тимчасово.

Виправлення: Корелюйте помилки dmesg зі SMART-статусом або деградацією пулу; замініть апарат, оновіть прошивку, перевірте кабелі/бэкплейн.

6) Очищення кешу «вирішує» продуктивність

Симптом: Після перезавантаження затримка різко кращає, потім поступово погіршується.

Корінна причина: Забруднення кешу, фрагментація, витік пам’яті або необмежена кардинальність (наприклад, кеші на орендаря).

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

7) Перезавантаження вузла Kubernetes спричиняє каскадне переміщення

Симптом: Перезавантаження одного вузла викликає кластерний сплеск затримок.

Корінна причина: Відсутні Pod Disruption Budgets, надто мало запасної потужності, агресивне autoscaling або важкі stateful робочі навантаження перенаправляються одночасно.

Виправлення: Коректно дренуйте, застосовуйте PDB, тримайте запас потужності і обмежуйте темп rollouts. Перезавантаження — ок; натовпи — ні.

8) Трактування мережевих таймаутів як багів додатка

Симптом: Випадкові таймаути по сервісах; перезавантаження деяких вузлів «допомагає».

Корінна причина: Проблеми резолвера DNS, втрати пакетів, виснаження conntrack або невідповідність MTU.

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

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

Чеклист A: Перед тим, як натиснути скидання (продакшен)

1. Підтвердьте масштаб: один вузол vs флот vs залежність.
2. Збережіть мінімальний форензичний бандл: uptime, знімок top, iostat, df -h, хвіст dmesg, збої сервісів.
3. Перевірте здоров’я зберігання: помилки в dmesg, стан пулу/RAID, насичення пристрою.
4. Перевірте базові мережеві речі: пропуски інтерфейсу, резолюцію DNS, таблиці маршрутів якщо релевантно.
5. Оберіть найменше пом’якшення: перезапуск сервісу → перезавантаження вузла → power-cycle.
6. Сплануйте вплив на клієнтів: дренуйте трафік, ізолюйте вузол, зробіть failover якщо можливо.
7. Комунікуйте: «Міграція: перезавантаження; мета — відновлення. Докази зібрані. Наступний крок — коренева причина.»

Чеклист B: Контрольоване перезавантаження в кластері (безпечно)

1. Кордонуйте/здрейніть вузол (або видаліть його з балансувальника).
2. Підтвердіть, що стан stateful робочого навантаження безпечний (реплікація здорова, немає rebuild у процесі).
3. Перезавантажте один раз. Якщо не допомогло — не робіть цього знову без аналізу.
4. Після повернення підтвердіть health checks і ключові метрики перед поверненням трафіку.
5. Слідкуйте за ефектами «прогріву кешу» і синхронними відновленнями.

Чеклист C: Після скидання (перетворіть це на навчання)

1. Порівняйте ключові метрики: затримка, рівень помилок, iowait, пропуски, використання пам’яті до/після.
2. Висуньте гіпотезу: «Перезавантаження допомогло, бо скинуто драйвер X» — це початок, а не кінець.
3. Зробіть одне зміцнення: алерт, ліміт, тест або оновлення. Одне правило за інцидент достатнє, щоб накопичувати покращення з часом.
4. Оновіть рунибук: включіть точні команди і правило прийняття рішень, яке спрацювало.

Питання та відповіді

1) Чи завжди шкідливо перезавантажувати сервер у продакшені?

Ні. Неконтрольоване перезавантаження — шкідливе. Контрольоване перезавантаження — після дренування трафіку і збору доказів — легітимне пом’якшення, особливо для стану ядра/драйвера.

2) Чому перезавантаження «фіксує» те, що не вдається відтворити?

Бо багато відмов — це емерджентний стан: витоки, фрагментація, накопичення черг або заклинені пристрої. Скидання обнуляє цей стан. Це не пояснює причину.

3) Перезапустити сервіс чи перезавантажити вузол?

Перезапуск сервісу, якщо вузол виглядає здоровим (немає iowait-шторма, купи процесів у D-state, немає помилок ядра). Перезавантажуйте вузол, коли підозрюєте проблеми ядра/драйвера/шляху I/O.

4) Що найважливіше зробити перед перезавантаженням?

Зберегти докази ядра і ресурсу: хвіст dmesg, iostat, top, df -h і відповідні логи сервісів. Якщо ви перезавантажите без цього — ви обираєте невідомість.

5) Як зрозуміти, що вузьке місце — диск I/O?

Шукайте високий iowait у top, високі await і %util у iostat -x і процеси в стані D, що чекають I/O.

6) Чи може перезавантаження погіршити інцидент зберігання?

Так. Перезавантаження може запустити rebuild/resilver, холодне кешування, повтори журналу і хвилі перепідключень до спільного зберігання. Спершу стабілізуйте, потім перезавантажуйте з наміром.

7) У Kubernetes чи допустимо перезавантажувати вузол?

Так, якщо ви cordon/дренуєте правильно, поважаєте Pod Disruption Budgets і тримаєте запас потужності в кластері. Обробляйте перезавантаження вузла як rolling upgrade, а не сюрприз.

8) Чому при мережевих проблемах «працює після перезавантаження»?

Бо перезавантаження скидає таблиці conntrack, очищає тимчасові стани драйвера і змушує оновити DNS і TCP-сесії. Саме тому воно маскує реальний дефект мережі.

9) Як зменшити залежність від скидань?

Додайте ліміти (пам’ять, диск, глибина черг), розширте спостережуваність (розбивка затримок по шарах) і зробіть відомі режими відмов самовиліковними (health checks, що перезапускають потрібний компонент, а не весь вузол).

10) Чи варто автоматизувати перезавантаження через watchdog?

Іноді так. Для одноцільових аплайенсів та edge-вузлів watchdog може бути коректним рішенням. Для складних stateful-систем автоматичне перезавантаження без збору доказів і обмежень частоти — це хороший спосіб стерти єдині підказки, що у вас були.

Висновок: наступні кроки, що зменшують «перезавантаження як стиль життя»

Ера кнопки скидання — не про стид. Вона про ясність. Скидання чесні тим, що визнають: система накопичила стан, який важко осмислити під тиском. Вони нечесні тим, що стирають сліди, якщо ви навмисно їх не зберегли.

Якщо ви керуєте продакшен-системами, зробіть три кроки вже цього тижня:

1. Стандартизувати передперезавантажувальний бандл (п’ять команд, один файл, завжди доданий до інциденту).
2. Прийняти правило «найменшого молотка» (перезапуск сервісу перед перезавантаженням; перезавантаження перед power-cycle; failover перед реконструкцією).
3. Перетворювати кожне успішне скидання на гіпотезу, яку можна протестувати: зберігання, мережа, пам’ять, ядро або залежність. Потім зміцніть одну слабку ланку.

Перезавантаження — це не провал. Перезавантаження без навчання — ось що провал.