Трюк «чистого завантаження»: виявіть проблемний додаток менше ніж за 10 хвилин

Що насправді означає «чисте завантаження» (і чого воно не робить)

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

У термінах продакшену це бінарний пошук у вашому середовищі під час завантаження та після входу в систему.

Чисте завантаження швидко відповідає на три питання

1. Чи хворий рівень ОС/драйверів? Якщо проблема зберігається при мінімальному завантаженні, підозрюйте kernel-драйвери, файлову систему, апаратне забезпечення або базову конфігурацію ОС.
2. Чи це проблема рівня сервісів? Якщо мінімальне завантаження нормальне, а звичайне — ні, підозрюйте сервіси, планувальники завдань, елементи автозапуску та агентське ПЗ.
3. Чи це специфічно для користувача? Якщо трапляється тільки для одного користувача, перевіряйте елементи автозапуску для користувача, скрипти ініціалізації shell, автозапуск робочого столу та user-сервіси.

Чого не є чисте завантаження

• Не є ліками. Це техніка діагностики та ізоляції. Якщо на цьому зупинитися, проблема повернеться, щойно ви «відновите все».
• Не дає права на хаотичне видалення. Видалення випадкових додатків — шлях до другого інциденту: «чому VPN тепер не працює?»
• Не тільки для десктопів. Сервери теж мають «елементи автозапуску» — вони просто називаються unit-файлами, cron-завданнями, init-скриптами та сайдкар-агентами.

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

Швидкий план діагностики: перша/друга/третя перевірки

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

Перше: визначте домінантну ресурсну проблему (30–90 секунд)

• CPU завантажений? Шукайте один або кілька процесів, які їдять ядра.
• Диск повільний? Перевірте високе читання/запис і глибину черги; багато «повільних завантажень» насправді — «повільне сховище».
• Тиск пам’яті? Свопінг під час завантаження робить усе виглядає зламаним.
• Зависання мережі? DNS або captive portal можуть зупиняти сервіси, які «дбайливо» блокують старт.

Друге: розділіть регресії під час завантаження і після входу (1–2 хвилини)

• Повільне під час завантаження: критичний ланцюг systemd, ініціалізація драйверів, перевірки файлової системи, зашифровані томи, таймаути DHCP.
• Повільне після входу: сервіси користувача, автозапуск програм робочого столу, клієнти синхронізації, endpoint-агенти, відновлення сеансів браузера.

Третє: зробіть мінімальне завантаження і порівняйте (3–6 хвилин)

• Якщо мінімальне завантаження чисте: винуватець — неосновний сервіс/агент/додаток.
• Якщо мінімальне завантаження все ще погане: підозрюйте оновлення ОС, kernel-модулі, проблеми ФС, апаратне забезпечення або базову конфігурацію.

Потім ви бісектуєте: вмикаєте половину підозрюваних, перезавантажуєте (або перезапускаєте сесію користувача), спостерігаєте. Повторюєте. Ви знайдете кривдника швидше, ніж «вимиканням по одному» і з меншим побічним ефектом.

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

Цікаві факти і історія: чому це працює

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

