.. назва: Методологія усунення несправностей мережі - системний підхід
.. slug: методологія усунення неполадок у мережі
.. дата: 2026-02-02 18:00:00 UTC
.. теги: мережа, усунення несправностей, методологія, діагностика
.. категорія: статті
.. посилання:
.. опис: систематичний науковий підхід до усунення несправностей мережі, який запобігає втраті часу та неправильним виправленням
.. тип: текст
<style>
.article-container {
    max-width: 900px;
    margin: 0 auto;
    padding: 20px;
    font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
    line-height: 1.8;
    color: #333;
}

h1 {
    color: #2c3e50;
    border-bottom: 3px solid #3498db;
    padding-bottom: 15px;
    margin-bottom: 30px;
}

h2 {
    color: #2c3e50;
    margin-top: 40px;
    margin-bottom: 20px;
    border-left: 5px solid #3498db;
    padding-left: 15px;
}

h3 {
    color: #34495e;
    margin-top: 30px;
    margin-bottom: 15px;
}

.intro-box {
    background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
    color: white;
    padding: 30px;
    border-radius: 12px;
    margin-bottom: 30px;
}

.intro-box h2 {
    color: white;
    border: none;
    margin-top: 0;
}

.warning-box {
    background: #fff3cd;
    border-left: 5px solid #ffc107;
    padding: 20px;
    margin: 25px 0;
    border-radius: 6px;
}

.info-box {
    background: #d1ecf1;
    border-left: 5px solid #17a2b8;
    padding: 20px;
    margin: 25px 0;
    border-radius: 6px;
}

.success-box {
    background: #d4edda;
    border-left: 5px solid #28a745;
    padding: 20px;
    margin: 25px 0;
    border-radius: 6px;
}

.danger-box {
    background: #f8d7da;
    border-left: 5px solid #dc3545;
    padding: 20px;
    margin: 25px 0;
    border-radius: 6px;
}

.flowchart {
    background: #f8f9fa;
    padding: 30px;
    border-radius: 12px;
    margin: 30px 0;
    border: 2px solid #dee2e6;
}

.flowchart-step {
    background: white;
    border: 2px solid #3498db;
    padding: 20px;
    margin: 15px 0;
    border-radius: 8px;
    position: relative;
}

.flowchart-step.decision {
    border-color: #e74c3c;
    background: #fee;
}

.flowchart-step.success {
    border-color: #27ae60;
    background: #efe;
}

.flowchart-arrow {
    text-align: center;
    font-size: 24px;
    color: #3498db;
    margin: 10px 0;
}

.command-box {
    background: #2d2d2d;
    color: #f8f8f2;
    padding: 20px;
    border-radius: 8px;
    font-family: 'Courier New', monospace;
    overflow-x: auto;
    margin: 20px 0;
}

.command-box code {
    color: #f8f8f2;
}

table {
    width: 100%;
    border-collapse: collapse;
    margin: 25px 0;
}

th, td {
    padding: 12px;
    text-align: left;
    border: 1px solid #dee2e6;
}

th {
    background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
    color: white;
    font-weight: 600;
}

tr:nth-child(even) {
    background: #f8f9fa;
}

.case-study {
    background: #f8f9fa;
    border-radius: 12px;
    padding: 25px;
    margin: 30px 0;
    border-left: 5px solid #3498db;
}

.case-study h3 {
    color: #3498db;
    margin-top: 0;
}

.checklist {
    list-style: none;
    padding: 0;
}

.checklist li {
    padding: 10px 10px 10px 35px;
    margin: 8px 0;
    background: #f8f9fa;
    border-radius: 6px;
    position: relative;
}

.checklist li:before {
    content: '✓';
    position: absolute;
    left: 10px;
    color: #28a745;
    font-weight: bold;
    font-size: 18px;
}

.tip-box {
    background: #e7f3ff;
    border-left: 5px solid #2196F3;
    padding: 20px;
    margin: 25px 0;
    border-radius: 6px;
}

