Resposta a incidentes e acidentes

(Seção Operações e Gerenciamento)

1) Definições e metas

O incidente é um evento que viola o SLO/segurança/complacência ou oferece riscos aos clientes, dinheiro, dados, reputação.
Os objetivos da reação são restaurar rapidamente o serviço, minimizar os danos, fixar provas, comunicar de forma transparente e evitar que se repita.

Princípios-chave

Safety first: proteger as pessoas/dados/dinheiro é mais importante que as funções.
One throat to choke: um único Invident Team (IC) toma decisões.
Actionable now: cada hipótese é acompanhada de verificação/ação.
Evidence matters: tudo é logado, artefatos são assinados, timeline é detalhado.

2) Classificação (severity & prioridade)

Trigger: violação do SLO, regra do alert, reporte manual, incidente legal (DPO/CCO).

3) Papéis e Responsabilidades (RACI)

Invident Commer (A) é o líder do incidente, de tarefas, de decisões, de mudanças de IC em longos incidentes.
Tech Lead (R) - diagnóstico técnico/fixação, coordenação SRE/engenharia.
Comms Lead (R) - escreve atualizações status (dentro/externo), dono de página status.
Scribe (R) - protocolo, timeline, coleta de artefatos.
Segurança/Legal (C/A para casos de security) - avaliação de risco, notificações obrigatórias.
Customer Apoio (C) - Modelos de resposta, rotação de tíquetes.
Parceiro Liaison (C) - comunicação com provedores/tenentes.
Gestão (I) - informação, soluções de negócios (crédito/compensação).

4) Primeiros 15 minutos (modelo)

1. Marcar IC e abrir o cartão do incidente (bate-papo, vídeo, jira/tracker).
2. Atribuir o SEV e fixar o sintoma SLO (o que foi quebrado).

• incluir runbooks/runas: circuito-breakers, trottling, mudança de rota, intervalo de promoção;
• ao comprometer - kill-switch funções sensíveis.
• 4. Comandos: Tech Lead - Diagnóstico; Comms - "Hold' (10-15 min - primeira atualização).
• 5. Definir as hipóteses (três no máximo), designar os proprietários, colocar os temporizadores para verificação (5-10 min).
• 6. Recolher artefatos: metricos, configs, hashs de lançamento, logs com 'trace _ id', recibos.

5) Primeira hora (modelo)

Comunicação v1 (15-20 min): fato, abrangência, sintomas, o que fazemos, a seguinte atualização. Sem especulação.
Os limites do incidente são quais as regiões/tenentes/canais/versões afetadas.
Controle de danos: caps/restrições temporais, desativação de integrações ruidosas, ativação do modo de degradação.
Forensica: congelar rotações de logs, proteger artefatos (WORM/assinaturas).
O mapa de recuperação é T + 30/T + 60 com cheques.

6) Comunicações e página de status

Intervalos internos: P1 a cada 15 minutos, P2 a 30-60 minutos.
Externo: página status/tenentes/parceiros SLA.

• «Com X: YY UTC aumento da rejeição checkout na região EU (p95> 250 ms)»
• A quem afeta: «operadoras A/B/C, £40% do tráfego»
• O que fazemos, "incluímos uma rota alternativa, trottling promo; trabalhando com o provedor PSP-1"
• Dados/deadline: «próxima atualização em 15 min»
• Compensações: «Aplicar uma nota de crédito de acordo com a SLA após o encerramento do incidente»

7) Playbooks (arbitragens para iGaming/fintech)

PriceMismatch (vitrine ≠ checkout): força deficiente do cachê, confecção 'fx _ versão/tax _ rule _ versão', congelamento de promoções dinâmicas, compensação de divergências de política.
WebhookLag (associados/afiliados): zoom de workers, aumento de batch, prioridade de retais, caixa temporário para novas subscrições.
Payments Outage/PSP-degradação: mudança para PSP de reserva, redução de temporizações de clientes, fila de clearing manual, transações «cinzentas» para quarentena.
RTP Drift: interrupção de bônus, verificação de tabelas de pagamento/versão, extensão da janela de observação, reversão do perfil RTP.
Fraud Spike: Apertar a velocidade/limites, incluir uma verificação KYC adicional, isolar os cômodos suspeitos, revidar manualmente os ganhos elevados.
Data/PII Exposure: isolação de sistemas, notificação DPO/Legal, inventário de registros afetados, notificações regulatórias de prazos.

8) Ferramentas e runas (auto-ações)

