Exemplos resolvidos para IncidentRelay v2.3.1, verificado em . Os nomes, identificadores e horários abaixo são ilustrativos; valide-os em uma implantação de teste antes de usar credenciais de produção.
Exemplo de negócios · Configuração · Exemplo prático · Verificações de aceitação · Limites e modos de falha
Exemplo de negócio: clientes de SaaS trabalham em fusos horários diferentes
Cenário ilustrativo, não um estudo de caso de cliente. As métricas abaixo são sugestões para o seu piloto, não economias medidas ou uma afirmação de que o RI inclui todos os painéis de relatórios.
Situação e risco. Uma equipe de SaaS B2B atende clientes na Europa e na América do Norte. A tarde de trabalho de um cliente se sobrepõe à noite de outro engenheiro, e o atendente habitual está de férias. Sem um cronograma acordado, a equipe depende de quem perceber primeiro o chat. O risco é uma interrupção sem dono e interrupções repetidas para funcionários fora de serviço.
Fluxo de trabalho com RI. Combine a cobertura com pessoal e represente-a com uma rotação básica e uma camada de dias úteis. Registre substituições de feriados como substituições e configure um destino de escalonamento de backup separado. Verifique transferências e lacunas futuras. Para uma implementação de faturação planeada, utilize uma janela de manutenção com âmbito de serviço enquanto os serviços não relacionados continuam a notificar.
Benefício operacional a ser validado. Torne a responsabilidade de suporte e engenharia previsível, incluindo licenças e transferências. O trabalho planejado não deve exigir o silenciamento de todo o fluxo de alertas da empresa.
O que medir. Revise os minutos descobertos em um período futuro definido, como os próximos 14 dias, transferências manuais de última hora e reconhecimentos dentro da meta de resposta da equipe. Compare as notificações noturnas por engenheiro com a programação real da equipe; um calendário equilibrado por si só não mostra a carga de trabalho.
Limite. Uma agenda preenchida não cria funcionários extras nem prova que alguém pode responder. O IR não garante um tempo de resposta contratual nem calcula a disponibilidade do cliente a partir de ACK s. Mantenha as decisões de pessoal, o monitoramento do SLO e a comunicação com o cliente no processo operacional mais amplo.
Cubra a noite antes de otimizar a jornada de trabalho
Suponha que uma equipe SRE possua confiabilidade de faturamento durante um turno de trabalho e um turno noturno. Em uma rotação, crie uma camada base com prioridade 10 e cobertura irrestrita 24/7. Adicione uma camada com prioridade 20, restrita a segunda a sexta, das 9h às 18h em Europe/Berlin. Use membros ativos reais e verifique o calendário gerado.
A camada ativa de maior prioridade fornece o destinatário; uma substituição tem precedência sobre as camadas. Estes não são dois respondedores simultâneos. Configure um destino de escalonamento ou rotação separado para cobertura de backup. Se nenhuma camada estiver ativa e nenhuma substituição for aplicada, não há destinatário. Consulte regras de rotação e camada.
Pausar notificações de cobrança durante uma implantação planejada
Crie uma janela com escopo de serviço por meio da interface ou envie essa configuração para POST /api/maintenance-windows usando uma sessão de gerenciamento autenticada API com permissão para modificar o escopo. Um token de rota de entrada não é uma credencial de gerenciamento. Substitua 42 pelo seu ID de serviço de cobrança real e escolha uma janela de teste futura.
{
"name": "Billing deploy",
"behavior": "suppress_notifications",
"timezone": "Europe/Berlin",
"starts_at": "2026-10-20T10:00:00",
"ends_at": "2026-10-20T11:00:00",
"enabled": true,
"scopes": [
{
"scope_type": "service",
"service_id": 42
}
]
}Esses carimbos de data e hora são horários no fuso horário selecionado, não valores UTC com um Z omitido. Durante esta janela, os alertas de cobrança recebidos permanecem visíveis, mas as notificações, os lembretes e o escalonamento são pausados. Outros serviços não devem permanecer afetados. Este comportamento não é suppress_incident, que impede novos AlertGroups, ou pause_escalation_only, que mantém as notificações ativadas.
Teste os limites, não apenas no meio de um turno
- Inspecione a tarefa um pouco antes e depois das 09h00 e das 18h00, durante um fim de semana e uma transição para o horário de verão. Adicione uma substituição temporária, confirme se ela venceu e remova-a.
- Abra a verificação completa de Saúde de plantão. Revise sua janela futura verificada, lacunas, membros inativos e métodos de entrega utilizáveis. Um resumo verde não é prova de cobertura para sempre ou de entrega por telefone.
- Envie eventos de teste de faturamento e serviços não relacionados durante a manutenção. Confirme se o faturamento está visível, mas silencioso, e se o serviço não relacionado ainda notifica. Para incluir alertas já não resolvidos, habilite explicitamente a opção de aplicar a janela aos alertas existentes; está desativado por padrão.
- Deixe o faturamento disparando quando a janela terminar. Com a reativação ativada, verifique a retomada normal da notificação sem repetir todos os lembretes perdidos. Confirme se o respondente real o recebeu e pode reconhecê-lo.
Um serviço silencioso não é um serviço recuperado
A manutenção não repara o serviço, não retira mensagens entregues nem implica resolução. A reativação no final está habilitada por padrão; desativá-lo mantém o efeito de manutenção após o término da janela. Janelas sobrepostas podem manter um alerta silencioso até que o último efeito ativo ou retido aplicável seja liberado. Revise esses controles no guia de manutenção.
Mantenha os cálculos de SLO e a detecção de taxa de gravação em sua pilha de monitoramento. O IR roteia e coordena os sinais resultantes. Um AlertGroup possui reconhecimento técnico, resolução, notificações e escalonamento; um incidente é um fluxo de trabalho operacional separado. Vincular vários AlertGroups a um Incidente não mescla seus históricos técnicos. Na v2.3.1, os respondentes e as partes interessadas ainda pertencem aos AlertGroups. Teste ambos os ciclos de vida em vez de tratar uma alteração de status de Incidente como um AlertGroup ACK.