Alertlər və bildirişlər: PagerDuty, Opsgenie

Alertlər və bildirişlər: PagerDuty, Opsgenie

1) Niyə ayrı alert platforması

• Xidmətlər/etiketlər/mühitlər üzrə marşrutlaşdırma.
• Eskalasiya və cədvəllər (növbə, təqib-gün).
• Hadisələrin deduplikasiyası/korrelyasiyası.
• Sakit pəncərələr (maintenance/freeze) və myut qaydaları.
• Monitorinqlə inteqrasiya, CI/CD və ChatOps.

Dəstək: SLO-eşik → alert → adam/avtomat → runbook → geri/fix → postmortem.

2) Siqnalların modeli və ciddilik (severity)

• critical (page) - SLO pozulması/pul yolu xətası (depozit/çıxarış), əlçatanlığın azalması, burn-rate.
• high (page/bilet) - aşkar SLO qırılmadan əhəmiyyətli deqradasiya.
• orta - tutum, bek deqradasiyası, retraj.
• low (məlumat) - trendlər, xəbərdarlıqlar.

Qayda: page yalnız SLO və ya açıq biznes tetikleyici ilə.

3) Marşrutlaşdırma arxitekturası

1. Mənbə (Prometheus/Alertmanager, Grafana, bulud monitorinqi, öz vebhukları).
2. Шлюз (PagerDuty/Opsgenie service/integration).
3. Siyasətçilər: tags marşrutları ('service', 'env', 'region'), severity, payload.
4. Eskalasiya: növbə səviyyələri ardıcıllığı (L1 → L2 → menecer).
5. Rabitə: ChatOps kanalları, status-səhifələr, poçt.

Əsas etiketlərin nümunəsi (standartlaşdırın)

'service', 'env', 'region', 'version', 'runbook', 'release _ id', 'route', 'tenant' (əgər B2B/multi-tenant).

4) On-call və eskalasiya cədvəlləri

Schedules: primary/secondary, роли (SRE, DBRE, Sec).
Rotations: gündüz/gecə, follow-the-sun, həftə sonu.
Overrides: tətil/xəstəlik.
Eskalasiya: ack-time 5-10 dəq → növbəti qat. İş saatları üzrə - müvafiq şöbəyə; - on-call platforması.

Məsləhət: gecə qısa eskalasiya addımları saxlayın (daha az yorğunluq) və gündüz daha uzun (kontekst var).

5) Alertmanager ilə inteqrasiya (əsas model)

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) Səs-küy, dedup və korrelyasiya

Dedup açarı: sabit fingerprint istifadə edin (məsələn, service + route + code).
Qruplaşma: 5xx kaskadının onlarla səhifə yaratmaması üçün 'group _ by' xidməti/mühiti ilə.
Musiqi/sakit pəncərələr: miqrasiya/relizlər/yük testləri zamanı.
Suppression səbəbi: Əgər artıq «api-gateway @prod» üçün P1 hadisəsi varsa, qız P2/P3 sıxışdırın.

Anti-pattern: SLO-da təsdiqlənmiş təsir olmadan CPU/Memory page.

7) Relizlər və avto fəaliyyət ilə əlaqə

PagerDuty/Opsgenie kanarya deployunda SLO-geyt → webhook-dan CI/CD → pause/rollback (Argo Rollouts/Helm) alert əldə edilir.
Alert daxildir: 'release _ id', 'image. tag ', payline link və geri addım runbook.

Şərhlərdə runbook bağlantıları nümunəsi

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

8) ChatOps və kommunikasiyalar

Slack/Teams-da avtomatik hadisə kanalının yaradılması, biletə bağlanması.
Slash-команды: `ack`, `assign @user`, `status set`, `postmortem start`.
Status-səhifə: P1/P2 avtomatik yeniləmə.

9) Hadisənin həyat dövrü (minimum)

1. Trigger (SLO/sensorlardan alert).
2. Page (primary on-call).
3. Ack (təsdiq, TTA).
4. Communicate (kanal/status).
5. Mitigate (rollback/feature-flag/izolyasiya).
6. Resolve (TTR).
7. Postmortem (time line, səbəblər, hərəkətlər, dərslər, tapşırıqların sahibi).

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

