Separe as comprobacións de saúde da VPN das da aplicación

O seu proceso de túnel pode estar en execución mentres a conexión protexida é inservible, e unha páxina web que falla non é proba de que o túnel se rompese. Cando unha soa sonda representa todas as demais, unha política de reinicio reinicia o compoñente equivocado e chámao automatización. Cada comprobación de abaixo nomea a capa que observa, a acción que desencadea o seu fallo e a evidencia de que a acción funcionou. O último paso converte todo o conxunto nunha páxina que alguén pode seguir ás tres da madrugada.

Paso 1: nomee a capa que observa cada comprobación

Pregunte que pode ver realmente cada sonda antes de escribir ningunha delas. A vitalidade demostra que o daemon está en marcha, un aperto de mans ou unha lista de pares demostra que a relación existe, unha petición encamiñada demostra a entrega e unha consulta demostra a resolución. Fallan exactamente nesa orde e ningunha implica a seguinte. Unha comprobación de proceso verde xunto a un túnel morto é o caso normal, non unha contradición.

Escriba as catro comprobacións nesa orde, co comando exacto e a saída esperada de cada unha. Unha sonda cuxa saída esperada vostede non poida enunciar será lida de forma distinta por cada operador que vexa a alerta. Poña a mesma lista no texto da alerta, non só no manual, para que a persoa espertada de noite atope a capa antes do síntoma. Manteña cada comando listo para copiar e pegar no host que o executa.

Despois engada a comprobación da aplicación como quinto elemento, separado. Unha páxina cuxo servizo de contas está caído non xustifica reiniciar o túnel.

Paso 2: ate cada fallo a unha soa acción

Para cada comprobación, decida que se reinicia, que queda bloqueado e que avisa a unha persoa. Un fallo da capa de túnel pode xustificar reiniciar o túnel; un fallo do resolutor apunta á integración de DNS no cliente; un fallo da capa de aplicación case nunca debería tocar o túnel.

Diga que non debe facer un fallo, porque os valores predeterminados perigosos son os permisivos. Un estado non saudable nunca debe converterse en permiso para o tráfico directo da aplicación, xa que unha vía alternativa que evita o túnel en silencio elimina a razón de existir do túnel. Estreite tamén as accións: reiniciar un compoñente compartido porque un destino é lento converte un problema local nun problema de toda a frota. Tamén destrúe a evidencia que necesitaba para atopar a causa.

Paso 3: manteña as sondas inocuas e baratas

Use peticións pequenas e de só lectura: un recurso estático, un punto de saúde que informe da súa propia dependencia ou unha conexión TCP a un porto que vostede controle. Evite credenciais, a navegación privada e calquera cousa que modifique o estado en cada intervalo, porque unha sonda que escribe é unha proba de carga programada.

Rexiste o destino, a expectativa de ruta e o tempo de espera de cada sonda. A expectativa de ruta é o campo que a xente omite, e é o que separa un fallo do túnel dun erro de encamiñamento cando lea a alerta máis tarde. Derive o intervalo e o limiar de fallo do tempo de recuperación que promete, e manteña o tempo de espera máis curto que o intervalo. Unha sonda que segue executándose cando comeza a seguinte informa dun fallo dúas veces e parece un parpadeo.

Paso 4: rompa cada capa e mire se a sonda correcta se pon vermella

Detéña o proceso do túnel e confirme que a comprobación do proceso falla mentres o DNS aínda pode responder desde a caché. Cambie unha ruta e confirme que a petición encamiñada falla mentres o proceso e o aperto de mans seguen sans. Rompa só o DNS e confirme que a comprobación da aplicación informa de resolución en lugar dun erro de túnel. Se dúas sondas se moven sempre xuntas, ten menos comprobacións das que cre.

Probe a dirección de recuperación coa mesma disciplina. Despois de restaurar a capa, a sonda debería limparse sen un reinicio manual, e a acción que se disparou non debería deixar ningún desvío detrás. Observe un ciclo completo antes de confiar no estado verde, porque unha sonda que só se limpa a man agocha unha ruta de recuperación rota.

Paso 5: poña o manual onde apunta a alerta

Unha páxina con cinco filas leva todo o deseño: capa, comando, resultado esperado, acción ante fallo, responsable. Engada unha liña por sonda sobre que non proba deliberadamente. Esa liña é o que impide que a seguinte persoa engada unha sexta comprobación que mide todo e non distingue nada. Enlace a páxina desde o texto da alerta, ou ninguén a abrirá mentres a incidencia estea activa.

En despregamentos de contedores, unha condición de dependencia dá forma ao arranque e a nada máis. Orde de arranque e condición de saúde de Compose documentación describe como a dispoñibilidade determina a orde na que arrincan os servizos; nada diso aplica despois unha política de saída, e nada diso falla pechado cando o túnel cae. A aplicación continua necesita a súa propia política e a súa propia sonda, escritas na mesma páxina.

O manual está rematado cando a capa correcta se recupera sen que ninguén lea un sitio web non dispoñible como un túnel roto. Iso pon a proba o documento, non o túnel.