Короткий ответ: график доступности сайта нужно читать как хронологию наблюдений, а не как непрерывную запись каждой секунды. Сначала выберите период и часовой пояс, затем найдите переходы между состояниями, сопоставьте их с интервалом проверок и только после этого оценивайте uptime. Узкая красная полоса может означать короткий подтверждённый сбой, но отсутствие красной полосы не доказывает, что между проверками не было ни одной ошибки.
Полезный график отвечает не только на вопрос «какой процент доступности», но и на более практичные: когда началась проблема, была ли она единичной или повторяющейся, из каких точек наблюдалась и что изменилось рядом по времени.
Что именно показывает график доступности
Обычно по горизонтали отложено время, а цветом или уровнем отмечен результат проверки: доступно, недоступно, замедлено, неизвестно. Но точный смысл состояния задаёт конкретный мониторинг.
Перед анализом выясните четыре вещи:
- что проверяется: главная страница, конкретный URL, API или другой ресурс;
- что считается успехом: установление соединения, допустимый HTTP-код, наличие текста, корректный TLS;
- как часто выполняется проверка;
- когда меняется состояние: после первой ошибки или только после подтверждения повторной проверкой либо другой точкой.
Без этих настроек одинаково выглядящие графики могут описывать разные события. Ответ 200 OK не гарантирует, что бизнес-функция работает, если мониторинг проверяет только главную страницу. И наоборот, ожидаемый редирект не должен становиться инцидентом, если он разрешён правилом проверки.
Как читать временную шкалу по шагам
1. Зафиксируйте период и часовой пояс
Сначала посмотрите границы окна: часы, сутки, неделя или месяц. При широком периоде интерфейс может укрупнять данные, объединяя несколько результатов в один пиксель или столбец. Поэтому обзорный график подходит для поиска подозрительных участков, а точные начало и конец инцидента нужно смотреть после увеличения масштаба или в журнале проверок.
Часовой пояс важен при сопоставлении с деплоем, логами и сообщениями пользователей. Если один источник показывает локальное время, а другой UTC, совпадающие события визуально разъедутся. В рабочей записи инцидента сохраняйте время вместе с часовым поясом, а не только «ночью» или «после релиза».
2. Найдите переходы, а не отдельные цвета
Главные точки графика — переход доступно → недоступно и последующий недоступно → доступно. Они задают наблюдаемое окно инцидента.
Дальше проверьте соседние результаты:
- одна ошибка между успешными проверками — краткий сигнал, который требует контекста;
- серия ошибок подряд — устойчивое наблюдаемое нарушение;
- чередование успехов и ошибок — нестабильность, возможная зависимость от узла, маршрута, балансировки или условия проверки;
- разрыв данных или состояние «неизвестно» — не то же самое, что подтверждённая доступность.
Не закрашивайте «unknown» мысленно зелёным. Отсутствие измерения означает недостаток данных: остановился агент, истёк таймаут инфраструктуры мониторинга, изменились настройки или результат не был получен.
3. Откройте детали красного участка
Цвет показывает класс события, но редко объясняет причину. В деталях ищите:
- HTTP-код или этап, на котором завершилась проверка;
- тип ошибки DNS, TCP, TLS или ожидания ответа;
- длительность запроса и таймаут;
- проверяемый URL и метод;
- точку мониторинга;
- число последовательных результатов одного типа;
- время первой ошибки, подтверждения и восстановления.
4. Сопоставьте участок с изменениями
Положите рядом временную шкалу релизов, DNS-изменений, продления сертификата, работ хостинга и уведомлений. Совпадение по времени — повод проверить гипотезу, но не доказательство причины.
Хорошая формулировка: «после изменения начались ошибки TLS на одной точке». Плохая: «релиз точно сломал сайт», если график показывает только временную близость. Причину подтверждают логи, трассировка, конфигурация и воспроизводимая проверка.
Почему короткий сбой может выглядеть по-разному
Мониторинг выполняет дискретные проверки. Между ними нет наблюдения, если система не использует дополнительный поток данных. Из этого следуют важные ограничения.
Сбой короче интервала может не попасть на график
Если сайт отказал и восстановился между двумя успешными проверками, синтетический мониторинг его не увидит. Поэтому зелёная шкала означает «в запланированные моменты проверки условие успеха выполнялось», а не «каждый запрос каждого пользователя был успешным».
Уменьшение интервала повышает временное разрешение, но само по себе не делает картину полной: остаются различия маршрутов, регионов, кэшей и пользовательских сценариев.
Начало и конец ограничены моментами наблюдения
Первая неуспешная проверка показывает, что к этому моменту проблема уже наблюдалась. Последняя успешная перед ней показывает, что раньше условие ещё выполнялось. Точный момент отказа лежит между этими наблюдениями, если нет более подробного источника.
Аналогично, первая успешная проверка после ошибок подтверждает восстановление к этому моменту, но не обязательно совпадает с секундой исправления. Поэтому длительность по графику — наблюдаемая оценка с точностью, ограниченной расписанием и логикой подтверждения.
Подтверждение инцидента добавляет задержку, но снижает шум
Некоторые системы не объявляют аварию после единственной ошибки: выполняют повторную проверку или ждут результат другой точки. Тогда на шкале могут существовать разные времена — первая ошибка, открытие инцидента, отправка уведомления и восстановление.
Это не ошибка интерфейса. В отчёте важно не смешивать их. Для реакции команды нужен момент уведомления, для технического разбора — первая неуспешная проверка, для расчёта по правилам сервиса — границы, которые использует его методика.
Как отличить короткий сбой от шумового сигнала
Один красный элемент не следует автоматически игнорировать или объявлять полноценной аварией. Проверьте контекст.
Сигнал убедительнее, если:
- соседние проверки показывают ту же ошибку;
- проблема подтверждена из нескольких независимых точек;
- код или этап сбоя одинаков;
- в логах origin, CDN или приложения есть событие в тот же период;
- обращения пользователей совпадают по времени и симптому.
Почему uptime не заменяет график
Итоговый процент сжимает весь период в одно число. Он не показывает, был ли простой единым длинным эпизодом или серией коротких, попадал ли он в часы нагрузки и затрагивал ли все точки.
График, наоборот, сохраняет порядок событий, но его нельзя читать без правил агрегации. При уменьшении масштаба интерфейс может отображать в одном сегменте множество проверок. Нужно выяснить, какой результат получает такой сегмент: худший статус, последний статус, доля ошибок или иная агрегация.
Если задача — проверить формулу и знаменатель, используйте отдельное руководство «Uptime сайта: как считать доступность». График нужен для интерпретации времени и структуры сбоев; формула — для сводного показателя. Эти инструменты дополняют, а не заменяют друг друга.
Ошибки чтения графика
«Тонкая полоса — значит сбой длился ровно столько, сколько она занимает на экране»
Ширина зависит от масштаба, плотности пикселей и агрегации. Смотрите отметки времени и исходные результаты.
«Зелёный график доказывает отсутствие ошибок у пользователей»
Он доказывает только успешность заданных проверок из заданных точек. Пользователь мог обращаться к другому URL, региону, IP-адресу или некэшированному сценарию.
«Одна точка упала — весь сайт был недоступен»
Сначала сравните другие точки и этап ошибки. Локальная сетевая проблема и глобальный отказ требуют разных выводов.
Практический чек-лист разбора
- Выбрать период и проверить часовой пояс.
- Уточнить URL, критерий успеха, таймаут и интервал.
- Найти первый переход в ошибку и первое восстановление.
- Открыть исходные результаты вокруг переходов.
- Сравнить коды, этапы и точки мониторинга.
- Отдельно отметить «unknown» и пропуски данных.
- Проверить, как обзорный график агрегирует несколько результатов.
- Сопоставить время с релизами, DNS, TLS, инфраструктурой и обращениями.
- Записать подтверждённые факты отдельно от гипотезы о причине.
- При необходимости изменить проверку так, чтобы она отражала важный пользовательский сценарий.
Публичную коммуникацию об уже разобранных событиях удобно отделять от рабочего графика мониторинга. Для этого подходит статус-страница с понятными состояниями и историей; подробнее — в материале «Зачем сайту статус-страница».
Как использовать график в Web-Puls
Добавляйте в мониторинг не «сайт вообще», а конкретный URL с осмысленным условием успеха. После сигнала открывайте историю вокруг перехода и сравнивайте результаты, а не ограничивайтесь процентом за период.
Если вам нужен регулярный график доступности и история коротких сбоев, добавьте сайт в Web-Puls. Первый полезный шаг после добавления — проверить URL, ожидаемый ответ и расписание наблюдений, чтобы график отражал реальную задачу, а не просто окрашивал шкалу.