Проблема: Приложение базы данных «медленно». Сетевая команда обвиняет серверную команду. Серверная команда обвиняет сеть. Между тем, пользователи разочарованы, и часы тратятся на круговую отладку.
Решение: Систематический, научный подход к устранению неполадок, который использует доказательства, а не предположения, для выявления коренных причин.
Стоимость устранения неполадок Haphazard: Потраченное время, неправильные исправления, которые маскируют реальные проблемы, указывание пальцем между командами и ухудшение пользовательского опыта.
Устранение неполадок в сети является фундаментальным упражнением в научном методе:
Эта статья предоставляет структурированную структуру для устранения сетевых неполадок, которая предотвращает распространенные подводные камни, такие как:
Прежде чем погрузиться в техническую диагностику, ответьте на эти пять важных вопросов, чтобы сузить область исследования:
Изменение конфигурации? Новое оборудование? Обновления программного обеспечения? Топологические модификации?
Один пользователь? Одно здание? Всем? Только конкретное применение?
Это происходит постоянно? Только в определенные часы? Случайные случаи?
Можно ли решить проблему по требованию?
Проверьте оба конца соединения
Модель OSI обеспечивает структурированную структуру для устранения неполадок. Работа от уровня 1 (Физический) вверх или от уровня 7 (Приложение) вниз, в зависимости от симптомов.
Когда использовать: Полная потеря связи, отсутствие световой связи или симптомы физического уровня
show interfaces, ethtool eth0show mac address-table, show spanning-treeping, traceroute, show ip routetelnet host port, netstat -anЗахват пакетовnslookup, dig, curl -vКогда использовать: Прикладные проблемы, где существует базовая связь
Начните с уровня 7 (работает ли служба SharePoint?) DNS-решение для исправления IP?) и работа вниз только при необходимости.
Используйте это быстрое диагностическое дерево, чтобы определить, какой слой выходит из строя:
Стек TCP/IP не работает. Проверьте службы ОС, переустановите сетевые драйверы.
NIC отключен, неправильный водитель, кабель отключен. Проверьте: ip link show Диспетчер устройств
Проверка: Физический кабель, состояние порта переключателя, назначение VLAN, таблица ARP
Проверка: таблица маршрутизации, правила брандмауэра, ACL. Использовать traceroute Где останавливаются пакеты
Проверка: настройки DNS-сервера, доступность DNS-сервера, брандмауэр блокировки порта 53
Проверка: правила брандмауэра, группы безопасности, сервис прослушивания портов
Проблема с самим приложением, аутентификацией или конфигурацией приложения
Когда у вас есть гипотеза о первопричине, используйте эти методы изоляции, чтобы подтвердить или отвергнуть ее:
Захват трафика в исходных, промежуточных точках и пункте назначения для определения того, где пакеты сбрасываются или изменяются:
# 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
Исключите внешние переменные, протестировав подключение к одному устройству:
# 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
Сравните конфигурацию и поведение с рабочей системой:
# 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")
Правильная документация предотвращает круговую отладку, когда вы пробуете одно и то же несколько раз, не осознавая этого.
Issue ID: TICKET-12345
Date/Time: 2026-02-02 14:30 UTC
Reported By: Jane Smith (jane.smith@company.com)
Affected Users: ~50 users in Building A, 3rd floor
Symptom: Cannot access file server \\fileserver01
Initial Observations:
- 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
Tests Performed:
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
Root Cause:
Dirty fiber connector on uplink between Building A floor switch
and distribution switch causing CRC errors and packet loss
Resolution:
Cleaned fiber connector with proper cleaning kit. CRC errors
dropped to zero. File server access restored.
Verification:
Users confirmed file server accessible. Monitored for 15 minutes
with no errors.
Time to Resolution: 25 minutes
Время отклика приложения базы данных ухудшилось с <100 мс до 5+ секунд. Команда приложений обвинила «сетевую задержку».
Буферы ОС сервера баз данных были слишком малы для продукта с высокой пропускной способностью × задержкой. Окно 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
Не думайте: "Медленный" не всегда означает "задержка сети". Всегда собирайте доказательства (задержка, захват пакетов для поведения), прежде чем делать выводы.
Подключение к серверу будет падать случайным образом, особенно под нагрузкой. Иногда работал нормально, иногда совершенно безответно.
Автопереговоры провалились. Сервер договорился о полнодуплексном, переключатель упал обратно на полудуплексный. Столкновения происходили только под нагрузкой, когда обе стороны пытались передавать одновременно.
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
Проверьте оба конца: Статус интерфейса показывает согласованные настройки. Несоответствие означает провал переговоров. Скорость/дуплекс жесткого кода для серверов.
Пользователи могут просматривать некоторые веб-сайты (Google, Yahoo), но не другие (банковский веб-сайт, портал компании). Работали небольшие HTTP-запросы, большие страницы.
ping -M do -s 1472 Успешно, ping -M do -s 1473 провалVPN-туннель уменьшил MTU до 1400, но брандмауэр блокировал сообщения ICMP «Fragmentation Needed». Путь 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.
Голосовые звонки имели дряблый звук, периодические отсева. Произошло это только в рабочее время (9 утра-5 вечера).
Политика 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 ошибки, ранты, гиганты, столкновения, поздние столкновения |
| Не могу пинг шлюз | Слой 2 | arp -a |
Нет ARP-записи, MAC не изучен, блокировка STP |
| Не удается добраться до удаленной подсети | Слой 3 | traceroute |
Пропавший маршрут, неверный следующий прыжок, петля маршрутизации |
| Подключение отказали | Слой 4 | telnet host port |
Сервис не слушает, брандмауэр блок, TCP RST |
| Медленная производительность | Слой 4+ | ping (RTT) |
Высокая задержка, ограничение пропускной способности, ретрансляции TCP, нулевые окна |
| Не могу определить имя хоста | Слой 7 | nslookup |
DNS-сервер недоступен, неправильная конфигурация DNS, NXDOMAIN |
| Прерывистые падения | Layer 1/2 | ping -f (flood) |
Дуплексное несоответствие, отказ кабеля, STP-конвергенция |
| Иногда работает, а не другие | многократно | Extended ping |
Проблема балансировки нагрузки, асимметрия ECMP, переполнение таблицы состояний |
Знайте, когда перейти к поставщику TAC или старшим инженерам. Эскалация когда:
Каждый сеанс устранения неполадок - это возможность обучения. Создайте личную базу знаний:
# 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
Организуйте часто используемые команды по сценарию для быстрой ссылки во время устранения неполадок.
Изменение конфигурации без понимания проблемы часто ухудшает ситуацию или маскирует реальную проблему.
Часто «сетевые проблемы» — это проблемы приложения, сервера или клиента. Соберите доказательства, прежде чем принять вину.
Вы будете тратить время на повторные тесты или не сможете объяснить коллегам, что вы пробовали.
Прерывистые проблемы часто являются ранними признаками надвигающейся неудачи. Исследуйте их, прежде чем они станут критическими.
Перезагрузка устройства может восстановить обслуживание, но если вы не узнаете, зачем ему нужна перезагрузка, проблема повторится.
Устранение неполадок в сети - это и наука, и искусство. Наука следует систематической методологии, правильно используя диагностические инструменты и понимание протоколов. Искусство заключается в том, чтобы знать, какие тесты следует проводить в первую очередь, основываясь на симптомах, распознавая закономерности из опыта и зная, когда следует наращивать.
Следуя систематическому подходу, изложенному в этой статье, задавая правильные вопросы, методично работая с моделью OSI, документируя свои шаги и изучая каждую проблему, вы станете более эффективными в устранении неполадок и избегании распространенных ошибок, которые приводят к потере времени и неправильным исправлениям.
Запомни: Цель состоит не только в том, чтобы восстановить сервис, но и понять, почему он потерпел неудачу, чтобы вы могли предотвратить его повторение.
Последнее обновление: 2 февраля 2026 | Автор: Baud9600 Техническая команда