Escalada de incidentes

1) Propósito e princípios

A escalada de incidentes é um processo controlado de captação rápida de papéis e recursos corretos para minimizar o impacto sobre usuários e métricas de negócios.

• A velocidade é mais importante do que a perfeição. É melhor apontar o incidente mais cedo e desperdiçá-lo do que chegar atrasado.
• Um só comando. Um responsável pela decisão é o Invident Team (IC).
• Transparência. Estados e canais de comunicação claros para steakholders internos e externos.
• Documentável. Todos os passos, soluções e temporizações são fixados para auditorias e melhorias.

2) Gradação de seriedade (Níveis V/P)

• V-0/P0 (crítico) - indisponibilidade total da função-chave (login/pagamento), fuga de dados, risco legal. Navegação imediata de todo o núcleo on-call, freeze lançamentos.
• V-1/P1 (alto) - degradação p95/p99, maior proporção de erros/falhas no processo-chave, indisponibilidade da região/provedor.
• O SEC-2/P2 (médio) é uma degradação parcial para uma linha limitada (região, provedor), há um caminho de volta.
• O V-3/P3 (baixo) não é crítico para o usuário, mas requer atenção (atraso de fundo do ETL, relatório atrasado).

• Raio de afetação (quantos usuários/circulação) x duração x sensibilidade (regulador/PR) → nível de SEV.

3) Processo KPI

MTTD (hora de detecção) - desde o início do incidente até o primeiro sinal.
MTTA (hora de aceitação) - desde o sinal até a confirmação do IC.
MTTR (tempo de recuperação) - antes da recuperação do SLO/função.
Escalation Latency - Desde a confirmação até a conexão do rol/comando desejado.
Reopen Rate - proporção de incidentes reabertos após «resolvido».
Comm SLA - Cumpre os intervalos de aplicativos externos/internos.

4) Papéis e Responsabilidades (RACI)

Invident Commer (IC): proprietário da solução, estabelece nível, plano, freeze, escalações, desoneração. Não escreve registos.
Tech Lead (TL): diagnóstico técnico, hipótese, coordenação de engenheiros.
Comms Lead (CL): páginas de status, comunicação de cliente e interna, alinhamento com o Legal/PR.
Scribe: Detecção exata de factos, timeline, decisões tomadas.
Liaisons (contatos): representantes de provedores/comandos externos (pagamentos, KYC, hospedagem).
Engenheiros on-call: execução do plano, lançamento de playbooks/recalls.

Designe gráficos e bacapes para cada papel.

5) Canais e artefatos

Canal War-room (ChatOps): um único ponto de coordenação (Slack/Teams) com um modelo de anotações automáticas (versões, bandeiras, canários).
Vídeo para V-1 +.
Tíquete incidente (one-pager): ID, SEC, IC, participantes, hipótese/diagnóstico, passos, ETA, status, impacto, links de gráficos.
Página de status pública/interna; agendamento de updates regulares (por exemplo, a cada 15 a 30 minutos para o V-1 +).

6) Pontas de tempo e espaçamento padrão

T0 (min 0-5): IC atribuído, SEC atribuído, freeze lançamentos (se necessário), war-room aberto.
T + 15 min: primeira mensagem pública/interna (que foi afetada, workaround, próxima janela de update).
T + 30/60 min: escalação do nível seguinte (plataforma/BD/segurança/provedores), a menos que haja uma dinâmica sustentável.
Updates regulares: V-0: a cada 15 min; V-1: a cada 30 minutos; V-2 +: cada hora.

7) Regras de escalação automática (políticas de execução)

• Burn-rate orçamento erros acima do limite em janelas curtas e longas.
• Quórum de amostras externas: ≥2 regiões registram degradação HTTP/TLS/DNS.
• O SLI (sucesso de pagamentos/registros) está caindo abaixo do SLO.
• Assinaturas de segurança, suspeitas de fuga/comprometimento.
• Sinal de provedor: webhook de status «major outage».

8) Processo de detecção a solução

1. Declaração de incidente (IC): SEC, abrangência, freeze, lançamento de playbooks.
2. Diagnóstico (TL): hipóteses, isolamento de raio (região, provedor, fichá), verificação (DNS/TLS/CDN/BD/cachê/pneu).
3. Ações mitigantes (vitórias rápidas): reversão/canário ↓, bandeira da degradação, provedor de failover, rate-limit, kesh-overley.
4. Comunicação (CL): página status, clientes/parceiros, Legal/PR, atualizações de cronograma.
5. Confirmação de recuperação: Sintético externo + métricas reais (SLI), levantamento freeze.
6. Desobstrução: redução do SEV, transição para observação N minutos/relógio.
7. Encerramento e RCA: preparação pós-mortem, action items, proprietários e prazos.

9) Trabalhar com provedores externos

