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:
Abra Settings → Service levels para encontrar quatro seções: Overview, Policies, Audit trail e SLO / SLI.
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
1
Abra o assistente de políticas
Vá em Settings → Service levels → Policies e escolha New policy (ou parta de um
modelo para configurações comuns).
2
Defina os limites por severidade
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.)
3
Escolha o escopo
Aplique a política a todos os repositórios ou restrinja-a a repositórios
e/ou tags específicos.
4
Escolha os canais de notificação
Selecione canais do Slack e/ou webhooks para receber as notificações de
violação.
5
(Opcional) Adicione etapas de escalonamento e uma meta de SLO
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.Escopo: repositórios e tags
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
O ZeroPath avalia as issues abertas a cada hora. Cada política controla quando seus resumos do Slack são enviados, independentemente dos prazos de remediação e da medição de SLO.Frequência e conteúdo no Slack
Edite Slack notifications na política e escolha:
Políticas existentes com Slack mantêm a entrega horária até serem alteradas. Use um
fuso IANA explícito, como
America/Sao_Paulo. Em mudanças de horário de verão, horários
inexistentes avançam e horários repetidos geram uma única entrega. A verificação de
entrega ocorre a cada cinco minutos. Salvar nunca envia uma mensagem imediatamente.
Políticas filhas mantêm suas próprias preferências.
Escolha incluir novos achados elegíveis, lembretes de achados ainda atrasados,
escalonamentos para os destinos de cada etapa e mudanças no risco de conformidade.
Desative os lembretes para não repetir o mesmo conjunto de achados. Um estado HIGH
inalterado não gera novos avisos de risco; dados ausentes ou insuficientes não indicam
recuperação.
Escolha apenas o resumo ou detalhes dos cinco principais achados, com repositório,
severidade, prazo, tempo de atraso e link direto. View overdue issues abre a lista
paginada da política, mesmo sem uma meta de SLO. Um achado que atinge tanto um limite
quanto um escalonamento é contado uma vez.
Preview message não envia mensagens. Para políticas salvas, mostra o escopo e os
limites salvos com o conjunto atual de achados; para novas políticas, mostra exemplos
identificados como fictícios. Gere uma nova prévia após alterar as opções.
Resumos vazios são ignorados. Após uma indisponibilidade, a atividade pendente é
consolidada em um resumo atual, sem reproduzir cada horário perdido. Cada canal tem
até cinco tentativas independentes; falhas não reenviam mensagens aos canais que já
receberam. Uma interrupção entre a aceitação pelo Slack e o registro da entrega ainda
pode causar uma duplicata.
Essas preferências não pausam webhooks
ISSUE_AGED_PAST_THRESHOLD ou
SLA_BURN_RATE_HIGH, nem automações do Assistant. Desative a política somente quando
também quiser parar a aplicação e a medição do SLA. Consulte
Webhooks.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. No Slack, as etapas respeitam o horário e as opções de
conteúdo da política, inclusive Off; não enviam mensagens imediatamente.
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
A seção SLO / SLI transforma a atividade de SLA em uma tendência. O botão Export report neste dashboard é exibido apenas para usuários que possuem a permissão de geração de relatórios; usuários sem ela ainda podem visualizar as métricas do dashboard, mas não podem gerar exportações de conformidade. 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:
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 compara a proporção medida de violações com a proporção permitida (100% − meta de conformidade). Acima de 1×, o nível medido excede o permitido;
não é uma contagem de novas issues nem uma frequência de entrega. O ZeroPath sinaliza
dois níveis e, quando configurado, emite SLA_BURN_RATE_HIGH:
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 para a geração e a exportação de relatórios.Trilha de Auditoria
A aba Audit trail registra varreduras horárias e tentativas de entrega de eventos. Na página View overdue issues da política, expanda Slack delivery history para ver as últimas 25 entregas do Slack: pendentes, entregues, tentadas novamente, com falha, silenciadas ou substituídas. Os registros são mantidos por 90 dias.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 eventoISSUE_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.