Управление инцидентами

Как работать с инцидентами мониторинга: от первого сбоя до восстановления

Инцидент объединяет последовательные неуспешные проверки в одну связанную историю. Разберите, когда началась проблема, сколько ошибок произошло, когда сервис восстановился и какие данные нужны команде для диагностики.

Создать аккаунт Открыть материалы

Управление инцидентами мониторинга в UpWatch

Краткий ответ

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

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

UpWatch показывает внешние симптомы и историю доставки email-уведомлений, но не читает внутренние логи приложения и не определяет первопричину автоматически. Окончательный вывод команда делает по данным мониторинга вместе с серверными логами, метриками и изменениями инфраструктуры.

Почему ленты отдельных ошибок недостаточно

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

Одна проблема выглядит как много разных событий

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

Теряется момент реального начала

Команда может заметить проблему позже первого сбоя. Время начала инцидента позволяет восстановить последовательность событий без опоры на память участников.

Непонятно, было ли восстановление устойчивым

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

Уведомление принимают за диагноз

Сообщение о сбое подтверждает внешний симптом, но не объясняет внутреннюю причину. Для диагноза нужны данные запуска, логи сервиса, метрики и сведения о релизах.

Жизненный цикл инцидента

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

Этап 1

Первая неуспешная проверка открывает инцидент

Началом считается время первого запуска, который завершился ошибкой.

Сохраняется идентификатор первого запуска.
Фиксируется причина сбоя и текст ошибки.
Для HTTP-проверки могут быть доступны HTTP-статус и задержка.
Для JSON- и SSL-проверок сохраняются профильные детали запуска.

Этап 2

Последовательные ошибки продолжают тот же инцидент

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

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

Этап 3

Успешная проверка фиксирует восстановление

Первый успешный запуск после серии ошибок закрывает инцидент и становится запуском восстановления.

Появляется время восстановления.
Можно рассчитать длительность инцидента.
Запуск восстановления имеет отдельный идентификатор.
При включённом событии восстановления формируется уведомление.

Этап 4

Команда разбирает причину после стабилизации

История мониторинга задаёт временные границы, а первопричина подтверждается внутренними источниками.

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

Как читать разные инциденты

Одинаковый статус «ошибка» может означать разные действия для команды.

Серия HTTP 503 после релиза

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

Таймауты без полного падения

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

Несоответствие JSON при HTTP 200

Сервис отвечает, но бизнес-признак не соответствует правилу. Откройте детали JSON-проверки, сравните ожидаемое и фактическое значения и выясните, изменился контракт или реально деградировала функция.

Истекающий SSL-сертификат

Причина ssl_expiring показывает предупреждение до истечения. После установки нового сертификата успешная проверка закрывает инцидент, но нужно убедиться, что сервер действительно отдаёт обновлённую цепочку.

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

Каждое поле отвечает на отдельный вопрос. Не делайте вывод по одному статусу.

Поле	Что означает	Как использовать
Начало	Время первой неуспешной проверки.	Сопоставьте с релизами, изменениями DNS, сертификатов и инфраструктуры.
Последняя ошибка	Время последнего неуспешного запуска внутри инцидента.	Поймите, продолжалась ли проблема непосредственно перед восстановлением.
Восстановление	Время первого успешного запуска после серии ошибок.	Используйте как внешнее подтверждение доступности, а не как доказательство устранения внутренней причины.
Длительность	Разница между началом и восстановлением; для открытого инцидента — до последней ошибки.	Оцените длительность внешне наблюдаемой недоступности.
Количество ошибок	Число неуспешных запусков в группе.	Отделите единичный сбой от устойчивой последовательности ошибок.
Последняя причина	Тип последней ошибки: сеть, таймаут, HTTP, JSON, настройка или SSL.	Выберите правильное направление первичной диагностики.
HTTP и задержка	Код ответа и время проверки, когда они применимы.	Различайте быстрый отказ, медленный ответ и сетевую проблему.
Запуски внутри инцидента	Последовательность проверок от первой ошибки до восстановления.	Проверьте, менялись ли симптомы по ходу проблемы.
История уведомлений	Решение по email-событию и попытки доставки.	Выясните, было ли событие разрешено настройками, отправлено, пропущено или завершилось ошибкой.

Порядок разбора инцидента

Не начинайте с предположения о причине. Сначала восстановите фактическую временную линию.

Шаг 1

Определите границы инцидента

Зафиксируйте начало, последнюю ошибку, восстановление и длительность.

Проверьте, открыт инцидент или закрыт.
Не считайте последнюю ошибку временем восстановления.
Учитывайте интервал мониторинга при оценке точности границ.
При приостановленном мониторе восстановление могло не зафиксироваться.

Шаг 2

Откройте проверки внутри инцидента

Посмотрите не только последнюю строку, а всю последовательность запусков.

Сравните первую и последнюю причины.
Проверьте HTTP-статусы и задержку.
Откройте детали JSON-правил при несовпадении.
Для SSL проверьте срок, издателя и субъект сертификата.

Шаг 3

Проверьте историю уведомлений

Отделите факт возникновения события от результата доставки сообщения.

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

Шаг 4

Сопоставьте с внутренними источниками

Мониторинг показывает внешний результат, а не внутреннее состояние всех компонентов.

Проверьте логи приложения и прокси.
Сопоставьте нагрузку, ошибки БД и внешних API.
Проверьте релизы и изменения конфигурации.
Учитывайте DNS, TLS и сетевую доступность.

Шаг 5

Подтвердите устойчивость восстановления

