История инцидентов — это хронология моментов, когда сайт переставал отвечать ожидаемым образом и затем восстанавливался. Она помогает не просто увидеть процент доступности, а понять, что именно происходило, как долго сохранялся симптом и повторяется ли он.
Начните с границ события: какой URL проверялся, какой ответ пришёл извне и когда снова появился ожидаемый результат. Затем сопоставьте эпизод с похожими сбоями и изменениями на сайте — так история превращается из списка тревог в рабочий материал для диагностики.
Что должно быть в записи об инциденте
Полезная запись отвечает на конкретные вопросы:
- когда внешний контроль впервые зафиксировал проблему и когда подтвердил восстановление;
- какой URL проверялся и какой результат ожидался;
- что наблюдалось: HTTP-код, тайм-аут, ошибка DNS или TLS, неожиданный редирект либо неверное содержимое;
- из какой точки выполнялась проверка и повторился ли симптом из других сетей;
- какие изменения, работы хостинга или действия команды происходили рядом по времени;
- кто проверил восстановление и каким способом.
Разделяйте наблюдение и причину. Например, код 502 подтверждает, что цепочка прокси или шлюзов не получила нормальный ответ, но сам по себе не доказывает, какой сервер или процесс виноват. Корневую причину устанавливают по журналам приложения, веб-сервера, балансировщика и данным провайдера.
Как анализировать историю падений сайта
1. Проверьте границы события
Уточните, что считается началом и окончанием инцидента в вашей схеме контроля. Одиночная неудачная проверка и подтверждённая недоступность — не всегда одно и то же: значение имеют частота проверок, повторные попытки и правило восстановления.
Сравните первую ошибку, последнюю ошибку и первый успешный ответ после неё. Это не заменяет серверные логи, но задаёт временной интервал, в котором нужно искать причину.
2. Сгруппируйте одинаковые симптомы
Не складывайте все падения в одну категорию «сайт не работает». Отдельно рассматривайте тайм-ауты, ошибки DNS, сбои TLS, ответы 4xx и 5xx, редиректы и случаи, когда сервер вернул успешный код, но не ту страницу.
Группировка показывает, повторяется ли один технический сценарий. Если тип ошибки каждый раз разный, вероятна более широкая проблема инфраструктуры или несколько независимых причин — это гипотеза, которую ещё нужно проверить.
3. Ищите повторяемость
Сопоставьте события по времени суток, дням, URL и точкам проверки. Регулярный сбой рядом с резервным копированием, импортом каталога или плановым заданием даёт направление для проверки нагрузки. Ошибка только на одном URL может указывать на конкретный обработчик, базу данных или внешнюю интеграцию.
Недоступность из одной сети не доказывает глобальное падение. Сначала сравните результат из других точек, DNS-ответы и маршрут, а затем отделяйте локальную сетевую проблему от сбоя сайта.
4. Сверьте инцидент с изменениями
Отметьте релизы, правки DNS, продление сертификата, переключение CDN, изменения правил доступа и работы хостинга. Совпадение по времени не является доказательством, но помогает расставить проверки по приоритету.
Начинайте с изменений, которые могли повлиять именно на наблюдаемый слой. При ошибке TLS сначала проверяйте сертификат и цепочку, при SERVFAIL — DNS-зону и DNSSEC, при 5xx — приложение, ресурсы сервера и промежуточные прокси.
5. Подтвердите восстановление
Открытие главной страницы в одном браузере ещё не закрывает инцидент. Повторите внешнюю проверку проблемного URL, убедитесь, что вернулся ожидаемый код и содержимое, а затем проверьте критичный пользовательский путь — например, вход, форму или корзину, если сбой затрагивал их.
Зафиксируйте, что было сделано и почему симптом исчез. Если причина осталась неизвестной, так и напишите: честная отметка полезнее выдуманного объяснения и поможет распознать следующий похожий эпизод.
Какие выводы нельзя делать по одной истории
История доступности показывает внешние симптомы, но не видит всё, что происходит внутри системы. Успешный HTTP-ответ не гарантирует работу JavaScript, отправку письма или завершение оплаты. Короткий список инцидентов также не доказывает надёжность на будущее.
Не оценивайте проблему только по общему проценту uptime. Два сайта с одинаковым показателем могут пережить разные ситуации: один длительный простой или несколько коротких сбоев в критичные моменты. Для решения важны время, длительность, затронутые функции и последствия для пользователей.
Как сделать журнал полезным заранее
До следующего сбоя настройте понятные правила:
- Проверяйте не случайную страницу, а критичный публичный URL с заранее известным ожидаемым ответом.
- Выберите частоту контроля и подтверждение сбоя с учётом допустимой задержки и риска ложной тревоги.
- Сохраняйте рядом с инцидентом заметки о релизах и инфраструктурных изменениях.
- Назначьте ответственного за проверку восстановления и краткое описание причины.
- После повторного сбоя обновляйте инструкцию: что смотреть первым, кому передавать проблему и по каким признакам закрывать событие.
Если сайт недоступен прямо сейчас, сначала используйте чеклист проверки падения. История нужна не вместо оперативной диагностики, а чтобы быстрее сузить круг причин и не начинать каждый раз с нуля.
Практический следующий шаг
Добавьте критичный URL в Web-Puls и после первого события проверьте, достаточно ли данных в истории для ответа на три вопроса: когда начался сбой, какой симптом наблюдался и чем подтверждено восстановление. Если ответа нет, уточните проверяемый URL, ожидаемый результат и порядок фиксации изменений.