Triagem de Severidade de Incidente

Passo 1 — Aplicar a matriz de severidade Gzero

A severidade é determinada pelo critério mais severo entre todas as dimensões. Se qualquer eixo bater P1, é P1.

| Severidade | Usuários afetados | Receita / hora | Dados | SLA | Regulatório |

|---|---|---|---|---|---| | P0 — Crítico | > 50% ou todos enterprise | > R$ 100k | Vazamento confirmado de PII | Múltiplos SLAs violados | Notificação regulatória obrigatória | | P1 — Alto | 10-50% ou enterprise único crítico | R$ 20-100k | Exposição interna sensível | SLA violado / em risco iminente | Risco regulatório | | P2 — Médio | 1-10% ou degradação geral | R$ 5-20k | Dado interno não-sensível | SLA degradado mas não violado | Sem exposição | | P3 — Baixo | < 1% ou caso isolado | < R$ 5k | Nenhum | Sem impacto SLA | Sem exposição |

Adapte os números absolutos ao porte da empresa. Para uma startup early-stage, R$ 5k/hora pode ser P1; para enterprise, P3. O importante é que sejam thresholds escritos, não inventados na hora.

Passo 2 — Calcular o impacto em usuários

Distinguir:

- Usuários afetados: quem está experimentando o sintoma.

- Usuários expostos: quem poderia ser afetado pela mesma causa em janela próxima. - Usuários enterprise vs. self-service: um cliente enterprise único pode justificar P1 mesmo sem volume.

Fontes: - Métrica em tempo real (Datadog, NewRelic). - Suporte (volume de tickets nas últimas 30 min). - Status page interna. - Distribuição geográfica (se incidente é regional vs global).

Output: número absoluto + percentual da base ativa.

Passo 3 — Quantificar impacto em receita

Não é necessária precisão, mas ordem de grandeza:

- Cobrança parada: receita média horária × tempo de queda.

- Funil quebrado (checkout, signup): taxa de conversão histórica × tráfego no intervalo. - Cliente enterprise específico afetado: valor mensal do contrato proporcional. - Multas contratuais por SLA violado: valor da cláusula.

Para times sem visibilidade financeira em tempo real, usar último dado disponível. "Não sei" não é resposta válida nesta dimensão.

Passo 4 — Avaliar exposição de dados

Critério crítico, frequentemente sub-avaliado:

- Vazamento confirmado: dado saiu para fora do controle da empresa. P0 quase sempre.

- Exposição interna: dado acessível por quem não deveria ter acesso (ex: vazamento entre tenants). Geralmente P1. - Acesso indevido sem extração confirmada: P1, escalando para P0 se cobrir PII. - Sem exposição: P2/P3 conforme outros eixos.

Para qualquer suspeita de vazamento de PII, acionar imediatamente o protocolo de breach notification do gdpr-data-handling-checklist.

Passo 5 — Avaliar SLA contratual em risco

Para cada cliente / contrato com SLA:

- Qual é o SLA contratual (uptime, latência, tempo de resposta)?

- O incidente atual já violou o SLA? - Em quanto tempo vai violar se não resolvido? - Há cláusula de service credit acionada?

Cliente enterprise único com SLA contratual pode justificar P1 mesmo se o volume geral é P2.

Passo 6 — Avaliar exposição regulatória

Mapear se o incidente tem componente regulatório:

- LGPD/GDPR: vazamento de dado pessoal aciona breach notification em 72h (ver gdpr-data-handling-checklist).

- PCI-DSS: exposição de dado de cartão tem regras específicas. - HIPAA: dados de saúde com proteção rigorosa. - Reguladores setoriais: financeiro (Bacen), telecom (Anatel), etc.

Se há exposição regulatória, a severidade é no mínimo P1, independente de outros eixos. P0 se há prazo regulatório < 24h.

Passo 7 — Aplicar a resposta proporcional à severidade

Cada severidade tem ações obrigatórias:

P0 — Crítico:

- Acordar imediatamente: primary on-call, manager on-call, líder técnico de domínio, COO/CTO. - Sala de guerra (war room) ativa em ≤ 15 min. - Status page externa atualizada em ≤ 15 min. - Comunicação a clientes enterprise em ≤ 30 min. - Comunicado executivo aos C-levels em ≤ 30 min. - IC (Incident Commander) nomeado explicitamente. - Comm Lead nomeado explicitamente. - Logs e timeline registrados em tempo real. - Atualização externa a cada 30 min.

P1 — Alto: - Acordar primary on-call (sempre) e secondary (se estado complexo). - Sala de guerra em ≤ 30 min. - Status page atualizada em ≤ 30 min se cliente vê impacto. - Manager on-call informado em ≤ 30 min. - IC nomeado. - Update interno a cada 60 min.

P2 — Médio: - On-call atua dentro do horário comercial; à noite, só se piorar. - Sem war room, mas thread dedicada em Slack. - Status page atualizada se cliente vê impacto. - Manager informado por canal assíncrono. - Update a cada 4h.

P3 — Baixo: - Tratado como ticket normal pelo time responsável. - Sem paging fora do horário. - Sem update de status externa.

Passo 8 — Definir SLA de resposta e resolução por severidade

Tabela explícita (adaptar ao contexto):

| Severidade | Tempo de ack | Tempo de mitigação | Tempo de resolução total |

|---|---|---|---| | P0 | 5 min | 30 min | 4h | | P1 | 5 min | 1h | 8h | | P2 | 15 min (horário comercial) | 4h | 24h | | P3 | 4h (horário comercial) | 24h | 1 semana |

Mitigação = restaurar serviço a estado aceitável (mesmo que não-resolvido). Resolução = root cause endereçado.

Passo 9 — Reclassificar conforme evolução

Severidade não é estática. Atualizar quando:

- Sobe (de P1 para P0): impacto cresce, dado é confirmado vazado, mais clientes afetados.

- Desce (de P0 para P1): mitigação parcial reduziu impacto; resolução ainda pendente. - Encerra: root cause resolvido, sistema estável, monitorando por 30-60 min antes de declarar resolvido.

A reclassificação é decisão do IC, registrada com timestamp e justificativa.

Passo 10 — Documentar a triagem

Para qualquer P0/P1, registrar a triagem no ticket de incident:

- Severidade inicial atribuída.

- Critério decisivo (qual eixo bateu). - Quem fez a triagem. - Timestamp da decisão. - Reclassificações posteriores (se houve).

Isso alimenta o postmortem (incident-postmortem) e a calibração da política ao longo do tempo.