Boas práticas de gestão de incidentes em times de desenvolvimento

1. Fundamentos da gestão de incidentes

Um incidente em times de desenvolvimento é qualquer evento que cause interrupção ou degradação significativa de um serviço, afetando usuários finais ou processos de negócio. A classificação padrão adota quatro níveis:

  • Crítico (P0): sistema completamente indisponível, perda de dados ou violação de segurança
  • Alto (P1): funcionalidade principal afetada, impacto em grande parte dos usuários
  • Médio (P2): funcionalidade secundária comprometida, sem impacto crítico no negócio
  • Baixo (P3): pequenos bugs ou problemas estéticos sem impacto operacional

É fundamental distinguir incidente de problema e de bug. Incidente é o evento em si (ex.: site fora do ar). Problema é a causa raiz subjacente (ex.: query mal otimizada). Bug é o defeito no código que originou o problema. A cultura de resposta rápida combinada com aprendizado contínuo permite que times evoluam sem repetir erros.

2. Estruturação do processo de resposta a incidentes

Todo time precisa de um plano de resposta documentado em runbooks. Um runbook básico para incidente crítico pode ser:

RUNBOOK: Incidente Crítico (P0)
================================
1. DETECÇÃO
   - Alerta recebido via PagerDuty/Slack
   - Engenheiro de plantão assume o chamado em até 5 minutos

2. TRIAGEM (5 min)
   - Verificar dashboards de APM (Datadog/New Relic)
   - Identificar escopo do impacto (todos os usuários? região específica?)
   - Classificar severidade e notificar líder técnico

3. MITIGAÇÃO (15 min)
   - Se deploy recente: executar rollback imediato
   - Se degradação: ativar feature toggle para desabilitar funcionalidade problemática
   - Documentar ações no canal #incidentes

4. ESCALONAMENTO
   - Se não resolvido em 30 min: acionar gerente de engenharia
   - Se não resolvido em 60 min: acionar VP de tecnologia

5. COMUNICAÇÃO
   - Atualizar status page a cada 15 minutos
   - Enviar resumo para stakeholders a cada 30 minutos

Canais de comunicação dedicados são essenciais. No Slack, crie um canal #incidentes com integração ao PagerDuty. Defina escalonamento automático: se o engenheiro primário não responder em 5 minutos, o secundário é acionado. Escalonamento manual deve ser usado quando a complexidade do incidente excede a capacidade da equipe inicial.

3. Ferramentas e automação para detecção e alerta

A detecção precoce reduz drasticamente o MTTR (Mean Time To Resolve). Ferramentas de APM como Datadog, New Relic ou Dynatrace monitoram métricas-chave:

Exemplo de alerta inteligente com Sentry:
-----------------------------------------
Nome do alerta: "Erro 500 em API de Pagamentos"
Condição: Erro_rate > 5% nos últimos 5 minutos
Ação: Notificar canal #pagamentos-criticos no Slack
       + Abrir incidente automático no PagerDuty
       + Criar issue no GitHub com stack trace completo

A observabilidade vai além de métricas: logs estruturados e tracing permitem identificar gargalos em tempo real. Configure alertas com base em percentis (p95, p99) em vez de médias, pois médias escondem picos de latência.

4. Estratégias de diagnóstico e mitigação rápida

Tracing distribuído com Jaeger ou Zipkin é indispensável para sistemas baseados em microserviços. Exemplo de fluxo de diagnóstico:

Fluxo de tracing com Jaeger:
-----------------------------
1. Usuário reporta lentidão no checkout
2. Jaeger mostra que 80% do tempo é gasto no serviço "inventário"
3. Ao abrir o span, identifica-se query SQL lenta (sem índice)
4. Ação imediata: adicionar índice ou cachear resultado
5. Rollback programado: desfazer alteração no schema se necessário

Técnicas de mitigação rápida incluem:

  • Rollback: reversão para versão estável anterior (deploy anterior)
  • Feature toggle: desabilitar funcionalidade problemática sem novo deploy
  • Hotfix: correção rápida em produção com aprovação mínima

Playbooks para incidentes recorrentes devem ser mantidos em repositório Git, versionados e revisados trimestralmente.

5. Comunicação e transparência durante o incidente

Comunicação clara reduz ansiedade de stakeholders e evita retrabalho. Use o formato abaixo para atualizações:

ATUALIZAÇÃO DE INCIDENTE - [TIMESTAMP]
---------------------------------------
Status: INVESTIGANDO / MITIGANDO / RESOLVIDO
Impacto: [descrição do impacto atual]
Ação: [próximo passo planejado]
Próxima atualização: [tempo estimado]

Status pages públicas (Statuspage da Atlassian, Instatus, Better Uptime) devem ser atualizadas automaticamente via API. Documente em tempo real o timeline do incidente em um documento compartilhado (Google Docs ou Confluence), registrando cada ação e sua justificativa.

6. Pós-incidente: análise e aprendizado

A post-mortem deve ser realizada em até 48 horas após o incidente, seguindo a cultura blameless (sem culpabilização). O foco é no sistema, não nas pessoas. Modelo de post-mortem:

POST-MORTEM: Incidente #42 - Queda do Gateway de Pagamentos
=============================================================
Data: 2024-03-15 | Duração: 2h34min | Severidade: P0

RESUMO
------
Falha no serviço de autenticação causou timeout em cadeia.

LINHA DO TEMPO
--------------
14:02 - Alerta de latência alta no gateway
14:05 - Engenheiro de plantão assume
14:12 - Identificado pico de requisições no serviço de auth
14:30 - Feature toggle ativado para bypass de auth
14:45 - Rollback do último deploy do serviço de auth
15:36 - Serviço restaurado, monitorando

CAUSA RAIZ
----------
Deploy de nova versão do serviço de auth sem rate limiting
Aumento de 300% no tráfego de autenticação

AÇÕES CORRETIVAS
----------------
[P0] Adicionar rate limiting no serviço de auth (Prazo: 1 semana)
[P1] Criar alerta de aumento repentino de tráfego (Prazo: 3 dias)
[P2] Revisar processo de deploy para incluir teste de carga (Prazo: 1 mês)

7. Melhoria contínua e cultura de confiabilidade

Métricas-chave para monitorar evolução:

  • MTTD (Mean Time to Detect): tempo médio entre início do incidente e detecção
  • MTTR (Mean Time to Resolve): tempo médio para resolução completa

Realize game days (simulações de incidentes) trimestralmente. Exemplo de cenário:

GAME DAY: Simulação de Falha no Banco de Dados
-----------------------------------------------
Cenário: Réplica de leitura cai durante pico de vendas
Objetivo: Testar failover automático e comunicação
Duração: 45 minutos
Participantes: Engenheiros de plantão, SRE, DBA
Checklist pós-simulação:
- [ ] Failover funcionou em menos de 30 segundos?
- [ ] Time soube identificar a causa em até 10 minutos?
- [ ] Status page foi atualizada corretamente?

As lições aprendidas devem ser integradas ao ciclo de desenvolvimento: crie histórias no backlog para cada ação corretiva, priorizando as de maior impacto (P0 e P1). Revise runbooks e playbooks a cada post-mortem.

Referências