Gerenciamento de incidentes

(Secção Tecnologia e Infraestrutura)

Resumo curto

Gerenciamento de incidentes é um processo repetitivo para restaurar rapidamente o valor do usuário e minimizar os danos ao negócio. Suporte - Papéis claros (Inident Gestor, Tech Lead, Comms), gates SLO, escalações, processos ChatOps, runabooks preparados e análises pós-incidentes «sem fio» com atribulações mensuráveis de items.

1) Objetivos e princípios

Velocidade e segurança: diagnóstico rápido → estabilização segura → recuperação sustentável.
Único proprietário: O Inident Gerente (IM) designado toma decisões de processo.
Comunicações como produto: updates previsíveis para steakhalders e usuários.
Dados> opiniões: SLO/métricas/trailers/logs - a origem da verdade.
Blameless: Analisar razões sem acusações pessoais; foco em melhorias de sistema.

2) Classificação de incidentes (Severity/Impact/Urgency)

• SEV1 (crítico): danos graves às receitas/TTW/pagamentos,> 20% dos usuários ou regiões inteiras; SLA violado/ameaça PII.
• SEV2 (alta): degradação parcial dos fluxos-chave (depósito/taxa/lançamento de jogos), impacto de 5 a 20%.
• SEV3 (média): degradação notável dos serviços secundários, contornação.
• SEV4 (baixo): menor, efeito limitado, sem efeito sobre o SLO/SLA.

Impacto: quem é afetado (toda/região/tenante/canal). Urgency: taxa de degradação (fast-burn/slow-burn sobre o orçamento de erros).

3) Ciclo de vida incidente

1. Detect é um sinal de alertas/SLO/sintéticos/reportes.
2. Acknowledge - on-call confirma a recepção, atribui IM.
3. Triage - Avaliação do SEC/Impact, coleta de hipóteses, abertura do War-Room.
4. Mitigate - Estabilização (reversão/alteração de rota/fichiflags/zoom).
5. Comunicate - status-update regular (dentro/fora).
6. Recover - recuperação completa de SLO/métricas de negócios.
7. Close - fixação de cronologia, coleta de artefatos, PIR (RCA + action items).

4) Papéis e responsabilidades (esquema RACI)

O Investent Gerente (IM) é o proprietário do processo, atribui papéis, monitora o tempo e toma decisões de processo (R).
Tecnical Lead (TL) - Faz diagnósticos/hipóteses/registos, coordena engenheiros (A/R).
Comunicações (Comms) - status-update, vínculo com suporte/negócio/PR, página-status (R).
Scribe - protocolo (timeline, decisões, links, artefatos) (R).
Stakeholders - produtos/pagamentos/provedores de jogos/segurança (C/I).

Mínimo em SEV1: IM + TL + Comms + Scribe. O SEV2 permite a combinação de papéis.

5) War-Room и ChatOps

Os canais individuais são '# invident-warroom- <id>', '# invident-status' (somente updates).
Comandos de modelo: '/invent start ', '/status update', '/call <owner> ', '/rollback', '/freeze ', '/scale + N'.
Bot puxa o contexto: lançamentos recentes, dashboards, alertas associadas, trace excempars, esquemas de dependências.
Regras de comunicação: breve, segundo os factos, um porta-voz (TL), IM moderniza.

6) Desencadeadores e gates

SLO-gates: fast/slow burn, queda na conversão de pagamentos, TTW p95> liminares, p99 API ↑, filas de pagamento «em chamas».
Desempenho automático: stop canary, rollback, ativação do modo degrade (limitação de funções), inclusão de sintéticos de alta frequência.
Freeze: todos os lançamentos/migrações para estabilização e PIR.

7) Cenários típicos (pattern runabook)

A) Pagamentos: aumento de temporizações/recusos em PSP

1. Stop promote e congelamento de lançamentos do circuito de pagamento.
2. Mudar a rota PSP para a rota de reserva, elevar o tempo/retrai de política.
3. Verificação de transações incompletas, repetição de chaves idumpotentes.
4. Comunicações Comms safort: A reserva funciona? ETA.

B) API p99↑ e 5xx após o lançamento

1. Retrocesso (blue-green/canary → stable).
2. Verificar o hit em dinheiro, a profundidade das filas, os pontos quentes do banco de dados/provedores de jogos.
3. Escala temporária, limitação de fits pesados através da função flags.

C) Provedor de jogos não disponível

1. Mudar o tráfego para os estúdios/jogos disponíveis, mostrar o banner de status.
2. Activar verificações sintéticas a cada 30-60s.
3. Concordar compensações/bônus (política) - colocar no PIR.

D) Fuga/suspeita de PII

1. Isolamento do componente, recapeamento de chaves/tokens, coleta de logs (WORM).
2. Negociação da Comunicação Legal/Regulação.
3. Ações pós-incidentes, segredo, rotação, disfarce, acessibilidade.

8) Comunicações (interna/externa)

Frequência de update: SEV1 a cada 15-30 min, SEV2 a 30-60 min.

• «Depósitos PSP-X, aumento de tempo».
• Quem foi afetado por «TR/BR, £18% dos usuários de fluxo».
• Quando começou, «12:07 EET, SEV1».
• O que fazemos é «Mudar a rota para PSP-Y, incluir retais/limitar a taxa».
• O próximo update é «daqui a 20 minutos».
• Contato: «IM @ duty-im, TL @ oncall-pay.»