10) Faydalı sahələr paiload (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) Siqnal mənbələrinin inteqrasiyası

Prometheus/Alertmanager SLO/RED-in əsas mənbəyidir.
Grafana Alerting - Dashboard/Business Metrics üçün daha asan.
OpenTelemetry/SpanMetrics - marşrutlar üzrə latency/error.
K8s-hadisələr - klaster qəzaları (control-plane, PDB pozuntuları).
DB/Növbələr - lag/locks/replication.
Applications webhucks - domen siqnalları (PSP səhv, frod sıçrayış).

12) Siyasət və uyğunluq

RBAC siyasətləri, cədvəlləri, musiqiləri yaratmaq/dəyişdirmək.
Audit: Kim statusunu tanıdı/təyin etdi/dəyişdirdi, time-stamplar.
PII-fayllarda minimallaşdırma (istifadəçi e-poçt/telefon əvəzinə ID bileti).
DR planı: PagerDuty/Opsgenie (fallback kanalı) əlçatmazlığında nə edirik.

13) Təcrübə nümunələri (PagerDuty vs Opsgenie)

14) Sakit pəncərələr və şaxtalar

Freeze: Yalnız P1 buraxılması planlaşdırılan buraxılış pəncərələrində peycinq qadağan.
'env = stage', 'region = dr', 'service = batch' etiketlərinə görə.
Müvəqqəti mute: DB/structest miqrasiyası zamanı - açıq sahibi ilə.

15) Effektivlik metrikası (Alertlər üçün SRE/DORA)

MTTA/MTTR (komandalar/xidmətlər/növbələr baxımından).
Runbook ilə% alert (hədəf ≥ 95%).
SLO-da page-alertlərin payı (hədəf ≥ 90%).
Ratio faydalı/səs-küylü (hədəf ≥ 3:1).
% avto yardım (WebHook vasitəsilə pause/rollback) - böyümək.
Burn-down postmortem action items 14/30 gün ərzində.

16) Anti-nümunələr

«Dəmir» Page (CPU, disk) istifadəçiyə təsir etmədən.
'group _ by' → «fırtına» alertlərin olmaması.
Sakit pəncərələr yoxdur - buraxılışlar hər şeyi qırmızı rəngləyir.
'service/env/runbook' olmadan pailoadlar - marşrutlaşdırmaq/hərəkət etmək mümkün deyil.
Heç bir vahid severity şkalası və qaydaları (hər mənbə - özünəməxsus).
Heç kimin düzəltmədiyi «əbədi» xəbərdarlıqlar (alert-borc).

17) Giriş çek siyahısı (0-45 gün)

0-10 gün

Severity şkalasını uyğunlaşdırın və etiketləri/izahları standartlaşdırın.
PagerDuty/Opsgenie xidmətlərini yaradın, schedules və əsas eskalasiyalar qurun.
Alertmanager/Grafana bağlamaq, daxil 'group _ by' və dedup.

11-25 gün

SLO (multi-window burn) daxil edin, runbook linkləri əlavə edin.
ChatOps konfiqurasiya: avtomobil kanalları, ack/assign əmrləri.
Buraxılışlarda/miqrasiyada sakit pəncərələri işə salın.

26-45 gün

Kanaryalar (webhucks) üçün avto-pause/rollback inteqrasiya.
MTTA/MTTR və allert gigiyena hesabatlarını daxil edin (səs-küy təmizlənməsi).
Postmortem və action items nəzarət standartlaşdırın.

18) Hazır snippet

Grafana Alerting → PagerDuty (JSON body mapping)

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" }
]
}

Alert 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 (psevdo)

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

19) Nəticə

Güclü alert konturu proses + nizam-intizamdır: SLO yönümlü stratifikasiya, səriştəli marşrutlaşdırma və eskalasiya, vahid etiketlər və pailoadlar, sakit pəncərələr, ChatOps və avtomatik hərəkətlər (pause/rollback). PagerDuty və ya Opsgenie büdcə və UX seçin, lakin eyni səs-küy, vəzifə və məsuliyyət qaydalarına riayət edin - sonra page nadir, dəqiq və faydalı olacaq və hadisələr qısa və idarə edilə bilər.