Incidentes e playbooks SRE

1) O que é um incidente e como ele se relaciona com o SLO

O incidente é um evento que viola o SLO/função ou oferece risco de violação (o orçamento errado é inadmissível rapidamente).
Métricas clássicas: MTTD, MTTA, MTTR, MTBF.
Erro de orçamento e burn-rate definem a prioridade e as janelas de escalação.

2) Níveis de gravidade (SEC) e critérios

SeV: 5xx% de excesso, p95> liminares, dexline spike de pagamento, Kafka-lag> limiar, NodeNotReady>X min, TLS expira <7 dias, sinais DDoS/fuga.

3) Papéis e responsabilidades (RACI)

Invident Team (IC) - Tomada de decisões exclusiva, gerenciamento de fluxo de tarefas, mudança de status do SEC.
Ops Lead (Tech Lead) - estratégia técnica, hipótese, coordenação de fixação.
Comunicação Lead (Comms) - status-update (interno/externo), StatusPage/chat/e-mail.
Scribe (Cronista) - timeline, soluções, artefatos, links gráficos/logs.
On-call Engineers/SMEs - Execução de playbooks.
Segurança/Privacidade - ativado em casos de segurança ou PII.
FinOps/Payments - quando influenciar o billing/PSP/custo.

4) Ciclo de vida incidente

1. Detect (alert/reporte/sintético) → auto-criação do cartão do incidente.
2. Triagem (IC atribuído, SEC atribuído, coletar contexto mínimo).
3. Estabilização (mitigation: desligar fic/rollback/rate-limit/failover).
4. Investigação (RCA-hipótese, coleta de factos).
5. Restauração do serviço (validate SLO, observação).
6. Comunicação (dentro/fora, relatório final).
7. A seguir (sem acusações, plano CAPA, proprietários, prazos).
8. Prévence (testes/alertas/playbooks/bandeiras, pré-ensinamento do comando).

5) Comunicações e «war-room»

Um único canal de incidente ('# inc-sev1-YYYMMDD-hhmm'), apenas factos e ações.
"IC: Atribuir rollback versão 1. 24 «ETA 10 min».

Status-update: V-1 a cada 15 minutos, V-2 a cada 30-60 minutos

Status Page/Comunicação Externa - via Comms Lead por modelo.
As salas paralelas «silenciosas», as hipóteses não testadas para o canal compartilhado.

6) Alerting e SLO-burn (exemplo de regras)

Canal rápido (1-5 min) e canal lento (1-2 h) burn-rate.
Sinais multi: erro de orçamento, 5xx%, p95, Kafka-lag, pagamento decline-rate, sintético.
A busca da causa primária é apenas após a estabilização dos sintomas.

promql
Ошибочная доля 5xx > SLO sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.01

Burn-rate быстрый (пример)
(sum(rate(http_requests_total{status=~"5.."}[1m])) / sum(rate(http_requests_total[1m])))
/ (1 - SLO) > 14.4

7) Playbooks vs ranbooks

Playbook é um cenário para o tipo de incidente (ramificações, condições, riscos).
Ranbook é um «mapa» específico de passos/comandos (verificação, fixação, verificação).
Regra: playbook refere-se a vários ranbooks (rollbacks, funções-flags, failover, zoom, bloqueio de tráfego etc).

8) Modelo de cartão de incidente

yaml id: INC-YYYYMMDD-XXXX title: "[SEV-1] Рост 5xx на API /payments"
status: active    monitoring    resolved sev: 1 reported_at: 2025-11-03T17:42Z ic: <ФИО>
ops_lead: <ФИО>
comms_lead: <ФИО>
scope: regions: [eu-west-1], tenants: [prod], services: [api, payments]
impact: "5xx=12% (обычно <0.5%), конверсия депозитов -20%"
mitigation: "откат на 1.23.4, включен rate-limit 2k rps, фича X выключена"
timeline:
- "17:42: алерт SLO burn-rate быстрый"
- "17:46: назначен IC, открыт war-room"
- "17:52: найден релиз 1.24 как кандидат"
- "18:02: откат завершен, 5xx вернулись к 0.3%"
artifacts:
dashboards: [...]
logs: [...]
traces: [...]
risk: "возможен очередной всплеск при включении фичи X"
next_steps: "канареечный релиз, тесты, постмортем до 2025-11-05"

9) Modelo de playbook SRE (Markdown)

markdown
Плейбук: <название>
Область/симптомы
Список детекторов, сигнатуры в метриках/логах/трассах.

Быстрая стабилизация (Triage & Mitigation)
- [ ] Ограничить трафик/включить WAF-правило/фичефлаг OFF
- [ ] Роллбэк/канареечный релиз/выкатить фикс конфигурации
- [ ] Включить деградационный режим (read-only, кэш-форс)

Диагностика (RCA hints)
- Метрики: … Логи: … Трассы: …
- Частые первопричины/чек-лист гипотез

Риски и коммуникации
- Внутренние/внешние апдейты, SLA-обязательства

Верификация
- [ ] SLO восстановлено (порог/время окна)
- [ ] Нет регресса по смежным сервисам

Последующие действия
- CAPA, задачи в backlog, обновление алертов/дашбордов/плейбука

10) Playbooks típicos

10. 1 API 5xx Spike

Estabilização: desligar o fichiflag problemático; aumentar as réplicas de API; ativar o armazenamento em dinheiro; O regresso do lançamento.
Diagnóstico: Desenho de lançamento, erros de logs (top-exceptions), altura p95, pressure BD/cajá.
Riscos: cascata em pagamentos/backends.

10. 2 БД: replication lag / lock storm

Estabilização: suspensão de jobs pesados/reportes; redirecionar as leituras para o assistente; aumentar wal _ buffers/réplica-slots.
Diagnóstico: transações longas que bloqueiam pedidos, alterações de plano.
Fixação: índices/hints, repaginação de jobs, partilha de consultas.

