Алерты и уведомления: PagerDuty, Opsgenie

Алерты и уведомления: PagerDuty, Opsgenie

1) Зачем отдельная платформа алертов

• Маршрутизацию по сервисам/тегам/окружениям.
• Эскалации и расписания (дежурства, follow-the-sun).
• Дедупликацию/корреляцию событий.
• Тихие окна (maintenance/freeze) и мьют-правила.
• Интеграции с мониторингом, CI/CD и ChatOps.

Опора: SLO-порог → алерт → человек/автомат → runbook → откат/фикс → постмортем.

2) Модель сигналов и серьезность (severity)

• critical (page) — нарушение SLO/ошибка денежного пути (депозит/вывод), падение доступности, burn-rate.
• high (page/тикет) — существенная деградация без явного SLO-пробоя.
• medium (тикет) — емкость, деградации бэка, ретраи.
• low (информ) — тренды, предупреждения.

Правило: page только по SLO или явному бизнес-триггеру.

3) Архитектура маршрутизации

1. Источник (Prometheus/Alertmanager, Grafana, облачный мониторинг, собственные вебхуки).
2. Шлюз (PagerDuty/Opsgenie service/integration).
3. Политики: маршруты по тегам (`service`, `env`, `region`), severity, payload.
4. Эскалации: последовательность дежурных уровней (L1→L2→менеджер).
5. Коммуникации: ChatOps-каналы, статус-страницы, рассылки.

Пример ключевых тегов (стандартизируйте)

`service`, `env`, `region`, `version`, `runbook`, `release_id`, `route`, `tenant` (если B2B/мульти-тенант).

4) Расписания on-call и эскалации

Schedules: primary/secondary, роли (SRE, DBRE, Sec).
Rotations: дневные/ночные, follow-the-sun, выходные.
Overrides: отпуск/болезнь.
Эскалации: ack-таймаут 5–10 мин → следующий слой. По рабочим часам — в профильный отдел; вне — площадка on-call.

Совет: держите короткие шаги эскалации ночью (меньше утомления), и длиннее днем (есть контекст).

5) Интеграция с Alertmanager (базовый паттерн)

yaml receivers:
- name: pagerduty pagerduty_configs:
- routing_key: ${PAGERDUTY_ROUTING_KEY}
severity: '{{ if eq. Labels. severity "critical" }}critical{{ else }}error{{ end }}'
class: '{{.Labels. service }}'
component: '{{.Labels. env }}'
group: '{{.Labels. region }}'
description: '{{.Annotations. summary }}'
details:
service: '{{.Labels. service }}'
env: '{{.Labels. env }}'
runbook: '{{.Annotations. runbook }}'
release: '{{.Annotations. release }}'
route:
receiver: pagerduty group_by: ["service","env","region"]
group_wait: 30s group_interval: 5m repeat_interval: 2h

Opsgenie (webhook)

yaml receivers:
- name: opsgenie opsgenie_configs:
- api_key: ${OPSGENIE_API_KEY}
responders:
- name: "SRE Primary"
type: team priority: '{{ if eq. Labels. severity "critical" }}P1{{ else }}P3{{ end }}'
details:
trace: '{{.Labels. trace_id }}'
runbook: '{{.Annotations. runbook }}'

6) Шум, дедуп и корреляция

Дедуп-ключ: используйте стабильный fingerprint (например, service+route+code).
Группировка: `group_by` по сервису/окружению, чтобы каскад 5xx не породил десятки страниц.
Мьюты/тихие окна: на время миграций/релизов/нагрузочных тестов.
Suppression по причине: если уже идет инцидент P1 для `api-gateway@prod`, подавляйте дочерние P2/P3.

Анти-паттерн: пейдж по CPU/Memory без подтвержденного влияния на SLO.

7) Связь с релизами и авто-действия

При канареечном деплое PagerDuty/Opsgenie получают алерт от SLO-гейта → webhook в CI/CD → pause/rollback (Argo Rollouts/Helm).
Алерт содержит: `release_id`, `image.tag`, ссылку на пайплайн и runbook шага отката.

Пример runbook ссылки в аннотациях

runbook: https://runbooks. company/rollback/api-gateway#canary

8) ChatOps и коммуникации

Авто-создание канала инцидента в Slack/Teams, привязка к тикету.
Slash-команды: `ack`, `assign @user`, `status set`, `postmortem start`.
Статус-страница: автоматическое обновление при P1/P2.

9) Жизненный цикл инцидента (минимум)

1. Trigger (алерт от SLO/датчиков).
2. Page (primary on-call).
3. Ack (подтверждение, TTA).
4. Communicate (канал/статус).
5. Mitigate (rollback/feature-flag/изоляция).
6. Resolve (TTR).
7. Postmortem (таймлайн, причины, действия, уроки, владелец задач).

Role-kit: IC (incident commander), Ops lead, Comms, Scribe.