1. Ранній Unix-завантаження фактично був скриптом. SysV init використовував послідовні shell-скрипти в /etc/rc*, тому «відключити елементи автозапуску» означало перейменувати симв’язок. Ідея передує більшості сьогоднішніх стеків ПЗ.
2. Windows популяризував термін «clean boot». Ідею формалізували для ізоляції сторонніх сервісів і автозапусків без переходу в повний Safe Mode.
3. systemd зробив вимірюваним час завантаження. Завдяки systemd-analyze ви можете кількісно визначити «що стало повільнішим», а не сперечатися через відчуття.
4. Час завантаження часто блокується таймаутами. Очікування мережі, помилки DNS і відсутні монтування можуть додати по 30–120 секунд кожен. Один неправильний unit може домінувати у таймлайні.
5. Агенти безпеки кінцевих точок частіше винні. Вони підключаються до шляхів файлової системи та мережі, тому їх «невеликий оверхед» стає величезним під час бурних стартових подій.
6. Стан SSD впливає на завантаження підступно. Диск з високою затримкою через вирівнювання зносу або помилки може змусити CPU «виглядати зайнятим», поки він фактично чекає на I/O.
7. Оновлення BIOS/UEFI і прошивки змінили правила гри. Сучасні «проблеми із завантаженням» можуть починатися ще до ОС, особливо коли Secure Boot, TPM або прошивка контролера зберігання поводяться некоректно.
8. Наліплення автозапусків — це інституційна проблема, не персональна. Підприємства розгортають агенти для VPN, DLP, EDR, моніторингу, чату та синхронізації. Кожен з них окремо є обґрунтованим; разом вони — трагедія.
9. Бінарний пошук перемагає лінійний пошук. Якщо у вас 32 елементи автозапуску, відключати по одному — 32 цикли. Бісекція знаходить кривдника приблизно за ~5 циклів.

Жарт #1: Налагодження під час завантаження схоже на археологію — кожен відкритий шар приховує інший шар, і якось усе покрите пилом від 2017 року.

Метод за менше ніж 10 хвилин (практичний потік)

Ось робочий процес, який я застосовую, коли хтось каже «все повільно», маючи на увазі «мій день зруйновано». Це передбачає Linux робочий стіл/сервер із systemd, але логіка добре відображається на macOS launch agents і Windows services.

Хвилина 0–1: зафіксуйте симптом у вимірюваних термінах

• «Завантаження до запиту входу займає 2 хвилини замість 25 секунд.»
• «Після входу CPU на 400% протягом 5 хвилин.»
• «Індикатор диска весь час горить; відкриття терміналу займає 20 секунд.»

Не пропускайте це. Без базової вимірювальної заяви ви «виправите» щось і все одно не знатимете, чи стало краще.

Хвилина 1–3: визначте, чи це конвеєр завантаження чи пост-логін

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

Хвилина 3–6: виконайте чисте завантаження

На systemd-системах найшвидший «чистий» старт — використовувати більш мінімальну ціль (multi-user без GUI), плюс тимчасове відключення неважливих сервісів. Також можна завантажитись з іншим kernel-entry або додати kernel-параметри, але спочатку зробіть простіше.

Хвилина 6–10: бісектуйте і виявляйте кривдника

Знову увімкніть половину відключених сервісів/елементів автозапуску і перевірте, чи повернувся симптом. Якщо так — кривдник у цій половині. Якщо ні — в іншій. Повторюйте.

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

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

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

Завдання 1: Перевірте, чи це CPU, пам’ять або I/O (top)

cr0x@server:~$ top -b -n 1 | head -n 20
top - 10:12:01 up  5:21,  1 user,  load average: 6.12, 5.90, 4.80
Tasks: 312 total,   3 running, 309 sleeping,   0 stopped,   0 zombie
%Cpu(s): 18.0 us,  4.0 sy,  0.0 ni, 72.0 id,  6.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  15948.5 total,    412.3 free,  11200.1 used,   4336.1 buff/cache
MiB Swap:   2048.0 total,   1800.0 free,    248.0 used.   3200.0 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 2345 root      20   0  167834  62120  13124 R  180.0   0.4   3:12.41 updatedb
 1988 root      20   0  912340  84212  30124 S   60.0   0.5   1:22.10 falcon-sensor

Що це означає: Тут CPU активний, але зверніть увагу на wa (I/O wait) 6%. Це не катастрофа, але натякає, що диск частково причетний. Список процесів показує updatedb і агент кінцевої точки, що працює.

Рішення: Якщо один процес домінує CPU — перевірте його першим. Якщо I/O wait високий (>15–20% стабільно) — переходьте до інструментів I/O (Завдання 3–5).

Завдання 2: Перевірте тиск пам’яті і своп (free)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi        11Gi       420Mi       1.2Gi       3.6Gi       3.1Gi
Swap:          2.0Gi       248Mi       1.8Gi

