Defina limites seguros para a autorrecuperação

Recupere uma condição conhecida

A autorrecuperação detecta automaticamente uma falha definida e tenta executar uma ação autorizada de recuperação. Reiniciar um processo com falha ou substituir uma instância não saudável são exemplos. A ação deve corresponder à falha e ao modelo de estado do serviço.

O Kubernetes pode substituir instâncias de cargas de trabalho com falha e reconciliar o estado declarado. Isso não corrige lógica defeituosa da aplicação nem toda falha de armazenamento. Recuperação de infraestrutura e correção do software precisam de verificações diferentes. Autorrecuperação no Kubernetes.

Defina o objetivo antes do mecanismo. Restaurar uma exportação significa que o trabalho elegível é concluído corretamente. Um contêiner em execução é apenas uma precondição.

Separe três tipos de alteração

Um agente pode propor uma correção após a recuperação. Essa proposta é uma nova alteração de software. Não deve herdar autoridade ilimitada do controlador de recuperação.

O controlador também não deve editar seus próprios critérios de sucesso quando uma verificação falhar. Caso contrário, o sistema pode relatar melhoria sem melhorar o serviço.

Escreva a política de recuperação antes de ativá-la

A política a seguir é fictícia. Seus números ilustram escolhas de projeto; não são configurações padrão recomendadas.

Use uma identidade com o menor privilégio necessário. Registre a versão da política, a evidência do acionamento, a ação, o recurso e o resultado. Ofereça um meio independente de desativar o controlador. Defina a pessoa responsável que recebe o escalonamento.

Teste caminhos de falha e a recuperação bem-sucedida

Uma nova tentativa pode repetir um efeito colateral. Um worker pode armazenar um arquivo e parar antes de confirmar o job. Verifique a idempotência antes de permitir outra execução. Consulte o exemplo de falha cloud native.

Novas tentativas também podem ampliar a sobrecarga de uma dependência. Use tentativas limitadas, tempos limite e backoff adequado. Evite novas tentativas sincronizadas em toda a frota. A AWS explica por que backoff e jitter ajudam a reduzir essa amplificação. Orientações sobre novas tentativas.

Teste a política fictícia com três casos. Um único worker parado deve se recuperar. Uma indisponibilidade do banco deve impedir substituições repetidas. Uma falha de integridade incerta deve interromper a automação e solicitar uma decisão de resposta.

Verifique também a ausência de telemetria. A falta de um sinal de atividade pode significar um worker com falha ou uma falha no caminho de coleta. O controlador precisa de evidências suficientes para sua ação, não de confiança em uma explicação de IA.

Meça se a política ajuda

Registre recuperações verificadas, tentativas malsucedidas, escalonamentos, trabalho duplicado e tempo com impacto nos usuários. Compare-os com o método operacional anterior em condições semelhantes.

Mantenha o defeito subjacente como trabalho de engenharia. Reiniciar repetidamente um processo com vazamento pode reduzir o impacto imediato enquanto o vazamento continua. Prossiga com melhoria contínua para relacionar a observação a uma correção duradoura.