На вашей странице статуса указано, что все работает. Ваш APM отображается зеленым цветом. Тем временем клиент из Сингапура не может войти в систему. Потенциальный клиент из Бразилии отказался от регистрации. Корпоративное соглашение в Германии сорвалось, потому что "время ожидания демо-версии истекало".
Глобальный мониторинг работоспособности SaaS не является обязательным — это то, как вы видите, что на самом деле испытывают ваши клиенты.
Вы создали надежный продукт. Инфраструктура находится на AWS или GCP. Вы используете Cloudflare или Fastly. У вас есть базовый мониторинг работоспособности — вероятно, проверка из одного или двух мест каждые несколько минут.
Затем вы начнете получать билеты в службу поддержки из определенных регионов. «Невозможно получить доступ к приложению». «Вход по-прежнему невозможен». «Страницы не загружаются». Вы проверяете приборную панель — все выглядит нормально. Вы просите их попробовать еще раз — иногда это работает, иногда нет.
Вы игнорируете это как ошибку пользователя, проблемы с сетью на их стороне или временные проблемы. Но билеты продолжают поступать. И вы понимаете: у вас нет возможности проверить, что на самом деле испытывают пользователи в Сингапуре, Сан-Паулу или Йоханнесбурге.
Ваш мониторинг лжет вам — не намеренно, а по бездействию. Он проверяет из одного места и предполагает, что оно представляет весь мир.
Именно здесь глобальный мониторинг бесперебойной работы SaaS становится критически важным. Не как приятное приобретение, а как единственный способ узнать, действительно ли ваш продукт доступен для клиентов, которых вы пытаетесь охватить.
Интернет неоднороден. Запрос из Токио в ваш регион происхождения на востоке США проходит через совершенно другую инфраструктуру, чем запрос из Лондона.
DNS не является мгновенным или универсальным. Если ближайший к пользователю узел произвольной рассылки вашего DNS-провайдера перегружен, неправильно настроен или недоступен, этот пользователь не сможет разрешить ваш домен, даже если ваши серверы работают нормально. Разные преобразователи DNS могут возвращать разные результаты, а некоторые могут кэшировать устаревшие или неправильные записи.
Реальный сценарий. У крупного поставщика облачных DNS произошел 4-часовой сбой, затронувший только серверы имен в Азиатско-Тихоокеанском регионе. Продукты SaaS, использующие этого провайдера, показали 100-процентное время безотказной работы в ходе мониторинга в США, при этом оставаясь полностью автономными для 2 миллиардов потенциальных пользователей.
Маршруты BGP могут измениться, сломаться или стать неоптимальными без предупреждения. Утечка маршрута, неправильно настроенный путь AS или сбой в работе транзитного провайдера могут сделать ваши серверы недоступными из целых стран, в то время как они будут полностью доступны из других. Эти проблемы возникают регулярно и могут сохраняться часами.
Реальный сценарий. Крупный интернет-провайдер в Бразилии неправильно настроил маршрутизацию, в результате чего весь трафик к американскому SaaS-сервису проходил через Европу, прежде чем попасть в США. Задержка подскочила со 120 мс до 800 мс — функционально, но неприемлемо медленно для функций реального времени.
У вашей CDN есть сотни периферийных местоположений, но не все из них всегда работоспособны. Преимущество в Джакарте может быть снижено, в то время как преимущество в Сингапуре в порядке. Страница состояния CDN может не отражать региональную деградацию, и пользователи, перенаправленные на проблемный край, сталкиваются со сбоями или крайней медлительностью.
Реальный сценарий. Периметр CDN в Сан-Паулу в течение 6 часов выдавал 502 ошибки из-за проблемы с конфигурацией серверной части. Глобальный статус CDN показывался как «Рабочий», поскольку 95% ребер были в порядке. Бразильские пользователи считали SaaS полностью сломанным.
У крупных интернет-провайдеров есть соглашения о пиринге, которые влияют на поток трафика. Если точка пиринга между региональным интернет-провайдером и вашим облачным провайдером перегружена или происходит потеря пакетов, пользователи этого интернет-провайдера будут иметь ограниченный доступ к вашему SaaS — даже если у пользователей другого интернет-провайдера в том же городе проблем не возникнет.
Реальный сценарий. У крупного индийского интернет-провайдера возник спор о пиринге с американским облачным провайдером, который длился три недели. У пользователей этого интернет-провайдера время загрузки составляло более 5 секунд. SaaS-компания потеряла значительную долю индийского рынка еще до того, как осознала, что существует проблема.
Основная проблема: Все эти сбои зависят от местоположения. Ваша инфраструктура работает. Ваш код в порядке. Но где-то между вашими серверами и пользователями в определенных регионах что-то сломалось, и единственный способ обнаружить это — проверить, где на самом деле находятся эти пользователи.
Большинство инструментов мониторинга работоспособности были созданы для более простой эпохи — когда «сервер отвечает?» Это был достаточный вопрос. Для SaaS с глобальными пользователями этого уже недостаточно.
Многие системы мониторинга SaaS проверяют данные из 1–5 мест, часто сгруппированных в США и Европе. Если ваши пользователи находятся в Азиатско-Тихоокеанском регионе, Латинской Америке, на Ближнем Востоке или в Африке, вы не имеете никакого представления об их опыте. Региональное отключение просто не будет зарегистрировано.
Выполнение проверок из регионов AWS в инфраструктуру, размещенную на AWS, выигрывает от оптимизированного подключения к магистральной облачной сети. Реальные пользователи в бытовых или корпоративных сетях проходят совершенно разные пути с разными режимами сбоев.
Технически ваш SaaS может ответить, но загрузка займет 15 секунд. Простая проверка HTTP 200 показывает «включено», но для пользователей оно фактически выключено. Без пороговых значений задержки для каждого региона вы пропустите медленные сбои, которые расстраивают пользователей.
Когда происходит региональный сбой, вам необходимо знать: это DNS? Это сетевой путь? Это тайм-аут рукопожатия TLS? Без трассировки, MTR и анализа задержки вы не сможете диагностировать основную причину или предоставить доказательства своему хостинг-провайдеру.
Когда вы осуществляете мониторинг только из нескольких мест, вы видите лишь часть того, что испытывают ваши пользователи. Остальное — это «слепая зона», где сбои происходят незаметно.
Каждую минуту, когда ваш SaaS недоступен в каком-то регионе, вы теряете пользователей, доход и репутацию — часто даже не подозревая об этом.
Пользователи, которые не могут получить доступ к вашему SaaS, не всегда жалуются — они уходят. Если у пробного пользователя произойдет сбой во время первого сеанса, он исчезнет. Если платящий клиент сталкивается с повторяющимися проблемами, он начинает искать альтернативы. Вы увидите изменение показателей, но не будете знать, что оно вызвано проблемами региональной доступности.
Ваш маркетинг привлекает трафик со всего мира. Если процесс регистрации нарушен или невероятно медленный в определенных регионах, этот трафик возвращается. Вы заплатили за приобретение, но преобразование не удалось из-за региональной проблемы, о существовании которой вы не знали. САС повышается; LTV падает.
Google сканирует данные из разных мест по всему миру. Если Googlebot сталкивается с медленными ответами или сбоями в определенных регионах, это влияет на показатели Core Web Vitals, частоту сканирования и, в конечном итоге, на рейтинги на этих рынках. Ваш органический трафик падает в определенных странах, и вы понятия не имеете, почему.
Слухи распространяются. «Этот SaaS ненадежен в Азиатско-Тихоокеанском регионе». «Мы попробовали их, но приложение никогда не загружается должным образом из нашего берлинского офиса». Обзоры G2, обсуждения в Твиттере и общение в сообществе Slack формируют восприятие таким образом, что его трудно изменить. К тому времени, как вы узнаете о проблеме, ущерб уже нанесен.
Эффективный глобальный мониторинг работоспособности требует географического разнообразия, глубины диагностики и правильных порогов оповещения.
Охват – это не только количество, но и соответствие географии ваших пользователей. Если у вас есть пользователи в Юго-Восточной Азии, вам нужны узлы в Сингапуре, Джакарте, Мумбаи, Токио, Сиднее. Если вы нацелены на Латинскую Америку, вам нужны Сан-Паулу, Буэнос-Айрес, Мехико. В каждом месте показаны разные условия сети.
Нанесите на карту места мониторинга, где находятся ваши платящие клиенты.
При возникновении сбоя необходимо знать, на каком участке сетевого пути произошел сбой. Это разрешение DNS? Конкретный сетевой переход? Ваше преимущество CDN? Данные Traceroute и MTR из пострадавшего региона дают вам возможность диагностировать основную причину и эффективно передавать ее поставщикам.
Диагностические данные превращают «это где-то внизу» в «вот почему».
Время отклика 300 мс из Токио — это нормально или это ухудшение? Без исторических данных ничего не скажешь. Непрерывный мониторинг формирует базовые показатели для каждого местоположения, поэтому вы можете предупреждать об отклонениях от нормы, фиксируя медленное снижение производительности до того, как оно перерастет в сбои, и отличая реальные проблемы от разовых сбоев.
Базовые показатели позволяют вам предупреждать о «хуже, чем обычно», а не просто о «падении».
Пошаговое руководство по внедрению мониторинга, который фактически выявляет региональные сбои.
Просмотрите аналитику, чтобы определить 20 лучших стран по активным пользователям и доходам. Узнайте, откуда берутся регистрации, где конвертируются пробные версии и откуда поступает доход от расширения. Это регионы, из которых вы должны вести мониторинг.
Не каждая конечная точка нуждается в глобальном мониторинге. Сосредоточьтесь на: главном URL-адресе приложения, конечных точках входа/авторизации, процессе регистрации, конечных точках API, используемых клиентами, и любых общедоступных страницах, важных для SEO или конверсий.
Выбирайте сервис мониторинга с широким географическим охватом — не менее 50 локаций на всех континентах. Убедитесь, что покрытие соответствует географии вашего пользователя. Установите интервал проверки в 1 минуту для критических конечных точек; 5 минут для второстепенных страниц.
Не просто предупреждайте об ошибках — предупреждайте, когда время ответа превышает допустимые пороговые значения. Для SaaS учитывайте: <1 с для страницы входа, <2 с для загрузки информационной панели, <500 мс для вызовов API. Для отдаленных мест региональные пороговые значения могут быть немного выше.
Настройте оповещения для срабатывания при сбое или ухудшении работы определенных регионов. Направляйте высокоприоритетные региональные оповещения дежурным инженерам. Интегрируйтесь со Slack, PagerDuty или существующим рабочим процессом управления инцидентами.
Убедитесь, что вы можете запускать трассировку и MTR из любого места мониторинга по требованию. При срабатывании оповещения вам потребуются немедленные диагностические данные, чтобы определить, связана ли проблема с DNS, сетевой маршрутизацией, CDN или источником.
Установите повторяющееся напоминание в календаре, чтобы отслеживать региональные тенденции работоспособности и задержек. Ищите медленное ухудшение, не вызывающее оповещений, регионы с постоянно более высокой задержкой и закономерности, которые коррелируют с жалобами пользователей или данными об оттоке.
Задокументируйте, что делать при обнаружении регионального сбоя: как проверить проблему, с кем связаться в вашей CDN или хостинг-провайдере, какие диагностические данные собрать и как сообщить о статусе затронутым клиентам.
Latency Global был создан специально для обеспечения глобальной видимости, необходимой продуктам SaaS. Мы отслеживаем данные из более 70 реальных мест на 6 континентах, охватывая все основные регионы, где могут находиться ваши пользователи.
Каждая проверка включает полную разбивку по времени (DNS, TCP, TLS, TTFB), и при исследовании проблем вы можете запускать трассировку и MTR из любого места. Исторические данные показывают тенденции по регионам, поэтому вы можете обнаружить ухудшения качества до того, как они перерастут в сбои. Цена проста: 5 долларов США в месяц за 5 мониторов с доступом ко всем местоположениям.
Глобальный мониторинг требует больших затрат на инфраструктуру, поэтому стоимость большинства инструментов составляет 50–500 долларов в месяц. Мы сохраняем его доступным для SaaS на ранней стадии, уделяя особое внимание тому, что важно: географическому охвату и глубине диагностики.
Продукты SaaS обычно обслуживают пользователей по всему миру, а не только из одного региона. В отличие от традиционного локального программного обеспечения, ваше SaaS должно быть доступно из любой точки мира, где находятся ваши клиенты. Региональные сбои, вызванные проблемами DNS, проблемами маршрутизации BGP, сбоями CDN или проблемами пиринга интернет-провайдера, могут сделать ваш продукт недоступным для целых рынков, но при этом он будет выглядеть полностью работоспособным из вашего местоположения мониторинга. Глобальный мониторинг работоспособности — единственный способ узнать, что на самом деле испытывают ваши международные пользователи.
Это зависит от географии вашего пользователя, но более 50 местоположений — это хорошая база для полного охвата. Ключевым моментом является обеспечение мониторинга в каждом регионе, где у вас есть значительные пользователи или доходы. Если 15 % вашего ARR приходится на Азиатско-Тихоокеанский регион, вам понадобится несколько узлов в Азиатско-Тихоокеанском регионе. Если вы расширяетесь в Латинскую Америку, вам нужны узлы в Бразилии, Аргентине, Мексике. Сопоставьте охват мониторинга с важностью бизнеса, а не только с количеством пользователей.
Панели мониторинга CDN и облачных провайдеров отображают их внутренний вид, который часто ограничен. Они могут показывать, что «все системы работают», в то время как пользователи в определенных регионах испытывают сбои из-за проблем с пирингом, проблем с маршрутизацией BGP или ухудшений на периферийном уровне, которые не регистрируются как полные сбои. Независимый мониторинг за пределами вашей инфраструктуры дает вам достоверную информацию о том, что на самом деле испытывают конечные пользователи, что часто отличается от того, что показывают информационные панели поставщиков.
Оба приоритетны по влиянию на бизнес. Начните с: (1) основного URL-адреса приложения или информационной панели, (2) конечных точек входа/авторизации, (3) процесса регистрации, (4) конечных точек API, используемых клиентами, (5) домашней страницы маркетингового сайта. Для SaaS поток аутентификации особенно важен — если пользователи не могут войти в систему из региона, они не смогут использовать ваш продукт. Конечные точки API имеют значение, если у вас есть платформа интеграции или клиенты, использующие ваш API.
Благодаря интервалу проверки в 1 минуту вы можете обнаружить сбои в работе в течение 1–2 минут. Оповещение должно быть немедленным после подтверждения сбоя (обычно после 2–3 последовательных сбоев, чтобы избежать оповещения о кратковременных сигналах). О критически важных конечных точках на основных рынках необходимо знать в течение 5 минут после начала сбоя. Чем быстрее вы обнаружите проблему, тем быстрее вы сможете диагностировать и устранить проблему или, как минимум, сообщить о статусе пострадавшим клиентам.
Даже если проблема находится в восходящем направлении, мониторинг дает вам: (1) свидетельство существования проблемы (вы не можете исправить то, что не можете доказать), (2) диагностические данные (traceroute, MTR) для определения конкретного провайдера или узла, вызывающего проблемы, (3) документацию для эффективного эскалации в вашу CDN или хостинг-провайдера и (4) данные, информирующие о том, нужно ли вам добавить избыточность, сменить провайдера или добавить периферийные местоположения в затронутых регионах. Знание о проблеме является первым шагом к любому смягчению последствий.
Перестаньте задаваться вопросом, действительно ли ваш SaaS доступен в Сингапуре, Сан-Паулу или Сиднее. Добавьте конечные точки, выберите места для мониторинга и посмотрите, что на самом деле испытывают ваши глобальные пользователи — прежде чем они расскажут вам об этом.
5 долларов США в месяц. • Более 70 локаций (скоро еще 40). Без контрактов. • Отмена в любое время.