Практические примеры для IncidentRelay v2.3.1, проверены . Имена, идентификаторы и интервалы ниже приведены для иллюстрации; проверьте их на тестовом развёртывании до использования production-учётных данных.
Бизнес-пример · Настройка · Практический пример · Приёмочные проверки · Ограничения и отказы
Бизнес-пример: клиенты SaaS работают в разных часовых поясах
Это модельная ситуация, а не история реального клиента. Метрики ниже предложены для вашего пилота: это не подтверждённая экономия и не утверждение, что все нужные отчёты встроены в IR.
Ситуация и риск. Команда B2B SaaS обслуживает клиентов в Европе и Северной Америке. У клиента ещё рабочий день, у инженера уже вечер, а привычный ответственный в отпуске. Без согласованного расписания команда полагается на того, кто первым заметит сообщение в чате. Риск — сбой без ответственного и постоянные отвлечения сотрудников вне дежурства.
Процесс с IR. Согласуйте покрытие реальными сотрудниками, затем отразите его в базовой ротации и слое на рабочие часы. Оформите отпускные подмены через overrides и задайте отдельного резервного адресата эскалации. Проверьте передачи смен и будущие пробелы. Для планового обновления биллинга используйте окно обслуживания конкретного сервиса, сохранив уведомления остальных сервисов.
Какую пользу проверить. Сделайте распределение ответственности понятным для поддержки и инженеров, в том числе во время отпусков и передачи смен. Плановые работы не должны требовать отключения всего потока алертов компании.
Что измерять. Проверяйте минуты без покрытия в заданном будущем периоде, например в ближайшие 14 дней, ручные передачи смен в последний момент и подтверждения в пределах целевого времени реакции. Сопоставляйте ночные уведомления на инженера с фактическим расписанием: одного равномерного календаря недостаточно для оценки нагрузки.
Ограничения. Заполненный календарь не создаёт дополнительных сотрудников и не доказывает, что кто-то сможет отреагировать. IR не гарантирует договорное время ответа и не рассчитывает доступность для клиентов по ACK. Планирование штата, контроль SLO и общение с клиентами остаются частью общего процесса эксплуатации.
Сначала закройте ночные смены, затем улучшайте дневные
Допустим, SRE-команда отвечает за надёжность биллинга в дневные и ночные смены. В одной ротации создайте базовый слой с приоритетом 10 и покрытием 24/7 без ограничений. Добавьте слой с приоритетом 20 на понедельник–пятницу, 09:00–18:00 в Europe/Berlin. Укажите реальных активных участников и проверьте получившийся календарь.
Ответственного определяет активный слой с наибольшим приоритетом; подмена имеет приоритет над слоями. Это не два одновременно назначенных дежурных. Для резервного покрытия настройте отдельного адресата эскалации или ротацию. Если нет активного слоя и применимой подмены, ответственный не назначается. Подробнее — в правилах ротаций и слоёв.
Приостановите уведомления биллинга на время планового развёртывания
Создайте окно для конкретного сервиса в интерфейсе или отправьте эту конфигурацию на POST /api/maintenance-windows через аутентифицированную сессию управляющего API с правами на изменение выбранной области. Входящий токен маршрута не даёт административных прав. Замените 42 реальным ID сервиса биллинга и выберите тестовое окно в будущем.
{
"name": "Billing deploy",
"behavior": "suppress_notifications",
"timezone": "Europe/Berlin",
"starts_at": "2026-10-20T10:00:00",
"ends_at": "2026-10-20T11:00:00",
"enabled": true,
"scopes": [
{
"scope_type": "service",
"service_id": 42
}
]
}Это локальное время в выбранном часовом поясе, а не UTC с пропущенным Z. Во время окна входящие алерты биллинга остаются видимыми, но уведомления, напоминания и эскалация приостанавливаются. Другие сервисы не должны быть затронуты. Это не режим suppress_incident, который не допускает создания новых AlertGroup, и не pause_escalation_only, при котором уведомления продолжаются.
Проверяйте границы смен, а не только их середину
- Проверьте назначение непосредственно до и после 09:00 и 18:00, на выходных и при переходе на летнее или зимнее время. Добавьте временную подмену, убедитесь, что она имеет приоритет, затем удалите её.
- Запустите полную проверку On-call Health. Изучите проверяемый будущий период, пробелы в расписании, неактивных участников и доступные способы доставки. Зелёная сводка не гарантирует покрытие навсегда или доставку на телефон.
- Во время обслуживания отправьте тестовые события биллинга и другого сервиса. Убедитесь, что биллинг виден без уведомлений, а другой сервис продолжает уведомлять. Чтобы включить уже существующие неразрешённые алерты, явно включите применение окна к ним; по умолчанию эта опция выключена.
- Оставьте алерт биллинга активным к концу окна. При включённой реактивации проверьте возобновление обычных уведомлений без воспроизведения каждого пропущенного напоминания. Убедитесь, что реальный дежурный получает сообщение и может подтвердить алерт.
Тишина не означает восстановление сервиса
Окно обслуживания не чинит сервис, не отзывает доставленные сообщения и не означает разрешение проблемы. Реактивация по завершении включена по умолчанию; если её отключить, действие обслуживания сохранится после конца окна. При пересечении окон алерт может оставаться без уведомлений, пока не будет снято последнее применимое активное или сохранённое воздействие. Разберите эти настройки в руководстве по окнам обслуживания.
Оставьте расчёт SLO и обнаружение расходования бюджета ошибок в системе мониторинга. IR маршрутизирует полученные сигналы и координирует реакцию. AlertGroup отвечает за технические подтверждение, разрешение, уведомления и эскалацию; Incident — это отдельный процесс управления инцидентом. Привязка нескольких AlertGroup к одному Incident не объединяет их технические истории. В v2.3.1 участники реагирования и заинтересованные стороны по-прежнему относятся к AlertGroup. Проверяйте оба жизненных цикла: изменение статуса Incident не следует считать ACK группы.