Алерти та повідомлення: 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→menedzher).
5. Комунікації: ChatOps-канали, статус-сторінки, розсилки.

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

«service», «env», «region», «version», «runbook», «release _ id», «route», «tenant» (якщо В2В/мульти-тенант).

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, але дотримуйтеся одних і тих же правил шуму, чергувань і відповідальності - тоді пейдж буде рідкісним, точним і корисним, а інциденти - короткими і керованими.