Хостинг может быть быстрым, удобным и недорогим, но все его преимущества теряют смысл, если сайт регулярно перестает открываться. Для оценки стабильности серверов используют показатель uptime, или аптайм.
Обычно он выглядит убедительно: 99%, 99,9%, 99,99%. Разница между этими числами кажется почти незаметной. На практике дополнительная девятка способна означать часы разницы в допустимом простое за год.
Но есть более важная проблема. Цифра на странице хостинг-провайдера еще не говорит о том, насколько доступен именно ваш сайт. Сервер может работать, а приложение выдавать ошибку. Сайт может открываться из Москвы, но быть недоступным из другого региона. Мониторинг способен проверить только главную страницу и не заметить, что корзина интернет-магазина уже полчаса не работает.
Поэтому uptime полезно не просто знать, а правильно измерять.
Что показывает uptime сайта
В самом простом понимании uptime показывает долю времени, в течение которого сервис оставался доступным.
Если за определенный период сайт ни разу не переставал отвечать, его фактический uptime за этот период составляет 100%.
Если были простои, показатель уменьшается.
Например, 99% и 99,9% визуально отличаются всего одной цифрой после запятой. Но при непрерывной работе сервиса разница становится намного заметнее.
За условные 30 дней:
- 99% допускает примерно 7 часов 12 минут недоступности;
- 99,9% соответствует примерно 43 минутам 12 секундам;
- 99,99% соответствует примерно 4 минутам 19 секундам;
- 99,999% оставляет уже около 26 секунд.
Это простая математика, а не обещание конкретного хостинга.
Поэтому фраза высокая доступность без цифр почти ничего не говорит. Но и сами проценты нельзя оценивать в отрыве от того, как они получены.
Прежде всего нужно различать uptime инфраструктуры и доступность конкретного сайта.
Провайдер может измерять работоспособность своей сети, оборудования или определенного сервиса. Владелец сайта обычно заинтересован в другом: может ли посетитель прямо сейчас открыть его страницу и выполнить нужное действие.
Это не всегда одно и то же.
Представим сервер, который работает совершенно нормально. Процессор доступен, сеть исправна, диски функционируют. Но после обновления плагина WordPress начал возвращать ошибку 500.
С точки зрения физического сервера никакого простоя может не быть. Для посетителя сайт фактически недоступен.
Другой пример: главная страница открывается, но база данных перестала отвечать и личный кабинет интернет-магазина не работает.
Простой мониторинг главной страницы покажет зеленый статус, хотя важная часть проекта уже сломана.
Поэтому вопрос какой uptime у моего сайта требует сначала определить, что именно мы считаем доступностью.
Для небольшого информационного сайта достаточно проверить, что сервер возвращает корректную страницу. Для интернет-магазина имеет смысл дополнительно следить за каталогом, корзиной или другим критичным URL. Для API проверяется уже его конечная точка и ожидаемый ответ.
Почему нельзя проверить uptime вручную
Владелец открывает свой сайт несколько раз в день и ни разу не замечает проблемы. Можно ли считать, что uptime составляет 100%?
Нет.
Сайт мог не работать двадцать минут ночью, пять минут утром и еще несколько минут в тот момент, когда владелец занимался другими делами.
Ручная проверка показывает только состояние сайта в конкретную секунду.
Для нормального измерения нужен автоматический мониторинг.
Его принцип довольно простой. Внешняя система через заданные промежутки времени обращается к сайту и проверяет ответ. Если проверка успешна, сервис считается доступным. Если возникает ошибка, выполняются дополнительные проверки и при подтверждении проблемы фиксируется инцидент.
Интервал имеет значение.
Предположим, мониторинг обращается к сайту раз в десять минут. Сайт упал через секунду после очередной проверки и восстановился через девять минут.
Следующая проверка снова увидит работающий сайт.
Для такого мониторинга простоя вообще не существовало.
Если проверять сайт каждую минуту, вероятность пропустить короткий сбой значительно меньше.
Но и минутная проверка не дает абсолютно точной картины до секунды. Сбой продолжительностью двадцать секунд может произойти между запросами.
Поэтому цифра uptime всегда связана с методикой измерения.
Для обычного сайта интервал в одну или несколько минут дает гораздо более полезную картину, чем редкие ручные проверки.
Еще одна проблема заключается в ложных тревогах.
Один запрос не прошел из-за кратковременной сетевой проблемы между системой мониторинга и сервером. Это еще не обязательно означает, что сайт был недоступен для всех пользователей.
Хорошая система мониторинга может перепроверить сайт из другой точки перед тем, как объявлять аварию.
География особенно важна для проектов с распределенной аудиторией.
Если проверка выполняется только из одного дата-центра, она показывает доступность сайта прежде всего из этой точки. Проблема маршрутизации между отдельными сетями способна сделать ресурс недоступным для части пользователей, хотя мониторинг продолжит считать его исправным.
Для обычного российского сайта не обязательно создавать десятки точек наблюдения по всему миру. Но если аудитория распределена между несколькими странами или континентами, географический мониторинг становится полезнее.
Что именно нужно проверять кроме главной страницы
Самая простая проверка выглядит так: сервис запрашивает главную страницу и убеждается, что сервер отвечает.
Для небольшого сайта этого иногда достаточно.
Но ответ сервера сам по себе еще не означает, что посетитель получил правильную страницу.
Например, вместо сайта может открываться страница заглушки хостинга. Сервер при этом успешно отвечает, и примитивная проверка считает задачу выполненной.
Поэтому полезно контролировать не только наличие HTTP-ответа, но и его код.
Обычная рабочая страница чаще всего возвращает 200. Если вместо нее сервер начал постоянно отвечать 500, 502, 503 или 504, это уже инцидент.
С редиректами ситуация сложнее.
Код 301 или 302 не обязательно означает ошибку. Например, запрос к HTTP-версии сайта может штатно перенаправляться на HTTPS.
Поэтому мониторинг должен учитывать нормальное поведение конкретного URL, а не считать любой ответ кроме 200 аварией.
Еще надежнее проверять содержимое.
Можно убедиться, что в ответе присутствует ожидаемый элемент страницы. Тогда ситуация, когда сервер вместо сайта показывает постороннюю заглушку с кодом 200, не пройдет незамеченной.
Для динамического проекта имеет смысл выбрать несколько контрольных адресов.
Интернет-магазину недостаточно знать, что главная страница работает из кэша. База данных или PHP могут уже испытывать проблемы, а закэшированная главная продолжит открываться.
Можно отдельно проверять страницу каталога, карточку товара или другую динамическую часть.
При этом не нужно каждую минуту автоматически оформлять настоящий заказ или отправлять форму клиентского сайта. Мониторинг не должен создавать собственную нагрузку и мусорные данные.
Для сложных сервисов существуют синтетические проверки, имитирующие определенную последовательность действий. Но обычному владельцу сайта достаточно начать с нескольких действительно важных URL.
Полезно следить и за временем ответа.
Сайт может формально оставаться доступным, но вместо обычных 300 миллисекунд отвечать по 15 секунд.
Это еще не downtime, однако для пользователя разница между полностью недоступной страницей и страницей, которая практически не загружается, становится довольно условной.
График времени ответа способен заранее показать ухудшение ситуации.
Например, сайт обычно отвечает стабильно, затем каждую ночь появляются большие пики. Возможно, в это время запускается резервное копирование, импорт каталога или тяжелая задача Cron.
Без истории измерений такой закономерности можно вообще не заметить.
Отдельно стоит следить за SSL-сертификатом и доменом.
Сервер способен работать идеально, но просроченный сертификат заставит браузер предупреждать посетителей об опасности соединения. Истекшая регистрация домена сделает сайт недоступным еще до обращения к веб-серверу.
Это не классический uptime сервера, но с точки зрения бизнеса результат тот же: пользователь не может нормально попасть на сайт.
Поэтому системы мониторинга часто используются не только для проверки HTTP, но и для предупреждений о сроке действия сертификата и других важных событиях.
Как оценивать uptime хостинга без самообмана
Самая красивая цифра в рекламе не всегда является самой полезной.
Если провайдер заявляет определенный уровень доступности, сначала нужно понять, к чему именно относится показатель.
Речь идет о сети? Виртуальном сервере? Конкретной услуге? Учитываются ли плановые технические работы? Как определяется начало и окончание аварии?
Особенно важно отличать маркетинговую цифру от SLA.
SLA представляет собой условия уровня обслуживания. В нем может быть описано, какой показатель доступности обещает поставщик, как он рассчитывается, какие события исключаются и какая компенсация предусмотрена при нарушении условий.
Само наличие 99,9% на рекламной странице еще не означает, что при любом простое клиент автоматически получит компенсацию.
Нужно читать условия конкретной услуги.
Но даже хороший SLA не заменяет собственный мониторинг.
У провайдера есть его данные, у владельца сайта должны быть свои.
Это особенно полезно при периодических проблемах. Вместо сообщения сайт иногда не работает можно отправить поддержке конкретную информацию: 28 августа с 14:32 до 14:39 внешний мониторинг из нескольких точек не получал корректного ответа, а в 14:40 доступность восстановилась.
С такими данными искать проблему намного проще.
При оценке нового хостинга не стоит делать вывод и по одному дню наблюдений.
100% uptime за последние восемь часов ничего не говорит о поведении сервиса в течение месяца.
Чем длиннее период наблюдения, тем полезнее статистика.
При этом нужно учитывать характер простоев.
Один пятиминутный инцидент за несколько месяцев и ежедневные отключения по десять секунд могут дать похожие суммарные цифры, но ощущаться владельцем сайта совершенно по-разному.
Для интернет-магазина особенно неприятны сбои в часы максимального количества заказов. Для корпоративного сайта короткий ночной простой может иметь значительно меньшее значение.
Поэтому вместе с общим процентом полезно смотреть историю инцидентов.
Когда сайт находится на виртуальном хостинге, собственный мониторинг помогает отделить проблему конкретного проекта от массового сбоя.
Если одновременно перестали отвечать несколько ваших независимых сайтов на одном аккаунте, подозрение на инфраструктуру усиливается.
Если один сайт упал, а остальные на том же хостинге продолжают нормально работать, стоит проверить приложение, его базу, конфигурацию и лимиты ресурсов.
На VPS возможностей еще больше. Внешнюю проверку доступности можно сопоставить с внутренним мониторингом CPU, RAM, диска, базы данных и веб-сервера.
Например, внешний сервис фиксирует 503 ровно в те моменты, когда память заканчивается и система начинает активно использовать swap. Это уже гораздо полезнее, чем абстрактная жалоба на нестабильный VPS.
Не нужно стремиться к 100% любой ценой.
Абсолютная доступность в течение бесконечного времени практически недостижима. Оборудование обслуживается, программное обеспечение обновляется, сети испытывают сбои, а человеческие ошибки полностью исключить невозможно.
Вопрос заключается в другом: насколько часто происходят проблемы, сколько они продолжаются и насколько быстро инфраструктура восстанавливается.
Для небольшого сайта несколько минут редкого планового обслуживания могут быть совершенно приемлемы. Для сервиса, через который каждую минуту проходят платежи, требования будут значительно выше.
Поэтому выбирать хостинг только по количеству девяток в рекламном блоке неправильно.
Гораздо полезнее проверить условия SLA, репутацию провайдера, качество поддержки и затем включить независимый мониторинг своего сайта.
После запуска настройте уведомления так, чтобы узнавать о подтвержденной проблеме быстро, но не получать десятки сообщений из-за каждого одиночного неудачного запроса.
И не ограничивайтесь только фактом сайт отвечает.
Следите хотя бы за основной страницей, одним важным динамическим разделом, кодами ответа и временем отклика. Для коммерческого проекта добавьте контроль SSL и других критичных компонентов.
Тогда uptime перестает быть рекламным процентом и превращается в нормальный измеряемый показатель.
А самое ценное происходит в момент настоящего сбоя: о недоступности сайта первым узнает его владелец, а не клиент, который пишет в мессенджер с вопросом, почему ничего не открывается.
