Модуль 6.1: Системне вирішення проблем

Вирішення проблем | Складність: [MEDIUM] | Час: 25–30 хв

Передумови

Перед початком цього модуля:

Обов’язково: Модуль 5.1: Метод USE
Бажано: Досвід роботи з реальними проблемами в продакшні.

Що ви зможете робити після цього модуля

Після завершення цього модуля ви зможете:

Застосувати науковий метод до відлагодження систем (спостерігати -> формулювати гіпотезу -> тестувати -> робити висновки)
Відтворити проблеми систематично та документувати знахідки для post-incident ревю
Класифікувати проблеми за серйозністю та визначити найшвидший шлях до вирішення
Уникати поширених антипатернів відлагодження (випадкові зміни, ігнорування доказів, пропуск відтворення)

Чому цей модуль важливий

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

Системне вирішення проблем допоможе вам:

Зменшити MTTR (Mean Time To Recovery) — середній час на відновлення.
Знаходити першопричини, а не просто лікувати симптоми.
Не робити гірше — випадкові зміни часто створюють нові проблеми.
Документувати для майбутнього — та сама проблема наступного разу не займе багато часу.

Найкращі фахівці не просто везучіші — вони більш методичні.

Чи знали ви?

Більшість проблем мають прості причини — переповнений диск, зупинений сервіс, помилка в конфігу. Екзотичні баги ядра зустрічаються рідко. Спочатку перевіряйте очевидне.
«Вчора воно працювало» — це головна підказка. Щось змінилося. Знайдіть зміну — знайдете причину. Перевірте деплої, зміни конфігів, оновлення системи.
Метод «гумової качечки» справді працює. Пояснення проблеми комусь іншому (навіть іграшці) змушує вас критично переглянути свої припущення. Багато багів знаходяться прямо під час пояснення.

Науковий метод вирішення проблем

┌─────────────────────────────────────────────────────────────┐
│                    НАУКОВИЙ МЕТОД                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. СПОСТЕРЕЖЕННЯ                                           │
│     │  Які симптоми? Яка реальна поведінка системи?         │
│     ▼                                                       │
│  2. ГІПОТЕЗА                                                │
│     │  Що могло це спричинити? Складіть список варіантів.   │
│     ▼                                                       │
│  3. ПРОГНОЗ                                                 │
│     │  Якщо гіпотеза Х вірна, що ми маємо побачити ще?      │
│     ▼                                                       │
│  4. ТЕСТУВАННЯ                                              │
│     │  Перевірте прогноз. Чи збігається він із реальністю?  │
│     ▼                                                       │
│  5. ВИСНОВОК                                                │
│     │  Гіпотеза підтверджена? Виправляйте.                  │
│     │  Відхилена? Переходьте до наступної гіпотези.         │
│     ▼                                                       │
│  6. ІТЕРАЦІЯ                                                │
│        Поверніться до кроку 2 з новими даними               │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Первинне сортування (Triage)

Перші 60 секунд на сервері

Швидка перевірка “здоров’я” системи:

# 1. Що відбувається зараз?
uptime                    # Навантаження та час роботи
dmesg | tail -20          # Повідомлення ядра
journalctl -p err -n 20   # Останні помилки

# 2. Стан ресурсів
free -h                   # Пам'ять
df -h                     # Диск
top -bn1 | head -15       # CPU та процеси

# 3. Мережевий стан
ss -tuln                  # Відкриті порти
ip addr                   # Інтерфейси

# 4. Що впало?
systemctl --failed        # Сервіси з помилками

Категорії проблем

Симптом	Можлива причина	З чого почати
”Не можу підключитися”	Мережа	`ping`, `ss`, `iptables`
”Все гальмує”	Продуктивність	`top`, `iostat`, `vmstat`
”Відмовлено у доступі”	Безпека	Права доступу, SELinux/AppArmor
”Сервіс не стартує”	Конфігурація	`systemctl status`, логи
”Немає місця”	Сховище	`df -h`, `du -sh /*`

Тест

Чому не варто відразу перезавантажувати сервіс, що впав?

Відповідь
Перезавантаження знищує діагностичну інформацію: вміст пам'яті, тимчасові файли, стан сокетів. Спочатку потрібно зняти лог і подивитися статус, щоб зрозуміти ПРИЧИНУ падіння, інакше воно повториться.
Яке головне питання потрібно поставити собі, коли система раптово зламалася?

Відповідь
"Що змінилося?". Системи, що стабільно працювали, рідко ламаються самі по собі. Шукайте нещодавні деплої, зміни конфігів або оновлення.
Що таке “розділяй і володарюй” (divide and conquer) у вирішенні проблем?

Відповідь
Це метод бінарного пошуку помилки. Перевірте середину шляху (наприклад, балансувальник). Якщо він працює — проблема далі. Якщо ні — раніше. Це відсікає 50% можливих причин одним тестом.
Яка команда в Linux показує всі сервіси, які не змогли запуститися?

Відповідь
`systemctl --failed`.

Практична вправа

Завдання: Навчитися збирати інформацію про “хвору” систему.

Запустіть свій скрипт “швидкої діагностики”:
Terminal window
```
uptime && free -h && df -h && systemctl --failed
```
Подивіться 10 останніх критичних помилок у системі:
Terminal window
```
journalctl -p err -n 10
```
Перевірте, чи не закінчилися іноди (inodes) на дисках:
Terminal window
```
df -i
```
Знайдіть процеси, що споживають найбільше пам’яті:
Terminal window
```
ps aux --sort=-%mem | head -n 5
```

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

Підсумок

Методика краща за вгадування.
Зберіть дані, перш ніж діяти.
Що змінилося? — ключ до 90% розгадок.
Документуйте свої кроки, щоб не ходити колами.

Далі: Модуль 6.2: Аналіз логів — навчіться ефективно використовувати системні журнали для пошуку доказів.