Що це означає: Низький «free» не обов’язково погано; важливе поле — «available». Якщо available малий і використання swap швидко зростає після завантаження, маєте тиск пам’яті.

Рішення: Якщо «available» менше ~10% від RAM і swap зростає, перестаньте звинувачувати «стартап-додатки» і почніть знаходити пам’ятєві гіганти (Завдання 6) або зменшувати сервіси.

Завдання 3: Знайдіть топ записувачів/читачів диска (iotop)

cr0x@server:~$ sudo iotop -o -b -n 3
Total DISK READ: 12.34 M/s | Total DISK WRITE: 48.91 M/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
 2345 be/4  root      0.00 B/s   35.12 M/s  0.00 %  12.45 %   updatedb.mlocate
 1988 be/4  root      1.20 M/s   10.50 M/s  0.00 %   8.90 %   falcon-sensor

Що це означає: У вас явний топ-риwriter. Високий IO> означає, що потік багато часу чекає на I/O.

Рішення: Якщо заплановане завдання (updatedb, індексація, антивірусний скан) б’є по диску під час входу — перемістіть його на інший час або виключіть каталоги. Якщо це агент — перевірте його політику й логи (Завдання 10–12).

Завдання 4: Підтвердіть затримки диска і черги (iostat)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0-21-generic (server) 	02/05/2026 	_x86_64_	(8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          20.12    0.00    5.01   18.22    0.00   56.65

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz aqu-sz  %util
nvme0n1         12.0    1024.0     0.0    0.0   25.10    85.3    210.0   45120.0     3.0    1.4   38.40   214.9   8.20   99.0

Що це означає: %util близько 99% і високе await вказують на насичення пристрою. Навіть «швидке» NVMe може страждати від важких дрібних записів або проблем з прошивкою/термообмеженнями.

Рішення: Якщо диск насичений, чисте завантаження не вирішить проблему, якщо винуватець у базовій ОС (шторм журналювання, помилки ФС, swap). Знайдіть процеси, які генерують I/O (Завдання 3), і перевірте стан сховища (Завдання 5).

Завдання 5: Перевірте стан диска і лічильники помилок (smartctl)

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | egrep -i 'critical_warning|media_errors|num_err_log_entries|temperature|percentage_used'
Critical Warning:                   0x00
Temperature:                       71 Celsius
Percentage Used:                   78%
Media and Data Integrity Errors:   12
Error Information Log Entries:     144

Що це означає: Гарячий диск з ненульовими помилками media/integrity — поганий знак. «Percentage Used» близько кінця ресурсу може корелювати зі стрибками затримки.

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

Завдання 6: Швидко знайдіть пам’ятевий гігант (ps)

cr0x@server:~$ ps -eo pid,comm,rss,%mem --sort=-rss | head
  PID COMMAND           RSS %MEM
 4121 chrome          1854320 11.3
 1988 falcon-sensor    512300  3.1
 2770 tracker-miner    402112  2.4

Що це означає: Resident set size (RSS) показує, хто займає пам’ять. Браузери часто винні, але іноді вони такі через те, що щось інше загальмувало систему і браузер накопичив стан.

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

Завдання 7: Визначте повільні systemd-юнити (systemd-analyze blame)

cr0x@server:~$ systemd-analyze blame | head -n 15
38.221s network-online.target
21.104s docker.service
12.880s snapd.service
10.512s systemd-journal-flush.service
 8.402s dev-sda2.device

Що це означає: Це ранжує юніти за витраченим часом. Воно не ідеальне (існує паралелізм), але відмінне для первинної орієнтації.

Рішення: Якщо network-online.target повільний — підозрюйте DHCP/DNS або сервіс, що чекає «онлайн», коли це не потрібно. Якщо Docker/snapd повільні — ви можете платити за образи, монтування або фонове оновлення.

Завдання 8: Подивіться критичний шлях завантаження (systemd-analyze critical-chain)

cr0x@server:~$ systemd-analyze critical-chain
graphical.target @1min 20.532s
└─multi-user.target @1min 20.532s
  └─docker.service @58.102s +21.104s
    └─network-online.target @36.900s +21.201s
      └─NetworkManager-wait-online.service @15.702s +21.190s
        └─NetworkManager.service @4.120s +11.550s
          └─dbus.service @4.090s

Що це означає: Показує ланцюжок залежностей і де накопичується час.

Рішення: Якщо wait-online сервіс блокує завантаження — вирішіть, чи дійсно він потрібен. Багато сервісів можуть стартувати, коли мережа стане доступною пізніше. Для десктопів чекати «онлайн» часто шкідливо.

Завдання 9: Перелік увімкнених сервісів (systemctl)

cr0x@server:~$ systemctl list-unit-files --type=service --state=enabled | head -n 25
UNIT FILE                                  STATE   PRESET
NetworkManager.service                     enabled enabled
docker.service                             enabled disabled
snapd.service                              enabled enabled
falcon-sensor.service                      enabled enabled
cups.service                               enabled enabled

Що це означає: Enabled означає, що він стартуватиме під час завантаження або при тригері.

Рішення: Позначте кандидатів для чистого завантаження: сторонні агенти, движки контейнерів на ноутбуках, індексатори, служби друку на серверах — усе, що не є критичним для ролі.

Завдання 10: Тимчасово відключити сервіс (безпечний і відновлюваний)

cr0x@server:~$ sudo systemctl disable --now docker.service
Removed "/etc/systemd/system/multi-user.target.wants/docker.service".

Що це означає: Сервіс не стартуватиме автоматично і зупинено зараз.

Рішення: Перезавантажте і виміряйте. Якщо поведінка покращилася — маєте сильного підозрюваного. Якщо нічого не змінилося — увімкніть назад і рухайтесь далі.

Завдання 11: Замаскуйте сервіс, який постійно повертається (жорстка зупинка)

cr0x@server:~$ sudo systemctl mask --now snapd.service
Created symlink /etc/systemd/system/snapd.service → /dev/null.

Що це означає: Маскування заважає ручним або залежнісним запускам. Це сильніше, ніж disable.

Рішення: Використовуйте маскування, коли сервіс активується сокетом або його постійно тригерить інший процес. Документуйте це; маскування дивує майбутнього вас.

Завдання 12: Читайте логи для конкретного завантаження (journalctl)

cr0x@server:~$ journalctl -b -p warning..alert --no-pager | tail -n 30
Feb 05 10:02:33 server kernel: nvme nvme0: I/O 17 QID 1 timeout, aborting
Feb 05 10:02:34 server systemd[1]: NetworkManager-wait-online.service: start operation timed out. Terminating.
Feb 05 10:02:34 server systemd[1]: Failed to start Network Manager Wait Online.

Що це означає: Таймаути сховища та очікування мережі не «випадкові». Це великі червоні стрілки.

Рішення: Таймаути NVMe: підозрюйте прошивку/стан диска/термічні проблеми (Завдання 5) або питання управління енергоспоживанням. Таймаути мережі: приберіть залежність від online target, виправте DHCP/DNS або зменшіть таймаут.

Завдання 13: Перевірте, що змінилося останнім часом (історія пакетів)

cr0x@server:~$ grep -E " upgrade | install " /var/log/dpkg.log | tail -n 10
2026-02-04 18:22:11 upgrade linux-image-6.5.0-21-generic:amd64 6.5.0-20.20 6.5.0-21.21
2026-02-04 18:22:15 upgrade network-manager:amd64 1.44.2-1ubuntu1 1.44.2-1ubuntu2
2026-02-04 18:22:17 install falcon-sensor:amd64 7.12.0-1 7.12.0-1

Що це означає: Якщо продуктивність впала «вчора», це дає вам кандидатів без покладання на пам’ять, яка відомо ненадійна.

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

Завдання 14: Перевірте автозапуски на рівні користувача (агностичне для середовища робочого столу)

cr0x@server:~$ ls -1 ~/.config/autostart 2>/dev/null | head
com.slack.Slack.desktop
dropbox.desktop
teams.desktop

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

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

Завдання 15: Перевірте фонві таймери та cron-подібні завдання (systemd timers)

cr0x@server:~$ systemctl list-timers --all | head -n 20
NEXT                         LEFT          LAST                         PASSED       UNIT                         ACTIVATES
Thu 2026-02-05 10:30:00 UTC  12min left    Thu 2026-02-05 10:00:00 UTC  18min ago    updatedb.timer               updatedb.service
Thu 2026-02-05 11:00:00 UTC  42min left    Thu 2026-02-05 09:00:00 UTC  1h 18min ago snapd.refresh.timer          snapd.service

Що це означає: «Мій ноутбук непридатний після входу» може бути через таймер, який спрацьовує відразу після завантаження.

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

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

cr0x@server:~$ systemctl show -p WantedBy,RequiredBy,After,Requires docker.service
WantedBy=multi-user.target
RequiredBy=
After=network-online.target containerd.service
Requires=containerd.service

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

Рішення: Якщо юніт «припхнутий» іншою залежністю, відключення може бути недостатнім; виправте батьківські відносини або налаштуйте wants/requires в файлах override.

Жарт #2: Єдина річ, що стартує швидше за поганого стартового агента — це зустріч, де хтось питає, навіщо він встановлений.

Три корпоративні міні-історії (як це йде неправильно і правильно)

Міні-історія 1: Інцидент, спричинений неправильною гіпотезою

Проблема почалася як стандартна скарга: «Ноутбуки інженерів повільні після rollout нового VPN». Хелпдеск зробив те, що роблять хелпдески — перевстановив кілька систем, поміняв док-станції, звинуватив Wi‑Fi. Нічого не допомогло.

Один SRE нарешті поставився до цього як до продакшен-інциденту: спочатку виміряли, потім ізолювали. Чисте завантаження (мінімальні сервіси, без сторонніх агентів) повернуло машини до нормального стану. Це відразу спростувало припущення, що «образ ОС занадто важкий» або «залізо старе». Проблема була в доповненнях.

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

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

Міні-історія 2: Оптимізація, яка вдарила в спину

Команда платформи захотіла швидших завантажень на лабораторних серверах. Хтось помітив, що journald flush і перевірки файлової системи займають час. Вони «оптимізували», змінивши стійкість логування і послабивши деякі перевірки монтування. Завантаження виглядали швидшими — на дашбордах.

Потім стався інцидент: періодичні відмови додатків після перезавантаження, без очевидної причини. Команда отримала менше логів (бо вони не так зберігалися), і коли вузол мав глюк сховища, послаблені перевірки дозволяли йому піднятися «ніби нормально», тоді як його ФС тихо була в поганому стані. Затримки зросли, завантаження образів Docker зависли, і on-call займався ворожінням на основі залишків інформації.

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

Відкат виправив ситуацію. Вони повторно ввели роботу з продуктивності правильно: зберегли перевірки цілісності, зберегли корисні логи, і натомість зосередилися на зменшенні непотрібних wait-online та відключенні неважливих сервісів для тієї ролі сервера. Мораль: зрізати секунди завантаження, прибираючи спостережуваність — як зменшувати вагу, знімаючи парашут.

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

У фінансовому відділі був парк десктопів з передбачуваним навантаженням: таблиці, вкладки браузера і інколи VPN. IT-команда мала звичку, яка ніколи не отримувала нагород: вони вели письмовий «базовий набір запуску» для стандартного образу — які сервіси були ввімкнені, які автозапуски дозволені, і які таймери працюють коли.

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

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

Виправлення теж було нудним: відкласти запуск клієнта, додати виключення для великих директорій збірки та обмежити паралельність. День врятовано не блиском, а базовою практикою і повторюваним workflow чистого завантаження.

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

Тут більшість команд марнують час. Не тому, що проблема складна, а тому, що метод налагодження недбалий.

1) Симптом: «Завантаження повільне» (але тільки після входу)

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

