2Dit 
Тендеры и лиды
Информация
Сайт может выглядеть совершенно нормально, но при этом уже перестать выполнять важные задачи: не отправлять заявки, не обновлять цены, не принимать оплату или не передавать данные в CRM.
Самое неприятное в таких ситуациях — проблема часто обнаруживается не системой, а человеком. Например, клиент пытается оформить заказ и пишет менеджеру: «У вас сайт не работает».
Для бизнеса это означает не просто технический сбой. Это потерянная заявка, сорванный заказ, недовольный клиент и иногда — несколько дней работы в режиме «срочно всё починить».
Поэтому мы в 2ДИТ считаем, что мониторинг сайта должен отвечать не только на вопрос «открывается ли сайт?», но и на гораздо более важный: «всё ли в порядке с тем, что сайт должен делать?»
Рассказываем, что именно мы проверяем, как отличаем серьёзную проблему от случайного сбоя и какую информацию видит клиент.
Самый простой способ проверить сайт — раз в несколько минут открыть его главную страницу и посмотреть, отвечает ли сервер.
Это полезная проверка. Если сайт вообще перестал открываться, важно узнать об этом как можно быстрее. Но у неё есть очевидное ограничение: она проверяет только сам факт доступности страницы.
Представим интернет-магазин: главная открывается, каталог загружается, фотографии на месте. На первый взгляд всё хорошо. Но при этом обмен с 1С остановился три дня назад, поэтому цены и остатки давно не обновлялись.
Или другая ситуация: форма заявки на сайте перестала отправлять письма. Посетитель её заполняет, нажимает кнопку — получает сообщение об успешной отправке и уходит. А заявка до менеджера так и не доходит.
Есть и другие сценарии:
закончилась свободная память на сервере;
перестала работать интеграция с CRM;
не проходит онлайн-оплата;
истёк ключ внешнего сервиса;
остановилась отправка писем;
на сайте перестала работать капча и формы начали получать поток спама.
При этом главная страница во всех этих случаях может продолжать прекрасно открываться.
Поэтому хороший мониторинг должен проверять не только доступность сайта, но и его ключевые функции и связи с другими системами.
Поэтому на сайтах, которые мы ведём, мы заводим служебный адрес — «health-ручку». Это закрытая токеном страница, которую сайт отдаёт не человеку, а нашему мониторингу. По ней сайт сам отчитывается о себе изнутри: жива ли база, сколько осталось места, работает ли обмен с CRM, отвечает ли платёжный шлюз, не застряла ли очередь писем.
Выглядит ответ примерно так — и раз в десять минут мы читаем его целиком, а не только код ответа:
GET /health?token=•••HTTP 200 · 340 мс
"status": "degraded",
"checks": [
{ "проверка": "База данных", "status": "ok", "состояние": "отклик 12 мс" },
{ "проверка": "Место на диске", "status": "ok", "состояние": "занято 61%" },
{ "проверка": "Почта заявок", "status": "ok", "состояние": "очередь пуста" },
{ "проверка": "Обмен с 1С", "status": "fail", "состояние": "нет выгрузки 3 дня" },
{ "проверка": "Капча на формах", "status": "ok", "состояние": "ключ активен" }
]Набор проверок у каждого проекта свой: у интернет-магазина это склад и оплата, у медиа — импорт новостей, у сервиса с личным кабинетом — очереди и внешние API. Ручку пишем под ваш сайт: она знает, что для него значит «работает», а мы просто читаем её ответ.
Если у сайта такой ручки нет — ничего страшного, мониторинг всё равно работает в простом режиме: проверяем, что сайт открывается и отдаёт нормальный ответ. Ручку можно добавить потом, отдельной небольшой задачей.
Мониторинг, который постоянно присылает ложные тревоги, со временем перестают воспринимать всерьёз.
Представьте: несколько раз в неделю приходит сообщение «сайт недоступен». Вы открываете его вручную — всё работает. Через какое-то время такие уведомления начинают просто пролистывать.
Сигнал тревоги имеет ценность ровно до тех пор, пока на него реагируют. Поэтому мы потратили больше времени на то, чтобы мониторинг молчал в правильные моменты, чем на сами проверки.
Что мы сделали, чтобы ложных тревог не было:
Три попытки внутри одной проверки. Одна неудача — это ещё не событие: интернет иногда просто моргает.
Подтверждение на нескольких прогонах. Тревога уходит людям, только если картина повторилась.
Разные пороги для разных бед. Сайт отвечает ошибкой — это почти всегда правда, ждём недолго. Обрыв соединения или таймаут — типичная «моргалка», ждём дольше.
Пишем и о выздоровлении. Сообщение «упал» без парного «поднялся» оставляет человека в тревоге, поэтому второе приходит обязательно.
Между зелёным и красным есть жёлтый, и это не придирка. Несколько примеров, которые мы специально научились отличать:
Сертификат отдан не полностью. Браузеры такое достраивают сами — люди ничего не замечают, сайт работает. Будить кого-то ночью незачем, но и молчать нельзя: часть мобильных приложений и платёжных сервисов на этом спотыкается. Это жёлтая отметка и задача в план, а не авария.
Истёкший или чужой сертификат — уже красное: браузер показывает предупреждение на весь экран, и посетители уходят.
Сайт закрыт паролем. Тестовые стенды мы намеренно прячем за паролем. Сервер отвечает «сюда нельзя» — значит, он жив. Считать это падением было бы глупо, и мы не считаем.
Домен на кириллице. Такие адреса нужно приводить к техническому виду перед запросом, иначе сервер ответит ошибкой на пустом месте — и мониторинг будет «ронять» совершенно здоровый сайт.
Такие мелочи не видны в рекламе сервисов мониторинга, но именно из них состоит разница между системой, которой доверяют, и очередным источником шума.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13755 тендеров
проведено за восемь лет работы нашего сайта.
Вторая половина работы — не про «упало», а про «скоро упадёт». Аварии редко случаются внезапно: у них почти всегда есть предыстория, которую видно за недели.
Место на диске. Раз в сутки собираем, сколько занимает каждый сайт. Заполненный диск — одна из самых обидных аварий: сайт перестаёт принимать файлы и писать в базу, при этом «вроде работает». Растущий график виден заранее, и вопрос решается уборкой логов или расширением тарифа — спокойно, в рабочее время.
Сроки домена и хостинга. Даты окончания мы забираем из официальных реестров, а не полагаемся на письма регистратора, которые уходят в спам или на почту уволившегося сотрудника. Раз в день собираем одну общую сводку: что заканчивается в ближайшее время.
Версии CMS и шаблона. Отдельно следим, на каких версиях живут сайты: отставание на пару лет — это не «неаккуратно», это открытая дверь.
Незаметная деталь: реестры доменов не любят частых обращений и начинают отвечать отказом. Поэтому опрос идёт по ночам, с паузами между запросами. Мониторинг не должен создавать проблемы там, где их не было.
Мы проверяем сайты регулярно — базовые проверки выполняются каждые 10 минут.
Если сайт действительно перестал отвечать или обнаружена проблема в одной из критичных проверок, уведомление отправляется ответственным сотрудникам.
При этом разные ситуации обрабатываются по-разному.
Такой подход позволяет разделять аварию, требующую реакции, и замечание, которое можно спокойно исправить в рабочем порядке.
Нам важно, чтобы история работы сайта была понятна не только техническому специалисту. Поэтому для каждого проекта собирается история проверок и формируется страница доступности.
На ней можно посмотреть, насколько стабильно работал сайт за определённый период, и при необходимости разобраться, что происходило в конкретный день.
День считается «плохим», если в нём была хотя бы одна неудачная проверка — так же, как это показывают публичные страницы состояния крупных сервисов. Рядом с календарём хранится история: какая именно проверка падала в этот день. Через месяц не придётся вспоминать, что случилось семнадцатого.
И одно принципиальное правило: если за период данных нет, мы не рисуем 100 %. Отсутствие проверок — это отсутствие проверок, а не безупречная работа. Красивая цифра, за которой ничего не стоит, обесценивает все остальные.
Для бизнеса мониторинг — это прежде всего не про серверы, базы данных и технические показатели.
Он про несколько гораздо более практичных вещей.
Базовый мониторинг доступности можно подключить практически к любому сайту. От вас нужен только адрес проекта.
Если нужно контролировать не только доступность, но и ключевые функции, мы дополнительно определяем, что именно должно считаться нормальной работой сайта. Для одного проекта это будет обмен с 1С и онлайн-оплата, для другого — CRM, личный кабинет и несколько внешних сервисов.
После этого мониторинг работает автоматически: регулярно проверяет сайт, фиксирует результаты, уведомляет о проблемах и сохраняет историю. При этом сам сайт не нужно переделывать под какую-то конкретную технологию. Мы подстраиваем мониторинг под существующий проект.
В результате у вас появляется не просто проверка «сайт открывается или нет», а постоянный контроль его работоспособности.
И чем важнее сайт для бизнеса — продажи, заявки, личный кабинет, онлайн-оплата, интеграции — тем больше смысла в том, чтобы узнать о проблеме раньше клиента.