.tip-box strong {
    color: #2196F3;
}
</style>
<div class="article-container">
<h1>Методологія усунення несправностей мережі: системний підхід</h1>
<div class="intro-box">
<h2>Чому методологія важлива</h2>
<p><strong>Проблема:</strong>Програма бази даних "повільна". Команда мережі звинувачує команду сервера. Команда сервера звинувачує мережу. Тим часом користувачі розчаровані, а години витрачаються на циклічне налагодження.</p>
<p><strong>Рішення:</strong>Систематичний, науковий підхід до усунення несправностей, який використовує докази, а не припущення, щоб визначити основні причини.</p>
<p><strong>Вартість випадкового усунення несправностей:</strong>Витрачений час, неправильні виправлення, які маскують реальні проблеми, вказування пальцями між командами та погіршення взаємодії з користувачем.</p>
</div>
<h2>Вступ: Науковий метод, застосований до мереж</h2>
<p>Усунення несправностей у мережі — це в основному вправа наукового методу:</p>
<ol>
<li><strong>Спостерігайте</strong>симптоми та збір даних</li>
<li><strong>Сформулюйте гіпотезу</strong>про першопричину</li>
<li><strong>Перевірте гіпотезу</strong>з діагностичними засобами</li>
<li><strong>Проаналізуйте результати</strong>і підтвердити або відхилити гіпотезу</li>
<li><strong>Впровадити виправлення</strong>на основі підтвердженої першопричини</li>
<li><strong>Підтвердити</strong>проблема вирішена</li>
</ol>
<p>У цій статті наведено структуровану структуру для усунення несправностей мережі, яка запобігає таким поширеним помилкам, як:</p>
<ul>
<li>Упередженість підтвердження (шукаємо лише докази, які підтверджують ваше початкове припущення)</li>
<li>Випадкові зміни без діагностики (підхід «розпилюй і молися»)</li>
<li>Усунення симптомів замість першопричин</li>
<li>Циклічний налагодження без документування того, що було спробовано</li>
</ul>
<h2>П'ять ключових питань</h2>
<p>Перш ніж заглибитися в технічну діагностику, дайте відповідь на ці п’ять важливих запитань, щоб звузити сферу дослідження:</p>
<div class="flowchart">
<div class="flowchart-step decision">
<strong>Запитання 1: Що змінилося останнім часом?</strong>
<p>Зміни конфігурації? Нове обладнання? Оновлення програмного забезпечення? Зміни топології?</p>
<ul>
<li>Перевірте журнали керування змінами</li>
<li>Перегляньте останні коміти в системах керування конфігурацією</li>
<li>Запитайте: "Це працювало вчора?"</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step decision">
<strong>Питання 2: Кого це стосується?</strong>
<p>Один користувач? Одна будівля? Всі? Лише конкретне застосування?</p>
<ul>
<li><strong>Один пристрій:</strong>Ймовірно, локальна проблема (мережева карта, кабель, конфігурація)</li>
<li><strong>Одна підмережа:</strong>Проблема зі шлюзом, DHCP або комутатором</li>
<li><strong>Всі:</strong>Основна інфраструктура, Інтернет-провайдер або поширена проблема</li>
<li><strong>Конкретний додаток:</strong>Сервер програм, правило брандмауера або DNS</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step decision">
<strong>Запитання 3: це постійно чи періодично?</strong>
<p>Трапляється весь час? Тільки в певні години? Випадкові випадки?</p>
<ul>
<li><strong>Константа:</strong>Серйозний збій (перерізання кабелю, неправильна конфігурація, несправне обслуговування)</li>
<li><strong>На основі часу:</strong>Затори в робочий час, заплановані процеси</li>
<li><strong>Переривчастий/випадковий:</strong>Невідповідність дуплексу, збій обладнання, переривчасте з’єднання</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step decision">
<strong>Запитання 4: Чи можете ви це відтворити?</strong>
<p>Чи можете ви викликати проблему на вимогу?</p>
<ul>
<li><strong>Так:</strong>Набагато легше діагностувати (можна перевіряти гіпотези)</li>
<li><strong>ні:</strong>Налаштуйте моніторинг/реєстрацію та дочекайтеся повторення</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step decision">
<strong>Запитання 5: Що бачить інша сторона?</strong>
<p>Перевірте обидва кінці з’єднання</p>
<ul>
<li>Точка зору клієнта проти перспективи сервера</li>
<li>Захоплення пакетів у джерела проти призначення</li>
<li>Асиметрична маршрутизація? Різні шляхи для надсилання та отримання?</li>
</ul>
</div>
</div>
<h2>Діагностичний підхід на основі моделі OSI</h2>
<p>Модель OSI забезпечує структуровану структуру для усунення несправностей. Працюйте від Рівня 1 (Фізичний) вгору або від Рівня 7 (Додаток) вниз, залежно від симптомів.</p>
<h3>Підхід «знизу вгору» (Рівень 1 → Рівень 7)</h3>
<p><strong>Коли використовувати:</strong>Повна втрата з’єднання, відсутність індикатора з’єднання або симптоми фізичного рівня</p>
<div class="flowchart">
<div class="flowchart-step">
<strong>Рівень 1: фізичний</strong>
<ul>
<li>Перевірте: кабель підключено? Лампи горять? Волокно чисте?</li>
<li>Команди:<code>show interfaces</code>, <code>ethtool eth0</code></li>
<li>Шукайте: помилки CRC, зіткнення, пізні зіткнення, ранти, гіганти</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step">
<strong>Рівень 2: канал передачі даних</strong>
<ul>
<li>Перевірте: правильна VLAN? Порт увімкнено? Блокування STP?</li>
<li>Команди:<code>show mac address-table</code>, <code>show spanning-tree</code></li>
<li>Шукайте: помилки MAC, зміни топології STP, невідповідності VLAN</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step">
<strong>Рівень 3: мережа</strong>
<ul>
<li>Перевірте: чи можна перевірити ping шлюзу за замовчуванням? Таблиця маршрутизації правильна?</li>
<li>Команди:<code>ping</code>, <code>traceroute</code>, <code>show ip route</code></li>
<li>Шукайте: відсутні маршрути, неправильний наступний крок, петлі маршрутизації</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step">
<strong>Рівень 4: Транспорт</strong>
<ul>
<li>Перевірте: Чи можна встановити з'єднання TCP? Брандмауер блокує порт?</li>
<li>Команди:<code>telnet host port</code>, <code>netstat -an</code>, захоплення пакетів</li>
<li>Шукайте: повторні передачі TCP, нульові вікна, пакети RST</li>
</ul>
</div>
<div class="flowchart-arrow">↓</div>
<div class="flowchart-step">
<strong>Рівень 5-7: Сеанс/Презентація/Додаток</strong>
<ul>
<li>Перевірте: вирішення DNS? Програма відповідає? Автентифікація працює?</li>
<li>Команди:<code>nslookup</code>, <code>dig</code>, <code>curl -v</code></li>
<li>Шукайте: збої DNS, помилки програми, проблеми з тайм-аутом</li>
</ul>
</div>
</div>
<h3>Підхід зверху вниз (Рівень 7 → Рівень 1)</h3>
<p><strong>Коли використовувати:</strong>Проблеми, пов’язані з програмою, де існує базове підключення</p>
<div class="info-box">
<strong>приклад:</strong>«Я можу переглядати Інтернет, але не можу отримати доступ до сайту компанії SharePoint».<p>Почніть із рівня 7 (чи запущена служба SharePoint? DNS вирішує виправити IP-адресу?) і перейдіть лише за потреби.</p>
</div>
<h2>Дерево рішень: це рівень 1, 2 чи 3?</h2>
<p>Використовуйте це дерево швидкої діагностики, щоб визначити, який рівень несправний:</p>
<div class="flowchart">
<div class="flowchart-step decision">
<strong>Чи можете ви пінгувати локальний хост (127.0.0.1)?</strong>
</div>
<div class="flowchart-arrow">↓ НІ</div>
<div class="flowchart-step danger">
<strong>Проблема: проблема з операційною системою/програмним забезпеченням</strong>
<p>Стек TCP/IP не працює. Перевірити служби ОС, перевстановити мережеві драйвери.</p>
</div>
<div class="flowchart-arrow">↓ ТАК</div>
<div class="flowchart-step decision">
<strong>Чи можете ви пінгувати власну IP-адресу?</strong>
</div>
<div class="flowchart-arrow">↓ НІ</div>
<div class="flowchart-step danger">
<strong>Проблема: рівень 1/2 – інтерфейс локальної мережі</strong>
<p>NIC вимкнено, драйвер неправильний, кабель від’єднано. перевірити:<code>ip link show</code>або Диспетчер пристроїв</p>
</div>
<div class="flowchart-arrow">↓ ТАК</div>
<div class="flowchart-step decision">
<strong>Чи можете ви пінгувати шлюз за замовчуванням?</strong>
</div>
<div class="flowchart-arrow">↓ НІ</div>
<div class="flowchart-step danger">
<strong>Проблема: рівень 1/2 – локальна мережа</strong>
<p>Перевірте: фізичний кабель, стан порту комутатора, призначення VLAN, таблицю ARP</p>
</div>
<div class="flowchart-arrow">↓ ТАК</div>
<div class="flowchart-step decision">
<strong>Чи можете ви пінгувати віддалений хост за IP-адресою?</strong>
</div>
<div class="flowchart-arrow">↓ НІ</div>
<div class="flowchart-step danger">
<strong>Проблема: Рівень 3 – Маршрутизація</strong>
<p>Перевірте: таблицю маршрутизації, правила брандмауера, ACL. використання<code>traceroute</code>щоб знайти, де зупиняються пакети</p>
</div>
<div class="flowchart-arrow">↓ ТАК</div>
<div class="flowchart-step decision">
<strong>Чи можете ви вирішити DNS (ім’я хоста nslookup)?</strong>
</div>
<div class="flowchart-arrow">↓ НІ</div>
<div class="flowchart-step danger">
<strong>Проблема: конфігурація DNS</strong>
<p>Перевірте: налаштування DNS-сервера, доступність DNS-сервера, брандмауер блокує порт 53</p>
</div>
<div class="flowchart-arrow">↓ ТАК</div>
<div class="flowchart-step decision">
<strong>Чи можете ви отримати доступ до порту програми (порт хосту Telnet)?</strong>
</div>
<div class="flowchart-arrow">↓ НІ</div>
<div class="flowchart-step danger">
<strong>Проблема: брандмауер/блокування портів</strong>
<p>Перевірте: правила брандмауера, групи безпеки, службу, що прослуховує порт</p>
</div>
<div class="flowchart-arrow">↓ ТАК</div>
<div class="flowchart-step success">
<strong>Мережа в порядку – Проблема рівня програми</strong>
<p>Проблема пов’язана з самою програмою, автентифікацією або конфігурацією програми</p>
</div>
</div>
<h2>Методи ізоляції</h2>
<p>Якщо у вас є гіпотеза про першопричину, використовуйте ці методи ізоляції, щоб підтвердити або спростувати її:</p>
<h3>1. Систематично замінюйте компоненти</h3>
<div class="tip-box">
<strong>Порада:</strong>Змінюйте ОДНУ змінну за раз. Якщо ви поміняєте і кабель, і порт комутатора, ви не дізнаєтеся, що це виправило.</div>
<ul class="checklist">
<li>Замініть патч-кабель на завідомо справний</li>
<li>Перевірте на іншому порту комутатора</li>
<li>Спробуйте інший мережевий адаптер (або мережевий адаптер USB)</li>
<li>Перевірте з іншого клієнтського пристрою</li>
<li>Перейдіть до іншої VLAN/підмережі</li>
</ul>
<h3>2. Захоплення пакетів у кількох точках</h3>
<p>Збирайте трафік у джерелі, проміжних точках і пунктах призначення, щоб визначити, де пакети відкидаються або змінюються:</p>
<div class="command-box">
<code># 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
</code>
</div>
<h3>3. Тестування петлі</h3>
<p>Усуньте зовнішні змінні, перевіривши підключення в одному пристрої:</p>
<div class="command-box">
<code># 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
</code>
</div>
<h3>4. Завідомо хороші базові порівняння</h3>
<p>Порівняйте конфігурацію та поведінку з робочою системою:</p>
<div class="command-box">
<code># Compare interface settings
diff &lt;(ssh working-switch "show run int gi1/0/1") \
     &lt;(ssh broken-switch "show run int gi1/0/1")