Кнопки: Pause Promo, Re-Route, Raise Limit, Rollback, Flush Cache, Disable Webhooks, Enable Safe Mode.
Guard rails: protecção contra «sedação» - reversões limitadas, revistas assinadas, cada ação ↔ IC/Scribe.
Prova: assinaturas DSSE, hashs de esmalte, cortes de logs de Merkle.

9) Conclusão do incidente

Critérios: SLO restaurado, fila reembolsada, dados/dinheiro cortado, riscos encerrados, comunicações enviadas.
Ritual de encerramento: Atualização de status final, timeline fixada, lista de influências, premissas de causa, data pós-mortem marcada.

10) Pós-mortem (sem acusações)

Prazo: P1 - em 3 dias úteis; P2 - 5 dias úteis.
Conteúdo: factos/timeline, causas primárias (5 Whys/FRAM), influência (SLO, finanças, clientes), que funcionou/não, action items (owner, prazo, efeito mensurável).
Verificação de eficiência: 30 a 60 dias depois - relento de execução e métricas (repetência, MTTR, ruído de alertas).

11) Métricas e gestão SLO incidente

MTTD/MTTA/MTTR, Mudança Failure Rate, Time to Comms v1,% permissões automáticas.
Alert Noise: proporção de sinais irrelevantes, pages per on-call shift.
Repeat Invents: proporção de repetições em 90 dias.
Post-mortem SLA: proporção de resultados/encerrados no prazo.
SLO reações: P1 - primeira comunicação ≤ 15 min; MTTR ≤ 60 min; totalidade dos artefactos = 100%.

12) Direito/complacência/privacidade

Notificações legais: prazos dos reguladores locais para fugas/incidentes.
PII-Minimização: Acesso ao primário somente através de jobs aprovados; Toquenização/camuflagem.
Armazenamento de artefatos: registros WORM, período de armazenamento jurisdicional; Controle de Acesso (RBAC/ABAC, JIT).
Contêineres: SLA contratual, processo de escalação, recibos de julgamento.

13) Organização de vigias e escalações

24 x 7 on-call: roteiros por papel (SRE, App, Data, Security, Payments).
Matriz de escalações: quem são as regiões/produtos/provedores; duplicação de contatos (bate-papo/voz/SMS).
Ensinamentos (GameDays): simulações - queda do PSP, avalanche de retais, raio de preços, comprometimento da chave, rejeição da região.

14) Incidentes de dashboard

Calor (agora): estado SLO, p95/p99, mapa de regiões/tenentes, fila de tarefas, artefatos coletados/não.
História: tendências por tipo de incidente, eficácia de runas, repetência de causas.
Controle de qualidade: timeline completa, «coverage» pós-mortem, comunicações SLA.

15) Folha de cheque de implementação

• Aprovar escala de SEV e desencadeadores SLO.
• Atribuir papéis (IC/Tech/Comms/Scribe/Sec/Legal) e rotação 24 x 7.
• Iniciar um único modelo de cartão de incidente e status-página.
• Descrever playbooks (PriceMismatch/WebhookLag/Payments/RTP/Fraud/PII).
• Implementar runas com áudio e botão vermelho.
• Incluir política forense: WORM/assinaturas/coleta de artefatos.
• Regulamento de comunicação (interior/exterior) , SLA atualizações.
• Processo pós-mortem e modelos; KPI de execução action items.
• GameDays mensalmente; uma revisão trimestral das tendências dos incidentes.
• Métricas IR em dashbord (MTTA/MTTR/Noise/Repeat/Comms SLA).

16) FAQ

Porquê o IC One?
Um único ponto de decisão remove o caos e acelera a resposta.

Quando anunciar publicamente?
Assim que houver um facto confirmado e um plano de estabilização. Avalie os prazos regulatórios.

O que é mais importante, um fix ou um relatório?
Primeiro, restabelecimento e segurança. Paralelamente, recolha de artefactos. O relatório é depois da estabilização.

Podemos automatizar tudo?
Não, mas as runas fecham passos «frequentes e simples». O resto é através de playbooks e treinos claros.

Resumo: O forte Invident Response não é apenas um canal de bate-papo e PagerDuty. É uma disciplina de papéis, rápidos primeiros 15 minutos, runas controladas, comunicações transparentes, forensura comprovável e pós-mortem obrigatório. Com este circuito, você reduz o MTTR, protege o dinheiro e os dados, e aumenta a confiança dos clientes e reguladores.