Клиент говорит «у вас медленно», а мониторинг зелёный: как проверить его сторону

MAATRIX

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

Шаг 2. Просим сменить сеть — короткая формулировка без жаргона

Если из шага 1 стало ясно, что проблема не про конкретный запрос, а про доступ в целом, следующий шаг — сменить сеть на стороне клиента. Если клиент был на домашнем Wi-Fi — попросите переключиться на мобильный интернет; если он и так был на мобильном — наоборот, попросите проверить через любой Wi-Fi (дом, офис, кафе). Формулировка для нетехнического человека:

Попробуйте, пожалуйста, буквально на минуту отключить Wi-Fi на телефоне
и открыть наш сайт через мобильный интернет (обычные моб. данные, не Wi-Fi).
Просто напишите — стало быстрее, так же медленно или без разницы.

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

Шаг 3. Сравниваем с другими сайтами — «а у вас и остальное тормозит?»

Третий шаг — короткий вопрос на сравнение:

Ещё один момент: у вас сейчас другие сайты (например, любой крупный
маркетплейс или видеосервис) тоже открываются медленно, или только наш?

Если тормозит вообще всё, что открывает клиент, — дело почти наверняка не в вашем сервисе: перегруженное устройство, старый браузер с кучей вкладок, проблема у провайдера в целом. Если тормозит именно и только ваш сервис, а остальной интернет летает — это весомый аргумент за узкую проблему на маршруте именно до вашего сервера, и следующие два шага стоит проходить обязательно, не пропуская. Как и с шагом 2, детальный разбор этого теста и таблица комбинаций ответов — в статье про отделение последней мили от хостинга; здесь фиксируем формулировку и идём дальше по скрипту.

Шаг 4. Просим скриншот speedtest и простой ping — команда, которую скопирует кто угодно

Если шаги 2-3 не дали однозначного ответа (например, клиенту неоткуда взять вторую сеть, или он забыл сравнить с другими сайтами), переходим к результату замера. Здесь важно дать клиенту не абстрактную просьбу «проверьте скорость», а конкретную, буквально копируемую последовательность действий.

Для скорости канала — обычный speedtest в браузере, без установки чего-либо:

Откройте, пожалуйста, сайт speedtest.net (или приложение Speedtest,
если оно уже стоит на телефоне), нажмите одну кнопку "Go" и пришлите
скриншот результата — там будет три числа: скорость скачивания,
скорость отдачи и Ping.

Оговорите клиенту сразу, что вы попросите не только скорость: она показывает общую пропускную способность канала, но не показывает маршрут до конкретно вашего сервера — можно иметь честные 100 Мбит/с и всё равно упираться в плохой участок именно на пути к вашему дата-центру. Поэтому вторым действием — простой пинг именно до вашего адреса, и здесь тоже нужна команда, которую нетехнический человек может скопировать целиком, не разбираясь, что она значит:

Windows: откройте меню Пуск, наберите "cmd", в открывшемся чёрном окне
введите (замените на ваш домен):
  ping ваш-домен.ru -n 10
и нажмите Enter. Пришлите скриншот того, что появится.

macOS: откройте Spotlight (Cmd+Пробел), наберите "Терминал", введите:
  ping -c 10 ваш-домен.ru
и нажмите Enter. Пришлите скриншот.

Не объясняйте клиенту, что означает каждая строка вывода — это не нужно. Достаточно, чтобы он прислал скриншот целиком: вам важны сами числа времени отклика и наличие потерь (строка вида "Packets: Sent = 10, Received = 10, Lost = 0" в Windows или "0.0% packet loss" на macOS), а это вы уже прочитаете сами. Держите в голове ограничение теста: чистый ping без потерь — не гарантия, что с сетью всё в порядке, ICMP-пакеты ведут себя не так, как настоящий трафик сайта, и могут не показывать потери, которые реально есть при передаче данных. Подробный разбор этого случая — почему ping бывает идеальным при живой проблеме в сети — в статье про потерю пакетов, которой не видно в ping.

Шаг 5. Для технических клиентов — трассировка до сервера

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

Windows: tracert ваш-домен.ru
macOS/Linux: traceroute ваш-домен.ru

