Как найти причину, если сеть тормозит по утрам?

Если сеть тормозит по утрам, причина почти всегда живет в расписании, даже когда никто не помнит, что именно запланировано. В одно и то же окно сходятся входы сотрудников, применение групповых политик, синхронизация файлов, обновления, антивирусные проверки, резервное копирование и первые тяжелые запросы к рабочим системам. Исправлять это заменой коммутатора наугад дорого и обычно бесполезно.

Диагностика должна связать пользовательскую задержку с конкретным ресурсом и конкретным потоком в одну временную шкалу. Нужны данные до, во время и после сбоя: задержка приложения, загрузка интерфейсов, потери и отбросы, состояние серверных CPU, памяти и дисков, а также журналы заданий. Один утренний снимок показывает совпадение. Повторение на втором дне и контролируемое изменение дают причинную связь.

Утренний сбой нужно ловить до первого звонка

Повторяющуюся деградацию нельзя расследовать по показаниям пользователей в десять утра, когда она уже закончилась. Настройте сбор хотя бы за полчаса до обычного начала проблемы и оставьте его работать до стабильного периода. Интервал в 15 секунд подходит для общей картины; на интерфейсах с короткими всплесками полезны 1-5 секунд, если система мониторинга выдержит такой объем.

Сначала зафиксируйте симптом как измеряемую операцию. «Все медленно» не годится. Выберите две или три проверки, которые повторяют жалобу: время входа до появления рабочего стола, открытие одного файла известного размера, ответ конкретного внутреннего веб-метода, подключение к базе или загрузка небольшой страницы без внешних ресурсов. Запускайте их с одной и той же проводной контрольной станции по расписанию.

У каждой проверки должны быть начало, конец, результат и адрес назначения. Если веб-приложение открывается за 18 секунд, разделите путь на DNS, установление TCP-соединения, TLS и время до первого байта. Долгий DNS указывает не туда же, куда быстрый TCP с долгим ожиданием первого байта. Пользователь видит одну паузу, но инженер должен видеть этап.

Собирайте одновременно четыре слоя:

• клиент: время входа, DNS, TCP и прикладной операции;
• сеть: байты, пакеты, очереди, отбросы, ошибки и повторные передачи;
• сервер: CPU, память, дисковая задержка, сетевой интерфейс и очередь запросов;
• расписание: резервные копии, обновления, сканирование, синхронизация и пакетные задания.

Не начинайте с постоянного захвата всего трафика на всех портах. Он создает гору данных и риск захватить содержимое, которое вам не нужно. Счетчики и синтетические проверки сужают окно и участок. Пакетную трассировку включают коротко, на определенной паре узлов, когда уже понятен вопрос к трассе.

Одна временная шкала отсекает половину ложных версий

Все источники нужно свести к одной шкале времени, иначе близкие события будут выглядеть одновременными. Проверьте синхронизацию часов на клиентах, серверах, гипервизорах, сетевом оборудовании и системе резервного копирования. Зафиксируйте часовой пояс и не смешивайте локальное время с UTC без явного преобразования.

Сделайте таблицу с шагом в минуту или меньше: число активных пользователей, длительность контрольной операции, загрузка входящего и исходящего канала, прирост отбросов, TCP retransmits, CPU и задержка диска целевого сервера, начало и конец каждого задания. Важен прирост счетчика за интервал, а не накопленное значение со дня установки коммутатора. Миллион старых ошибок не объясняет сегодняшнее утро; сто новых отбросов за одну проблемную минуту объясняют гораздо больше.

Отмечайте границы, а не только пики. Если резервное копирование начинается в 08:00, канал заполняется в 08:03, повторные передачи растут в 08:04, а приложение замедляется в 08:05, версия правдоподобна. Если приложение тормозит уже в 07:55, копирование не может быть первой причиной, даже если позже оно делает ситуацию хуже.

Полезно сравнить три окна: спокойное время, проблемное утро и такое же утро без предполагаемого задания. Сравнение понедельника с воскресеньем часто вводит в заблуждение, потому что меняется и число пользователей, и набор пакетных процессов. Лучше перенести одно задание в согласованном тестовом окне или ограничить его скорость, оставив остальную нагрузку прежней.

Записывайте изменения в отдельной колонке. Перезапуск службы, переключение точки доступа или ручная остановка копирования меняют наблюдаемую систему. Без этой записи график может показать «самовосстановление», хотя его вызвал администратор.

Массовый вход создает несколько разных нагрузок