# Compare routing tables
diff &lt;(ssh router1 "show ip route") \
     &lt;(ssh router2 "show ip route")
</code>
</div>
<h2>Документація під час усунення несправностей</h2>
<p>Належна документація запобігає циклічному налагодженню, коли ви намагаєтеся те саме кілька разів, не усвідомлюючи цього.</p>
<h3>Шаблон усунення несправностей</h3>
<div class="command-box">
<code><strong>Ідентифікатор проблеми:</strong> TICKET-12345
<strong>Дата/час:</strong> 2026-02-02 14:30 UTC
<strong>Повідомив:</strong> Jane Smith (jane.smith@company.com)
<strong>Постраждалі користувачі:</strong> ~50 users in Building A, 3rd floor
<strong>Симптом:</strong> Cannot access file server \\fileserver01

<strong>Початкові спостереження:</strong>
- 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

<strong>Виконані тести:</strong>
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

<strong>Основна причина:</strong>
Dirty fiber connector on uplink between Building A floor switch
and distribution switch causing CRC errors and packet loss

<strong>роздільна здатність:</strong>
Cleaned fiber connector with proper cleaning kit. CRC errors
dropped to zero. File server access restored.

<strong>Перевірка:</strong>
Users confirmed file server accessible. Monitored for 15 minutes
with no errors.

