Сравнение с альтернативами

Если вы уже работали с одной из основных систем on-call, этот раздел поможет быстро сориентироваться в нашей терминологии и логике. Это не сравнение «лучше / хуже» и не выбор между системами, а карта архитектурных и терминологических различий. Прочитайте секцию про продукт, с которым вы знакомы — этого достаточно, чтобы понять, с чем имеете дело.

Если вы из OpsGenie

• Приоритет vs severity. В OpsGenie приоритеты P1–P5 фиксированные и проставляются на алерте (или меняются через alert policies). У нас два уровня severity (critical, warning), которые маппятся из payload через настройку severity_mapping на каждой Integration.

• Routing внутри Team. В OpsGenie у Team — собственные Routing Rules с conditions (тэги, источник, сообщение) и first-match-wins. У нас цепочка фиксирована: Integration → Team → Escalation Policy. Условная обработка алертов — отдельная сущность Integration Policy с ограниченным набором conditions и actions (без regex, без шаблонизации).

• Status page. В OpsGenie status page — отдельный продукт (Statuspage). У нас встроен: Services, Service Groups, Events.

• Unacknowledge. В OpsGenie unacknowledge перезапускает уведомления заново с шага 1, и при исчерпании политики повтор может пройти многократно. У нас unacknowledge продолжает эскалацию со следующего шага после того, на котором был ack. При исчерпании цепочки алерт остаётся в firing, повтор не делается. Подробнее — в Quick Start: Escalation Policy.

• Notification Policies. В OpsGenie это отдельная team-level сущность с действиями suppress / delay / auto-restart / auto-close. У нас нет отдельных Notification Policies: подавление и задержка — через Integration Policy actions; временные тишины — через Silence. Auto-close по таймеру не делается.

Если вы из Grafana OnCall

• Routing. В Grafana OnCall маршрутизация описывается Jinja2-шаблонами, возвращающими True/False для каждого route (условия вида payload.severity == "critical"). У нас шаблонизации нет: маршрут идёт по цепочке Integration → Team → Escalation Policy. Условная обработка — через Integration Policy с ограниченным набором conditions (точное совпадение labels, severity_in, time_window). Подробнее про подключение источника — в Quick Start: Connect Integration.

• Группировка алертов. В Grafana OnCall grouping_id вычисляется Jinja2-шаблоном на интеграции. У нас flat-группировка: один batch AlertManager = один Alert, ключ группы — sha256 от sorted groupLabels, без шаблонизации.

• Severity. В Grafana OnCall нет явной модели уровней — значение severity приходит в labels payload'а и используется в Routing Templates или в флаге Important на шагах эскалации. У нас два явных уровня (critical, warning), их источник и маппинг настраивается на Integration.

• Status page. В Grafana OnCall встроенного status page нет — состояние сервисов визуализируется через Grafana dashboards. У нас status page встроен в продукт.

• Escalation behavior по важности. В Grafana OnCall агрессивные уведомления включаются флагом Important на шаге эскалации и Important-набором personal notification rules. У нас поведение определяется самой severity: critical идёт по всей цепочке автоматически, warning отрабатывает только шаг 1 и дальше эскалируется вручную. Personal notification rules выбирают каналы под critical и warning отдельно. Подробнее — в Quick Start: Escalation Policy.

Если вы из PagerDuty

• Priority и Urgency. В PagerDuty два независимых измерения: пять уровней Priority (P1–P5, настраиваемые) и отдельная Urgency (high / low / dynamic), которая определяет агрессивность уведомлений. У нас одно измерение — severity (critical, warning) — оно одновременно определяет и важность, и поведение уведомлений (см. эскалацию ниже).

• Service в маршрутизации. В PagerDuty Service — центральная сущность routing: Events API принимает routing_key, привязанный к конкретному Service, и Escalation Policy назначена на Service. У нас Service используется только для status page и аналитики. Маршрутизация идёт по Integration → Team → Escalation Policy, и Escalation Policy привязана к Team, не к Service. Подробнее про подключение источника — в Quick Start: Connect Integration.

• Условная обработка. В PagerDuty это Event Orchestration: трёхуровневая система (Global Orchestration / Router / Service Orchestration) с собственным языком условий PCL (PagerDuty Condition Language), action variables, cache variables. У нас условная обработка — Integration Policy с ограниченным набором: три типа conditions (точное совпадение labels, severity_in, time_window) и пять actions (drop, suppress, delay_until, override_severity, add_labels). Собственного condition language нет.

• Группировка алертов. В PagerDuty встроены ML-based grouping (Intelligent Alert Grouping в нескольких режимах) и rule-based (Time-Based, Content-Based) — частично доступны через AIOps add-on. У нас flat-группировка без ML: один batch AlertManager = один Alert, ключ группы — sha256 от sorted groupLabels.

• Business Services vs Technical Services. В PagerDuty два типа сервисов: Technical Services принимают events и привязаны к Escalation Policy, Business Services агрегируют их статус для Internal Status Page и не получают events напрямую. У нас один тип Service + Service Groups. Ни Service, ни Service Group не получают events напрямую — статус сервиса вычисляется из активных Events (incident, maintenance) по приоритету «худшее побеждает».