Утренний вход нагружает не только контроллер домена. Рабочая станция получает адрес, ищет DNS и контроллер домена, проверяет учетные данные, применяет политики, запускает сценарии, подключает сетевые диски, читает профиль и запускает программы автозагрузки. Сотня почти одновременных входов превращает каждую небольшую операцию в пачку обращений к DNS, LDAP, Kerberos, SMB и хранилищу профилей.

Поэтому средняя загрузка магистрали в 30 процентов не оправдывает сеть. Короткие микровсплески могут заполнить выходную очередь между двумя опросами, а медленный контроллер домена может задерживать вход при свободном канале. Смотрите на распределение по назначениям и протоколам, на очереди портов и на ресурсы служб, которые участвуют во входе.

В среде Windows начните с журнала Microsoft-Windows-GroupPolicy/Operational на контрольной станции. Руководство Microsoft по диагностике Group Policy советует связывать события одного применения политики по ActivityID и разделять обработку на подготовительную, основную и завершающую фазы. Это лучше, чем искать одно красное событие: длинная успешная фаза тоже может быть причиной задержки.

Проверьте, какие сценарии входа копируют файлы, какие GPO ставят пакеты, какие диски подключаются и где лежат перемещаемые профили. Один сценарий, который при каждом входе сравнивает большой каталог через WAN, способен создать регулярную волну без явной ошибки. Измерьте его отдельно на холодном и теплом кэше.

На контроллерах домена сопоставьте запросы аутентификации с CPU, диском и сетевым интерфейсом. В Windows Server 2025 Microsoft добавила отдельные счетчики DC Locator и LDAP-клиента, включая задержку успешных и неуспешных поисков контроллера, новые запросы, pending responses и average response time. На более ранних версиях опирайтесь на журналы Netlogon, Directory Service, DNS и обычные счетчики системы, не придумывая отсутствующие метрики.

Признаки массового входа имеют характерный набор: число входов резко растет, обращения к DNS и контроллерам домена идут тем же фронтом, файловый сервер профилей читает много мелких файлов, а проблема сходит на нет после завершения первой пользовательской сессии. Если повторный вход того же компьютера проходит быстро из-за кэша, это дополнительная улика, но не доказательство сети.

Популярный совет «разрешить проблему увеличением пропускной способности» часто ошибочен. Более широкий канал не ускорит перегруженный DNS, диск файлового сервера или последовательный сценарий входа. Сначала назовите ресурс, у которого растет очередь, и только потом меняйте емкость.

Обновления и копирование выдают себя направлением трафика

Фоновые задания различаются по направлению, адресам назначения и нагрузке на диск. Развертывание обновлений обычно дает большой исходящий поток от локального репозитория к множеству клиентов либо большой входящий поток через интернет-канал, если клиенты скачивают пакеты снаружи. Резервное копирование чаще читает рабочие серверы и пишет в репозиторий, поэтому одновременно нагружает сеть, исходный диск и целевое хранилище.

Проверьте не только расписание центрального задания. У клиентов бывают собственные случайные задержки, повторные попытки после ночного выключения и запуск «при первой возможности», когда пропущенное задание начинается сразу после включения. Именно поэтому администратор может честно сказать, что обновления назначены на ночь, а график все равно покажет утреннюю волну.

Сопоставьте пятерку признаков:

• адреса крупнейших отправителей и получателей в проблемное окно;
• отношение входящего трафика к исходящему на узком интерфейсе;
• фактическое, а не плановое время задания и его объем;
• очередь и задержку дисков источника и репозитория;
• ограничение скорости, число параллельных потоков и повторные попытки.

Если канал занят копированием, временное ограничение его скорости должно уменьшить задержку приложений в следующем сопоставимом окне. Если трафик снизился, а приложение осталось медленным, ищите общий диск, перегруженный прокси, серверную CPU или иной зависимый ресурс. Это важное различие: совпавшее по времени задание может быть нагрузкой, но не узким местом.

Не переносите все обслуживание на 02:00 без проверки. Ночью могут сходиться полные копии, репликация, выгрузки из баз, антивирус и обслуживание хранилища. Лучше разнести задания по зависимостям, задать допустимую полосу и оставить запас перед началом рабочего дня. Пропущенное задание должно иметь контролируемое окно повторного запуска, а не правило «сразу после включения».

Для каждого тяжелого задания храните владельца, сервер, источник, назначение, обычный объем, предел параллелизма и допустимое окно. Эта простая ведомость часто обнаруживает два независимых расписания, которые никто раньше не видел рядом.