<strong>Час вирішення:</strong> 25 minutes
</code>
</div>
<div class="warning-box">
<strong>Чому документація важлива:</strong>Без цього запису наступного разу, коли хтось побачить помилки CRC на цьому комутаторі, він може витратити час на заміну кабелів і тестування портів замість негайної перевірки чистоти оптоволокна.</div>
<h2>Практичні приклади з реального світу</h2>
<h3>Приклад 1: «Мережа повільна» (насправді: вікно TCP виснажено)</h3>
<div class="case-study">
<h3>Симптом</h3>
<p>Час відгуку програми бази даних зменшився з &lt;100 мс до 5+ секунд. Команда додатка звинуватила "затримку мережі".</p>
<h3>Початкові припущення (невірні)</h3>
<ul>
<li>Перевантаження мережі</li>
<li>З’єднання WAN насичене</li>
<li>Вузьке місце брандмауера</li>
</ul>
<h3>Діагностичний процес</h3>
<ol>
<li><strong>Тест ping:</strong>RTT = 2 мс (відмінно, виключає затримку рівня 3)</li>
<li><strong>Перевірка пропускної здатності (iperf):</strong>950 Мбіт/с на каналі 1 Гбіт/с (без перевантаження)</li>
<li><strong>Захоплення пакетів:</strong>Виявлено пакети TCP Zero Window із сервера бази даних</li>
<li><strong>Перевірка сервера:</strong>Сервер бази даних приймає буфери = 64 КБ (маленькі!)</li>
</ol>
<h3>Основна причина</h3>
<p>Буфери ОС сервера бази даних були замалі для продукту високої пропускної здатності × затримки. Вікно TCP заповнюється, змушуючи відправника чекати.</p>
<h3>роздільна здатність</h3>
<div class="command-box">
<code># Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
</code>
</div>
<h3>Вивчений урок</h3>
<p><strong>Не припускайте:</strong>«Повільно» не завжди означає «затримку мережі». Завжди збирайте докази (ping для визначення затримки, захоплення пакетів для поведінки), перш ніж робити поспішні висновки.</p>
</div>
<h3>Приклад 2: переривчасте підключення (насправді: дуплексна невідповідність)</h3>
<div class="case-study">
<h3>Симптом</h3>
<p>З’єднання з сервером випадково втрачалося, особливо під навантаженням. Іноді працювало нормально, іноді взагалі не реагувало.</p>
<h3>Початкові припущення (невірні)</h3>
<ul>
<li>Помилка NIC</li>
<li>Поганий кабель</li>
<li>Проблема з обладнанням комутатора</li>
</ul>
<h3>Діагностичний процес</h3>
<ol>
<li><strong>Перевірка інтерфейсу:</strong>NIC сервера = 1000/повний, порт комутатора = 1000/наполовину (невідповідність!)</li>
<li><strong>Лічильники помилок:</strong>Значна кількість колізій на порту комутатора</li>
<li><strong>Пізні зіткнення:</strong>Індикатор дуплексної невідповідності</li>
</ol>
<h3>Основна причина</h3>
<p>Помилка автоматичного узгодження. Сервер домовився про повний дуплекс, комутатор повернувся до напівдуплексного режиму. Зіткнення відбувалися лише під навантаженням, коли обидві сторони намагалися передавати одночасно.</p>
<h3>роздільна здатність</h3>
<div class="command-box">
<code>! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
 speed 1000
 duplex full
