Alert e notifiche: PagerDuty, Opsgenie

Alert e notifiche: PagerDuty, Opsgenie

1) Perché una piattaforma di alert separata

• Instradamento per servizi/tag/ambienti.
• Escalation e orari (servizio, follow-the-sun).
• Deduplicazione/correlazione degli eventi.
• Finestre silenziose (maintenance/freeze) e regole di miele.
• Integrazioni con monitoraggio, CI/CD e ChatOps.

2) Modello di segnale e gravità (severity)

• critical (page) - violazione SLO/errore del percorso di cassa (deposito/ritiro), riduzione della disponibilità, burn-rate.
• high (page/ticket) è una degradazione significativa senza una prova SLO esplicita.
• medium - capacità, degrado del beck, retrai.
• low (informazioni) - tendenze, avvisi.

Regola: pagina solo per SLO o trigger esplicito aziendale.

3) Architettura di instradamento

1. Sorgente (Prometheus/Alertmanager, Grafana, monitoraggio cloud, siti web personalizzati).
2. Шлюз (PagerDuty/Opsgenie service/integration).
3. Criteri: percorsi di tag («service», «eng», «region»), severity, payload.
4. Escalation: sequenza di livelli di servizio (L1→L2→menedzher).
5. Comunicazioni: canali ChatOps, pagine statali, mailing.

Esempio di tag chiave (standardizzare)

servizio, env, region, versione, runbook, release _ id, route, tenant (se B2V/multi-tenant).

4) Pianificazioni on-call e scalate

Schedules: primary/secondary, роли (SRE, DBRE, Sec).
Rotations: diurni/notturni, follow-the-sun, weekend.
Overrides - vacanza/malattia.
→ ack-timeout 5-10 min per il prossimo strato. Per orari di lavoro, nel reparto di specializzazione; fuori è un sito on-call.

Suggerimento: tenete i brevi passi di escalation di notte (meno stanchezza) e più lunghi di giorno (c'è il contesto).

5) Integrazione con Alertmanager (pattern base)

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) Rumore, deadup e correlazione

Chiave di deduplicazione: utilizzare un fingerprint stabile (ad esempio servizio + route + code).
Raggruppa «group _ by» per servizio/ambiente in modo che la cascata 5xx non generi decine di pagine.
Mute/finestre silenziose per il tempo di migrazione/rilascio/test di carico.
Supponendo che se c'è già un incidente P1 per «api-gateway @ prod», sopprimi i P2/P3 secondari.

Anti-Pattern: Un programma CPU/Memory senza effetti confermati su SLO.

7) Comunicazioni con le release e attività auto

In caso di deposito di canne, le riceve un alert da un -gate di webhook in CA/CD-pausa/rollback (Argo Rollouts/Helm).
Alert contiene "release _ id", "immagine. tag ', collegamento a pipline e runbook del passo di ripristino.

Esempio di riferimento runbook nelle annotazioni

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

8) ChatOps e comunicazioni

Creazione automatica di un canale di incidente in Slack/Teams, allineamento al ticket.
Slash-команды: `ack`, `assign @user`, `status set`, `postmortem start`.
Stato pagina aggiornamento automatico P1/P2.

9) Ciclo di vita dell'incidente (minimo)

1. Trigger (alert SLO/sensori).
2. Page (primary on-call).
3. Ack (conferma, TTA).
4. Comunicato (canale/stato).
5. Mitigate (rollback/feature-flag/isolamento).
6. Resolve (TTR).
7. Postmortem (timeline, cause, azioni, lezioni, proprietario delle attività).

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

10) Campi di paylade utili (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) Integrazione delle sorgenti di segnale

Prometheus/Alertmanager è la fonte principale di SLO/RED.
Grafana Alerting è più semplice per i dashboard/metriche aziendali.
OpenTelemetry/SpanMetrics-latency/error lungo le rotte.
Eventi K8s - Crash del cluster (control-plane, PDB violazione).
Database/Code - lag/locks/replication.
Web hook applicazioni - Segnali di dominio (errore PSP, sfogo di frodo).

12) Regole e compliance

RBAC per la creazione/modifica di regole, pianificazioni, mute.
Controllo: chi ha riconosciuto/assegnato/modificato lo stato, i timestempi.
Riduzioni PII nei pagliacci (ID del ticket invece di email/telefono utente).
DR: cosa facciamo quando il canale fallback non è disponibile.

13) Esempi di pratiche (PagerDuty vs Opsgenie)

14) Finestre silenziose e congelamento

Freeze: proibisce il cercapersone nelle finestre di rilascio pianificate, lasciando solo P1.
Mit per tag: «eng = stage», «region = dr», «service = batch».
Mute temporale: durante la migrazione di database/carichi di lavoro, con un proprietario esplicito.

15) Metriche di efficienza (SRE/DORA per alert)

MTTA/MTTR (nel taglio comandi/servizi/turni).
% di alert con runbook (obiettivo 95%).
Percentuale di pagine-alert SLO (obiettivo 90%).
Ratio utile/rumoroso (obiettivo 3:1).
% di attività automatiche (pausa/rollback tramite webhook) - crescere.
Burn-down postmortem action items in 14/30 giorni.

16) Anti-pattern

Raggruppamento di ferro (CPU, disco) senza impatto sull'utente.
L'assenza dì group _ by "è" tempesta "degli alert.
Niente finestre silenziose. Le release colorano di rosso.
Payload senza «service/eng/runbook» - Impossibile instradare/agire.
Nessuna scala di severity e regole (ciascuna sorgente a suo modo).
Avvertimenti «eterni» che nessuno ripara (alert-dovere).

17) Assegno foglio di implementazione (0-45 giorni)

0-10 giorni

Allineare la scala severity e standardizzare i tag/annotazioni.
Crea servizi nel PagerDuty/Opsgenie, configura schedule e scalate di base.
Aggancia Alertmanager/Grafana, abilita «group _ by» e deadup.

11-25 giorni

Inserisci alert SLO (multi-window burn), aggiungi link runbook.
Configura i canali automatici, i comandi ack/assign.
Abilita finestre silenziose per rilasci/migrazioni.

26-45 giorni

Integrare auto-pausa/rollback per canarini (webhook).
Immettere report MTTA/MTTR e allert (pulizia dei rumori).
Standardizzare il controllo post-mortem e action items.

18) Snippet finiti

Grafana Alerting (JSON body mupping)

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 da alert di Argo Rollouts pause

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

Opsgenie - Routing Rule (pseudo)

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

19) Conclusione

Un tracciato forte di alert è un processo + disciplina: stratificazione orientata a SLO, routing e scalate corrette, tag e payload unificati, finestre silenziose, attività automatiche (pausa/rollback). Scegli l'Opsgenie per budget e UX, ma attenetevi alle stesse regole di rumore, servizio e responsabilità - in questo caso il software sarà raro, preciso e utile, e gli incidenti sono brevi e gestibili.