Status público (página/rede social) - reduzido, sem PII ou detalhes extras, com ETA e referência a atualizações futuras.

9) Coleta de artefatos e auditoria

Timeline de eventos (precisão de minutos), versões de serviços, bandeiras de fich, alterações de configs.
Imagens de dashboards, trechos (trace _ id), logs «antes/durante/depois».
Referências a tíquetes, PR, lançamentos, runabooks.
Relatório de comunicação (quando/quem/quê).
Tudo está no cartão do incidente.

10) Encerramento e PIR (Post-Invent Review)

• Resumo: O que aconteceu, escala, duração, SEC.
• Influência: usuários/regiões, SLO/SLA, fina. efeito.
• Timeline, detalhe, minutos.
• Root Causa: técnica + organizacional (porque não foi concebido antes).
• Detections & Defenses: O que ajudou/desiludiu (alertas, sintéticos, fichiflags).
• Action Items: tarefas específicas, proprietários, prazos (e como verificar o efeito).
• Lessons Learned: O que mudamos no processo/arquitetura/observabilidade.

Regras: Sem acusações, o máximo de factos, o follow-up obrigatório dentro de 2-4 semanas de verificação de itens cumpridos.

11) Métricas de confiabilidade de processo

MTTD (Mean Time To Detect) - Tempo médio de detecção.
MTTA (… Acknowledge) - antes da confirmação on-call.
MTTR (… Restore) - antes da recuperação do SLO.
Mudança Failure Rate -% dos lançamentos que resultaram em incidentes.
Invident Rate por SEC, distribuído por domínios (Payments/Games/Infra).
Alert Quality: proporção de ruídos/falsos, tempo anterior à ação pós-alert.
Comm-SLA: Cumprimento da periodicidade de status-update.

12) Integração com SLO e lançamentos

Gates em CD: promoção canarinho apenas com proxy SLO verde (availability, p95, 1962, TTW).
Procedimentos Freeze: para fast-burn/SEV1 - parar lançamentos até PIR.
Anotações automáticas em gráficos: lançamentos/bandeiras/migração são visíveis em dashboards.

13) Regulação e complacência

PII: camuflagem/pseudonimização em logs/trens, armazenamento de auditoria WORM, controle de acesso.
Regionalidade: não levar dados do usuário para fora das jurisdições permitidas.
Relatórios: e-mails formalizados/notificações aos reguladores - modelos e processo de escalação.

14) Treinamento e preparação (Game-Day)

Exercícios trimestrais: «queda PSP», «provedor de jogos não disponível», «p99», «fuga de chave».
Times em MTTA/MTTR, retro de exercício.
Atualizar roteiros e contatos, verificar comandos ChatOps.

15) Folha de cheque pronta (antes do incidente)

1. As regras SEC e a matriz de escalações estão alinhadas.
2. Rotações on-call designadas, IM/TL/Comms/Scribe.
3. Runabucky em cenários-chave (pagamentos, jogos, BD, cachês, filas).
4. Mapa SLO e burn-rate alerts, página status.
5. ChatOps-bot: comandos, controle automático, modelos de status.
6. Modelos PIR e cartões de incidente.
7. Game-day regular e revisões de contatos/permissões.
8. Política freeze e botão vermelho (rollback/kill-switch).

16) Antipattern

Não há um único IM, «multidão lidera» → caos e atrasos.
Falta de gates SLO → detecção tardia, alertas ruidosas.
O lançamento durante o incidente sem freeze → falhas em cascata.
Logs e trailers não são suficientes, não há artefatos → PIR fraco.
Cultura acusatória → erros ocultos, medo de escalada.
Comunicações de inspiração → perda de confiança do negócio/usuário.

17) Modelos (copie em seu wiki)

A) Cartão de incidente (YAML)

yaml id: INC-2025-11-005 title: PSP-X timeouts in TR/BR sev: SEV1 start_at: 2025-11-05T12:07:00+02:00 status: active impact: "Deposits via PSP-X failing for ~18% users (TR, BR)"
im: "@oncall-im"
tl: "@oncall-pay"
comms: "@oncall-comms"
scribe: "@oncall-scribe"
mitigations:
- "Reroute to PSP-Y"
- "Enable retries and raise timeouts"
next_update_in: "20m"
links:
grafana: "<dashboard-url>"
traces: "<tempo-link>"
logs: "<loki-query>"
runbook: "payments/psp_timeout"

B) Status-update (interno)

[12:25] SEV1 PSP-X timeouts — TR/BR
Impact: ~18% deposits affected. SLO fast-burn active.
Mitigation: Rerouting to PSP-Y; retries enabled; release freeze.
ETA next update: 12:45 EET
IM: @oncall-im      TL: @oncall-pay

C) PIR (chapéu)

Summary, Impact, Timeline, Root Cause (tech+org),
Detections/Defenses, Action Items (owner+due), Lessons Learned.

Resumo

Um forte gerenciamento de incidentes é uma estrutura + disciplina: papéis pré-definidos, gates SLO, runabooks trabalhados, comunicações transparentes e PIR «sem vida». Esse caminho reduz o MTTA/MTTR, reduz o custo de interrupção, fortalece a confiança dos usuários e permite o lançamento mais ousado - mas seguro.