Incidents

Инциденты — это механизм управления проблемами и сбоями в работе сервисов. Они позволяют фиксировать, отслеживать и координировать работу команды по устранению неполадок, а также анализировать историю проблем для улучшения надёжности системы.

Инциденты создаются автоматически при сбоях мониторов для отслеживания проблем в проекте.

Для чего используются инциденты

1. Централизованное отслеживание проблем

Инциденты обеспечивают единую точку для:

• фиксации всех проблем в работе сервисов;
• отслеживания статуса решения проблемы;
• координации действий команды;
• сохранения истории событий и решений.

Это особенно важно для:

• production-окружений с высокой нагрузкой;
• распределённых команд;
• систем с SLA-требованиями;
• постмортем-анализа и улучшения процессов.

2. Автоматическое реагирование на сбои

При возникновении проблем с мониторами платформа:

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

3. Координация работы команды

Инциденты помогают команде:

• назначать ответственных за решение проблемы;
• отслеживать прогресс работы;
• добавлять комментарии и заметки;
• анализировать первопричины после устранения.

Создание инцидентов

Инциденты создаются автоматически от мониторов.

Когда монитор обнаруживает проблему, платформа автоматически создаёт инцидент, если:

• монитор остаётся недоступным 3 минуты подряд;
• превышены пороговые значения проверок;
• ошибка сохраняется стабильно.

Это предотвращает создание инцидентов при кратковременных сбоях (например, перезапуск сервиса).

Что происходит при автоматическом создании:

• создаётся инцидент с привязкой к монитору;
• указывается окружение монитора;
• время начала (startedAt) устанавливается на момент первого сбоя;
• статус устанавливается в Open;
• фиксируются детали ошибки в событиях.

Пример сценария:

00:00 - Монитор недоступен (начало отслеживания)
00:01 - Монитор недоступен (ожидание)
00:02 - Монитор недоступен (ожидание)
00:03 - Монитор недоступен (создание инцидента)

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

Статусы инцидента

Инцидент проходит через следующие статусы:

Open (Открыт)

Начальный статус инцидента.

Означает:

• проблема обнаружена;
• требуется внимание команды;
• работа по устранению не начата или в процессе.

Что делать:

• оценить серьёзность проблемы;
• назначить ответственного;
• начать исследование причин.

Acknowledged (Подтверждён)

Инцидент взят в работу.

Означает:

• команда знает о проблеме;
• кто-то активно работает над устранением;
• уведомления о проблеме получены.

Что делать:

• исследовать первопричину;
• применять временные решения (workarounds);
• добавлять заметки о прогрессе.

Resolved (Разрешён)

Проблема устранена.

Означает:

• инцидент закрыт;
• проблема больше не воспроизводится;
• зафиксирована первопричина (root cause).

Что делать:

• документировать решение;
• обновить runbook и документацию;
• провести постмортем для критичных инцидентов.

Переходы между статусами

      [Создание]
          ↓
    ┌─── Open ───┐
    │     ↓      │
    │ Acknowledged│
    │     ↓      │
    └→ Resolved ←┘

Возможные действия:

• Open → Acknowledged — подтвердить инцидент (acknowledge);
• Acknowledged → Resolved — разрешить инцидент (resolve);
• Open → Resolved — разрешить напрямую (для простых случаев).

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

Инциденты, созданные от мониторов, могут автоматически разрешаться, если:

• монитор восстановился;
• монитор работает стабильно 2 минуты подряд;
• нет повторных сбоев в период восстановления.

При автоматическом разрешении:

• статус меняется на Resolved;
• время разрешения (resolvedAt) фиксируется;
• создаётся событие с пометкой auto: true;
• сохраняется время стабильной работы (uptimeMs).

Важно: Если монитор снова падает во время периода восстановления, отсчёт начинается заново.

Критичность инцидента (Severity)

Уровень критичности помогает приоритизировать работу и определять скорость реагирования.

Critical (Критический)

Когда использовать:

• полный отказ основного сервиса;
• недоступность production для всех пользователей;
• потеря данных;
• нарушение безопасности.

