Метод усунення несправностей

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

Почніть із семи кроків та пункту «Перевірка очікуваного проти фактичного» і використовуйте їх у Завданні 1. Порядок в обробці мережі є підтримкою, коли проблема стосується мережі. Таблица Linux/Proxmox — це один приклад, а не команди, які ви повинні виконувати для всіх помилок. Самоперевірка є необов’язковим вправленням.

Якщо ви хочете побачити, як цей метод застосований до конкретної помилки, дотримуйтесь моделювання усунення несправностей додатка. Там вам потрібно буде обґрунтувати наступний тест перед тим, як відкриватися пропозицію з відповідями.

Сім кроків

1. Оцініть обставини. Що сталося і коли це почалося?
2. Відтворіть помилку, якщо безпечно зробити це знову.
3. З’ясуйте та визначте межі можливих джерел помилок — який шар або яка компонента може бути причиною?
4. Отримайте інформацію — журнали, повідомлення про помилки, результати команд.
5. Розгляньте можливі рішення на основі того, що вам відомо зараз.
6. Тестуйте по одному рішенню чи гіпотезі за раз. Якщо ви змінюєте кілька речей одночасно, ви не знаєте, що саме фактично вирішило проблему.
7. Задокументуйте помилку та її розв’язання, щоб ви (або хтось інший) впізнали його наступного разу.

Порядок діагностики мережі та служб

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

flowchart TD
    A[Фізичне з'єднання] --> B[Мережевий інтерфейс]
    B --> C[Налаштування IP]
    C --> D[Локальна мережа]
    D --> E[Шлюз і маршрутизація]
    E --> F[DNS]
    F --> G[Сервіс]

Відео: Як перевірити з’єднання мережі за допомогою команди ping

У відео показано, як можна використовувати команду ping для перевірки доступності пристрою в межах мережі.

Для кожного пункту ви повинні бути здатними:

• пояснити, що саме фактично перевіряється контрольною точкою
• знаходити відповідні значення за допомогою правильної команди (див. 🌐 Мережеві протоколи щодо команд ping, nslookup тощо)
• розрізняти спостереження та припущення
• обирати наступну перевірку на основі результату попередньої, а не інтуїції

Команди по шарах у Linux-VM у Proxmox

Це застосування методу, коли Linux-VM не може отримати доступ до служби. Виконуйте відповідні команди в Консолі (Console) самої VM, а не в оболонці (Shell) хоста Proxmox. За потреби зверніться до 🧭 Навігація у Proxmox VE. Оберіть тест для того, що ви досліджуєте; таблиця не є обов’язковою вимогою для Завдання 1.

Якщо стандартного маршруту немає, досліджуйте, як VM має отримувати доступ до цілей поза своєю мережею; окремі цілі можуть мати власні маршрути. Деякі мережі блокують ping, тому відсутність відповіді сама по собі не є доказом розриву зв’язку. Якщо пошук імен та репозитории пакетів працюють, у вас є конкретні результати для подальшої роботи. 🌐 IP, підресурси та стандартний шлюз пояснює адреси, префікси та маршрути.

Тест очікуваного проти фактичного

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

Потрібно:          Що повинен міг робити користувач?
Мета:              Яку адресу/сервіс ви тестуєте?
Очікуване:         Що має статися, якщо все працює?
Фактичне:          Що сталося?
Доводить:          Який результат це доводить?
Не доводить окремо:  Чого НЕ доводить цей результат?

Завдання 1 - Застосуйте метод до реальної проблеми

Візьміть проблему, з якою ви стикнулися в іншому курсі або темі з підтримки експлуатації (Driftsstøtte) чи розробки (Utvikling): контейнер, який не запускається, служба, яку не вдається досягти, скрипт із помилкою:

1. Проходьте сім кроків, описаних вище, по одному за разом.
2. Запишіть «очікуване проти фактичного» для кожного тесту, який ви виконуєте.
3. Зробіть нотатки про те, який компонент або шар визначає цей тест. Використовуйте мережеву послідовність лише тоді, коли вона відповідає проблемі.
4. Спробуйте одну обґрунтовану виправлення у тестовому середовищі, де вам дозволено вносити зміни. Повторіть початкову дію користувача та перевірте, що виправлення дійсно працює. Збережіть можливість повернення до попереднього налаштування.

Якщо у вас немає доступних помилок, ви можете проаналізувати цей приклад: додаток відображає очікуючу сторінку на /, але HTTP 404 на /status. Що показують ці два відповіді і що б ви досліджували першим? Обидва запиту отримали HTTP-відповідь; перша перевірка полягає в тому, чи /status дійсно існує в додатку та чи клієнт використовує правильний маршрут. Цей приклад є вправою для аналізу, а не підтвердженням того, що ви вирішили власну проблему.

Контрольна точка: Помилка визначена та контрольована

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

Перевірте себе

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

Підсумок

• Відладка — це метод, а не вгадування – сім фіксованих кроків від ідентифікації до документування
• Метод подвоєння може обмежити ланцюг, якщо ви знаєте елементи, які використовує тест
• Для мереж: використовуйте шари, щоб обрати відповідний наступний тест на основі того, що ви спостерігаєте
• Завжди записуйте очікувані та фактичні значення перед тестом і пам’ятайте, що один тест рідко доводить все