Практические примеры для IncidentRelay v2.3.1, проверены . Имена, идентификаторы и интервалы ниже приведены для иллюстрации; проверьте их на тестовом развёртывании до использования production-учётных данных.
Бизнес-пример · Настройка · Практический пример · Приёмочные проверки · Ограничения и отказы
Бизнес-пример: оплата сломалась после закрытия офиса
Это модельная ситуация, а не история реального клиента. Метрики ниже предложены для вашего пилота: это не подтверждённая экономия и не утверждение, что все нужные отчёты встроены в IR.
Ситуация и риск. В интернет-магазине работают четыре инженера. В 22:40 мониторинг обнаруживает ошибки платёжных запросов, пока покупатели продолжают оформлять заказы. Сообщение в общем чате не объясняет поддержке, кто занимается проблемой. Бизнес-риски — незавершённые покупки и растущая очередь обращений; сам алерт лишь сообщает о сбое.
Процесс с IR. Направьте алерт биллинга текущему основному дежурному. Если подтверждения нет, политика переключится на указанного резервного. Назначенный инженер подтверждает группу и разбирается в причине; поддержка по согласованному процессу работы с инцидентами может найти этого ответственного и получить обновление статуса. Проверьте цепочку парой событий сбоя и восстановления ниже.
Какую пользу проверить. Замените ручной поиск свободного инженера заранее определённой цепочкой ответственных. Сохраняйте понятную ответственность при передаче задачи: доставленное сообщение в чате ещё не означает, что кто-то уже занимается проблемой.
Что измерять. Фиксируйте время от первого алерта, требующего реакции, до ACK, долю подтверждений в пределах внутренней цели и число ручных переназначений. Отдельно отслеживайте ошибки оплаты и время до возобновления успешных платежей в мониторинге магазина.
Ограничения. IR не чинит оплату или платёжного провайдера. ACK не доказывает, что покупатели снова могут платить, а политика эскалации не поможет, если оба инженера недоступны. Сохраните резервный способ связи и реальную проверку восстановления платежей.
Четыре инженера, один биллинг и понятная цепочка ответственных
Допустим, четыре инженера поддерживают API биллинга. Начните с одной команды и основной ротации с еженедельной сменой. Укажите в маршруте сервис по умолчанию и один проверенный канал доставки. Явно назначьте резервного дежурного: общий чат не заменяет политику эскалации.
| Объект | Пример настройки в интерфейсе |
|---|---|
| Собственность | Команда payments; сервис billing-api; ротация payments-primary с четырьмя активными участниками и покрытием 24/7. |
| Приём событий | Источник webhook, сервис по умолчанию billing-api, эскалация по политике и подключённые каналы уведомлений. |
| Эскалация | Правило 1: основная ротация, задержка 300 секунд. Правило 2: конкретный резервный пользователь, задержка 600 секунд. Для этого пилота задайте repeat_count=0. |
Настройте каналы и контакты дежурных до отправки алерта. Откройте полную диагностику On-call Health: зелёный статус в таблице сам по себе не проверяет будущее покрытие и не доказывает доставку сообщения на телефон.
Отправьте сбой, затем восстановление
Отправьте эти JSON-тела по отдельности на POST /api/integrations/webhook с заголовками Content-Type: application/json и Authorization: Bearer ROUTE_TOKEN. Подставьте токен тестового маршрута из интерфейса; не сохраняйте его в репозиторий или общие логи. Это формат generic webhook, а не нормализованное событие Simulator.
{
"status": "firing",
"fingerprint": "billing-api:health:prod",
"title": "Billing API health check failed",
"severity": "critical",
"labels": {
"alertname": "BillingUnavailable",
"environment": "production",
"service": "billing-api"
}
}{
"status": "resolved",
"fingerprint": "billing-api:health:prod",
"title": "Billing API health check failed",
"severity": "critical",
"labels": {
"alertname": "BillingUnavailable",
"environment": "production",
"service": "billing-api"
}
}При восстановлении сохраните тот же маршрут, fingerprint и метки группировки. Fingerprint идентифицирует дочерний алерт; новое случайное значение при каждом запросе ломает дедупликацию. Восстановление без соответствующего алерта не создаёт новую группу.
Проверьте всю цепочку до первой настоящей ночной смены
- Дважды отправьте тело события firing. Ожидайте один дочерний алерт, нужный сервис и текущего основного дежурного; проверьте реальную доставку, а не только успешный HTTP-ответ.
- Оставьте отдельный тестовый алерт без подтверждения. Проверьте, что после задержки первого правила адресатом становится резервный дежурный. Период работы планировщика, очереди и доставка провайдером означают, что это не SLA доставки ровно за пять минут.
- Подтвердите другую тестовую группу и убедитесь, что ожидающие уведомления, предназначенные только для состояния firing, прекращаются. Отправьте восстановление и проверьте, что группа переходит в resolved, когда в ней не осталось активных дочерних алертов.
- Создайте временную подмену в ротации и повторите проверку. Убедитесь, что фактически назначен подменяющий дежурный, затем удалите тестовую настройку.
Знайте, когда цепочка остановится
В режиме политики командная эскалация по числу напоминаний игнорируется. Когда все правила и разрешённые повторы исчерпаны, напоминания политики прекращаются, хотя алерт может оставаться активным. Резервный дежурный без работающих контактов — просто имя в базе.
ACK означает принятие ответственности, а не восстановление биллинга. IR не может починить приложение или заменить отсутствующего инженера. Оставьте внешний способ связаться с командой на случай недоступности IR или провайдера уведомлений и объясните его при вводе сотрудников в работу.