10. 3 Kafka consumer lag

Estabilização: escalar temporariamente o consumer's; reduzir a produção de serviços não críticos; aumentar as partições/quotas.
Diagnóstico: rebalances, deserialização lenta, pausas GC.
Verificação: A liga → ao alvo, sem dropas.

10. 4 K8s NodeNotReady/tempestade de recursos

Estabilização: cordon + drain; redistribuir cargas; verificar CNI/overlay; desligar os barulhentos daemonSet's.
Diagnóstico: disk pressure, OU, throttling, network drops.
Prevenção: pod disrupition budgets, limites de recursos/requests.

10. 5 TLS/certificados expiram

Estabilização: atualização forçada do segredo/ingress; override temporário.
Diagnóstico: cadeia de confiança, clock-skew.
Prevenção: Alert T-30/T-7/T-1, auto-renuvial.

10. 6 DDoS/tráfego anormal

Estabilização: regras WAF/bot, rate-limit/geo-filtros, upstream shed load.
Diagnóstico: perfis de ataque (L3/4/7), fontes, guarda-chuvas.
Prevenção: anycast, autoscaling, cachê, play-nice com provedores.

10. 7 Pagamento PSP-outeage

Estabilização: smart-roting para métodos PSP alternativos; levantar retry com jitter; degradação UI «suave».
Diagnóstico: pike falhas de código, API/status de página PSP.
Comunicações: updates transparentes para negócios e safort, estatísticas corretas de ND/conversão.

10. 8 Incidente de segurança/fuga de PII

Estabilização: isolamento de nós/segredo-rotação, bloqueio de excfiltração, Legal Hold.
Diagnóstico: tempo de acesso, sujeitos/campos afetados.
Notificações: Reguladores/parceiros/usuários para os requisitos de jurisdição.
Prevenção: Maior DLP/segmentação, «least privege».

11) Automação de playbooks

ChatOps comandos: '/ic set sec 1 ', '/deploy rollback api 1. 23. 4`, `/feature off X`.
Runbook-bots: passos meio automáticos (drain node, flip traffic, purge cachê).
Ganchos Self-healing: detector → mitigation padrão (rate-limit, restart, scale).
Auto-criação de cartões/timeline de alertas e comandos.

12) Qualidade dos playbooks: folha de cheque

• Sintomas claros e detectores (métricas/logs/pistas).
• Passos rápidos de estabilização com avaliação de risco.
• Os comandos/script são válidos, verificados em estaging.
• Verificação de recuperação SLO.
• Modelos de comunicação e critérios de update externo.
• Referência pós-mortem e CAPA após encerramento.

13) Pós-morte (blameless) e CAPA

O objetivo é treinar, não encontrar o culpado.
Conteúdo: o que aconteceu, como descobriram que foi bom/ruim, a contribuição de fatores (aqueles + processos), ações para prevenção.
Prazo: SEC-1 - no prazo de 48 horas; V-2 - 3 dias úteis.
CAPA: proprietários específicos, prazos, efeitos mensuráveis (redução MTTR/crescimento MTTD).

14) Aspectos legais e base de provas

Legal Hold: congelamento de logs/trilhos/alertas, write-once armazenamento.
A cadeia de armazenamento de artefactos, acessibilidade por papel, controle de integridade.
Notificações regulatórias: prazos/modelos para jurisdições (especialmente para pagamentos afetados/PII).
Privacidade: Minimizar e disfarçar PII na análise.

15) Métricas de eficiência do processo de incidentes

MTTD/MTTA/MTTR por bairros e domínios.
O SEV (underrating/overrating) é válido.
O número de incidentes com o carro mitigate.
Cobertura com playbooks top-N do cenário (> 90%).
Executar CAPA dentro do prazo.

16) Implementação por etapa

1. Semana 1: matriz de SEV, papéis on-call, modelo de cartão compartilhado, regulamento de war-room.
2. Semana 2: Playbooks para top 5 sintomas (5xx, BD, Kafka-lag, NodeNotReady, TLS).
3. Semana 3: ChatOps/bots, auto-criação de cartões, modelos de comunicação/StatusPage.
4. Semana 4 +: Playbooks de segurança, PSP-outeijs, Legal Hold, regulares drills/jogos de caos.

17) Exemplos de ranbooks «rápidos» (fatias)

Rollback API (K8s)

bash kubectl rollout undo deploy/api -n prod kubectl rollout status deploy/api -n prod --timeout=5m
Верификация:
kubectl -n prod top pods -l app=api

Drain node

bash kubectl cordon $NODE && kubectl drain $NODE --ignore-daemonsets --delete-emptydir-data --timeout=10m

Função-flag OFF (exemplo)

bash curl -X POST "$FF_URL/toggle" -H "Authorization: Bearer $TOKEN" -d '{"feature":"X","enabled":false}'

18) Mini-FAQ

Quando levantar o SEC-1?
Quando sofre a função SLO/negócio chave (pagamentos, login, jogo), e burn-rate «come» o orçamento com horas de antecedência.

O que é mais importante: RCA ou recuperação?
Sempre estabilizado, depois RCA. O tempo até a estabilização é o principal indicador.

É preciso automatizar tudo?
Automatize passos frequentes e seguros; raras/de risco - meio-carro e confirmação IC.

Resultado

Um processo de incidentes confiável é mantido em três pilares: papéis claros e regras SEC, playbooks de qualidade/ranbooks automatizados e cultura pós-mortem sem acusações. Fixe os modelos, treine on-call, mede MTTR/orçamento errado e melhore constantemente os detectores e playbooks - reduzindo diretamente os riscos e os custos de interrupção.