10) Полезные поля пэйлоада (normalize)

json
{
"service": "payments-api",
"env": "prod",
"region": "eu-central-1",
"severity": "critical",
"event_class": "slo_burn",
"summary": "Withdraw 5xx > 0. 5% for 10m",
"runbook": "https://runbooks/payments/withdraw-5xx",
"release_id": "rel-2025-11-03-14-20",
"image": "ghcr. io/org/payments:1. 14. 2",
"trace_id": "8a4f0c2e9b1f42d7",
"annotations": { "canary": "25%" }
}

11) Интеграции источников сигналов

Prometheus/Alertmanager — главный источник SLO/RED.
Grafana Alerting — проще для дашбордов/бизнес-метрик.
OpenTelemetry/SpanMetrics — latency/error по маршрутам.
K8s-события — аварии кластера (control-plane, PDB нарушения).
БД/Очереди — lag/locks/replication.
Вебхуки приложений — доменные сигналы (ошибка PSP, всплеск фрода).

12) Политики и комплаенс

RBAC на создание/изменение политик, расписаний, мьютов.
Аудит: кто признал/назначил/изменил статус, таймстемпы.
PII-минимизация в пэйлоадах (ID тикета вместо email/телефона пользователя).
DR-план: что делаем при недоступности PagerDuty/Opsgenie (fallback канал).

13) Примеры практик (PagerDuty vs Opsgenie)

14) Тихие окна и заморозки

Freeze: запрет пейджинга в плановые окна релизов, оставив только P1.
Мьют по тегам: `env=stage`, `region=dr`, `service=batch`.
Временной mute: при миграции БД/нагрузтестах — с явным владельцем.

15) Метрики эффективности (SRE/DORA для алертов)

MTTA/MTTR (в разрезе команд/сервисов/смен).
% алертов с runbook (цель ≥ 95%).
Доля page-алертов по SLO (цель ≥ 90%).
Ratio полезных/шумных (цель ≥ 3:1).
% автодействий (pause/rollback через вебхук) — растить.
Burn-down postmortem action items за 14/30 дней.

16) Анти-паттерны

Пейдж по «железу» (CPU, диск) без влияния на пользователя.
Отсутствие `group_by` → «шторм» алертов.
Нет тихих окон — релизы красят все красным.
Пэйлоады без `service/env/runbook` — невозможно маршрутизировать/действовать.
Нет единой шкалы severity и правил (каждый источник — по-своему).
«Вечные» предупреждения, которые никто не чинит (алерт-долг).

17) Чек-лист внедрения (0–45 дней)

0–10 дней

Согласовать шкалу severity и стандартизировать теги/аннотации.
Создать сервисы в PagerDuty/Opsgenie, настроить schedules и базовые эскалации.
Привязать Alertmanager/Grafana, включить `group_by` и дедуп.

11–25 дней

Ввести SLO-алерты (multi-window burn), добавить runbook ссылки.
Настроить ChatOps: автоканалы, команды ack/assign.
Включить тихие окна на релизы/миграции.

26–45 дней

Интегрировать авто-pause/rollback для канареек (вебхуки).
Ввести отчеты MTTA/MTTR и аллерт-гигиену (чистка шумов).
Стандартизировать постмортем и контроль за action items.

18) Готовые сниппеты

Grafana Alerting → PagerDuty (JSON body маппинг)

json
{
"routing_key": "${PAGERDUTY_ROUTING_KEY}",
"event_action": "trigger",
"payload": {
"summary": "{{.RuleName }}: {{ index. Labels \"service\" }}",
"severity": "{{ if eq (index. Labels \"severity\") \"critical\" }}critical{{ else }}error{{ end }}",
"source": "grafana",
"component": "{{ index. Labels \"env\" }}",
"group": "{{ index. Labels \"region\" }}"
},
"links": [
{ "href": "{{.DashboardURL }}", "text": "Dashboard" },
{ "href": "{{ index. Labels \"runbook\" }}", "text": "Runbook" }
]
}

Webhook из алерта → Argo Rollouts pause

bash curl -X POST "$ARGO_API/rollouts/pause" \
-H "Authorization: Bearer $TOKEN" \
-d '{"name":"api-gateway","namespace":"prod"}'

Opsgenie — Routing Rule (псевдо)

yaml if:
tags: ["service:payments","env:prod"]
severity: ["P1","P2"]
then:
route_to: "SRE-Payments"
notify: ["Primary OnCall","Secondary"]

19) Заключение

Сильный контур алертов — это процесс + дисциплина: SLO-ориентированная стратификация, грамотная маршрутизация и эскалации, единые теги и пэйлоады, тихие окна, ChatOps и автоматические действия (pause/rollback). Выберите PagerDuty или Opsgenie по бюджету и UX, но придерживайтесь одних и тех же правил шума, дежурств и ответственности — тогда пейдж будет редким, точным и полезным, а инциденты — короткими и управляемыми.