Виправлення: ізолюйте сервіси користувача і автозапуски; вимірюйте час до запиту входу і час до робочого столу окремо. Використайте Завдання 14 і вибірково видаляйте елементи з ~/.config/autostart. Поверніть їх пакетами.

2) Симптом: тривала пауза «A start job is running…»

Корінна причина: systemd-юнит чекає network-online, відсутній маунт або ланцюг залежностей з великим таймаутом.

Виправлення: запустіть systemd-analyze critical-chain (Завдання 8), потім приберіть непотрібні залежності від network-online.target або виправте маунт. Розгляньте зменшення wait-online таймаутів для десктопів.

3) Симптом: вентилятори крутяться, CPU «зайнятий», але все пригальмовує

Корінна причина: насичення диска I/O, що викликає CPU I/O wait; часто індексатор, антивірус/EDR-скан або шторм логування.

Виправлення: перевірте iostat (Завдання 4) і iotop (Завдання 3). Перенесіть важкі завдання (Завдання 15), налаштуйте політики агентів, додайте виключення або виправте апаратну проблему диска.

4) Симптом: випадкові зависання під час завантаження, помилки в логах

Корінна причина: таймаути сховища, ненадійний SSD, проблеми контролера або термотротлінг.

Виправлення: перевірте SMART (Завдання 5) і kernel-логи (Завдання 12). Якщо є помилки — сприймайте це як близьку відмову: робіть бекапи, плануйте заміну, зменшуйте навантаження, оновлюйте прошивку, якщо доречно.