Для более информативной картины (статистика по каждому узлу за минуту, а не разовый снимок) попросите mtr ваш-домен.ru — на macOS и Linux он часто уже установлен или ставится одной командой (brew install mtr / apt install mtr), на Windows потребуется скачать WinMTR. Как читать вывод mtr по колонкам и почему потери на промежуточном узле почти никогда не значат реальную потерю данных — отдельно разобрано в статье MTR вместо traceroute: как читать колонки; эту ссылку можно смело кидать техническому клиенту вместе с просьбой прислать вывод, чтобы он сам примерно понимал, что видит.

Не просите трассировку у нетехнического клиента первым шагом — вывод traceroute выглядит пугающе для человека, который не понимает, что такое хопы и AS-номера, и вы почти наверняка получите в ответ «я не понимаю, что это». Порядок шагов в этом скрипте выстроен намеренно: от простого и понятного к более техническому, и трассировка — почти всегда последний, а не первый вопрос.

Как формулировать это неайтишнику: три правила

Три простых правила, которые стоит держать перед глазами при написании любого из пяти шагов клиенту:

• Одно действие — одно сообщение. Не присылайте все пять шагов сразу единым списком — это выглядит как домашнее задание и отпугивает. Присылайте по одному, дожидайтесь ответа, переходите к следующему только если предыдущий не дал ясности.
• Никогда не объясняйте термин, если можно его избежать. Не «проверьте latency», а «пришлите скриншот того, что получилось»; не «выполните traceroute», а «скопируйте эту строку в чёрное окно и нажмите Enter». Клиенту не нужно понимать, что он делает — ему нужно понимать, что нажать.
• Всегда объясняйте зачем, одной короткой фразой. «Это поможет понять, на чьей стороне проблема» работает лучше, чем просьба без контекста — люди охотнее выполняют шаги, когда видят, что это не отговорка, а реальная часть поиска причины.

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

Здравствуйте! Чтобы быстрее найти причину, пройдите, пожалуйста,
по порядку и пришлите ответы одним сообщением:

1. Уточните точное время проблемы и было ли это постоянно
   или периодически, на всех страницах или на конкретной.
2. Отключите Wi-Fi на телефоне, откройте сайт через мобильный
   интернет — стало лучше?
3. Попробуйте открыть пару других крупных сайтов — они тоже
   тормозят или только наш?
4. Зайдите на speedtest.net, нажмите Go, пришлите скриншот.
5. Если возможно — выполните "ping ваш-домен.ru -n 10"
   (Windows) или "ping -c 10 ваш-домен.ru" (Mac) и пришлите
   скриншот результата.

Это займёт около пяти минут и поможет сразу понять, где искать
причину — у нас на сервере или на вашей стороне.

Что делать с собранными данными: локальная причина или реальная зацепка

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

Второй результат не менее полезен: данные не подтверждают локальную причину — мобильный интернет тоже медленный, другие сайты быстрые, пинг чистый, а трассировка упирается в задержку на участке ближе к вашему серверу, а не в последних одном-двух хопах у клиента. Это прямая зацепка на реальную проблему, которую собственный мониторинг мог не увидеть — например, если он проверяет доступность из одной точки или одного региона, а деградация специфична для конкретного провайдера или города клиента. Разбор того, почему мониторинг из одной точки создаёт ложное чувство благополучия и как расширить его на несколько городов и сетей, — в статье про мониторинг связности из десяти городов. А если у вас уже настроены health-check'и балансировщика, но они всё равно зелёные при живой проблеме у части пользователей, стоит посмотреть, что именно эти проверки на самом деле измеряют — часто не то, что видит реальный пользователь, — это разобрано в статье Health-чек зелёный, пользователи жалуются.

Практический вывод простой: не пытайтесь угадать, чья это проблема, до того как соберёте эти пять точек данных. Пять коротких сообщений клиенту почти всегда экономят больше времени, чем час гадания по логам сервера впустую или чем спор в переписке о том, кто прав. По состоянию на конец августа 2026 года ни один из этих пяти шагов не требует от клиента установки чего-либо — speedtest в браузере и ping в системной консоли есть на любом устройстве без исключений, а значит скрипт применим буквально к каждому обращению независимо от технического уровня человека на том конце переписки.

Частые вопросы