Отдельно проверьте DNS и прокси, через которые идут обновления. Волна клиентов может не заполнить канал, но исчерпать число одновременных соединений, рабочие потоки или кэш промежуточного сервиса. В этом случае байты остаются умеренными, а время установления соединения или ответа DNS растет. Сравните прямую контрольную операцию с той же операцией через штатный промежуточный узел и следите за его очередями.

Нормализуйте трафик к реальной скорости интерфейса. Счетчик байт в секунду нужно умножить на восемь, чтобы сравнивать с битами в секунду, а служебные заголовки и особенности измерения оставляют небольшой разрыв между расчетом и номиналом. Для агрегированного канала смотрите загрузку и отбросы каждого физического участника: хеширование может положить один крупный поток на один линк, пока весь агрегат на графике выглядит свободным.

Данные NetFlow, IPFIX или sFlow помогают назвать крупнейшие пары адресов, порты и направления. Они показывают, кто занял полосу, но не заменяют интерфейсные счетчики: выборка может сгладить короткую пачку, а flow-запись не всегда объясняет аппаратный отброс. Используйте потоки для атрибуции, очереди для доказательства перегрузки и серверные метрики для проверки последствий.

Сравните объем полезной работы с поведением задания. Если ежедневное инкрементальное копирование внезапно читает полный набор данных, выясните, не сбросилась ли цепочка, не отключилось ли отслеживание изменений и не началась ли повторная индексация. Утренний пик бывает следствием ошибки предыдущей ночи: неудачная попытка заканчивается, клиенты включаются, а система запускает повтор. Журнал со статусом, обработанным объемом и причиной повтора полезнее строки расписания.

После ограничения задания проверяйте не только исчезновение жалоб, но и его завершение в допустимое окно. Ограничение, которое переносит копирование на весь рабочий день, просто размазывает конкуренцию. Подберите скорость и параллелизм так, чтобы интерактивные операции сохраняли базовую задержку, а фоновая задача выполняла требование по времени восстановления.

Перегруженный канал виден по очередям и потерям

Высокий процент использования сам по себе не доказывает перегрузку, а низкое среднее значение ее не исключает. Узкое место подтверждают растущая очередь, новые отбросы и увеличение задержки в тот же интервал. На коротком всплеске интерфейс может передать столько же средних байт в секунду, сколько вчера, но пакеты интерактивного приложения будут ждать за крупной передачей.

Снимайте счетчики на обоих концах подозрительного участка: клиентский access-порт, uplink коммутатора, WAN-интерфейс, виртуальный коммутатор и интерфейс сервера. RFC 2863 определяет стандартные IF-MIB счетчики ifHCInOctets, ifHCOutOctets, ifInErrors, ifOutErrors, ifInDiscards и ifOutDiscards. Они удобны для разных производителей, но сравнивайте дельты и учитывайте перезапуск устройства или обнуление счетчика.

Ошибки и отбросы означают разные вещи. CRC и другие input errors чаще ведут к физическому уровню, кабелю, оптике, трансиверу или согласованию параметров. Discards при отсутствии физических ошибок обычно указывают на заполненную очередь, политику QoS или нехватку буфера. Документация Cisco для show interfaces прямо связывает растущий Total output drops с насыщением выходных очередей, но конкретная семантика счетчика зависит от платформы.

На Windows-сервере соберите встроенные счетчики до утра. Команда создает циклический журнал и опрашивает сеть, TCP, процессор, память и диски каждые 15 секунд:

logman create counter MorningTrace -o C:\PerfLogs\MorningTrace.blg -f bincirc -max 1024 -si 00:00:15 -c "\Network Interface(*)\*" "\TCPv4\Segments Retransmitted/sec" "\Processor Information(*)\% Processor Time" "\Memory\*" "\PhysicalDisk(*)\*"
logman start MorningTrace

После проблемного окна остановите сбор:

logman stop MorningTrace

Microsoft рекомендует Data Collector Sets для длительного наблюдения, когда короткий просмотр Task Manager не ловит проблему. В ее руководстве по сетевым счетчикам есть Bytes Sent/sec, Bytes Received/sec, Output Queue Length, ошибки, отбросы и TCP Segments Retransmitted/sec. Порог из чужой статьи не заменяет базовую линию вашей системы: сравнивайте однотипные утра и пропускную способность реального интерфейса.