Время реакции: немедленно (24/7)

Примеры:

• основная база данных недоступна;
• API возвращает 500 для всех запросов;
• платёжная система не работает;
• утечка персональных данных.

High (Высокий)

Когда использовать:

• серьёзное ухудшение работы сервиса;
• проблема затрагивает значительную часть пользователей;
• критичные функции недоступны.

Время реакции: в течение часа

Примеры:

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

Medium (Средний)

Когда использовать:

• проблема затрагивает небольшую группу пользователей;
• есть workaround;
• некритичная функциональность работает неправильно.

Время реакции: в рабочее время

Примеры:

• баг в редко используемой функции;
• проблемы с UI в определённом браузере;
• медленная работа некритичного API;
• проблемы с экспортом отчётов.

Low (Низкий)

Когда использовать:

• косметические проблемы;
• улучшения и оптимизации;
• минорные баги без влияния на бизнес.

Время реакции: по возможности

Примеры:

• опечатки в интерфейсе;
• незначительные UI-неточности;
• запросы на улучшение документации;
• предложения по оптимизации.

События инцидента

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

Типы событий

opened

Инцидент создан.

Payload содержит:

• детали ошибки монитора;
• статус ошибки;
• тип ошибки (errorKind).

check_failed

Новая неудачная проверка монитора.

Payload содержит:

• статус ошибки;
• тип ошибки (errorKind);
• сообщение об ошибке;
• HTTP-статус (если применимо).

acknowledged

Инцидент подтверждён.

Payload содержит:

• кто подтвердил (acknowledgedBy);
• время подтверждения.

resolved

Инцидент разрешён.

Payload содержит:

• кто разрешил (resolvedBy);
• первопричина (rootCause);
• auto: true/false (автоматическое разрешение);
• время стабильной работы (для автоматических разрешений).

note

Добавлена заметка.

Payload содержит:

• текст заметки;
• кто добавил (addedBy);
• время добавления.

assigned

Назначен ответственный.

Payload содержит:

• кому назначен (assignedTo);
• кто назначил (assignedBy);
• информация о пользователе.

Просмотр событий

События инцидента доступны в деталях инцидента и показывают:

• хронологию всех действий;
• кто и когда выполнил действие;
• детали каждого изменения;
• историю проверок монитора.

Это помогает при:

• анализе времени реакции;
• постмортем-анализе;
• аудите действий команды;
• понимании эволюции проблемы.

Работа с инцидентами

Назначение ответственного

Любому инциденту можно назначить ответственного из команды проекта.

Зачем это нужно:

• чёткое понимание, кто работает над проблемой;
• предотвращение дублирования усилий;
• отслеживание загрузки команды;
• быстрая эскалация при необходимости.

Ответственный может быть назначен:

• при создании инцидента;
• после подтверждения (acknowledge);
• переназначен другому члену команды.

Добавление заметок

Заметки позволяют документировать процесс работы над инцидентом.

Что фиксировать в заметках:

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

Все заметки сохраняются в истории событий с указанием автора и времени.

Разрешение инцидента

При разрешении инцидента рекомендуется указать первопричину (root cause).

Root Cause (первопричина):

• что именно вызвало проблему;
• какие действия были предприняты;
• какие изменения внесены для предотвращения повторения.

Примеры root cause:

- Исчерпана память на сервере БД, увеличен размер инстанса
- Неправильная конфигурация nginx, исправлен upstream timeout
- Внешний API изменил формат ответа, обновлен парсер
- DDoS-атака, настроены rate limits и WAF

Документирование первопричины важно для:

• предотвращения повторения проблемы;
• накопления знаний команды;
• улучшения мониторинга и алертинга;
• проведения постмортем-анализа.

Автоматизация и интеграция

Пороговые значения (Thresholds)

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

Создание инцидента:

• Монитор должен быть недоступен 3 минуты подряд
• Предотвращает создание инцидентов при кратковременных сбоях
• Время начала (startedAt) = момент первого сбоя

Автоматическое разрешение:

• Монитор должен работать 2 минуты подряд
• Предотвращает преждевременное закрытие при нестабильной работе
• Если монитор снова падает — отсчёт начинается заново

