> ## Documentation Index
> Fetch the complete documentation index at: https://zeropath.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# SLAs, SLOs e SLIs
> Defina prazos de remediação por severidade, seja notificado quando issues os ultrapassarem e acompanhe a conformidade ao longo do tempo
Visão Geral
As políticas de SLA permitem que sua equipe mantenha a remediação dentro de prazos
mensuráveis. Você define por quantos dias uma issue aberta de cada severidade pode
permanecer sem resolução; o ZeroPath então observa suas issues, **notifica as pessoas
certas quando uma issue ultrapassa seu limite de idade** e acompanha o quão bem você
está cumprindo essas metas ao longo do tempo.
O recurso tem três camadas:
| Camada | Pergunta que responde | Onde você a vê |
| ------------------- | ---------------------------------------------------------------------- | ------------------------------ |
| **SLA** (política) | "Com que rapidez precisamos corrigir issues de cada severidade?" | Settings → SLA → Policies |
| **SLO** (objetivo) | "Qual % de conformidade estamos buscando, e estamos no caminho certo?" | Settings → SLA → SLO Dashboard |
| **SLI** (indicador) | "Qual é a conformidade medida e o tempo de resolução, dia a dia?" | Gráficos do SLO Dashboard |
Abra **Settings → SLA** para encontrar quatro abas: **Overview**, **Policies**, **SLO Dashboard**
e **Audit Trail**.
A avaliação de SLA é executada apenas sobre issues abertas. Issues resolvidas, arquivadas
e de repositórios efêmeros ficam fora do escopo, então fechar uma issue interrompe seu
relógio de SLA.
Criando uma política de SLA
Vá em **Settings → SLA → Policies** e escolha **New policy** (ou parta de um
**modelo** para configurações comuns).
Dê a cada severidade um prazo em dias — por exemplo, Critical = 7, High = 14,
Medium = 30. Uma issue entra em violação quando fica aberta por mais tempo que o
limite da sua severidade. (As severidades derivam da pontuação/confiança de cada
issue; INFO não é elegível para limites de SLA.)
Aplique a política a **todos os repositórios** ou restrinja-a a **repositórios**
e/ou **tags** específicos.
Selecione canais do **Slack** e/ou **webhooks** para receber as notificações de
violação.
Adicione etapas de escalonamento que envolvem canais adicionais em offsets de dias
posteriores e defina uma meta de conformidade de SLO para acompanhar no dashboard.
Limites por severidade
Um limite é o número máximo de dias (1–365) que uma issue aberta daquela severidade pode
permanecer sem resolução antes de ser considerada em violação. O relógio de violação
começa no início do ciclo de vida da issue — o momento em que ela entrou (ou reentrou)
em um estado aberto — então uma issue fechada que é reaberta depois inicia um relógio
novo.
Uma política se aplica a toda a organização por padrão, ou a um conjunto escolhido de
repositórios e tags. O escopo por tag acompanha os repositórios atualmente em cada tag,
então adicionar um repositório a uma tag o coloca automaticamente sob qualquer política
com escopo naquela tag.
Hierarquia de políticas
As políticas podem ser organizadas em uma hierarquia pai/filho (com até cinco níveis de
profundidade). Uma política filha só pode **apertar** os limites da política pai — nunca
afrouxá-los — de modo que uma linha de base da organização pode ser tornada mais rígida
para uma equipe crítica sem permitir que nenhuma equipe fique abaixo da linha de base.
Quando os limites de uma política pai mudam, as políticas filhas são recalculadas
automaticamente e quaisquer severidades recém-apertadas são preenchidas retroativamente,
mantendo a hierarquia consistente.
Modelos
Os modelos preenchem previamente uma política com limites e canais sensatos para
necessidades comuns, para que você possa criar uma política em uma única etapa e ajustar
a partir dela.
Notificações
Uma vez que uma política existe, o ZeroPath varre suas issues abertas **a cada hora** e
envia um **resumo agrupado** por `(policy, severity, threshold)` para os canais da
política — assim, um lote de issues Critical recém-violadas produz uma única mensagem
"N issues breached", em vez de uma mensagem por issue.
* **Slack** — publica um resumo em Block Kit em cada canal configurado.
* **Webhooks** — entrega um evento `ISSUE_AGED_PAST_THRESHOLD` (consulte [Webhooks](/pt/webhook/introduction)).
A entrega é idempotente e deduplicada entre deploys, e canais com falha são tentados
novamente em varreduras posteriores, de modo que uma indisponibilidade atrasa uma
notificação em vez de descartá-la.
Etapas de escalonamento
Cada política pode definir etapas de escalonamento, cada uma com um **offset em dias** e
seu próprio conjunto de canais do Slack e webhooks. Quando uma issue atinge a idade do
offset de uma etapa, os canais daquela etapa são adicionados à notificação — permitindo
ampliar o público (por exemplo, envolvendo um gerente no dia 14) quanto mais tempo uma
issue permanece aberta.
As etapas de escalonamento entregam para seus próprios canais independentemente da
seleção de canais base da política, então uma etapa pode introduzir um canal que a
política base não usava.
Datas de vencimento em tickets exportados
Quando um achado é exportado para o Jira ou o Linear, o ZeroPath pode marcar o ticket com
o prazo de SLA do achado como sua **data de vencimento**, para que os engenheiros vejam o
prazo de remediação diretamente no rastreador.
Ative **Set due date from SLA** nas configurações de auto-ticketing do Jira ou do Linear
(**Settings → Integrations → Jira/Linear → Auto-Ticketing**). Quando habilitado, todo ticket
criado por essa integração — automaticamente na conclusão do scan, ou manualmente a partir de
um achado — recebe uma data de vencimento igual ao **prazo de SLA mais apertado em escopo**
da issue: a data de violação mais próxima entre todas as políticas que cobrem a issue,
usando a mesma definição de violação da varredura e do SLO Dashboard.
* Se nenhuma política de SLA cobre o achado, nenhuma data de vencimento é definida.
* A data de vencimento é marcada uma única vez, quando o ticket é criado; edições
posteriores na política não movem a data de vencimento de um ticket existente.
* Um achado que já passou do prazo no momento da exportação recebe uma data de vencimento
no passado (exibida como atrasada), porque o relógio de SLA começa quando a issue foi aberta.
Para o Jira, a data de vencimento só é aplicada quando o tipo de issue selecionado expõe um
campo **Due date** em sua tela de criação. Se não expuser, o ZeroPath avisa você ao salvar a
configuração e cria os tickets sem data de vencimento, em vez de falhar a exportação.
Dashboard de SLO
O **SLO Dashboard** transforma a atividade de SLA em uma tendência. Defina um SLO em uma
política atribuindo a ela uma **porcentagem-alvo de conformidade** (50–100%) e uma
**janela de avaliação** (1–730 dias); o dashboard então mostra, por política:
| Métrica | Significado |
| ----------------------------- | ---------------------------------------------------------------------------------------------- |
| **Compliance %** | Parcela das issues em escopo atualmente dentro do seu SLA |
| **Breach count** | Número de issues em escopo atualmente em violação |
| **P50 / P95 time-to-resolve** | Dias para resolver, na mediana e no percentil 95 |
| **Burn rate** | Velocidade com que o orçamento de erro (a parcela permitida de violações) está sendo consumido |
Esses valores vêm de **snapshots de SLI** — uma medição pontual que o ZeroPath registra
uma vez por dia por política (e por tag), de modo que os gráficos constroem um histórico
diário de conformidade, contagens de violação e latência de resolução.
Burn rate
O burn rate expressa a rapidez com que você está consumindo seu orçamento de erro — a
folga entre 100% e a sua meta. Um burn rate acima de **1×** significa que você está
violando mais rápido do que a meta permite. O ZeroPath sinaliza dois níveis e, quando
configurado, envia uma notificação `SLA_BURN_RATE_HIGH`:
| Nível | Significado |
| -------- | ------------------------------------------------------------------------------- |
| **WARN** | A janela de 7 dias está consumindo o orçamento mais rápido do que o sustentável |
| **HIGH** | A janela de 14 dias está bem acima do orçamento — a meta está em sério risco |
O burn rate é suprimido para políticas de volume muito baixo, em que uma única violação
faria a porcentagem oscilar e produziria alertas ruidosos.
Relatórios de conformidade
A partir de uma política, você pode gerar um **relatório de conformidade de SLA** (PDF,
CSV ou JSON) para uma auditoria ou revisão com stakeholders. O relatório usa a **mesma
definição de violação** da varredura ao vivo e do dashboard, então os números sempre
coincidem. Consulte [Relatórios](/pt/platform/reports) para a geração e a exportação de
relatórios.
Trilha de Auditoria
A aba **Audit Trail** registra cada execução da varredura horária e as tentativas
individuais de despacho que ela fez — qual canal, o resultado e qualquer erro — para que
você possa confirmar que uma notificação foi enviada e diagnosticar um problema de
entrega.
Disparando automações a partir de eventos de SLA
Eventos de SLA podem disparar automações de agentes de IA. Configure um gatilho de evento
de agente para o evento `ISSUE_AGED_PAST_THRESHOLD` ou `SLA_BURN_RATE_HIGH` para, por
exemplo, abrir automaticamente uma tarefa de remediação ou publicar um plano priorizado
quando um grupo de violações disparar. Gatilhos com escopo em repositórios ou tags
específicos correspondem quando qualquer repositório de um grupo de violações está no
escopo.
Como funciona a execução
A avaliação de SLA é totalmente automatizada por jobs em segundo plano — não há nada que
você precise executar:
| Job | Agendamento |
| -------------------------------------------------------------- | ----------- |
| Varredura de issues envelhecidas + notificações | A cada hora |
| Snapshot de SLI + avaliação de burn rate | Diário |
| Limpeza de retenção de registros antigos de varredura/despacho | Diário |
Como os limites são medidos em dias inteiros, uma mudança de política entra em vigor na
próxima varredura horária, e novos pontos de conformidade de SLO aparecem após o próximo
snapshot diário de SLI.