Большинство из нас регулярно сталкивается с вопросом технической доступности сайтов, которые мы посещаем ежедневно. Хотя кажется, что надежные каналы доступа и высокая скорость связи уже давно решили эту проблему, но появление мобильных устройств, облачной инфраструктуры, распространение Интернета в регионы заставляют по-прежнему задумываться: а почему для меня (или для моих пользователей) этот сайт не открывается или работает некорректно? И как открывается (и вообще выглядит) мой сайт для моих пользователей?
Как ответить на эти вопросы?
Техническая доступность веб-сайта
Начну немного издалека. Находясь только в одной точке Сети (используя одно подключение к Интернету) мы не можем достоверно сказать, работает ли веб-сайт, на который мы заходим, если он у нас не открывается. Проблем тут может быть множество, например:
- Недоступность (низкая скорость обмена данными) нашего сегмента Сети и «основной Сети». Это хорошо заметно, когда заходишь с мобильного в метро на какой-нибудь сайт: дождаться открытия удается только в зоне уверенного приема сигнала, если сигнал слабый, то сайт недоступен.
- Более опасная модификация предыдущей проблемы, когда настройки прокси-сервера (защиты от DDoS, облака, сетевой инфраструктуры) изменяют первоначальные запросы от пользователей, что приводит к неверному функционированию сайта. Наиболее безобидный пример: для половины пользователей сайт открывается с www без редиректа, для остальных — с редиректом.
- Низкая скорость работы сайта (или канала связи, к которому подключен сервер). В этом случае для ряда пользователей (у которых опять-таки небыстрый канал или нестабильное соединение с Сетью) сайт будет открываться очень долго или вообще не откроется. В этом случае на реальные проблемы доступности сайта накладываются проблемы доступности пользователей.
- Достаточно новая (для Рунета) проблема, когда из-за большого количества объектов / размер страниц на медленном или нестабильном соединении (читай мобильные или публичный WiFi) пользователь просто не успевает дождаться загрузки / отображения страниц в браузере.
За кадром пока остаются вопросы функциональной доступности сайта: когда, в целом, сайт работает, но у ряда пользователей по определенным причинам (существенный) функционал сайта не работает. Например, проверка Captcha при регистрации новых клиентов.
Находим проблемы доступности
К сожалению, команда разработки или поддержки сайта (в офисе) самостоятельно может отследить только малую часть описанных проблем, а именно: замерить время ответа сервера на ключевые запросы и оптимизировать этот показатель; устранить серверные ошибки сайта; продиагностировать общее время открытия страниц сайта и устранить ключевые проблемы клиентской доступности.
Но отследить проблемы технической доступности, связанные со связностью и скоростью работы Сети вовне, внутренняя команда сама по себе не сможет. Нет, можно, конечно, попросить каждого сотрудника проверить сайт из дома, но это далеко не всегда реально и нормальным решением быть не может.
Связность распределенной сети
И снова уйду немного в сторону от темы. Если у нас есть пользователи из разных частей города / регионов России или мира, то однозначно сказать, доступен ли для них наш сайт или нет, мы не можем (только если физически не сядем рядом с ними). Для проверки проблем географической доступности нам нужен сеть точек (серверов), которые сами по себе будут доступны (будут видеть друг друга) — связная сеть. Только в этом случае, поставив точку проверки «рядом» с нашими пользователями и убедившись, что у самой точки нет проблем технической доступности (она видит другие точки, и скорость подключения к Сети у нее достаточная) мы можем с твердостью заявить: «Да, сайт для указанных пользователей доступен» или «Нет, сайт для этих пользователей недоступен».
Пример: у нас есть аудитория банка из Москвы, Санкт-Петербурга, Екатеринбурга и Казани. Однозначно сказать, что сайт банка доступен для нашей аудитории (и у сайта нет каких-либо проблем для указанной аудитории) мы сможем, только проверяя сайт из указанных городов. И этом сами точки проверки должны постоянно находиться «в Сети», иначе мы не сможем положиться на их данные: если «упадет» канал между Москвой и Казанью, то все внешние ресурсы станут для казанцев недоступны. И информация о том, что и нащ сайт станет для них недоступен, не будет ценна: проблемы с доступностью есть, но решить мы их не можем, и проблемы имеют глобальный характер.
Но если иногда, когда с каналом связи все хорошо, наш сайт становится недоступен для казанцев — это уже повод задуматься и начать искать проблему, чтобы повысить качество предоставляемых услуг.
Распределенный мониторинг
Возвращаясь к заявленным вопросам. Чтобы узнать, как открывается или выглядит сайт для моих (распределенных, мобильных, региональных) пользователей, необходимо использовать сеть точек распределенного мониторинга, которые будут максимально близко находиться к целевой аудитории. Если для разных регионов России ситуация более-менее понятна: просто проверяем доступность сайта из нужных городов, то для мобильных пользователей интересно проверять покрытие (скорость) сети из разных точек по городу — и с радостью находить проблемы доступности — хотя это актуально только для операторов мобильной сети и 3/4/5G.
При этом в случае проверки региональной доступности важно убедиться, что сами точки проверки доступны, что в самой сети точек проверки не нарушена связность.
Сервисы мониторинга
В Рунете есть всего несколько сервисов, предлагающих проверку сайта из нескольких городов России (т.е. именно распределенный географический мониторинг):
- Host Tracker, 4 точки в России (Москва — 2, Санкт-Петербург — 2), проверка доступности.
- Ping Admin, 20 точек в России (Москва — 7, Санкт-Петербург — 2, Нижний Новгород, Владивосток, Новосибирск и др.), проверка доступности (несколько алгоритмов)
- WEBO Pulsar, 11 точек в России (Москва — 4, Санкт-Петербург — 2, Екатеринбург, Новосибирск, Хабаровск, Самара, Краснодар, протестировать их всех точек), проверка доступности, скорости, времени открытия страниц (несколько алгоритмов).
Автор: sunnybear