</code>
</div>
<h3>Вивчений урок</h3>
<p><strong>Перевірте обидва кінці:</strong>Статус інтерфейсу показує узгоджені налаштування. Невідповідність означає помилку автоматичного узгодження. Завжди встановлюйте жорсткий код швидкості/дуплексу для серверів.</p>
</div>
<h3>Приклад 3: «Не вдається отримати доступ до певних веб-сайтів» (насправді: чорна діра MTU/PMTUD)</h3>
<div class="case-study">
<h3>Симптом</h3>
<p>Користувачі могли переглядати одні веб-сайти (Google, Yahoo), але не могли переглядати інші (веб-сайт банку, портал компанії). Невеликі HTTP-запити працювали, великі сторінки минув.</p>
<h3>Початкові припущення (невірні)</h3>
<ul>
<li>Проблема з DNS</li>
<li>Брандмауер блокує певні сайти</li>
<li>Проблема з маршрутизацією провайдера</li>
</ul>
<h3>Діагностичний процес</h3>
<ol>
<li><strong>Роздільна здатність DNS:</strong>Добре працює для всіх сайтів</li>
<li><strong>Тест ping:</strong>Може пінгувати "недоступні" сайти</li>
<li><strong>Невеликий HTTP-запит (curl):</strong>Працює для невеликих сторінок</li>
<li><strong>Велике завантаження:</strong>Зривається після рукостискання TCP</li>
<li><strong>Тест MTU:</strong> <code>ping -M do -s 1472</code>вдається,<code>ping -M do -s 1473</code>не вдається</li>
<li><strong>Моніторинг ICMP:</strong>Немає повідомлень "Потрібна фрагментація" (Тип 3, код 4).</li>
</ol>
<h3>Основна причина</h3>
<p>Тунель VPN зменшив MTU до 1400, але брандмауер блокував повідомлення ICMP «Потрібна фрагментація». Шлях MTU Discovery (PMTUD) не міг працювати, створюючи чорну діру MTU. Маленькі пакети підходять, великі пакети з установленим бітом DF мовчки відкидаються.</p>
<h3>роздільна здатність</h3>
<div class="command-box">
<code>! 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
</code>
</div>
<h3>Вивчений урок</h3>
<p><strong>Розмір має значення:</strong>Якщо невеликі запити працюють, але великі передачі не вдаються, підозрюйте проблеми з MTU/фрагментацією. Використовуйте ping із бітом DF, щоб перевірити MTU шляху.</p>
</div>
<h3>Приклад 4: Проблеми з якістю VoIP (насправді: неправильна конфігурація QoS)</h3>
<div class="case-study">
<h3>Симптом</h3>
<p>Голосові дзвінки мали переривчастий звук, періодичні перерви. Відбувається лише в робочий час (з 9:00 до 17:00).</p>
<h3>Початкові припущення (невірні)</h3>
<ul>
<li>Недостатня пропускна здатність</li>
<li>Сервер VoIP перевантажений</li>
<li>Якість з'єднання провайдера</li>
</ul>
<h3>Діагностичний процес</h3>
<ol>
<li><strong>Перевірка пропускної здатності:</strong>Під час напруженої години посилання використовується лише на 40%.</li>
<li><strong>Перевірка QoS:</strong>Голосовий трафік правильно позначено DSCP EF (46).</li>
<li><strong>Перевірка черги:</strong>Голосова черга мала лише 5% розподілу пропускної здатності (має бути 33%)</li>
<li><strong>Захоплення пакетів:</strong>Голосові пакети скидаються під час перевантаження</li>
</ol>
<h3>Основна причина</h3>
<p>Політика QoS існувала, але пропускна здатність розподілялася у зворотному напрямку: найкраще – 60%, голос – 5%. У робочий час, коли трафік даних збільшився, голосові пакети відкидалися через переповнення черги.</p>
<h3>резолюція</h3>
<div class="command-box">
<code>! 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
</code>
</div>
<h3>Вивчений урок</h3>
<p><strong>Проблеми на основі часу = ємність:</strong>Якщо проблеми виникають лише в години напруженої роботи, це не серйозний збій, а проблема ємності/QoS. Перевірте статистику черги, а не лише загальну пропускну здатність.</p>
</div>
<h2>Посилання на команду за симптомом</h2>
<table>
<thead>
<tr>
<th>Симптом</th>
<th>Шар</th>
<th>Команди для запуску</th>
<th>Що шукати</th>
</tr>
</thead>
<tbody>
<tr>
<td>Немає індикатора посилання</td>
<td>1 шар</td>
<td><code>show interfaces<br/>ethtool eth0</code></td>
<td>Статус: не працює, немає носія, кабель від’єднано</td>
</tr>
<tr>
<td>Втрата пакетів</td>
<td>Шар 1/2</td>
<td><code>show interfaces<br/>show interfaces counters errors</code></td>
<td>Помилки CRC, ранти, гіганти, зіткнення, пізні зіткнення</td>
</tr>
<tr>
<td>Не вдається перевірити ping шлюзу</td>
<td>2 шар</td>
<td><code>arp -a<br/>show mac address-table<br/>show spanning-tree</code></td>
<td>Немає запису ARP, MAC не розпізнано, STP блокується</td>
</tr>
<tr>
<td>Не вдається отримати доступ до віддаленої підмережі</td>
<td>3 шар</td>
<td><code>traceroute<br/>show ip route<br/>show ip route summary</code></td>
<td>Відсутній маршрут, неправильний наступний крок, петля маршрутизації</td>
</tr>
<tr>
<td>Підключення відмовлено</td>
<td>4 шар</td>
<td><code>telnet host port<br/>netstat -an<br/>tcpdump</code></td>
<td>Служба не прослуховує, брандмауер блокує, TCP RST</td>
</tr>
<tr>
<td>Повільна продуктивність</td>
<td>Шар 4+</td>
<td><code>ping (RTT)<br/>iperf3<br/>tcpdump<br/>show interfaces</code></td>
<td>Висока затримка, обмеження пропускної здатності, повторна передача TCP, нуль вікон</td>
</tr>
<tr>
<td>Не вдається розпізнати ім’я хоста</td>
<td>Шар 7</td>
<td><code>nslookup<br/>dig<br/>cat /etc/resolv.conf</code></td>
<td>Сервер DNS недоступний, неправильна конфігурація DNS, NXDOMAIN</td>
</tr>
<tr>
<td>Переривчасті краплі</td>
<td>Шар 1/2</td>
<td><code>ping -f (flood)<br/>show logging<br/>show interfaces</code></td>
<td>Невідповідність дуплексу, збій кабелю, повторна конвергенція STP</td>
</tr>
<tr>
<td>Інколи працює, інколи ні</td>
<td>множинний</td>
<td><code>Extended ping<br/>Packet capture<br/>Interface statistics</code></td>
<td>Проблема балансування навантаження, асиметрія ECMP, переповнення таблиці станів</td>
</tr>
</tbody>
</table>
<h2>Коли посилити</h2>
<p>Знайте, коли передати проблему TAC постачальника або старшим інженерам. Ескалація, коли:</p>
<ul class="checklist">
<li>Ви вичерпали всі кроки з усунення несправностей у своїй базі знань</li>
<li>Проблема потребує доступу/дозволів, яких у вас немає</li>
<li>Проблема пов’язана з помилкою програмного забезпечення постачальника або апаратним дефектом</li>
<li>Вплив на бізнес є критичним і чутливим до часу</li>
<li>Кілька команд повинні співпрацювати (програма + мережа + сервер)</li>
</ul>
<div class="tip-box">
<strong>Перед ескалацією:</strong>Задокументуйте все, що ви пробували. Інженерам TAC потрібна ця інформація, щоб уникнути повторення ваших кроків. включають:<ul>
<li>Повний опис симптомів</li>
<li>Час початку проблеми</li>
<li>Виконання діагностичних команд та їх виведення</li>
<li>Резервне копіювання конфігурації</li>
<li>Перехоплення пакетів (якщо актуально)</li>
<li>Те, що ви вже пробували</li>
</ul>
</div>
<h2>Створення вашої особистої бази знань</h2>
<p>Кожен сеанс усунення несправностей – це можливість навчитися. Створіть особисту базу знань:</p>
<h3>1. Створіть журнал усунення несправностей</h3>
<div class="command-box">
<code># 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
</code>
</div>
<h3>2. Створіть шпаргалку команд</h3>
<p>Упорядкуйте часто використовувані команди за сценарієм для швидкого використання під час усунення несправностей.</p>
<h3>3. Задокументуйте свою мережу</h3>
<ul>
<li>Топологічні діаграми (рівень 2 і рівень 3)</li>
<li>Документація щодо схеми IP-адрес</li>
<li>призначення VLAN</li>
<li>Стандартні конфігурації (шаблони)</li>
<li>Завідомо справні базові лінії (статистика інтерфейсу до проблем)</li>
</ul>
<h2>Загальні антишаблони, яких слід уникати</h2>
<div class="danger-box">
<h3>❌ НЕ: Робіть випадкові зміни без діагностики</h3>
<p>Зміна конфігурацій без розуміння проблеми часто погіршує ситуацію або маскує справжню проблему.</p>
</div>
<div class="danger-box">
<h3>❌ НЕ ТРИМАЙТЕ: припускайте, що мережа завжди несправна</h3>
<p>Часто «проблеми з мережею» пов’язані з проблемами програми, сервера чи клієнта. Зберіть докази, перш ніж прийняти провину.</p>
</div>
<div class="danger-box">
<h3>❌ НЕ МОЖЕТЕ: пропустіть документування кроків щодо усунення несправностей</h3>
<p>Ви витрачаєте час на повторення вже зроблених тестів або не зможете пояснити колегам, що ви пробували.</p>
</div>
<div class="danger-box">
<h3>❌ НЕ: Ігноруйте періодичні проблеми</h3>
<p>Періодичні проблеми часто є ранніми попереджувальними ознаками майбутньої невдачі. Дослідіть їх, перш ніж вони стануть критичними.</p>
</div>
<div class="danger-box">
<h3>❌ НЕ: виправляйте симптоми, а не першопричини</h3>
<p>Перезавантаження пристрою може відновити службу, але якщо ви не з’ясуєте, ЧОМУ було потрібно перезавантаження, проблема повториться.</p>
</div>
<h2>Резюме: контрольний список систематичного усунення несправностей</h2>
<div class="success-box">
<h3>✓ Перш ніж почати</h3>
<ul class="checklist">
<li>Дайте відповіді на п’ять ключових запитань (що змінилося? кого це вплинуло? постійне чи періодичне? відтворюване? що бачить інша сторона?)</li>
<li>Зберіть початкові симптоми та звіти користувачів</li>
<li>Перевірте наявність останніх змін або обслуговування</li>
</ul>
<h3>✓ Під час усунення несправностей</h3>
<ul class="checklist">
<li>Методична робота через рівні OSI (знизу вгору або зверху вниз)</li>
<li>Під час тестування змінюйте ОДНУ змінну за раз</li>
<li>Документуйте кожен тест і його результат</li>
<li>Використовуйте захоплення пакетів, щоб побачити фактичну поведінку трафіку</li>
<li>Порівняйте з завідомо справними базовими лініями</li>
</ul>
<h3>✓ Після вирішення</h3>
<ul class="checklist">
<li>Переконайтеся, що виправлення дійсно вирішило проблему</li>
<li>Задокументуйте першопричину та рішення</li>
<li>Оновіть свою базу знань</li>
<li>Якщо конфігурація змінена, оновіть документацію</li>
<li>Поміркуйте: чи міг моніторинг зафіксувати це раніше?</li>
</ul>
</div>
<h2>Висновок</h2>
<p>Усунення несправностей мережі – це і наука, і мистецтво. Наука дотримується систематичної методології, правильно використовує інструменти діагностики та розуміє протоколи. Мистецтво полягає в тому, щоб знати, які тести проводити в першу чергу на основі симптомів, розпізнавати шаблони з досвіду та знати, коли посилити.</p>
<p>Дотримуючись систематичного підходу, викладеного в цій статті — ставлячи правильні запитання, методично опрацьовуючи модель OSI, документуючи свої кроки та навчаючись на кожній проблемі, ви станете ефективнішими у вирішенні проблем і уникнете типових пасток, які призводять до марної втрати часу та неправильних виправлень.</p>
<p><strong>Пам'ятайте:</strong>Мета полягає не просто у відновленні служби, а в тому, щоб зрозуміти, ЧОМУ сталася помилка, щоб ви могли запобігти повторенню цього.</p>
<hr style="margin-top: 40px;"/>
<p style="text-align: center; color: #6c757d;">
<em>Останнє оновлення: 2 лютого 2026 р. | Автор: технічна команда Baud9600</em>
</p>
</div>