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: checkout falha após o fechamento do escritório
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 loja on-line tem quatro engenheiros. Às 22h40, seu monitoramento detecta solicitações de pagamento com falha enquanto os clientes ainda estão finalizando a compra. Uma mensagem no chat geral não informa ao suporte quem está lidando com o problema. Compras inacabadas e uma fila de suporte crescente são o risco do negócio; o alerta em si é apenas o sinal.
Fluxo de trabalho com IR. Envie o alerta de faturamento ao atendente principal atual. Se ninguém confirmar, a política passa para o backup nomeado. O engenheiro designado reconhece o grupo e investiga; o suporte pode usar o processo de incidente acordado para encontrar o proprietário e obter uma atualização. Teste esta cadeia com o par de falha e recuperação abaixo.
Benefício operacional a ser validado. Substitua a pesquisa manual por um engenheiro disponível por uma cadeia de propriedade predefinida. Mantenha a responsabilidade visível durante a transferência, em vez de presumir que uma mensagem de bate-papo entregue significa que alguém está trabalhando nela.
O que medir. Registre o tempo desde o primeiro alerta acionável até ACK, a parcela reconhecida dentro de sua meta interna e o número de reatribuições manuais. Rastreie separadamente os checkouts com falha e o tempo até que os pagamentos bem-sucedidos sejam retomados no monitoramento do comércio.
Limite. O IR não repara o checkout ou um provedor de pagamento. Um ACK não prova que os clientes podem pagar novamente e uma política de escalonamento não pode ajudar se nenhum dos engenheiros estiver acessível. Mantenha o caminho de contato alternativo e uma verificação real de recuperação de pagamento.
Quatro engenheiros, um serviço de cobrança, uma cadeia de propriedade
Suponha que quatro engenheiros compartilhem suporte para um faturamento API. Comece com uma equipe e uma rotação primária semanal. Dê à rota um serviço padrão e um canal de entrega testado. Adicione uma pessoa reserva explicitamente; uma sala de chat compartilhada não é uma política de escalonamento.
| Objeto | Configuração de exemplo na IU |
|---|---|
| Propriedade | Equipe payments; serviço billing-api; rotação payments-primary com quatro membros ativos e cobertura 24/7. |
| Ingestão | Fonte webhook, serviço padrão billing-api, modo de escalonamento de política e canais de notificação anexados. |
| Escalação | Regra 1: rotação primária, atraso de 300 segundos. Regra 2: um usuário de backup nomeado, atrase 600 segundos. Defina repeat_count=0 para este piloto. |
Configure canais e contatos de resposta antes de enviar um alerta. Abra o diagnóstico de saúde de plantão completo: o resumo da tabela verde por si só não verifica a cobertura futura nem prova que uma mensagem chegou a um telefone.
Envie uma falha e depois sua recuperação
Envie esses JSON corpos separadamente para POST /api/integrations/webhook com Content-Type: application/json e Authorization: Bearer ROUTE_TOKEN. Substitua o espaço reservado pelo token da rota de teste da IU; mantenha-o fora do controle de origem e dos logs compartilhados. Este é o formato genérico de webhook, não um evento normalizado do Simulador.
{
"status": "firing",
"fingerprint": "billing-api:health:prod",
"title": "Billing API health check failed",
"severity": "critical",
"labels": {
"alertname": "BillingUnavailable",
"environment": "production",
"service": "billing-api"
}
}{
"status": "resolved",
"fingerprint": "billing-api:health:prod",
"title": "Billing API health check failed",
"severity": "critical",
"labels": {
"alertname": "BillingUnavailable",
"environment": "production",
"service": "billing-api"
}
}Mantenha a mesma rota, impressão digital e rótulos de agrupamento para recuperação. A impressão digital identifica o alerta infantil; alterá-lo para um novo valor aleatório em cada solicitação anula a desduplicação. Uma recuperação órfã não cria um novo grupo.
Prove a corrente antes de um verdadeiro turno noturno
- Envie o corpo de disparo duas vezes. Espere um alerta infantil, o serviço pretendido e o responsável principal atual; confirme a entrega real, não apenas um sucesso HTTP.
- Deixe um alerta de teste separado sem confirmação. Verifique se o backup se torna o destino após o primeiro atraso da política. A cadência do agendador, as filas e a entrega do fornecedor significam que este não é um SLA de entrega exato de cinco minutos.
- Reconheça outro grupo de teste e verifique se as notificações somente de disparo pendentes param. Envie a recuperação e confirme se o grupo resolve quando não restarem crianças demitidas.
- Crie uma substituição de rotação temporária e repita o teste. Confirme se a substituição é o destinatário efetivo e remova a configuração de teste.
Saiba quando a corrente para
No modo de política, o escalonamento baseado em lembretes da equipe é ignorado. Depois que todas as regras e repetições permitidas forem esgotadas, os lembretes de política serão interrompidos; o alerta ainda pode estar disparando. Uma pessoa de backup sem detalhes de contato profissional é apenas um nome em um banco de dados.
ACK é propriedade e não recuperação do serviço de cobrança. A IR não pode reparar a aplicação ou fornecer um engenheiro ausente. Mantenha uma forma externa de entrar em contato com a equipe se o RI ou seu provedor de notificação não estiver disponível e concorde com essa alternativa durante a integração.