Network Troubleshooting Methodology - The Systematic Approach
Методологія усунення несправностей мережі: системний підхід
Чому методологія важлива
Проблема:Програма бази даних "повільна". Команда мережі звинувачує команду сервера. Команда сервера звинувачує мережу. Тим часом користувачі розчаровані, а години витрачаються на циклічне налагодження.
Рішення:Систематичний, науковий підхід до усунення несправностей, який використовує докази, а не припущення, щоб визначити основні причини.
Вартість випадкового усунення несправностей:Витрачений час, неправильні виправлення, які маскують реальні проблеми, вказування пальцями між командами та погіршення взаємодії з користувачем.
Вступ: Науковий метод, застосований до мереж
Усунення несправностей у мережі — це в основному вправа наукового методу:
- Спостерігайтесимптоми та збір даних
- Сформулюйте гіпотезупро першопричину
- Перевірте гіпотезуз діагностичними засобами
- Проаналізуйте результатиі підтвердити або відхилити гіпотезу
- Впровадити виправленняна основі підтвердженої першопричини
- Підтвердитипроблема вирішена
У цій статті наведено структуровану структуру для усунення несправностей мережі, яка запобігає таким поширеним помилкам, як:
- Упередженість підтвердження (шукаємо лише докази, які підтверджують ваше початкове припущення)
- Випадкові зміни без діагностики (підхід «розпилюй і молися»)
- Усунення симптомів замість першопричин
- Циклічний налагодження без документування того, що було спробовано
П'ять ключових питань
Перш ніж заглибитися в технічну діагностику, дайте відповідь на ці п’ять важливих запитань, щоб звузити сферу дослідження:
Зміни конфігурації? Нове обладнання? Оновлення програмного забезпечення? Зміни топології?
- Перевірте журнали керування змінами
- Перегляньте останні коміти в системах керування конфігурацією
- Запитайте: "Це працювало вчора?"
Один користувач? Одна будівля? Всі? Лише конкретне застосування?
- Один пристрій:Ймовірно, локальна проблема (мережева карта, кабель, конфігурація)
- Одна підмережа:Проблема зі шлюзом, DHCP або комутатором
- Всі:Основна інфраструктура, Інтернет-провайдер або поширена проблема
- Конкретний додаток:Сервер програм, правило брандмауера або DNS
Трапляється весь час? Тільки в певні години? Випадкові випадки?
- Константа:Серйозний збій (перерізання кабелю, неправильна конфігурація, несправне обслуговування)
- На основі часу:Затори в робочий час, заплановані процеси
- Переривчастий/випадковий:Невідповідність дуплексу, збій обладнання, переривчасте з’єднання
Чи можете ви викликати проблему на вимогу?
- Так:Набагато легше діагностувати (можна перевіряти гіпотези)
- ні:Налаштуйте моніторинг/реєстрацію та дочекайтеся повторення
Перевірте обидва кінці з’єднання
- Точка зору клієнта проти перспективи сервера
- Захоплення пакетів у джерела проти призначення
- Асиметрична маршрутизація? Різні шляхи для надсилання та отримання?
Діагностичний підхід на основі моделі OSI
Модель OSI забезпечує структуровану структуру для усунення несправностей. Працюйте від Рівня 1 (Фізичний) вгору або від Рівня 7 (Додаток) вниз, залежно від симптомів.
Підхід «знизу вгору» (Рівень 1 → Рівень 7)
Коли використовувати:Повна втрата з’єднання, відсутність індикатора з’єднання або симптоми фізичного рівня
- Перевірте: кабель підключено? Лампи горять? Волокно чисте?
- Команди:
show interfaces,ethtool eth0 - Шукайте: помилки CRC, зіткнення, пізні зіткнення, ранти, гіганти
- Перевірте: правильна VLAN? Порт увімкнено? Блокування STP?
- Команди:
show mac address-table,show spanning-tree - Шукайте: помилки MAC, зміни топології STP, невідповідності VLAN
- Перевірте: чи можна перевірити ping шлюзу за замовчуванням? Таблиця маршрутизації правильна?
- Команди:
ping,traceroute,show ip route - Шукайте: відсутні маршрути, неправильний наступний крок, петлі маршрутизації
- Перевірте: Чи можна встановити з'єднання TCP? Брандмауер блокує порт?
- Команди:
telnet host port,netstat -an, захоплення пакетів - Шукайте: повторні передачі TCP, нульові вікна, пакети RST
- Перевірте: вирішення DNS? Програма відповідає? Автентифікація працює?
- Команди:
nslookup,dig,curl -v - Шукайте: збої DNS, помилки програми, проблеми з тайм-аутом
Підхід зверху вниз (Рівень 7 → Рівень 1)
Коли використовувати:Проблеми, пов’язані з програмою, де існує базове підключення
Почніть із рівня 7 (чи запущена служба SharePoint? DNS вирішує виправити IP-адресу?) і перейдіть лише за потреби.
Дерево рішень: це рівень 1, 2 чи 3?
Використовуйте це дерево швидкої діагностики, щоб визначити, який рівень несправний:
Стек TCP/IP не працює. Перевірити служби ОС, перевстановити мережеві драйвери.
NIC вимкнено, драйвер неправильний, кабель від’єднано. перевірити:ip link showабо Диспетчер пристроїв
Перевірте: фізичний кабель, стан порту комутатора, призначення VLAN, таблицю ARP
Перевірте: таблицю маршрутизації, правила брандмауера, ACL. використанняtracerouteщоб знайти, де зупиняються пакети
Перевірте: налаштування DNS-сервера, доступність DNS-сервера, брандмауер блокує порт 53
Перевірте: правила брандмауера, групи безпеки, службу, що прослуховує порт
Проблема пов’язана з самою програмою, автентифікацією або конфігурацією програми
Методи ізоляції
Якщо у вас є гіпотеза про першопричину, використовуйте ці методи ізоляції, щоб підтвердити або спростувати її:
1. Систематично замінюйте компоненти
- Замініть патч-кабель на завідомо справний
- Перевірте на іншому порту комутатора
- Спробуйте інший мережевий адаптер (або мережевий адаптер USB)
- Перевірте з іншого клієнтського пристрою
- Перейдіть до іншої VLAN/підмережі
2. Захоплення пакетів у кількох точках
Збирайте трафік у джерелі, проміжних точках і пунктах призначення, щоб визначити, де пакети відкидаються або змінюються:
# Capture on client
tcpdump -i eth0 -w client.pcap host server.example.com
# Capture on server
tcpdump -i eth0 -w server.pcap host client.example.com
# Compare:
# - Do packets leave client? (check client.pcap)
# - Do packets arrive at server? (check server.pcap)
# - If yes/no: problem is in the path between
# - If yes/yes but server doesn't respond: server-side issue
3. Тестування петлі
Усуньте зовнішні змінні, перевіривши підключення в одному пристрої:
# Test TCP stack without network
ping 127.0.0.1
# Test application listening locally
telnet localhost 80
# Test loopback on network interface (if supported)
# Some NICs support physical loopback for Layer 1 testing
4. Завідомо хороші базові порівняння
Порівняйте конфігурацію та поведінку з робочою системою:
# Compare interface settings
diff <(ssh working-switch "show run int gi1/0/1") \
<(ssh broken-switch "show run int gi1/0/1")
# Compare routing tables
diff <(ssh router1 "show ip route") \
<(ssh router2 "show ip route")
Документація під час усунення несправностей
Належна документація запобігає циклічному налагодженню, коли ви намагаєтеся те саме кілька разів, не усвідомлюючи цього.
Шаблон усунення несправностей
Ідентифікатор проблеми: TICKET-12345
Дата/час: 2026-02-02 14:30 UTC
Повідомив: Jane Smith (jane.smith@company.com)
Постраждалі користувачі: ~50 users in Building A, 3rd floor
Симптом: Cannot access file server \\fileserver01
Початкові спостереження:
- Issue started around 14:00 UTC
- Only affects Building A, 3rd floor
- Other buildings can access fileserver01
- Ping to fileserver01 (10.1.50.10) times out from affected users
- Ping to default gateway (10.1.30.1) succeeds
Виконані тести:
1. [14:35] Checked switch port status: gi1/0/15 is UP/UP
2. [14:38] Checked VLAN assignment: Port is in VLAN 30 (correct)
3. [14:42] Checked interface errors: 1,234 CRC errors on gi1/0/15
4. [14:45] Replaced patch cable - still seeing CRC errors
5. [14:50] Moved uplink to different port (gi1/0/16) - errors persist
6. [14:55] Checked fiber cleanliness - dirty connector found
Основна причина:
Dirty fiber connector on uplink between Building A floor switch
and distribution switch causing CRC errors and packet loss
роздільна здатність:
Cleaned fiber connector with proper cleaning kit. CRC errors
dropped to zero. File server access restored.
Перевірка:
Users confirmed file server accessible. Monitored for 15 minutes
with no errors.
Час вирішення: 25 minutes
Практичні приклади з реального світу
Приклад 1: «Мережа повільна» (насправді: вікно TCP виснажено)
Симптом
Час відгуку програми бази даних зменшився з <100 мс до 5+ секунд. Команда додатка звинуватила "затримку мережі".
Початкові припущення (невірні)
- Перевантаження мережі
- З’єднання WAN насичене
- Вузьке місце брандмауера
Діагностичний процес
- Тест ping:RTT = 2 мс (відмінно, виключає затримку рівня 3)
- Перевірка пропускної здатності (iperf):950 Мбіт/с на каналі 1 Гбіт/с (без перевантаження)
- Захоплення пакетів:Виявлено пакети TCP Zero Window із сервера бази даних
- Перевірка сервера:Сервер бази даних приймає буфери = 64 КБ (маленькі!)
Основна причина
Буфери ОС сервера бази даних були замалі для продукту високої пропускної здатності × затримки. Вікно TCP заповнюється, змушуючи відправника чекати.
роздільна здатність
# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
Вивчений урок
Не припускайте:«Повільно» не завжди означає «затримку мережі». Завжди збирайте докази (ping для визначення затримки, захоплення пакетів для поведінки), перш ніж робити поспішні висновки.
Приклад 2: переривчасте підключення (насправді: дуплексна невідповідність)
Симптом
З’єднання з сервером випадково втрачалося, особливо під навантаженням. Іноді працювало нормально, іноді взагалі не реагувало.
Початкові припущення (невірні)
- Помилка NIC
- Поганий кабель
- Проблема з обладнанням комутатора
Діагностичний процес
- Перевірка інтерфейсу:NIC сервера = 1000/повний, порт комутатора = 1000/наполовину (невідповідність!)
- Лічильники помилок:Значна кількість колізій на порту комутатора
- Пізні зіткнення:Індикатор дуплексної невідповідності
Основна причина
Помилка автоматичного узгодження. Сервер домовився про повний дуплекс, комутатор повернувся до напівдуплексного режиму. Зіткнення відбувалися лише під навантаженням, коли обидві сторони намагалися передавати одночасно.
роздільна здатність
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
Вивчений урок
Перевірте обидва кінці:Статус інтерфейсу показує узгоджені налаштування. Невідповідність означає помилку автоматичного узгодження. Завжди встановлюйте жорсткий код швидкості/дуплексу для серверів.
Приклад 3: «Не вдається отримати доступ до певних веб-сайтів» (насправді: чорна діра MTU/PMTUD)
Симптом
Користувачі могли переглядати одні веб-сайти (Google, Yahoo), але не могли переглядати інші (веб-сайт банку, портал компанії). Невеликі HTTP-запити працювали, великі сторінки минув.
Початкові припущення (невірні)
- Проблема з DNS
- Брандмауер блокує певні сайти
- Проблема з маршрутизацією провайдера
Діагностичний процес
- Роздільна здатність DNS:Добре працює для всіх сайтів
- Тест ping:Може пінгувати "недоступні" сайти
- Невеликий HTTP-запит (curl):Працює для невеликих сторінок
- Велике завантаження:Зривається після рукостискання TCP
-
Тест MTU:
ping -M do -s 1472вдається,ping -M do -s 1473не вдається - Моніторинг ICMP:Немає повідомлень "Потрібна фрагментація" (Тип 3, код 4).
Основна причина
Тунель VPN зменшив MTU до 1400, але брандмауер блокував повідомлення ICMP «Потрібна фрагментація». Шлях MTU Discovery (PMTUD) не міг працювати, створюючи чорну діру MTU. Маленькі пакети підходять, великі пакети з установленим бітом DF мовчки відкидаються.
роздільна здатність
! Implemented TCP MSS clamping on router
interface Tunnel0
ip tcp adjust-mss 1360
! Alternative: Allow ICMP Type 3 Code 4 through firewall
access-list 101 permit icmp any any packet-too-big
Вивчений урок
Розмір має значення:Якщо невеликі запити працюють, але великі передачі не вдаються, підозрюйте проблеми з MTU/фрагментацією. Використовуйте ping із бітом DF, щоб перевірити MTU шляху.
Приклад 4: Проблеми з якістю VoIP (насправді: неправильна конфігурація QoS)
Симптом
Голосові дзвінки мали переривчастий звук, періодичні перерви. Відбувається лише в робочий час (з 9:00 до 17:00).
Початкові припущення (невірні)
- Недостатня пропускна здатність
- Сервер VoIP перевантажений
- Якість з'єднання провайдера
Діагностичний процес
- Перевірка пропускної здатності:Під час напруженої години посилання використовується лише на 40%.
- Перевірка QoS:Голосовий трафік правильно позначено DSCP EF (46).
- Перевірка черги:Голосова черга мала лише 5% розподілу пропускної здатності (має бути 33%)
- Захоплення пакетів:Голосові пакети скидаються під час перевантаження
Основна причина
Політика QoS існувала, але пропускна здатність розподілялася у зворотному напрямку: найкраще – 60%, голос – 5%. У робочий час, коли трафік даних збільшився, голосові пакети відкидалися через переповнення черги.
резолюція
! Corrected QoS policy
policy-map WAN-QOS
class VOICE
priority percent 33
class VIDEO
bandwidth percent 25
class CRITICAL-DATA
bandwidth percent 20
class class-default
bandwidth percent 22
Вивчений урок
Проблеми на основі часу = ємність:Якщо проблеми виникають лише в години напруженої роботи, це не серйозний збій, а проблема ємності/QoS. Перевірте статистику черги, а не лише загальну пропускну здатність.
Посилання на команду за симптомом
| Симптом | Шар | Команди для запуску | Що шукати |
|---|---|---|---|
| Немає індикатора посилання | 1 шар | show interfaces |
Статус: не працює, немає носія, кабель від’єднано |
| Втрата пакетів | Шар 1/2 | show interfaces |
Помилки CRC, ранти, гіганти, зіткнення, пізні зіткнення |
| Не вдається перевірити ping шлюзу | 2 шар | arp -a |
Немає запису ARP, MAC не розпізнано, STP блокується |
| Не вдається отримати доступ до віддаленої підмережі | 3 шар | traceroute |
Відсутній маршрут, неправильний наступний крок, петля маршрутизації |
| Підключення відмовлено | 4 шар | telnet host port |
Служба не прослуховує, брандмауер блокує, TCP RST |
| Повільна продуктивність | Шар 4+ | ping (RTT) |
Висока затримка, обмеження пропускної здатності, повторна передача TCP, нуль вікон |
| Не вдається розпізнати ім’я хоста | Шар 7 | nslookup |
Сервер DNS недоступний, неправильна конфігурація DNS, NXDOMAIN |
| Переривчасті краплі | Шар 1/2 | ping -f (flood) |
Невідповідність дуплексу, збій кабелю, повторна конвергенція STP |
| Інколи працює, інколи ні | множинний | Extended ping |
Проблема балансування навантаження, асиметрія ECMP, переповнення таблиці станів |
Коли посилити
Знайте, коли передати проблему TAC постачальника або старшим інженерам. Ескалація, коли:
- Ви вичерпали всі кроки з усунення несправностей у своїй базі знань
- Проблема потребує доступу/дозволів, яких у вас немає
- Проблема пов’язана з помилкою програмного забезпечення постачальника або апаратним дефектом
- Вплив на бізнес є критичним і чутливим до часу
- Кілька команд повинні співпрацювати (програма + мережа + сервер)
- Повний опис симптомів
- Час початку проблеми
- Виконання діагностичних команд та їх виведення
- Резервне копіювання конфігурації
- Перехоплення пакетів (якщо актуально)
- Те, що ви вже пробували
Створення вашої особистої бази знань
Кожен сеанс усунення несправностей – це можливість навчитися. Створіть особисту базу знань:
1. Створіть журнал усунення несправностей
# Example structure
~/troubleshooting-journal/
├── 2026-01-15-duplex-mismatch.md
├── 2026-01-22-mtu-black-hole.md
├── 2026-02-02-tcp-window-exhaustion.md
└── README.md # Index of all issues
# Each file contains:
# - Symptom
# - Diagnostic steps
# - Root cause
# - Resolution
# - Lessons learned
# - Related tickets/documentation
2. Створіть шпаргалку команд
Упорядкуйте часто використовувані команди за сценарієм для швидкого використання під час усунення несправностей.
3. Задокументуйте свою мережу
- Топологічні діаграми (рівень 2 і рівень 3)
- Документація щодо схеми IP-адрес
- призначення VLAN
- Стандартні конфігурації (шаблони)
- Завідомо справні базові лінії (статистика інтерфейсу до проблем)
Загальні антишаблони, яких слід уникати
❌ НЕ: Робіть випадкові зміни без діагностики
Зміна конфігурацій без розуміння проблеми часто погіршує ситуацію або маскує справжню проблему.
❌ НЕ ТРИМАЙТЕ: припускайте, що мережа завжди несправна
Часто «проблеми з мережею» пов’язані з проблемами програми, сервера чи клієнта. Зберіть докази, перш ніж прийняти провину.
❌ НЕ МОЖЕТЕ: пропустіть документування кроків щодо усунення несправностей
Ви витрачаєте час на повторення вже зроблених тестів або не зможете пояснити колегам, що ви пробували.
❌ НЕ: Ігноруйте періодичні проблеми
Періодичні проблеми часто є ранніми попереджувальними ознаками майбутньої невдачі. Дослідіть їх, перш ніж вони стануть критичними.
❌ НЕ: виправляйте симптоми, а не першопричини
Перезавантаження пристрою може відновити службу, але якщо ви не з’ясуєте, ЧОМУ було потрібно перезавантаження, проблема повториться.
Резюме: контрольний список систематичного усунення несправностей
✓ Перш ніж почати
- Дайте відповіді на п’ять ключових запитань (що змінилося? кого це вплинуло? постійне чи періодичне? відтворюване? що бачить інша сторона?)
- Зберіть початкові симптоми та звіти користувачів
- Перевірте наявність останніх змін або обслуговування
✓ Під час усунення несправностей
- Методична робота через рівні OSI (знизу вгору або зверху вниз)
- Під час тестування змінюйте ОДНУ змінну за раз
- Документуйте кожен тест і його результат
- Використовуйте захоплення пакетів, щоб побачити фактичну поведінку трафіку
- Порівняйте з завідомо справними базовими лініями
✓ Після вирішення
- Переконайтеся, що виправлення дійсно вирішило проблему
- Задокументуйте першопричину та рішення
- Оновіть свою базу знань
- Якщо конфігурація змінена, оновіть документацію
- Поміркуйте: чи міг моніторинг зафіксувати це раніше?
Висновок
Усунення несправностей мережі – це і наука, і мистецтво. Наука дотримується систематичної методології, правильно використовує інструменти діагностики та розуміє протоколи. Мистецтво полягає в тому, щоб знати, які тести проводити в першу чергу на основі симптомів, розпізнавати шаблони з досвіду та знати, коли посилити.
Дотримуючись систематичного підходу, викладеного в цій статті — ставлячи правильні запитання, методично опрацьовуючи модель OSI, документуючи свої кроки та навчаючись на кожній проблемі, ви станете ефективнішими у вирішенні проблем і уникнете типових пасток, які призводять до марної втрати часу та неправильних виправлень.
Пам'ятайте:Мета полягає не просто у відновленні служби, а в тому, щоб зрозуміти, ЧОМУ сталася помилка, щоб ви могли запобігти повторенню цього.
Останнє оновлення: 2 лютого 2026 р. | Автор: технічна команда Baud9600