Alerte și notificări: PagerDuty, Opsgenie
Alerte și notificări: PagerDuty, Opsgenie
1) De ce o platformă separată de alerte
Scopul este de a transmite un semnal imediat și relevant persoanei/echipei potrivite și de a începe procesul de incident: recunoaștere (ack), escaladare, comunicare, postmortem. PagerDuty și Opsgenie dau:- Rutare după servicii/etichete/medii.
- Escaladarea și orarele (la datorie, urmați-soare).
- Deduplicarea/corelarea evenimentelor.
- Ferestre liniștite (întreținere/congelare) și reguli de muzică.
- Integrări cu monitorizare, CI/CD și ChatOps.
Suport: SLO-prag → alertă → persoană/mașină → runbook → rollback/fix → postmortem.
2) Modelul semnalului și severitatea
Cantar recomandat:- critică (pagină) - eroare de încălcare SLO/cale de bani (depozit/retragere), scădere a disponibilității, burn-rate.
- mare (pagină/bilet) - degradare semnificativă fără defalcare SLO evidentă.
- mediu (bilet) - capacitate, degradarea spatelui, retrasare.
- low (inform) - tendințe, avertismente.
Regulă: pagină de SLO sau numai declanșator explicit de afaceri.
3) Arhitectura de rutare
1. Sursa (Prometheus/Alertmanager, Grafana, monitorizare cloud, propriile carti web).
2. Шлюз (serviciul PagerDuty/Opsgenie/integrare).
3. Politici: rute după etichete ('service', 'env', 'region'), severitate, sarcină utilă.
4. Escaladarea: succesiunea nivelurilor taxei (L1→L2→menedzher).
5. Comunicații: canale ChatOps, pagini de stare, corespondență.
Exemplu de etichete cheie (standardizare)
"serviciu", "env", "regiune", "versiune", "runbook", "release _ id'," rută "," chiriaș "(dacă B2B/multi-chiriaș).
4) Programe de escaladare și escaladare
Orare: primar/secundar, роли (SRE, DBRE, Sec).
Rotații: zi/noapte, după-soare, week-end.
Suprascrie: concediu/boală.
Escaladare: ack-timeout 5-10 min → următorul strat. Prin program de lucru - la departamentul de profil; exterior - platformă de gardă.
Sfat: Păstrați pași scurți de escaladare pe timp de noapte (mai puțină oboseală) și mai mult în timpul zilei (există context).
5) Integrarea cu Alertmanager (model de bază)
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) Zgomot, deadup și corelație
Cheie dedup: utilizați o amprentă digitală stabilă (de exemplu, serviciu + traseu + cod).
Grupare: „group _ by” prin serviciu/mediu, astfel încât cascada 5xx să nu provoace zeci de pagini.
Mute/ferestre silențioase: în timpul migrațiilor/eliberărilor/testelor de încărcare.
Suprimarea pentru un motiv: dacă există deja un incident P1 pentru "api-gateway @ prod', suprima P2/P3 copilului.
Anti-model: Page by CPU/Memorie fără efect confirmat asupra SLO.
7) Conectarea cu versiuni și auto-acțiuni
Cu depresia canară, PagerDuty/Opsgenie primește o alertă de la poarta SLO → cârlig web în CI/CD → pauză/rollback (Argo Rollouts/Helm).
Alert conține: 'release _ id',' image. tag ", referire la conducta și runbook rollback.
Exemplu de legătură runbook în adnotări
runbook: https://runbooks. company/rollback/api-gateway#canary
8) ChatOps și comunicații
Crearea automată a unui canal incident în Slack/Echipe, conectarea la un bilet.
Slash- команды: 'ack', 'assign @ user', 'status set', 'postmortem start'.
Status page - Actualizări automate pe P1/P2.
9) Ciclul de viață incident (minim)
1. Declanșator (alertă de la SLO/senzori).
2. Page (primar de gardă).
3. Ack (confirmare, TTA).
4. Comunicați (canal/stare).
5. Atenuare (rollback/feature-flag/izolare).
6. Rezolvați (TTR).
7. Postmortem (cronologie, motive, acțiuni, lecții, proprietarul sarcinii).
Kit de rol: IC (comandantul incidentului), Ops plumb, Comms, Scribe.
10) Câmpuri de sarcină utilă (normalizați)
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) Integrarea surselor de semnal
Prometheus/Alertmanager este principala sursă de SLO/RED.
Grafana Alerting este mai ușor pentru tablouri de bord/metrici de afaceri.
OpenTelemetry/SpanMetrics - latență/eroare pe rută.
evenimente K8s - defecțiuni ale clusterului (controale de plan, încălcări ale PDB).
DB/Cozi - lag/lacăte/replicare.
Webhook-uri de aplicații - semnale de domeniu (eroare PSP, creștere a fraudei).
12) Politici și conformitate
RBAC pentru a crea/modifica politici, programe, mutas.
Audit: cine a recunoscut/numit/schimbat statutul, marcajele de timp.
Minimizarea PII în sarcini utile (ID-ul biletului în loc de e-mail/telefon al utilizatorului).
DR-plan: ce facem atunci când PagerDuty/Opsgenie nu este disponibil (canal de rezervă).
13) Studii de caz (PagerDuty vs Opsgenie)
14) Ferestre și înghețuri liniștite
Freeze: Banning paging în ferestrele de lansare planificate, lăsând doar P1.
Tag memorization: 'env = stage', 'region = dr', 'service = lot'.
Mut temporar: atunci când migrați baze de date/teste de încărcare - cu un proprietar explicit.
15) Măsurători de performanță (SRE/DORA pentru alerte)
MTTA/MTTR (defalcat pe echipe/servicii/schimburi).
% din alerte cu runbook (obiectiv ≥ 95%).
Ponderea alertelor de pagină de către SLO (țintă ≥ 90%).
Raportul util/zgomotos (obiectivul ≥ 3:1).
% de auto-acțiuni (pauză/rollback prin webhook) - să crească.
Arde-jos postmortem elemente de acțiune în 14/30 zile.
16) Anti-modele
Page by hardware (CPU, disc) fără a afecta utilizatorul.
Absența „group _ by” → „furtună” de alerte.
Nu există ferestre liniștite - eliberează vopsea totul roșu.
Sarcinile utile fără „service/env/runbook” - nu pot fi dirijate/acționate.
Nu există o singură scară de severitate și reguli (fiecare sursă este diferită).
Avertismente „eterne” că nimeni nu repară (datorie de alertă).
17) Lista de verificare a implementării (0-45 zile)
0-10 zile
Aliniați scala de severitate și standardizați etichetele/adnotările.
Creați servicii în PagerDuty/Opsgenie, configurați programe și escaladări de bază.
Bind Alertmanager/Grafana, activați 'group _ by' și deadup.
11-25 zile
Introduceți alerte SLO (multi-fereastră arde), adăugați un runbook link.
Configurați ChatOps: canale auto, comenzi ack/assign.
Activați ferestre silențioase pe versiuni/migrații.
26-45 zile
Integrați auto-pauză/rollback pentru canari (webhooks).
Introduceți rapoartele MTTA/MTTR și igiena alertă (curățarea zgomotului).
Standardizarea postmortem și controlul asupra elementelor de acțiune.
18) Fragmente gata
Grafana alertare → PagerDuty (cartografiere corp JSON)
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 de alertă → pauză Argo Rollouts
bash curl -X POST "$ARGO_API/rollouts/pause" \
-H "Authorization: Bearer $TOKEN" \
-d '{"name":"api-gateway","namespace":"prod"}'
Opsgenie - Regula de rutare (pseudo)
yaml if:
tags: ["service:payments","env:prod"]
severity: ["P1","P2"]
then:
route_to: "SRE-Payments"
notify: ["Primary OnCall","Secondary"]
19) Concluzie
Un contur puternic de alerte este un proces + disciplină: stratificare orientată spre SLO, rutare și escaladare competentă, etichete și sarcini utile uniforme, ferestre silențioase, ChatOps și acțiuni automate (pauză/rollback). Alegeți PagerDuty sau Opsgenie pe buget și UX, dar respectați aceleași reguli de zgomot, taxe și responsabilitate - atunci pagina va fi rară, exactă și utilă, iar incidentele vor fi scurte și ușor de gestionat.