IncidentRelay vs PagerDuty

IncidentRelay или PagerDuty: что меняется, когда вы сами обслуживаете систему дежурств?

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

Сравнение подготовила команда IncidentRelay. Документация проверена ; рассматриваемая версия IncidentRelay — v2.3.1. Это сравнение по документации, а не тест производительности и не обещание полного совпадения возможностей.

Коротко о выборе · Возможности · Ограничения миграции · План пилота

Короткий ответ

Рассмотрите IncidentRelay, если вы осознанно хотите эксплуатировать систему дежурств сами: контролировать развёртывание, изучать исходный код и управлять маршрутизацией алертов. Рассмотрите PagerDuty, если сервис под управлением поставщика и его готовые рабочие процессы для вас важнее собственного размещения.

Ни один вариант не избавляет от назначения ответственных, поддержки расписаний и проверки уведомлений. В случае IR к обязанностям добавятся хостинг, обновления, резервные копии и мониторинг самой системы оповещения. Сравнивайте эти затраты с нужным вам тарифом PagerDuty и дополнениями, а не только с рекламной ценой за пользователя.

Сравнивайте рабочий процесс, а не только названия функций

Критерий IncidentRelay v2.3.1 PagerDuty
Операционная модель Приложение с открытым исходным кодом в вашей инфраструктуре. За эксплуатацию отвечает ваша команда. Платформа управления инцидентами под управлением поставщика.
Расписания и эскалация Слои ротации, переопределения и политики эскалации. Ограничения импорта зависят от типа исходного расписания. Расписания и политики эскалации определяют, кому назначается инцидент и кто получает уведомление.
Маршрутизация событий Глобальная оркестрация и оркестрация сервисов, нормализованные метки, моделирование, воспроизведение и теневой режим. Оркестрация событий; расширенные возможности зависят от тарифа и дополнений.
Уведомления Чаты, email и голосовые вызовы, а также браузерные/PWA push-уведомления в профиле пользователя. Провайдеров и контакты настраиваете вы. Пользовательские правила уведомлений: push, звонки, Slack, email и SMS.
Модель инцидента AlertGroup отвечает за техническое оповещение дежурных; отдельный Incident — за оперативную работу с инцидентом. События сервисов создают алерты и инциденты с назначением ответственного, подтверждением, закрытием и хронологией.

Описание жизненного цикла и доставки в PagerDuty основано на его обзоре инцидентов. Перед выбором проверьте возможности тарифа, доступность провайдеров доставки и конкретные интеграции, от которых вы зависите.

Чего не стоит ожидать от модели инцидентов IR

IR 2.3 разделяет технические группы алертов (AlertGroup) и оперативные инциденты (Incident). Один Incident может объединять ссылки на несколько AlertGroup, не смешивая их техническую историю. Подтверждение и эскалация остаются на уровне AlertGroup; участники реагирования и заинтересованные стороны в этом релизе тоже привязаны к AlertGroup. Изучите границы модели Incident Management, прежде чем переносить свой процесс реагирования.

Может ли IR полностью заменить API PagerDuty?

Нет. IR принимает алерты в формате, совместимом с PagerDuty Events API v2, по адресу /api/integrations/webhook. Отправитель должен позволять изменить адрес API и передавать токен маршрута IR в routing_key. Проверьте trigger, acknowledge и resolve с одним и тем же dedup_key.

Эта совместимость относится к приёму алертов, но не к REST API PagerDuty, мобильному приложению, ресурсам Terraform или поведению всех интеграций. Отдельно составьте список автоматизаций. Инструменту с жёстко заданным адресом API PagerDuty может понадобиться другая интеграция или адаптер.

Что действительно переносит импортёр PagerDuty

В руководстве по миграции для IR v2.3.1 описан импортёр, который по умолчанию работает в пробном режиме через публичные API обоих продуктов. Изучите отчёт перед добавлением --apply.

  • Поддерживаются: пользователи, команды, членство, расписания старого типа и их слои, ежедневные и еженедельные ограничения, будущие переопределения, политики эскалации, сервисы, вебхук-маршруты и текущие или будущие окна обслуживания.
  • Не импортируются: история инцидентов и алертов, Event Orchestrations и Rulesets, расписания V3 на основе смен, телефонные номера, способы связи, правила и каналы уведомлений.
  • Преобразования с потерей исходной семантики: общие расписания и политики копируются для каждой команды; сервис с несколькими командами привязывается к первой сопоставленной; параллельные цели эскалации превращаются в последовательные правила с нулевой задержкой после первой цели. Проверьте каждое предупреждение: соответствует ли результат нужному порядку вызова дежурных?
  • Обязательное условие переключения: у созданных маршрутов нет каналов уведомлений. Импортированный сервис не готов вызывать дежурных, пока каналы или политики уведомлений не настроены и не проверены.

Сохраните state.json для безопасного продолжения импорта. Защитите route-secrets.json и route-switch-map.csv: в них хранятся секреты приёма событий. Переносите правила оркестрации осмысленно: похожие названия функций не делают языки правил взаимозаменяемыми.

Чек-лист приёмки миграции

  1. Выполните пробный запуск, составьте список неподдерживаемых объектов и отрепетируйте импорт в тестовой среде IR. Перед применением изменений сделайте резервную копию.
  2. Сравните полный цикл дежурств, переходы часовых поясов, переопределения и порядок эскалации. Используйте On-call Health для поиска пробелов в расписании и недостающих настроек доставки.
  3. Дважды отправьте событие срабатывания с одним ключом дедупликации, затем подтвердите и закройте алерт. Проверьте группировку, назначенного ответственного и итоговое состояние, а не только код ответа.
  4. Проверьте реальную доставку в чат, по email, через push или звонок. Оставьте один алерт неподтверждённым для проверки эскалации и убедитесь, что подтверждение прекращает дальнейшие вызовы.
  5. Переключите один некритичный сервис по CSV-таблице перехода и понаблюдайте за циклом дежурств. До приёмки сохраните настройки PagerDuty и документированный способ вернуть отправителей на прежний адрес. На пилоте не допускайте двойного оповещения дежурных.

Когда миграцию лучше отложить

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

Готовы попробовать? Разверните тестовый экземпляр и проверьте один типичный сервис, прежде чем планировать общий переход.

PagerDuty является товарным знаком PagerDuty, Inc. IncidentRelay не связана с PagerDuty.