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

Эта страница проводит через жизненный цикл инцидента в дашборде: создание инцидента, публикацию обновлений, его подтверждение и устранение. Всё управление инцидентами происходит в разделе Dashboard → Incidents (/dashboard/incidents).

Концепции, лежащие в основе серьёзности, статуса и типов объектов, см. в Обзоре инцидентов.

Просмотр и фильтрация инцидентов

Список инцидентов в разделе Dashboard → Incidents показывает инциденты вашей команды, сначала самые новые. Используйте фильтры, чтобы сузить список:

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

Создание инцидента вручную

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

1. Перейдите в Dashboard → Incidents → Create.
2. Выберите затронутый монитор из выпадающего списка (перечислены только ваши активные мониторы). Инциденты, созданные вручную, всегда привязаны к монитору.
3. Выберите серьёзность: minor, major или critical.
4. Выберите начальный статус: investigating, identified, monitoring или resolved.
5. Напишите заголовок (3–255 символов) и описание (не менее 10 символов).
6. Отправьте.

Что происходит при отправке:

• Инцидент записывается с источником обнаружения manual и выбранным временем начала.
• Если начальный статус — любой, кроме resolved, монитор помечается как down, и новый инцидент становится его активным инцидентом.
• Если вы создаёте инцидент уже в статусе resolved, монитор остаётся исправным.

Создание инцидентов требует командного разрешения manage_incidents. Участники и выше могут управлять инцидентами; наблюдатели — нет. См. Роли в команде для матрицы разрешений.

Публикация обновлений

Обновления — это то, как вы продвигаете инцидент и сообщаете о прогрессе. Каждое обновление — это сообщение с отметкой времени, при желании сопровождаемое изменением статуса, и приписывается своему автору.

В подробном виде инцидента используйте Add Update:

1. При желании выберите новый статус (investigating, identified, monitoring или resolved). Оставьте без изменений, чтобы опубликовать сообщение без смены статуса.
2. Напишите сообщение (не менее 5 символов).
3. Отправьте.

Примечания:

• Обновления отображаются в хронологии инцидента и на любой status-странице, к которой относится затронутый монитор, сначала самые новые, поэтому пишите сообщения обновлений для ваших конечных пользователей.
• Если вы установите статус resolved в обновлении, инцидент закрывается: проставляется время устранения, а для инцидентов мониторов монитор возвращается в up, и его активный инцидент очищается.
• Установка неразрешающего статуса просто продвигает жизненный цикл.

Редактирование деталей инцидента

Чтобы изменить заголовок, описание, серьёзность или статус существующего инцидента (в отличие от добавления обновления), используйте Edit для инцидента. Применяются те же правила валидации (заголовок 3–255 символов, описание ≥ 10 символов, серьёзность из minor/major/critical, статус из четырёх значений жизненного цикла).

Редактирование статуса имеет побочные эффекты:

• Изменение статуса на resolved проставляет время устранения и возвращает монитор в up.
• Изменение статуса с resolved (повторное открытие) очищает время устранения и снова помечает монитор как down с этим активным инцидентом.

Подтверждение инцидента

Подтверждение сигнализирует, что кто-то им занимается. В подробном виде инцидента нажмите Acknowledge.

• Инцидент фиксирует, кто его подтвердил и когда (acknowledged_by / acknowledged_at).
• Подтверждение не меняет статус инцидента — он остаётся в том состоянии жизненного цикла, в котором был.
• Уже подтверждённый инцидент не будет переотмечен.

Это наиболее полезно для on-call ротаций: позволяет остальной команде увидеть, что у активного оповещения есть ответственный.

Устранение инцидента

Когда проблема устранена, закройте инцидент. Сделать это можно двумя способами:

• Нажмите Resolve на инциденте, или
• Опубликуйте обновление (или отредактируйте), устанавливающее статус resolved.

Устранение:

• Устанавливает статус resolved и проставляет resolved_at.
• Для инцидентов мониторов возвращает монитор в up и очищает его активный инцидент.
• Для инцидентов серверов просто закрывает запись — статус сервера продолжает определяться агентом.
• Идемпотентно: устранение уже устранённого инцидента не имеет эффекта.

Автоматическое устранение

Закрывать инциденты вручную не всегда нужно. Когда недоступный монитор снова начинает успешно проходить проверки, конвейер мониторинга устраняет открытый инцидент за вас и возвращает монитор в up.

Типичный рабочий процесс

Монитор становится недоступен, и инцидент открывается автоматически (investigating):

1. Acknowledge, чтобы команда знала, что у инцидента есть ответственный.
2. Опубликуйте обновление — «Подтверждены 503 во всех локациях, расследуем.»
3. Как только найдёте причину, опубликуйте обновление со статусом identified — «Неудачный деплой в 09:10 UTC; откатываем.»
4. После применения исправления опубликуйте обновление со статусом monitoring — «Откат завершён, частота ошибок снижается.»
5. Когда всё исправно, Resolve (или опубликуйте обновление resolved) — «Полностью восстановлено.»

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

Дальнейшие шаги

• Обзор инцидентов — концепции серьёзности, статуса и объектов
• Окна обслуживания — объявление о запланированном простое
• Status-страницы — публикация обновлений инцидентов для ваших пользователей
• Каналы оповещений — получение уведомлений при открытии инцидентов
• Incidents API — программное чтение инцидентов