Alertas e notificações: PagerDuty, Opsgenie

Alertas e notificações: PagerDuty, Opsgenie

1) Por que uma plataforma de alertas separada

• Roteiro por serviços/marcas/ambientes.
• Escalação e agendamento (serviço, follow-the-sun).
• Deduplicação/correlação de eventos.
• Janelas silenciosas (maintenance/freeze) e regras de mel.
• Integração com monitoramento, CI/CD e ChatOps.

Suporte: porta SLO alert de pessoas/máquina runbook reversão/fix pós-mortem.

2) Modelo de sinais e gravidade (severity)

• critical (page) - violação do SLO/erro no caminho do dinheiro (depósito/retirada), queda na disponibilidade, burn-rate.
• high (página/tíquete) é uma degradação substancial sem perfuração SLO explícita.
• medium (tíquete) - capacidade, degradação, retraí.
• low (informação) - tendências, avisos.

Regra: página apenas para SLO ou desencadeador de negócios explícito.

3) Arquitetura de rotação

1. Origem (Prometheus/Alertmanager, Grafana, monitoramento na nuvem, webhooks próprios).
2. Шлюз (PagerDuty/Opsgenie service/integration).
3. Políticas: rotas de formatação ('service', 'eng', 'region'), 'severity', 'payload'.
4. Escalação: sequência de níveis de serviço (L1→L2→menedzher).
5. Comunicações: canais ChatOps, páginas de status, e-mails.

Exemplo de marcas-chave (normalizar)

'service', 'eng', 'region', 'version', 'runbook', 'release _ id', 'road', 'tenant' (se B2V/multi-tenante).

4) Agendamento on-call e escalação

Schedules: primary/secondary, роли (SRE, DBRE, Sec).
Rotações: diurno/noturno, follow-the-sun, fim de semana.
Overrides: férias/doença.
Ack-timout de 5-10 min → camada seguinte. Por horas de trabalho, para o departamento de perfil; fora é um local on-call.

Conselho: mantenha os passos curtos da escalada à noite (menos cansativo), e mais longo de dia (contexto).

5) Integração com Alertmanager (pattern 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) Ruído, dedução e correlação

Chave de dedução: use fingerprint estável (por exemplo, serviço + rota + código).
Agrupamento: 'group _ by' por serviço/ambiente, para que a cascata 5xx não gere dezenas de páginas.
Motas/janelas silenciosas, durante as migrações/lançamentos/testes de carga.
Supressão por motivo: Se já houver um incidente P1 para 'api-gateway @ prod', suprime o P2/P3 filho.

Anti-Pattern: navegar por CPU/Memory sem efeitos confirmados sobre o SLO.

7) Comunicação com lançamentos e ação automática

Em canárias, os recebem alert de SLO-gate webhook em CI/CD-pause/rollback (Argo Rollouts/Helm).
Alert contém: 'release _ id', 'imagem. tag ', link para pipeline e runbook passo de reversão.

Exemplo de linbook de referência em anotações

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

8) ChatOps e comunicações

Auto-criar um canal de incidente em Slack/Teams, atrelado ao tíquete.
Slash-команды: `ack`, `assign @user`, `status set`, `postmortem start`.
Página de status: atualização automática para P1/P2.

9) Ciclo de vida incidente (mínimo)

1. Trigger (alert de SLO/sensores).
2. Page (primary on-call).
3. Ack (confirmação, TTA).
4. Comunicate (canal/status).
5. Mitigate (rollback/função-flag/isolamento).
6. Resolve (TTR).
7. Postmortem (timeline, razões, ações, aulas, proprietário de tarefas).

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

10) Campos de paladar úteis (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) Integração de fontes de sinal

Prometheus/Alertmanager é a principal fonte de SLO/RED.
Grafana Alerting - mais fácil para dashboards/metricas de negócios.
«Latency/Errador».
Eventos K8s - acidentes do cluster (controle-plano, PDB violações).
BD/Filas - lag/locks/reprodução.
Webhooks de aplicativos - sinais de domínio (erro PSP, pouso de frode).

12) Políticas e complicações

RBAC para criação/alteração de políticas, agendamentos, mouts.
Auditoria: quem reconheceu/designou/alterou status, temporizadores.
Minimização PII em paladares (ID do tíquete em vez de email/telefone do usuário).
Plano Dr.: O que fazemos quando o PagerDuty/Opsgenie não está disponível (canal fallback).

13) Exemplos de práticas (PagerDuty vs Opsgenie)

14) Janelas silenciosas e congelamento

Freeze: Proibir paging em janelas de lançamento programadas, deixando apenas P1.
Mit de formatação: 'eng = estágio', 'region = dr', 'service = batch'.
Mute temporal: quando o banco de dados/cargas é migrado, com um dono explícito.

15) Métricas de eficiência (SRE/DORA para alertas)

MTTA/MTTR (em corte de comandos/serviços/turnos).
% de alertas com runbook (meta ≥ 95%).
Proporção de página-alert SLO (meta ≥ 90%).
Ratio útil/ruído (alvo ≥ 3:1).
% de atividade automática (pause/rollback via webhook) - criar.
Burn-down postmortem action items em 14/30 dias.

16) Anti-pattern

Página por «ferro» (CPU, disco) sem afetar o usuário.
Falta de 'group _ by' → 'tempestade' de alertas.
Não há janelas calmas. Os releitores pintam tudo vermelho.
Paylades sem 'service/eng/runbook' - Não é possível routar/agir.
Não há uma única escala de severity e regras (cada fonte é diferente).
Avisos «eternos» que ninguém conserta (alert-dever).

17) Folha de cheque de implementação (0-45 dias)

0-10 dias

Alinhar a escala severity e normalizar tags/anotação.
Criar serviços em PagerDuty/Opsgenie, personalizar schedulas e escalas básicas.
Vincular Alertmanager/Grafana, incluir 'group _ by' e o Dedup.

11 a 25 dias

Digite alertas SLO (multi-window burn), adicione um link runbook.
Configurar ChatOps: canais automáticos, comandos ack/assign.
Incluir janelas silenciosas para lançamentos/migração.

26-45 dias

Integrar auto-pause/rollback para canarinhos (webhooks).
Digite relatórios MTTA/MTTR e de higiene de alert (limpeza de ruídos).
Normalizar pós-mortem e controlar action items.

18) Snippets prontos

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 de 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) Conclusão

Um forte traçado de alertas é um processo + disciplina: Estrato orientado pelo SLO, rotação e escalação bem ajustadas, marcas de formatação e payloads, janelas silenciosas, ChatOps e ações automáticas (pause/rollback). Selecione PagerDuty ou Opsgenie em orçamento e UX, mas mantenha as mesmas regras de ruído, serviço e responsabilidade - para que a aplicação seja rara, precisa e útil e os incidentes sejam curtos e controláveis.