На Linux аналогичную первую картину дает sar, если sysstat уже собирает историю:

sar -n DEV,EDEV,TCP,ETCP -s 07:30:00 -e 10:00:00

В выводе DEV ищите rxkB/s и txkB/s, в EDEV - rxerr/s, txerr/s, rxdrop/s и txdrop/s, в ETCP - retrseg/s. Названия полей могут отличаться между версиями, поэтому сохраните заголовок вместе с данными.

Медленный сервер отделяется контрольными парами

Сеть и сервер различаются не командой ping, а сравнением операций, которые делят часть пути. Если ping до сервера стабилен, это подтверждает лишь прохождение небольших ICMP-пакетов в данных условиях. Приложение может ждать DNS, TLS, очередь веб-сервера, блокировку базы или диск, а сетевое устройство может обрабатывать ICMP иначе, чем рабочий трафик.

Постройте контрольные пары. Обратитесь к одному приложению с клиента в проблемном сегменте и с клиента рядом с сервером. Затем обратитесь с проблемного клиента к другому исправному серверу по тому же пути. Получится простая матрица:

• Медленно к одному серверу из всех сегментов: проверяйте сервер или его ближайшее подключение.
• Медленно ко всем серверам из одного сегмента: проверяйте access, uplink, Wi-Fi или маршрут сегмента.
• Медленно только по имени, но быстро по IP: проверяйте DNS и порядок разрешения имен.
• TCP соединяется быстро, а первый байт приходит поздно: проверяйте приложение, базу, диск или серверную очередь.
• Задержка и потери растут на нескольких назначениях: ищите общий сетевой участок.

На целевом сервере в ту же секунду измеряйте CPU, свободную память, paging, дисковую latency, длину очереди запросов и активные соединения. Высокая загрузка сетевого интерфейса сервера еще не делает сеть виноватой: сервер может сам создавать поток копирования или долго обслуживать запросы из-за диска.

Для проверки пропускной способности между двумя контролируемыми узлами подходит iperf3. Документация ESnet указывает, что клиент и сервер могут выдавать JSON, а параллельные потоки задаются параметром -P. Начните с одного короткого потока и отдельно проверьте направления:

iperf3 -c 10.20.0.15 -t 15 -J
iperf3 -c 10.20.0.15 -t 15 -R -J

Не запускайте много параллельных потоков на уже насыщенном рабочем канале: тест добавляет нагрузку и способен ухудшить сбой. Согласуйте окно, ограничьте тест или используйте изолированный VLAN. iperf3 отвечает на вопрос о доступной пропускной способности между двумя узлами, но не имитирует задержку конкретной базы или файловой операции.

Короткий пакетный захват полезен, когда нужно увидеть, где появляется ожидание: повторяется ли SYN, есть ли TCP retransmission, кто долго не подтверждает данные, сколько занимает DNS. Захватывайте обе стороны одной сессии с синхронизированными часами. Один захват на клиенте не всегда позволяет отличить потерю по пути от задержки сервера.

Wi-Fi и проводная сеть требуют разных доказательств

Если жалуются пользователи Wi-Fi, сначала повторите ту же операцию по кабелю в той же подсети или максимально близком маршруте. Утро меняет радиосреду: одновременно просыпаются клиенты, точки получают больше ассоциаций, возрастает конкуренция за эфир, а устройства могут переходить между точками. Загрузка проводного uplink при этом остается умеренной.

Для Wi-Fi смотрите число клиентов на радио, использование эфирного времени, повторные передачи кадров, уровень сигнала, отношение сигнал-шум, выбранный канал и события роуминга. Процент занятости Ethernet-порта точки доступа не показывает, сколько времени клиенты спорят за радиоэфир. Два клиента с плохим сигналом могут занимать непропорционально много эфирного времени на низких скоростях.

Не делайте вывод по индикатору «полоски Wi-Fi» на ноутбуке. Он показывает оценку сигнала, но не конкуренцию, помехи, повторные передачи или задержку за точкой доступа. Нужны данные контроллера или точки и контрольный проводной тест в то же время.

Если по кабелю быстро, а по радио медленно, проверьте распределение клиентов между точками и диапазонами до увеличения мощности. Слишком высокая мощность может удерживать клиента на дальней точке и ухудшать повторное использование каналов. Если медленно и по кабелю, вернитесь к общему uplink, WAN или серверу.

Отдельно исключите утреннее подключение гостевых и личных устройств, автоматическую синхронизацию фото и обновления мобильных систем. Здесь помогают разбивка трафика по SSID и назначению, а не догадка по числу людей в офисе.