5) Симптом: чисте завантаження все ще повільне

Корінна причина: це не проблема «додатку»; базова ОС, kernel, драйвер, ФС або апарат.

Виправлення: протестуйте попередній kernel, перевірте стан диска, помилки ФС і логі завантаження. Чисте завантаження — це фільтр; якщо воно нічого не покращує, припиніть полювання на користувацькі додатки.

6) Симптом: ви відключаєте сервіс, але він повертається

Корінна причина: socket activation, path activation, таймери або менеджмент-агент, що знову вмикає його.

Виправлення: знайдіть тригери за допомогою systemctl list-timers (Завдання 15) і залежності юнітів (Завдання 16). Тимчасово замаскуйте (Завдання 11) і координуйтеся з політикою управління пристроями.

7) Симптом: продуктивність нормальна, а потім деградує через 2–10 хвилин після завантаження

Корінна причина: таймери, що спрацьовують після завантаження (updatedb, snap refresh, telemetry upload) або відкладені стартові агенти.

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

8) Симптом: мережезалежні додатки зависають при старті

Корінна причина: затримки DNS, конфлікти split-DNS у VPN, captive portal або зламана конфігурація резолвера.

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

Контрольні списки / покроковий план

Чекліст A: План бісекції чистого завантаження (швидко і контрольовано)

