Кто узнаёт о падении сайта первым – вы или ваш клиент

Почему «сайт открывается» – не то же самое, что «сайт работает»

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

Проблема во второй половине. Сайт на WordPress теряет соединение с базой и показывает «Error establishing a database connection» – с кодом 200, потому что PHP отработал и что-то отдал. Плагин кэширования отдаёт пустую страницу – 200. Хостер вешает заглушку про неоплату – 200. Фаервол показывает капчу вместо контента – тоже нередко 200. Во всех этих случаях мониторинг по коду ответа молчит, а клиент видит сломанный сайт.

Лечится это проверкой по содержимому: сервис загружает страницу и ищет в ней текст, который там обязан быть. Для магазина – «Добавить в корзину», для лендинга – заголовок первого экрана, для API – фрагмент JSON. Можно наоборот: искать текст, которого быть не должно, – «Error establishing», «Service Unavailable», название плагина-заглушки.

Практическое правило: выбирайте якорь, который рендерится в самом конце. Если фраза приходит из базы или из шаблона, который подключается последним, её отсутствие означает, что сломалось что-то раньше. Заголовок в <title> для этого плохой якорь – он часто статичен и выживает при упавшей базе.

Пять вещей, которые ломаются тихо

Падение сайта заметно сразу. Дальше – то, что не подаёт признаков до самого конца.

Сертификат. Истекает по расписанию и всегда не вовремя. Let’s Encrypt живёт 90 дней и обновляется сам – пока не сломается cron, не поменяется вебрут или не переедет сайт. Предупреждать нужно за 14 дней: это два рабочих цикла, за которые можно спокойно разобраться, почему автообновление молчит. Проверять надо не только дату: цепочка без промежуточного сертификата – отдельная беда. Десктопные браузеры дотягивают недостающее звено сами, а мобильные клиенты, боты соцсетей и парсеры – нет. Сайт «работает у меня» и не работает у половины интернета.

Домен. Самая дорогая из тихих поломок. Напоминание о продлении уходит на почту, указанную при регистрации пять лет назад, – иногда на ящик человека, который давно не работает в компании. Предупреждать за 30 дней: продление домена может потребовать участия того, у кого есть доступ к аккаунту регистратора, а такого человека иногда приходится искать неделю. Дату окончания регистрации отдаёт сам реестр – по RDAP или WHOIS, это публичные данные. Никакого доступа к вашему аккаунту для этого не нужно, и статус платежа так не увидеть.

DNS-запись. Ломается при миграции: перенесли сайт, поменяли A-запись, забыли MX – и почта уходит на старый сервер. Или наоборот, при перехвате домена запись меняется без вашего участия. Проверка простая: раз в несколько минут спросить у резолвера значение записи и сверить с ожидаемым. Разошлось – сообщить.

Почтовый порт. Формы на сайте отправляются, письма не приходят. Это выясняется, когда клиент спрашивает, почему на его заявку не ответили. Проверка TCP-порта – самая грубая из возможных, но она отвечает на вопрос «принимает ли кто-нибудь соединение на 25 или 587».

Ночная задача. Бэкап, выгрузка в 1С, синхронизация остатков. У неё нет публичного адреса, поэтому обычным мониторингом её не поймать. Здесь работает обратная схема – heartbeat: задача сама зовёт сервис по завершении, а сервис поднимает тревогу, если звонка не было к назначенному времени. Единственный способ узнать, что бэкап не делается, до того как он понадобится.

Как не приучить себя игнорировать алерты

Это важнее выбора сервиса. Мониторинг, который будит зря, перестают читать через неделю – и тогда он хуже, чем никакого: создаёт ощущение, что всё под контролем.

Ложные тревоги берутся из четырёх мест, и от каждого есть защита.

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

Проблема на стороне наблюдателя. Если у самого сервиса мониторинга отвалилась сеть, он честно сообщит, что упало всё. Защита – проверка собственной связности по эталонным хостам перед тем, как поверить в любой сбой.

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

Мигающий монитор. Цель падает и поднимается каждые две минуты. За ночь это пятьдесят сообщений, после которых чат с алертами закрывают навсегда. Лечится схлопыванием: серия переключений собирается в одно сообщение с числом эпизодов.

Отдельно – тихие часы. Здесь легко перестараться: если заглушить всё ночью, смысл мониторинга исчезает. Разумная граница проходит по типу события. Напоминание «сертификат истекает через 12 дней» может подождать до утра. Авария – не может, у неё нет тихих часов.

Что показывать клиенту, а что нет

Статус-страница снимает половину входящих вопросов. Клиент, который может сам посмотреть, работает ли его сайт, не пишет вам «у вас лежит?» – и, что важнее, не пишет этого, когда всё работает.

Два правила. Первое: называйте сервисы словами клиента. «Оплата», «Каталог», «Личный кабинет» – а не prod-lb-03 и не api-gw. Внутренние имена хостов на публичной странице – это и непонятно, и лишняя информация для тех, кто будет ваш сайт ломать.

Второе: причину аварии формулируйте в общих словах. «Сбой на стороне хостинг-провайдера, восстановлено в 04:12» – достаточно. Версия PHP, имя упавшего сервиса и текст исключения – не для клиентской страницы.

Хорошая практика – вынести статус-страницу на домен клиента поддоменом. Тогда она выглядит частью его инфраструктуры, а не вашим сервисом, и ей верят больше.

Доказательство вместо спора

Разговор «у вас вечно всё падает» не выигрывается аргументами. Он выигрывается историей инцидентов: дата, длительность, причина. Три записи за полгода общей длительностью двадцать две минуты – это конец разговора, а не его начало.

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

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

Как это подключить за десять минут

Для типового клиентского сайта хватает четырёх проверок, и заводить их стоит в этом порядке.

Аптайм главной – интервал минута, диапазон ожидаемых кодов 200–299, три подтверждения перед тревогой. Ключевое слово на той же странице или на самой важной для бизнеса: фраза, которая приходит из базы. SSL – предупреждение за 14 дней. Домен – предупреждение за 30 дней.

Если есть формы – добавьте TCP-проверку почтового порта. Если есть ночные задачи – heartbeat, с запасом по времени: задача, которая обычно идёт двадцать минут, не должна поднимать тревогу на двадцать первой.

И последнее, о чём забывают все. Внесите проверяющего бота в исключения фаервола. Cloudflare, Wordfence, Nginx с лимитом запросов – любой из них может ответить проверяющему 403 или капчей, и работающий сайт будет помечен как упавший. Нормальный сервис мониторинга публикует свой User-Agent и IP-адреса именно для этого. Сверяйтесь по IP: User-Agent подделывается одной строкой, доверять ему как признаку нельзя.

Собрать такую связку можно на любом сервисе. Я веду клиентские сайты в Acme Pulse – это мой собственный продукт, и бесплатного плана на десять проверок хватает как раз на сайт, API, почтовый порт, сертификат и домен. Как он устроен внутри и почему механика достоверности алертов оказалась самой дорогой частью – в кейсе.