Поддержка сайта: почему доля успешных проверок не равна времени доступности

В отчёте подрядчика половина проверок оказалась успешной. Значит ли это, что сайт работал половину времени? Только по этому числу — нет. Проверки могут идти с разными промежутками, а результат отдельного запроса относится к моменту наблюдения. При заказе сопровождения полезно заранее согласовать, как из журнала проверок получается показатель доступности.

Сначала выясните, что измеряли

Запрос главной страницы, вход в кабинет и оформление заявки проверяют разные свойства системы. В этой статье выбран один условный монитор с результатом up или down. Его критерий уже согласован вне формы. Инструмент не определяет, означает ли ответ HTTP 200 работающую корзину, и не проверяет сайт по адресу.

Better Stack определяет частоту как то, как часто выполняется проверка. UptimeRobot отдельно описывает, что при длительном состоянии down интервалы повторных проверок могут увеличиваться. Поэтому не следует автоматически считать, что каждая строка чужой выгрузки представляет одинаковое число минут. В расчёте нужны фактические отметки, а не только количество результатов.

Две успешные пробы из четырёх дают 50%. Если же по выбранному правилу переносить состояние каждой пробы до следующей, получится 420 секунд down и 300 секунд up. Доля времени up по этому правилу — примерно 41,67%. Оба числа арифметически верны, но отвечают на разные вопросы. Ни одно само по себе не восстанавливает истинную историю сервиса между запросами.

Перенос состояния — правило отчёта, а не запись скрытого события

В учебной форме правило называется «состояние слева до следующей пробы». Оно считает down от отметки 300 до отметки 720. Однако из двух результатов нельзя узнать, начался ли сбой сразу после первой успешной пробы или почти перед первой неудачной. Время восстановления также находится между наблюдениями, если нет дополнительных данных.

Системы мониторинга могут иметь свои правила подтверждения сбоя и восстановления. Поэтому наша формула не названа способом расчёта Better Stack или UptimeRobot. Здесь показана самостоятельная модель, чтобы при проверке договора спросить, какое правило использует конкретный отчёт и где это описано.

Что можно посчитать при дополнительной гипотезе

Допустим, между двумя соседними пробами состояние менялось не больше одного раза. Тогда между двумя down оно оставалось down, между двумя up — up, а при разных результатах момент единственного перехода неизвестен. Это отдельная гипотеза, которую журнал мгновенных проб сам не доказывает.

В примере интервал 300–480 даёт 180 секунд down по этой гипотезе. Два переходных промежутка, 0–300 и 480–720, могут добавить до 540 секунд к верхней границе. Получаются условные внешние границы от 180 до 720 секунд, то есть от трёх до двенадцати минут. Это границы выбранной модели, а не измеренный фактический простой и не доверительный интервал.

Какие данные запросить у подрядчика

Границы отчётного окна

Последняя успешная проба не должна автоматически добавлять время после окончания периода.

Времена и источник результатов

Фактические интервалы, используемый монитор и критерий up/down.

Правила начала и окончания инцидента

Повторные пробы, подтверждение восстановления и способ перевода результатов в длительности.

Паузы и исключения

Как учитываются отключённый монитор, обслуживание и отсутствие наблюдений; они не становятся успешными запросами сами по себе.

Проверочная форма принимает относительные целые секунды по возрастанию. Первая точка должна быть нулевой, последняя завершает окно. Паузы, пропущенные результаты, тайм-ауты как длительности запросов и несколько наблюдательных узлов здесь не моделируются. Статусы считаются корректно заданными пользователем.

Как использовать сравнение при выборе сопровождения

1. Уточнить, какую пользовательскую функцию должен проверять монитор.
2. Получить небольшой журнал с фактическими отметками и воспроизвести заявленную формулу отчёта.
3. Отделить долю успешных запросов от времени, присвоенного состояниям по выбранному правилу.
4. Согласовать обработку неизвестных участков и подтверждённых инцидентов до обещаний по доступности.

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

При обсуждении поддержки сайта с Левицкий Концепт принесите такой фрагмент журнала и описание критерия доступности. Это позволит согласовать понятный способ измерения, границы ответственности и действия после уведомления. Инструмент не запускает проверки, не отправляет сообщения и не оценивает реальные обязательства подрядчика: он показывает различие между данными наблюдения и правилами их интерпретации.