1. Визначте відмову: запишіть час завантаження і/або час до робочого столу.
2. Виміряйте домінантний ресурс: CPU, пам’ять, диск, мережа (Завдання 1–4).
3. Зробіть знімок того, що ввімкнено: сервіси, таймери, автозапуски користувача (Завдання 9, 15, 14).
4. Виберіть мінімальний набір: залиште лише сервіси, потрібні для входу й віддаленого доступу.
5. Вимкніть підозрюваних двома партіями: не по одному. Користуйтесь disable/mask обережно (Завдання 10–11).
6. Перезавантажте і виміряйте: ті самі метрики щоразу.
7. Якщо стало краще: знову ввімкніть половину відключених елементів (бісекція) і повторюйте.
8. Коли відтворено: ізолюйте до одного юніта/додатка, потім підтвердіть, перемикаючи лише його.
9. Виправте правильно: конфігурація, розклад, виключення або деінсталяція з контролем змін.
10. Задокументуйте і створіть базу: зафіксуйте, що змінили і чому.

Чекліст B: Правила безпеки (уникайте самонанесених падінь)

• Не вимикайте віддалений доступ на віддаленій системі, якщо у вас немає консолі OOB.
• Краще disable ніж mask. Маскування — це молоток.
• Змінюйте одну «партію» за перезавантаження. Інакше неможливо атрибутувати ефект.
• Тримайте список відкату: що ви відключили, в якому порядку і як це повернути.