Два утра дают причинную связь

Пошаговая диагностика укладывается в два сопоставимых утра, если подготовить сбор заранее. Первое утро нужно для локализации, второе для проверки одного контролируемого изменения. Менять одновременно расписание копирования, QoS и конфигурацию Wi-Fi нельзя: даже улучшение не скажет, что именно сработало.

1. Накануне выберите точную пользовательскую операцию и контрольные узлы. Синхронизируйте время, включите циклический сбор на подозрительных интерфейсах и серверах, выгрузите расписания заданий.
2. В первое утро отметьте начало и конец симптома. Найдите первый ресурс, у которого одновременно растут очередь, задержка или отбросы, и назовите крупнейшие потоки.
3. Проверьте зависимости предполагаемого виновника. Для входа это DNS, контроллер домена, GPO и хранилище профилей; для копирования это источник, сеть и репозиторий; для приложения это веб-узел, база и диск.
4. Выберите одно обратимое изменение: сдвиньте задание, ограничьте его полосу, уменьшите параллелизм или направьте тестовую группу клиентов к другому ресурсу.
5. Во второе утро повторите те же измерения. Версия подтверждается, если изменился предполагаемый фактор, исчезла соответствующая очередь и ускорилась пользовательская операция.

Разберем типичный провал рассуждения. В 08:10 пользователи жалуются на файловую систему, а WAN показывает 95 процентов. Команда сразу покупает более широкий канал. После замены жалобы остаются: резервное копирование действительно заполняло WAN, но файлы находились в локальном хранилище, где тот же процесс чтения поднял дисковую задержку. Контрольная пара с клиентом рядом с сервером показала бы медленное открытие без WAN и сэкономила бы замену канала.

Другой вариант выглядит наоборот. Сервер показывает невысокую CPU и нормальный диск, но клиенты нескольких площадок тормозят одновременно. На центральном выходном интерфейсе растут ifOutDiscards, а ограничение утренней раздачи обновлений убирает и отбросы, и задержку. Здесь сеть действительно была узким местом, а изменение расписания подтвердило механизм.

Храните пакет доказательств вместе: графики с одинаковой осью времени, дельты счетчиков, журналы задания, результаты контрольных операций и перечень изменений. Он нужен не для красивого отчета, а чтобы через месяц не расследовать тот же сбой заново после нового расписания.

Исправление должно убрать очередь, а не график

Исправление выбирают по найденному механизму. Массовые входы лечат сокращением и распределением операций входа, локальным размещением нужного содержимого, исправлением DNS и профилей, а иногда добавлением емкости конкретной службе. Фоновую передачу лечат расписанием, ограничением полосы и параллелизма. Перегруженный uplink требует перераспределения потоков, корректного QoS или увеличения емкости после проверки портов на обоих концах.

QoS не создает новую полосу. Он защищает чувствительный трафик при перегрузке, если классы определены по реальным приложениям и политика стоит на фактическом узком интерфейсе. Слепое повышение приоритета «всему корпоративному» лишь переносит потери в другой класс. После изменения проверяйте счетчики очередей каждого класса и пользовательскую задержку.

Увеличение канала оправдано, когда полезная нагрузка устойчиво подходит к доступной скорости, выходные очереди и отбросы растут, физические ошибки отсутствуют, а перенос или ограничение фоновых потоков не соответствует требованиям бизнеса. Если интерфейс свободен, а очередь растет на серверном диске, новый канал ничего не исправит.

После ремонта оставьте легкий постоянный контроль: длительность синтетической операции, использование ключевых интерфейсов, дельты errors и discards, TCP retransmits, серверную дисковую задержку и фактические окна тяжелых заданий. Порог задавайте по своей базовой линии и длительности, чтобы секундный допустимый пик не будил дежурного, а десятиминутная деградация не терялась в среднем за час.

Для сложной инфраструктуры GSE.kz может спроектировать серверную и сетевую часть как одну систему и поддерживать ее круглосуточно по Казахстану. Но даже интегратор начнет с временной шкалы и измерений: без них закупка оборудования остается ставкой.

Закройте расследование проверяемой формулировкой: «с 08:02 до 08:27 задание X передавало данные через интерфейс Y, на нем росли выходные отбросы, а после ограничения до согласованной скорости задержка операции Z вернулась к базовой». Если вы не можете написать такое предложение, причина еще не найдена.