Alertas y notificaciones: PagerDuty, Opsgenie

Alertas y notificaciones: PagerDuty, Opsgenie

1) Por qué una plataforma de alertas separada

• Enrutamiento por servicios/etiquetas/entornos.
• Escaladas y horarios (de servicio, follow-the-sun).
• Desduplicación/correlación de eventos.
• Ventanas tranquilas (mantenimiento/libertad) y reglas de muda.
• Integraciones con monitoreo, CI/CD y ChatOps.

Soporte: SLO-umbral → alerta → persona/autómata → runbook → retroceso/fix → post mortem.

2) Modelo de señales y seriedad (severity)

• critical (page) - violación de SLO/error de la ruta monetaria (depósito/retiro), caída de la disponibilidad, burn-rate.
• high (page/ticket) es una degradación sustancial sin una rotura de SLO explícita.
• medium (ticket) - capacidad, degradación de la base, retraye.
• low (inform) - tendencias, advertencias.

Regla: page sólo por SLO o activador de negocio explícito.

3) Arquitectura de enrutamiento

1. Fuente (Prometheus/Alertmanager, Grafana, monitoreo en la nube, webhooks propios).
2. Шлюз (PagerDuty/Opsgenie service/integration).
3. Políticas: rutas por etiquetas ('service', 'env', 'region'), severity, payload.
4. Escaladas: secuencia de niveles de servicio (L1→L2→menedzher).
5. Comunicaciones: canales de ChatOps, páginas de estado, boletines de noticias.

Ejemplo de etiquetas clave (estandarizar)

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

4) Horarios on-call y escalada

Schedules: primary/secondary, роли (SRE, DBRE, Sec).
Rotaciones: día/noche, follow-the-sun, fin de semana.
Overrides: vacaciones/enfermedad.
Escalaciones: ack-timeout 5-10 min → la siguiente capa. Por horas de trabajo - en el departamento especializado; fuera - sitio on-call.

Consejo: mantenga los pasos cortos de la escalada por la noche (menos cansancio), y más largo durante el día (hay contexto).

5) Integración con Alertmanager (patrón básico)

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) Ruido, dedoup y correlación

Clave de dedoup: utilice fingerprint estable (por ejemplo, service + route + code).
Agrupar: 'group _ by' por servicio/entorno para que la cascada 5xx no genere decenas de páginas.
Mutas/ventanas silenciosas: durante las migraciones/lanzamientos/pruebas de carga.
Suppression por la razón: si ya hay un incidente P1 en marcha para 'api-gateway @ prod', suprime los P2/P3 secundarios.

Anti-patrón: Page por CPU/Memory sin impacto confirmado en SLO.

7) Relación con lanzamientos y acciones automáticas

En Canarian Deplay, PagerDuty/Opsgenie recibe una alerta de una puerta de SLO → un webhook en CI/CD → pause/rollback (Argo Rollouts/Helm).
La alerta contiene: 'release _ id', 'image. tag ', el enlace de paipline y runbook del paso de retroceso.

Ejemplo de referencia runbook en anotaciones

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

8) ChatOps y comunicaciones

Auto-creación del canal del incidente en Slack/Teams, enlace al ticket.
Slash-команды: `ack`, `assign @user`, `status set`, `postmortem start`.
Página de estado: actualización automática cuando se P1/P2.

9) Ciclo de vida del incidente (mínimo)

1. Trigger (alerta de SLO/sensores).
2. Page (primary on-call).
3. Ack (confirmación, TTA).
4. Comunicate (canal/estado).
5. Mitigate (rollback/feature-flag/aislamiento).
6. Resolve (TTR).
7. Postmortem (tiempo en línea, razones, acciones, lecciones, propietario de tareas).

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

10) Campos útiles de paload (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) Integración de fuentes de señal

Prometheus/Alertmanager es la fuente principal de SLO/RED.
Grafana Alerting es más fácil para dashboards/métricas de negocio.
OpenTelemetry/SpanMetrics - latency/error a lo largo de las rutas.
Eventos K8S - Accidentes de clúster (control-plan, infracciones PDB).
BD/Colas - lag/locks/replication.
Aplicaciones Webhooks - Señales de dominio (error PSP, estallido de frodo).

12) Políticas y cumplimiento

RBAC para crear/modificar políticas, programaciones, mutaciones.
Auditoría: quién reconoció/designó/cambió el estado, los timestamps.
Minimización PII en paloadas (ID de ticket en lugar de email/teléfono del usuario).
Plan DR: qué hacemos cuando PagerDuty/Opsgenie (canal fallback) no está disponible.

13) Ejemplos de prácticas (PagerDuty vs Opsgenie)

14) Ventanas silenciosas y heladas

Freeze: prohibir la paginación en las ventanas de lanzamiento programadas, dejando sólo P1.
Meut por etiquetas: 'env = stage', 'region = dr', 'service = batch'.
Tiempo mute: durante la migración de la base de datos/cargas - con un propietario explícito.

15) Métricas de eficacia (SRE/DORA para alertas)

MTTA/MTTR (en el corte de comandos/servicios/turnos).
% alertas con runbook (objetivo ≥ 95%).
Porcentaje de page-alert de SLO (objetivo ≥ 90%).
Ratio útil/ruidoso (objetivo ≥ 3:1).
% de autocaravanas (pause/rollback a través de webhook) - crecer.
Burn-down postmortem action items en 14/30 días.

16) Anti-patrones

Page por «hierro» (CPU, disco) sin afectar al usuario.
Falta de alertas 'group _ by' → 'tormenta'.
No hay ventanas tranquilas - los lanzamientos pintan todo en rojo.
Paloads sin 'service/env/runbook': no es posible enrutar/actuar.
No hay una escala única de severidades y reglas (cada fuente es a su manera).
Advertencias «eternas» que nadie arregla (deber de alerta).

17) Lista de verificación de implementación (0-45 días)

0-10 días

Armonizar la escala de severity y estandarizar las etiquetas/anotaciones.
Cree servicios en PagerDuty/Opsgenie, configure schedules y escalaciones básicas.
Vincular Alertmanager/Grafana, habilitar 'group _ by' y dedoup.

11-25 días

Introducir alertas SLO (multi-window burn), añadir enlaces runbook.
Configurar ChatOps: canales automáticos, comandos ack/assign.
Habilitar ventanas silenciosas en versiones/migraciones.

26-45 días

Integrar auto-pause/rollback para canarios (webhooks).
Introduzca los informes MTTA/MTTR y alert-higiene (limpieza de ruidos).
Estandarizar el post mortem y controlar los items de acción.

18) Snippets listos para usar

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 desde 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) Conclusión

Un fuerte circuito de alertas es un proceso + disciplina: estratificación orientada a SLO, enrutamiento y escalamiento competente, etiquetas únicas y paloadas, ventanas silenciosas, ChatOps y acciones automáticas (pause/rollback). Elija PagerDuty u Opsgenie por presupuesto y UX, pero siga las mismas reglas de ruido, servicio y responsabilidad - entonces page será raro, preciso y útil, y los incidentes serán cortos y manejables.