Чекліст C: Якщо підозрюєте сховище (ухил SRE/інженера зберігання)

1. Перевірте I/O wait у top і насичення у iostat.
2. Знайдіть I/O-кривдника через iotop.
3. Перевірте SMART на помилки/температуру.
4. Якщо є помилки: припиніть «тонування», почніть план заміни і забезпечте резервні копії.
5. Якщо помилок немає: налаштуйте кривдника (обсяг індексації, політики агента, об’єм логування), а не всю ОС.

FAQ

1) Чи «чисте завантаження» те саме, що Safe Mode?

Ні. Safe Mode зазвичай завантажує навмисно обмежений набір драйверів і сервісів для відновлення. Чисте завантаження — це діагностичний старт, який намагається зберегти систему придатною до роботи, виключивши сторонні та неважливі компоненти.

2) Як зрозуміти, чи проблема у драйвері/kernel чи в додатку?

Якщо проблема зберігається при мінімальному завантаженні (без GUI, мінімальні сервіси) і ви все ще бачите I/O таймаути, kernel-помилки або постійні стрибки затримки — підозрюйте драйвер/kernel/сховище/залізо. Якщо мінімальне завантаження чисте — майже завжди це сервіс/агент/елемент автозапуску.

3) Який найшвидший спосіб знайти, що уповільнює завантаження на systemd?

systemd-analyze blame і systemd-analyze critical-chain. Blame показує час на юніт; critical-chain показує залежності, що дійсно впливають на кінцевий шлях.

4) Чому «network-online.target» викликає так багато повільних завантажень?

Тому що «онлайн» — це сильніша обіцянка, ніж потрібно більшості програм, і часто реалізується через очікування DHCP, маршрутів і DNS. Якщо щось з цього повільне або заблоковане (VPN, captive portal, поганий DNS), ви платите податок таймаутів.

5) Чи можна зробити чисте завантаження без перезавантаження?

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

6) Що робити, якщо система управління пристроями знову вмикає сервіси, які я вимкнув?

Тоді ви налагоджуєте дві системи: ОС і політику управління. Маскування тимчасово завадить юніту стартувати, але координуйтеся з власником політики; інакше «фікс» відкотиться мовчки.

7) Як безпечно чисто завантажити віддалений сервер?

Не відключайте SSH або мережеві юніти, якщо у вас немає доступу до консолі поза мережею. Краще спочатку відключати тільки неядерні сервіси. Тримайте план відкату з таймером (хоча б другу сесію, готову відкотити зміни).

8) Який поширений «поганий додаток» на ноутбуках розробників?

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

9) Якщо винуватець — агент кінцевої точки, що робити?

Зазвичай: налаштувати політику (виключити каталоги збірки, node_modules, кеші), змінити розклад сканів і зменшити обсяг логування. Видаляти ПЗ без дозволу — рішення, що обмежує кар’єру.

10) Як уникнути цього в майбутньому?

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

Висновок: наступні кроки, які працюють

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

1. Запустіть швидкий план діагностики і вирішіть, який ресурс домінує.
2. Зробіть контрольоване чисте завантаження (мінімальні цілі + відключені підозрювані).
3. Бісектуйте, замість відключення по одному.
4. Виправте корінну причину: таймаути, розклад, виключення, ланцюги залежностей або відмовне сховище — а не забобони.
5. Напишіть базову конфігурацію для вашого середовища, щоб наступна регресія була швидким дифом, а не тижневим полюванням на привидів.

Якщо все зроблено правильно — ви ізолюєте проблемний додаток менше ніж за 10 хвилин. Якщо ні — ви все одно ізолюєте щось, зазвичай вашу довіру.