Separe as verificações de saúde da VPN das verificações da aplicação
Um processo de túnel em execução, uma rota protegida, o DNS e o destino podem falhar de forma independente. Faça cada verificação nomear a sua camada e a ação que desencadeia.
O seu processo de túnel pode estar em execução enquanto a ligação protegida é inutilizável, e uma página web que falha não é prova de que o túnel se quebrou. Quando uma única sonda representa todas as outras, uma política de reinício reinicia o componente errado e chama a isso automatização. Cada verificação abaixo nomeia a camada que observa, a ação que o seu falhanço desencadeia e a evidência de que a ação funcionou. O último passo transforma todo o conjunto numa página que alguém consegue seguir às três da manhã.
Passo 1: nomeie a camada que cada verificação observa
Pergunte o que cada sonda consegue realmente ver antes de escrever qualquer uma delas. A vivacidade prova que o daemon está a correr, um aperto de mão ou uma lista de pares prova que a relação existe, um pedido encaminhado prova a entrega e uma consulta prova a resolução. Falham exatamente nessa ordem e nenhuma implica a seguinte. Uma verificação de processo verde ao lado de um túnel morto é o caso normal, não uma contradição.
Escreva as quatro verificações nessa ordem, com o comando exato e a saída esperada de cada uma. Uma sonda cuja saída esperada não consegue enunciar será lida de forma diferente por cada operador que veja o alerta. Coloque a mesma lista no texto do alerta, não apenas no manual, para que a pessoa acordada de noite encontre a camada antes do sintoma. Mantenha cada comando pronto a copiar no anfitrião que o executa.
Depois acrescente a verificação da aplicação como quinto elemento, separado. Uma página cujo serviço de contas está em baixo não justifica reiniciar o túnel.
Passo 2: ligue cada falhanço a uma única ação
Para cada verificação, decida o que reinicia, o que fica bloqueado e o que avisa uma pessoa. Um falhanço da camada de túnel pode justificar reiniciar o túnel; um falhanço do resolvedor aponta para a integração de DNS no cliente; um falhanço da camada de aplicação quase nunca deve tocar no túnel.
Diga o que um falhanço não deve fazer, porque os valores predefinidos perigosos são os permissivos. Um estado não saudável nunca deve tornar-se permissão para tráfego direto da aplicação, já que uma via alternativa que contorna o túnel em silêncio retira a razão de existir do túnel. Restrinja também as ações: reiniciar um componente partilhado porque um destino está lento transforma um problema local num problema de toda a frota. Também destrói a evidência de que precisava para encontrar a causa.
Passo 3: mantenha as sondas inofensivas e baratas
Use pedidos pequenos e só de leitura: um recurso estático, um ponto final de saúde que informe a sua própria dependência ou uma ligação TCP a uma porta que controla. Evite credenciais, navegação privada e tudo o que altere o estado em cada intervalo, porque uma sonda que escreve é um teste de carga programado.
Registe o destino, a expectativa de rota e o tempo limite de cada sonda. A expectativa de rota é o campo que as pessoas omitem, e é o que separa um falhanço do túnel de um erro de encaminhamento quando lê o alerta mais tarde. Derive o intervalo e o limiar de falhanço do tempo de recuperação que promete, e mantenha o tempo limite mais curto do que o intervalo. Uma sonda ainda em execução quando a seguinte começa comunica um falhanço duas vezes e parece um tremeluzir.
Passo 4: quebre cada camada e veja a sonda certa a ficar vermelha
Pare o processo do túnel e confirme que a verificação de processo falha enquanto o DNS ainda pode responder a partir da cache. Mude uma rota e confirme que o pedido encaminhado falha enquanto o processo e o aperto de mão permanecem saudáveis. Quebre apenas o DNS e confirme que a verificação da aplicação comunica resolução em vez de um erro de túnel. Se duas sondas se movem sempre juntas, tem menos verificações do que pensa.
Teste a direção de recuperação com a mesma disciplina. Depois de restaurar a camada, a sonda deveria limpar-se sem reinício manual, e a ação que disparou não deveria deixar qualquer desvio atrás. Observe um ciclo completo antes de confiar no estado verde, porque uma sonda que só se limpa à mão esconde um caminho de recuperação quebrado.
Passo 5: coloque o manual onde o alerta aponta
Uma página com cinco linhas carrega todo o desenho: camada, comando, resultado esperado, ação em caso de falhanço, responsável. Acrescente uma linha por sonda sobre o que deliberadamente não testa. É essa linha que impede a pessoa seguinte de acrescentar uma sexta verificação que mede tudo e não distingue nada. Ligue a página a partir do texto do alerta, ou ninguém a abrirá enquanto o incidente estiver ativo.
Em implementações de contentores, uma condição de dependência molda o arranque e nada mais. Ordem de arranque e condição de saúde do Compose documentação descreve como a prontidão determina a ordem em que os serviços arrancam; nada disso aplica depois uma política de saída, e nada disso falha fechado quando o túnel cai. A aplicação contínua precisa da sua própria política e da sua própria sonda, escritas na mesma página.
O manual está terminado quando a camada certa recupera sem que ninguém leia um sítio indisponível como um túnel quebrado. Isso testa o documento, não o túnel.