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: um backup noturno nunca termina
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 empresa faz backup de seu banco de dados de pedidos em dois servidores antes do início do dia útil. Um trabalho para silenciosamente; o outro consegue. Um único sinal de sucesso partilhado esconderia a lacuna. O risco comercial é descobrir um ponto de recuperação antigo ou ausente somente quando uma restauração for necessária.
Fluxo de trabalho com IR. Defina um prazo de conclusão e acompanhe cada servidor esperado separadamente. Um host envia sua pulsação somente após a conclusão do trabalho e das verificações de sucesso. Uma conclusão ausente cria um alerta atrasado roteado para o respondente da plataforma, com um caminho de escalonamento de backup. O engenheiro investiga ou executa novamente o trabalho e registra o resultado.
Benefício operacional a ser validado. Transforme uma falha silenciosa de trabalho agendado em uma tarefa própria antes do próximo turno de negócios. O mesmo padrão pode abranger uma exportação agendada ou um trabalho em lote, desde que seu sinal de conclusão represente genuinamente sucesso.
O que medir. Acompanhe os prazos perdidos por servidor, o tempo desde o prazo até a confirmação e a idade do último backup verificado. Mantenha a verificação de backup e os resultados da análise de restauração no sistema de backup ou no relatório de operações; não os infira a partir de um batimento cardíaco verde.
Limite. Uma pulsação prova que um sinal chegou, e não que os dados podem ser restaurados. Não garante um ponto ou tempo de recuperação. Teste as restaurações de forma independente e monitore o próprio IR fora do mesmo domínio de falha.
Trate o sistema de paging como um serviço que você opera
Considere uma equipe de plataforma que possui um cluster de produção e backups noturnos de banco de dados. Ele quer o IR próximo à sua pilha de monitoramento, mas isso também torna a equipe responsável pelo sistema que o ativa. Nomeie um proprietário para o serviço web, agendador, banco de dados, segredos e procedimento de recuperação.
A configuração da versão Docker executa serviços da Web e do agendador separadamente. Depois de seguir esse guia de implantação em um ambiente de teste, inspecione-os na verificação da versão:
docker compose ps
docker compose logs --tail=50 incidentrelay
docker compose logs --tail=50 incidentrelay-schedulerO processo web aceita alertas recebidos; o agendador lida com lembretes, escalonamento e trabalhos periódicos. Não inicie um agendador dentro de cada web trabalhador. Uma página de login funcional não prova que o escalonamento cronometrado está em execução.
Detecte um backup ausente em um host
Crie uma pulsação de conclusão programada com vencimento diário às 3h no UTC, anexada a uma rota cuja origem seja heartbeat. Habilite o rastreamento de instâncias; para uma frota fixa, use instâncias estáticas esperadas, como db-1 e db-2. Anexe a rotação da plataforma ou a política e os canais de teste.
Depois que o backup de um host e suas verificações de sucesso forem concluídas, envie esse corpo para POST /api/heartbeats/ping/HEARTBEAT_TOKEN com o tipo de conteúdo JSON. Use o URL secreto dessa pulsação, não um token de rota ou um token API administrativo.
{
"status": "completed",
"instance": "db-1",
"payload": {
"job": "nightly-database-backup"
}
}Envie um valor de instância distinto de cada host. Sem rastreamento de instância, um ping bem-sucedido de um servidor pode ocultar o backup ausente de outro servidor. Não envie um ping de sucesso incondicionalmente de um manipulador de limpeza de shell após uma tarefa com falha. Edite URLs de ping secretos de logs de proxy e de trabalho.
Falha no teste, não apenas na inicialização
- Faça ping em ambas as instâncias esperadas e, em seguida, omita deliberadamente uma delas em um breve cronograma de teste. Espere um alerta atrasado para essa instância enquanto a instância íntegra permanece OK.
- Retome a instância ausente. Se a resolução automática estiver habilitada, verifique se o alerta vencido é resolvido sem resolver a falha de outra instância.
- Pare o agendador somente na implantação de teste. Observe o efeito no trabalho cronometrado e prove que um monitor independente percebe isso; em seguida, restaure-o e verifique o processamento.
- Restaure o banco de dados, a configuração e os segredos necessários em um ambiente isolado com notificações de saída bloqueadas. Revise os grupos de disparo antigos antes de permitir a entrega, para que um exercício de restauração não possa paginar os respondentes de produção.
Um ping bem-sucedido não é um teste de restauração
Os batimentos cardíacos detectam sinais ausentes; eles não são sondagens HTTP/TCP ativas e não podem provar que um backup é utilizável. O IR também não pode notificá-lo de forma confiável sobre sua interrupção total. Mantenha uma verificação de disponibilidade externa e um caminho de contato separado fora do mesmo domínio de falha.
A auto-hospedagem não remove dependências de chat, e-mail, voz ou rede. Decida qual banco de dados e modelo de implantação se adequam à carga de trabalho, fixe a versão testada e ensaie atualizações e reversões. Esses exemplos não estabelecem alta disponibilidade nem garantia de rendimento.
Defina a retenção deliberadamente: o histórico de alertas resolvidos é retido indefinidamente por padrão. A limpeza também pode remover comentários vinculados e registros de entrega e não necessariamente reduz o arquivo de banco de dados. A retenção não substitui os backups.