Fiabilidade e autorreparação

Sondas

A maioria das sondas tem de falhar duas vezes seguidas antes de um incidente abrir; um contentor parado ou uma base de dados corrompida agem à primeira falha. Uma sonda que passa limpa o contador de todos os tipos de incidente que pode levantar.

O manual de ações

• Serviço ou escutador em baixo: reiniciar o contentor e esperar pela saúde; se os registos mostrarem um token de chat inválido, escalar com o excerto em vez de reescrever um token em silêncio.
• Escutador desatualizado duas vezes numa hora: escalar, porque isso parece uma regressão e não um soluço.
• Fluxo de eventos ou API em baixo: recarregar a configuração do proxy se validar, reiniciar o contentor e, se houve um deploy nas últimas 24 horas, assinalá-lo como candidato a reversão.
• Pressão de disco: compactar o journal, rodar os registos, limpar o estado do guardião.
• Certificado a expirar: renovar e recarregar o proxy.
• Anti-oscilação: o mesmo incidente a repetir-se mais do que o número configurado de vezes em 24 horas interrompe a autorreparação e escala.

Além dos reinícios

• Um resumo diário sintetiza incidentes e ações.
• Uma execução sintética semanal de ponta a ponta exercita os fluxos reais contra o ambiente de staging.
• Uma vigilância de lógica corre o próprio conjunto de testes do produto contra o código implementado num contentor só de leitura e compara com a linha de base verde: um teste que estava verde e agora está vermelho é uma regressão; um teste vermelho fora da linha de base é uma notificação, não uma ação.
• Um pipeline de correção autónomo pode levar uma regressão confirmada por um patch delimitado, testes locais, um ramo, CI, staging, a execução sintética, integração e produção, com uma barreira de saúde e reversão automática. Os segredos sensíveis são retirados do seu ambiente e os caminhos proibidos são recusados.
• O guardião corre sob um supervisor de serviços com um watchdog, por isso um ciclo parado é reiniciado, e não apenas um que tenha falhado.

Dentro do produto

• Uma caixa de saída durável do bot: as mensagens de aprovação, os avisos nas salas e as suas remoções são escritos na base de dados e descarregados pelo ciclo, por isso uma decisão tomada com o bot em baixo continua a ser entregue.
• Os webhooks tentam de novo com recuo e um circuito por endpoint.
• Uma varredura noturna reconcilia a lista de eventos do homeserver com o próprio registo de mensagens do bot e regista todas as mensagens que nunca entraram; uma falha é retirada quando a mensagem aparece mais tarde, e uma varredura parcial é registada como incompleta em vez de limpa.
• Um watchdog de materialização alerta os administradores quando a pontuação em cache mais recente tem mais de 26 horas ou a janela está insuficientemente coberta.
• O failsafe de IA muda de fornecedor quando o ativo deixa de responder.
• Todas as tarefas que pontuam correm fora do ciclo de eventos, para que uma passagem longa nunca possa congelar o bot; isto é guardado por um teste.