Интеграция с Workflows

⚠️ В разработке: Система автоматизаций (Workflows) находится в активной разработке. Функциональность может быть ограничена или изменена.

Инциденты могут запускать автоматизации через систему Workflows.

Доступные триггеры:

• Incident Opened — инцидент создан
• Incident Acknowledged — инцидент подтверждён
• Incident Resolved — инцидент разрешён

Примеры автоматизаций:

1. Уведомление в Slack при критическом инциденте:

Триггер: Incident Opened
Условие: severity == "critical"
Действие: Отправить сообщение в #incidents

2. Создание задачи в Jira:

Триггер: Incident Opened
Условие: severity == "high" OR severity == "critical"
Действие: Создать задачу в проекте SUPPORT

3. Автоматическое отключение feature flag:

Триггер: Incident Opened
Условие: monitor связан с определённым сервисом
Действие: Отключить флаг "new_feature"

4. Уведомление команды о разрешении:

Триггер: Incident Resolved
Действие: Отправить отчёт в Slack с root cause

Summary и аналитика

Платформа предоставляет сводку по инцидентам проекта:

• Open — количество открытых инцидентов
• Acknowledged — количество подтверждённых
• Resolved — количество разрешённых
• Total — общее количество

Эта информация помогает:

• оценить текущую нагрузку;
• отслеживать динамику инцидентов;
• планировать ресурсы команды;
• выявлять проблемные зоны системы.

Лучшие практики

Настройка мониторинга

Правильные пороги:

• Используйте встроенные пороговые значения (3 мин / 2 мин);
• Для критичных сервисов — уменьшайте интервал проверок;
• Для стабильных сервисов — увеличивайте интервалы.

Разделение по окружениям:

• Production — жёсткие пороги и немедленная реакция;
• Staging — более мягкие условия создания инцидентов;
• Development — мониторинг без автоматических инцидентов.

Работа с критичностью

Используйте правильные уровни:

• Не завышайте критичность — это приводит к "усталости от алертов";
• Critical только для реальных production-outage;
• Medium/Low для большинства проблем в staging/dev.

Документируйте критерии:

• Создайте внутренний runbook с критериями severity;
• Обучите команду правильной классификации;
• Регулярно пересматривайте и обновляйте критерии.

Процесс работы с инцидентами

Быстрое реагирование:

• Настройте автоматические уведомления;
• Определите дежурство для критичных систем;
• Документируйте процедуры эскалации.

Эффективное расследование:

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

Документирование решений:

• Всегда указывайте root cause при разрешении;
• Обновляйте документацию и runbook;
• Создавайте задачи на улучшение мониторинга;
• Проводите постмортем для серьёзных инцидентов.

Интеграция с процессами

Связь с Feature Flags:

• Автоматически отключайте проблемные фичи через workflows;
• Включайте fallback-режимы при инцидентах;
• Используйте флаги для быстрого отката изменений.

Связь с Jira/Task Trackers:

• Автоматически создавайте задачи для инцидентов;
• Синхронизируйте статусы между системами;
• Сохраняйте контекст в обе стороны.

Интеграция с мониторингом:

• Добавляйте ссылки на дашборды в заметки;
• Настройте correlation между инцидентами и метриками;
• Используйте трейсинг для быстрой диагностики.

Постмортем и улучшения

После разрешения критичных инцидентов:

• Проведите постмортем в течение 24-48 часов;
• Определите action items для предотвращения повторения;
• Обновите мониторинг и алертинг;
• Поделитесь результатами с командой.

Регулярный анализ:

• Еженедельно анализируйте статистику инцидентов;
• Выявляйте повторяющиеся проблемы;
• Приоритизируйте системные улучшения;
• Отслеживайте MTTR (Mean Time To Resolve).

Дополнительные материалы

Инциденты тесно интегрированы с другими возможностями платформы:

• Monitoring — настройка мониторов для автоматического создания инцидентов
• Workflows — автоматизация реагирования на инциденты (в разработке)
• Feature Flags — управление функциональностью при возникновении проблем