Amostras próprias para provedores de várias regiões + exemplos de logs espelhados de pedidos/erros.
Acordos de escalação (contatos, SLA resposta, prioridade, webhooks de status).
Failover automático/reencaminhamento de tráfego pelo provedor SLO.
Base de provas: timeline, sample perguntas/respostas, gráficos de latência/erro, ID do tíquete do provedor.

10) Regulação, segurança e PR

Segurança/P0: isolamento, coleta de artefatos, minimização de divulgação, notificações obrigatórias (interno/externo/regulador).
Legal: alinhamento da formulação de updates externos, contabilidade de SLA/multas contratuais.
PR/Serviço de clientes: modelos de resposta prontos, Q&A, compensações/empréstimos (se aplicável).

11) Modelos de mensagens

• "Nós estamos investigando um incidente da SEC-1 que afeta [função/região]. Sintomas: [brevemente]. Ativamos o caminho de volta [descrição]. A próxima atualização é no [horário]"

• "Diagnóstico [hipótese/confirmação]. Ações: [alteraram o provedor/revogaram o lançamento/ativaram a degradação]. O impacto foi reduzido para [%/cômodo]. O próximo update é [hora]"

• "O incidente do SEC-1 está resolvido. A razão é [raiz]. Tempo de recuperação [MTTR]. Os seguintes passos são [fix/verificação/observação N/relógio]. Pós-mortem - [quando/onde]

12) Playbooks (padrão)

Reduzir a participação no provedor A, transferir X% para B; incluir «degrade-payments-UX»; incluir retais nos limites; avisar a equipa fina.
Crescimento p99 API: reduzir canário nova versão; desligar os fichos pesados; Aumentar o kesh-TTL; verificar os índices de BD/conectórios.
Problema DNS/TLS/CDN: verificar certificados/cadeia; atualizar a gravação; mudar para CDN de reserva; Roubar o carro.
Suspeita de segurança: isolamento de nós, rotação-chave, ativação de canetas mTLS, coleta de artefatos, notificação legal.

13) Desoneração e critérios «resolvidos»

• O SLI/SLO é estável na área verde ≥ N intervalos;
• ações mitigênicas e observação, sem regressão;
• para a classe segura - confirmado vetores fechados, chaves/segredos rotativos.

O fechamento é apenas após a fixação da timeline, proprietários de action items e prazos.

14) Post-mortem (não-oficial)

1. Factos (timeline que os usuários/métricas viram).

2. Razão raiz (técnica/processo).

3. O que funcionou ou não funcionou na escalada.

4. Medidas preventivas (testes, alertas, limites, arquitetura).

5. Um plano de acção com os deadline e proprietários.

6. Conexão com o error budet e revisão de SLO/processos.

15) Métricas de maturidade de processo

Taxa de incidentes declarados antes das queixas dos usuários.
O MTTA em níveis de SEC; Tempo para a conexão do papel desejado.
Cumpre os intervalos de update (Comm SLA).
Porcentagem de incidentes resolvidos por playbooks sem «criatividade» manual.
Executar action items a partir de pós-mortem dentro do prazo.

16) Anti-pattern

«Alguém faça alguma coisa», não há papéis IC/IC.
A multiplicidade no war-room é uma discussão sobre versões em vez de ações.
Declaração tardia → perda de tempo para reunir pessoas.
Sem freeze ou anotações de lançamento - alterações paralelas mascaram a causa.
Falta de comunicação externa - escalada de queixas/risco PR.
Encerrar sem pós-mortem ou agir, repetir os mesmos erros.

17) Folha de cheque IC (cartão de bolso)

• Atribuir o SEV e abrir o war-room.
• Atribuir TL, CL, Scribe, verificar on-call estão presentes.
• Ativar o lançamento-freeze (com o V-1 +).
• Confirmar as fontes da verdade: dashboard SLI, sintético, logs, trailing.
• Aceitar ações de mitigação rápida (reversão/bandeiras/failover).
• Forneça updates regulares.
• Fixar Criteria for Resolve e vigilância após a recuperação.
• Iniciar pós-mortem e nomear proprietários de action items.

18) Incorporação às operações diárias

Treinos (game-days): simulações em cenários-chave.
Catálogo de playbooks: versionizados, testados, com parâmetros.
Ferramentas: ChatOps comandos «/declare », «/page», «/status », «/rollback».
Integrações: tiketing, status-página, pós-mortem, CMDB/catálogo de serviços.
Alinhamento com SLO/Erro Budet: desencadeadores de escalação automática e regras freeze.

19) Resultado

A escalada é uma disciplina operacional, não apenas uma chamada ao responsável. Níveis claros de SEC atribuídos a IC, playbooks prontos, boates de atualização e integração com métricas SLO e políticas Budet transformam um incêndio caótico em um processo controlado com resultado previsível - restauração rápida do serviço, risco mínimo PR/regulatório e melhorias sistêmicas após cada incidente.