Alertes et notifications : PagerDuty, Opsgenie

Alertes et notifications : PagerDuty, Opsgenie

1) Pourquoi une plate-forme d'alertes séparée

• Routage par service/tags/environnement.
• Escalade et horaires (service, follow-the-sun).
• Déduplication/corrélation des événements.
• Fenêtres calmes (maintenance/freeze) et règles de mue.
• Intégration avec monitoring, CI/CD et ChatOps.

Support : SLO-seuil → alert → homme/machine → runbook → retour/fix → post mortem.

2) Modèle de signal et gravité (severity)

• critical (page) - violation de SLO/erreur de chemin d'argent (dépôt/retrait), baisse de disponibilité, burn-rate.
• high (page/ticket) est une dégradation significative sans trou SLO explicite.
• medium (tiket) - capacité, dégradation du back, retrai.
• low (info) - tendances, avertissements.

Règle : page uniquement par SLO ou déclencheur d'entreprise explicite.

3) Architecture de routage

1. Source (Prometheus/Alertmanager, Grafana, surveillance cloud, webhooks natifs).
2. Шлюз (PagerDuty/Opsgenie service/integration).
3. Politiques : itinéraires par tag ('service', 'bou', 'région'), severity, payload.
4. Escalade : séquence des niveaux de garde (L1→L2→menedzher).
5. Communications : Chaines ChatOps, pages de statut, newsletters.

Exemple de tags clés (standardiser)

"service", "bou", "région", "version", "runbook", "release _ id'," route "," tenant "(si B2B/multi-tenant).

4) Horaires d'appel et d'escalade

Schedules: primary/secondary, роли (SRE, DBRE, Sec).
Rotations : jour/nuit, follow-the-sun, week-end.
Overrides : vacances/maladie.
Escalade : ack-timout 5-10 min → la couche suivante. En heures de travail, dans le département professionnel ; en dehors - site on-call.

Conseil : gardez les étapes courtes de l'escalade la nuit (moins de fatigue), et plus longtemps le jour (il y a un contexte).

5) Intégration avec Alertmanager (modèle de 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) Bruit, déduplication et corrélation

Clé dedup : utilisez un fingerprint stable (par exemple, service + route + code).
Groupement : 'group _ by' par service/environnement afin que la cascade 5xx ne produise pas des dizaines de pages.
Muts/fenêtres silencieuses : pour la durée des migrations/sorties/tests de charge.
Suppression par cause : si un incident P1 est déjà en cours pour 'api-gateway @ prod', supprimez les P2/P3 enfants.

Anti-modèle : Page par CPU/Mémoire sans effet confirmé sur SLO.

7) Lien avec les sorties et auto-action

Dans le cas canarien, PagerDuty/Opsgenie obtient un alert de SLO-gate → webhook dans CI/CD → pause/rollback (Argo Rollouts/Helm).
Alert contient : 'release _ id', 'image. tag ', lien Pipline et runbook de l'étape de retour.

Exemple de lien runbook dans les annotations

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

8) ChatOps et communications

Création automatique d'un canal d'incident dans Slack/Teams, lien vers un ticket.
Slash-команды: `ack`, `assign @user`, `status set`, `postmortem start`.
Page d'état : Mise à jour automatique lors de l' P1/P2.

9) Cycle de vie de l'incident (minimum)

1. Trigger (alert de SLO/capteurs).
2. Page (primary on-call).
3. Ack (confirmation, TTA).
4. Communication (canal/statut).
5. Mitigate (rollback/feature-flag/isolation).
6. Resolve (TTR).
7. Postmortem (temps, causes, actions, leçons, propriétaire des tâches).

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

10) Champs utiles de paloade (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) Intégration des sources de signaux

Prometheus/Alertmanager est la source principale de SLO/RED.
Alerting Grafana - plus facile pour les dashboards/métriques d'affaires.
OpenTelemetry/SpanMetrics - latency/error le long des itinéraires.
K8s-événements - accidents de cluster (control-plane, violation PDB).
OBD/Files d'attente - lag/locks/replication.
Les webhooks des applications sont des signaux de domaine (erreur PSP, surtension fred).

12) Politiques et conformité

RBAC pour créer/modifier des politiques, des horaires, des mutes.
Vérification : qui a reconnu/assigné/modifié le statut, les délais.
Minimisation des PII dans les Paloades (ID ticket au lieu de l'email/téléphone de l'utilisateur).
Plan DR : ce que l'on fait lorsque PagerDuty/Opsgenie (canal fallback) est indisponible.

13) Exemples de pratiques (PagerDuty vs Opsgenie)

14) Fenêtres silencieuses et gelées

Freeze : interdiction de paging dans les fenêtres de sortie planifiées, ne laissant que P1.
Myuth par les balises : « bou = stage », « région = dr », « service = batch ».
Mute temporaire : lors de la migration OBD/charges - avec un propriétaire explicite.

15) Métriques d'efficacité (SRE/DORA pour alerts)

MTTA/MTR (en coupe commandes/services/postes).
% d'alerts avec runbook (objectif ≥ 95 %).
Proportion de pages alertes par SLO (objectif ≥ 90 %).
Ratio utile/bruyant (objectif ≥ 3:1).
% d'autopsies (pause/rollback via le webhook) - élever.
Burn-down postmortem action items en 14/30 jours.

16) Anti-modèles

Page par « fer » (CPU, disque) sans affecter l'utilisateur.
L'absence de "groupe _ by '→" tempête "d'alerts.
Il n'y a pas de fenêtres silencieuses - les sorties peignent tout en rouge.
Paloades sans 'service/bou/runbook' - impossible de router/agir.
Il n'y a pas d'échelle de severity et de règles (chaque source est à sa façon).
Des avertissements « éternels » que personne ne répare (alert devoir).

17) Chèque de mise en œuvre (0-45 jours)

0-10 jours

Aligner l'échelle de severity et normaliser les balises/annotations.
Créer des services dans PagerDuty/Opsgenie, configurer les schedules et les escalades de base.
Lier Alertmanager/Grafana, activer 'group _ by' et dedup.

11-25 jours

Entrez SLO-alerts (multi-window burn), ajoutez un lien runbook.
Configurer ChatOps : canaux automatiques, commandes ack/assign.
Activer les fenêtres silencieuses sur les versions/migrations.

26-45 jours

Intégrer auto-pause/rollback pour canaries (webhooks).
Entrez les rapports MTTA/MTR et allert-hygiène (nettoyage du bruit).
Uniformiser le post mortem et le contrôle de l'action items.

18) Prêtes à partir

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

Webhook d'alert → 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) Conclusion

Le contour fort des alertes est un processus + discipline : stratification orientée SLO, routage et escalades intelligents, étiquettes et paloades uniques, fenêtres silencieuses, ChatOps et actions automatiques (pause/rollback). Choisissez PagerDuty ou Opsgenie sur le budget et l'UX, mais respectez les mêmes règles de bruit, de garde et de responsabilité - alors la page sera rare, précise et utile, et les incidents sont courts et gérables.