Incidentes
Um incidente é qualquer evento não planejado que afete materialmente a disponibilidade, a confiabilidade, a latência, a correção ou a postura de segurança dos serviços da EvoMap.
Ciclo de vida
| Fase | O que significa |
|---|---|
| Investigando | A equipe está confirmando o impacto, o alcance e a causa provável. |
| Identificado | O componente ou a dependência afetada é conhecida. |
| Mitigando | Uma correção, reversão, mudança de tráfego ou alternativa está sendo aplicada. |
| Monitorando | O serviço parece recuperado e a equipe está observando se há regressão. |
| Resolvido | O incidente foi encerrado e não causa mais impacto ao cliente. |
| Post-mortem | Um resumo de acompanhamento ou uma análise mais profunda está sendo preparada ou publicada. |
Níveis de severidade
| Severidade | Impacto no cliente | Exemplos |
|---|---|---|
| P0 | Indisponibilidade ampla em produção ou risco à segurança dos dados. | Troca de token OAuth indisponível para todos os clientes; a API pública devolve 5xx de forma sustentada. |
| P1 | Degradação importante de um caminho crítico. | Entregas de webhook atrasadas em muitos aplicativos; fila de revisão de aplicativos bloqueada. |
| P2 | Impacto limitado ou existe uma alternativa confiável. | Uma família de endpoints está lenta; o histórico de status está desatualizado enquanto a API ao vivo funciona. |
| P3 | Defeito menor, problema de documentação ou caso de suporte isolado. | Link incorreto na documentação; entrada pouco clara no registro de alterações. |
Registros públicos de incidentes
Um registro público de incidente deve incluir:
- Os serviços afetados e os sintomas visíveis ao cliente.
- O horário da primeira detecção e o horário de resolução.
- Uma linha do tempo das atualizações.
- A mitigação ou a alternativa, se houver.
- O resumo final da resolução.
- Um link para o post-mortem quando uma análise mais profunda se justificar.
Registros de incidentes não devem incluir dados pessoais de clientes, secrets, tickets privados, logs internos ou payloads de requisição sem ocultação.
Manutenção programada
A manutenção programada deve listar:
- O horário planejado de início e fim com fuso horário.
- Os serviços que podem ser afetados.
- Se chamadas de API, fluxos OAuth, entrega de webhooks ou revisão de aplicativos podem ser interrompidos.
- A ação esperada do cliente, se houver.
As atualizações de manutenção devem ser publicadas antes da janela, quando a janela começa e quando ela é concluída.
Como os tickets de suporte se relacionam com os incidentes
Tickets de suporte são conversas privadas sobre um desenvolvedor, uma organização, um cliente OAuth, uma entrega de webhook ou um caso de faturamento específico. Incidentes são registros operacionais públicos quando o impacto é amplo o suficiente para ser comunicado na página de status.
Um ticket pode ser vinculado a um incidente quando reporta o mesmo problema subjacente da plataforma. O ticket permanece privado; o registro do incidente permanece público e com dados ocultados.
Relatar um suspeito de incidente
Antes de abrir um ticket:
- Verifique
/status. - Verifique o Registro de alterações para ver uma mudança recente de API ou de comportamento.
- Abra um ticket de suporte ou envie e-mail para
[email protected]com marcas de tempo, IDs de requisição, endpoints afetados e os códigos de erro observados.