Один успешный запуск закрывает инцидент, но команда должна проверить последующие результаты.

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

Шаг 6

Зафиксируйте вывод и действие

Разбор полезен только тогда, когда приводит к изменению системы или процесса.

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

Типовые ошибки при разборе инцидентов

Неверная интерпретация полей приводит к ложным выводам даже при корректных данных мониторинга.

Симптом	Возможная причина	Что делать
Инцидент открыт, хотя сервис уже работает	Монитор выключен, приостановлен лимитом тарифа или успешная проверка ещё не выполнилась.	Проверьте состояние монитора, тарифные ограничения и наличие новых запусков.
После восстановления быстро появился новый инцидент	Сервис нестабилен, а единичный успешный запуск разделил две серии ошибок.	Смотрите соседние проверки и внутренние метрики, а не только число карточек инцидентов.
Причина последней ошибки не совпадает с первой	Симптом менялся по ходу сбоя: например, таймаут сменился HTTP 503.	Откройте список запусков внутри инцидента и восстановите последовательность изменений.
Инцидент есть, но email не пришёл	Событие отключено, действуют тихие часы, нет получателей, канал выключен или доставка завершилась ошибкой.	Откройте журнал уведомлений и проверьте решение по событию и попытки отправки.
HTTP 200, но инцидент открыт	Не прошла JSON-проверка либо текущая строка относится не к HTTP-монитору.	Проверьте failure_kind и детали JSON expected/actual.
Длительность кажется короче реального сбоя	Внешний монитор увидел проблему только на ближайшем запуске и подтвердил восстановление на следующем успешном запуске.	Учитывайте интервал проверок и сопоставляйте данные с внутренними временными метками.

Как сделать инциденты полезными для команды

Ценность инцидента зависит не только от интерфейса, но и от того, что именно проверяет монитор.

Проверяйте критичные точки отдельно

Главная страница, API авторизации и страница оплаты могут падать независимо и должны иметь собственные мониторы.

Настройте рабочий интервал

Слишком редкая проверка увеличивает неопределённость времени начала и восстановления, а слишком частая может создавать лишнюю нагрузку.

Не скрывайте ошибки слишком большим таймаутом

Таймаут должен отражать допустимое время ответа, а не маскировать деградацию сервиса.

Разделяйте симптом и первопричину

HTTP 502, таймаут или сетевой сбой — это наблюдаемый результат. Истинная причина подтверждается внутренней диагностикой.

Проверяйте уведомления заранее

Тестовая отправка и корректные получатели уменьшают риск обнаружить проблему канала во время реального инцидента.

Разбирайте повторяющиеся эпизоды

Несколько похожих инцидентов — сигнал искать системную причину, а не закрывать каждый случай отдельно.

Что показывает UpWatch в карточке инцидента

Доступные данные зависят от вида монитора и фактически выполненных проверок.

Открытый или закрытый статус

Видно, зафиксировано ли успешное восстановление после серии ошибок.

Временная линия

Показываются начало, последняя ошибка, восстановление и рассчитанная длительность.

Количество ошибок

Можно оценить, была ли ошибка единичной или повторялась несколько запусков подряд.

Причина последнего сбоя

Используются отдельные причины для сети, таймаута, HTTP, JSON, конфигурации и SSL.

Проверки внутри инцидента

Карточка содержит список запусков, относящихся к конкретному эпизоду.

Журнал email-уведомлений

Для доступной трассировки показываются решения по событиям и попытки доставки.

Ограничения

UpWatch наблюдает сервис снаружи и не читает внутренние логи приложения.
Система не определяет строку кода или компонент, который вызвал сбой.
Граница начала и восстановления зависит от интервала и фактического времени запусков.
Один успешный запуск закрывает инцидент, но не гарантирует дальнейшую стабильность.
Открытый инцидент может оставаться без восстановления, если монитор выключен или приостановлен.
История доставки сообщения не подтверждает, что человек прочитал уведомление.
Карточка инцидента не заменяет внутренний APM, логи, трассировку и бизнес-метрики.

Частые вопросы

Чем инцидент отличается от неуспешной проверки?

Неуспешная проверка — один запуск. Инцидент объединяет последовательность ошибок до первого успешного восстановления.

Когда инцидент считается восстановленным?

Когда после серии неуспешных запусков выполняется успешная проверка.

Почему после закрытия появился новый инцидент?

После успешного запуска следующая серия ошибок уже считается отдельным эпизодом.

Можно ли по карточке узнать точную первопричину?

Нет. Карточка показывает внешний симптом и временную линию. Первопричину нужно подтверждать по внутренним данным.

Почему открытый инцидент может быть устаревшим?

Если монитор выключен или приостановлен, новая успешная проверка не выполняется и восстановление не фиксируется.

Видно ли, почему уведомление не отправилось?

Для доступной истории email-событий можно увидеть решение, состояние и попытки доставки.

Связанные материалы

Дополнительные руководства помогут связать настройку с API, историей запусков, инцидентами и уведомлениями.

История проверок и запусков

Разберите отдельные запуски, фильтры, причины ошибок и технические детали.

Настройка уведомлений

Проверьте события начала и восстановления, каналы, тихие часы и историю доставки.

Уведомления о падении сайта

Настройте практическую схему обнаружения и оповещения о недоступности.

Диагностика ошибок API

Сопоставьте причины мониторинга с HTTP-кодами, таймаутами и ошибками ответа.

Разбирайте сбой как единый инцидент

Создайте монитор, получите связанную историю ошибок и фиксируйте восстановление без ручной сборки временной линии.

Создать аккаунт Открыть справочный центр