Команды, ротации, слои и маршруты#

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

Incoming alert
  -> Route
  -> Service
  -> Team
  -> Rotation / Escalation policy
  -> Final schedule
  -> On-call user
  -> Channels

Команда#

Команда — это единица владения дежурством (on-call) внутри группы.

Пример:

Group: Production
Team: Infrastructure
Team slug: infra

Slug команды обычно используется в метках алертов, например с Alertmanager:

team: infra

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

Сервис#

Сервис — это логическая затрагиваемая система, принадлежащая команде.

Пример:

Team: Infrastructure
Service: RabbitMQ Cloud
Service slug: rabbitmq-cloud
Type: queue
Environment: production
Criticality: critical

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

Сервис может иметь:

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

Ротация#

Ротация — это объект расписания, обращённый к маршруту. Маршруты указывают на ротации, а ротации выдают итогового дежурного.

Ротация принадлежит одной команде и может содержать один или несколько слоёв.

Пример:

Team: infra
Rotation: infra-primary
Timezone: Europe/Berlin
Reminder interval: 300 seconds

Когда ротация создаётся, IncidentRelay создаёт слой по умолчанию. Если включено Add all active team members to this rotation, активные участники команды добавляются в этот слой по умолчанию по порядку.

Слой#

Слой — это правило расписания внутри ротации.

Каждый слой имеет:

имя;
приоритет;
флаг включённости;
время начала;
тип ротации;
время передачи дежурства (handoff);
опциональный день недельной передачи дежурства;
часовой пояс;
упорядоченных участников;
опциональные ограничения активного времени.

Ротация может иметь несколько слоёв. Это полезно для разных схем покрытия, например:

Layer: Business hours
Members: Ivan -> Petr -> Anna
Active: Monday-Friday 09:00-18:00

Layer: Nights
Members: Petr -> Anna -> Ivan
Active: Monday-Friday 18:00-09:00

Layer: Weekend
Members: Anna -> Ivan -> Petr
Active: Saturday-Sunday 00:00-00:00

Приоритет слоя#

Когда одновременно активны несколько слоёв, побеждает слой с более высоким приоритетом.

priority 10: Business hours
priority 20: Nights
priority 30: Weekend

Слой с более высоким приоритетом переопределяет слой с более низким приоритетом для перекрывающихся временных окон.

Ограничения слоя#

Ограничения определяют, когда слой активен.

Если у слоя нет ограничений, он активен круглосуточно (24/7).

Примеры ограничений:

Monday-Friday 09:00-18:00
Monday-Friday 18:00-09:00
Saturday-Sunday 00:00-00:00

00:00-00:00 означает весь день.

Времена интерпретируются в часовом поясе слоя. Храните абсолютные метки времени в UTC, но задавайте повторяющиеся недельные/дневные ограничения в локальном времени слоя.

Итоговое расписание#

Итоговое расписание — это эффективное расписание, используемое календарём и маршрутизацией алертов.

Порядок приоритета:

rotation override > highest-priority active layer > no assignee

Если ни один слой не активен, IncidentRelay не возвращает запланированного дежурного для этой ротации. Логика маршрутизации и эскалации может затем решить, как обработать алерт.

Переопределения#

Переопределение временно заменяет итогового запланированного пользователя для ротации.

Переопределения применяются поверх всех слоёв.

Пример:

Rotation: infra-primary
Override: Anna replaces current on-call user
Window: 2026-05-25 12:00 -> 2026-05-26 12:00

Маршрут#

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

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

Пример:

Source: alertmanager
Team: infra
Rotation: infra-primary
Channels: infra-mattermost, infra-voice-critical
Matchers: {"labels": {"team": "infra"}}

Маршрут может существовать без ротации. Это может произойти, если ротация удалена. Маршрут остаётся, но rotation_id очищается. В таком состоянии маршрут по-прежнему существует как конфигурация, но он не назначает запланированного дежурного из этой ротации.

Несколько маршрутов для одной команды#

У одной команды может быть несколько независимых маршрутов приёма:

infra-alertmanager -> source alertmanager -> Alertmanager token
infra-webhook      -> source webhook      -> Generic webhook token
infra-zabbix       -> source zabbix       -> Zabbix token

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

Несколько ротаций для одной команды#

У одной команды может быть несколько ротаций.

Пример:

Team: Cloud
Rotation: Cloud primary
Rotation: Cloud secondary
Rotation: Cloud weekend

В UI календаря ротация рассматривается как отдельный календарь. Это предотвращает смешивание нескольких ротаций одной команды в одно расписание.