Separe las comprobaciones de salud de la VPN de las de la aplicación

Su proceso de túnel puede estar en ejecución mientras la conexión protegida es inservible, y una página web que falla no es prueba de que el túnel se haya roto. Cuando una sola sonda representa a todas las demás, una política de reinicio reinicia el componente equivocado y lo llama automatización. Cada comprobación de abajo nombra la capa que observa, la acción que desencadena su fallo y la evidencia de que la acción funcionó. El último paso convierte todo el conjunto en una página que alguien puede seguir a las tres de la madrugada.

Paso 1: nombre la capa que observa cada comprobación

Pregunte qué puede ver realmente cada sonda antes de escribir ninguna de ellas. La vitalidad demuestra que el demonio está en marcha, un apretón de manos o una lista de pares demuestra que la relación existe, una petición enrutada demuestra la entrega y una consulta demuestra la resolución. Fallan exactamente en ese orden y ninguna implica la siguiente. Una comprobación de proceso en verde junto a un túnel muerto es el caso normal, no una contradicción.

Escriba las cuatro comprobaciones en ese orden, con el comando exacto y la salida esperada de cada una. Una sonda cuya salida esperada usted no pueda enunciar la leerá de forma distinta cada operador que vea la alerta. Ponga la misma lista en el texto de la alerta, no solo en el manual, para que la persona despertada de noche encuentre la capa antes que el síntoma. Mantenga cada comando listo para copiar y pegar en el host que lo ejecuta.

Después añada la comprobación de la aplicación como quinto elemento, separado. Una página cuyo servicio de cuentas está caído no justifica reiniciar el túnel.

Paso 2: ate cada fallo a una sola acción

Para cada comprobación, decida qué se reinicia, qué queda bloqueado y qué avisa a una persona. Un fallo de la capa de túnel puede justificar reiniciar el túnel; un fallo del resolutor apunta a la integración de DNS en el cliente; un fallo de la capa de aplicación casi nunca debería tocar el túnel.

Diga qué no debe hacer un fallo, porque los valores predeterminados peligrosos son los permisivos. Un estado no saludable nunca debe convertirse en permiso para el tráfico directo de la aplicación, ya que una vía alternativa que evita el túnel en silencio elimina la razón de existir del túnel. Estreche también las acciones: reiniciar un componente compartido porque un destino es lento convierte un problema local en un problema de toda la flota. También destruye la evidencia que necesitaba para encontrar la causa.

Paso 3: mantenga las sondas inocuas y baratas

Use peticiones pequeñas y de solo lectura: un recurso estático, un punto de salud que informe de su propia dependencia o una conexión TCP a un puerto que usted controle. Evite credenciales, la navegación privada y cualquier cosa que modifique el estado en cada intervalo, porque una sonda que escribe es una prueba de carga programada.

Registre el destino, la expectativa de ruta y el tiempo de espera de cada sonda. La expectativa de ruta es el campo que la gente omite, y es lo que separa un fallo del túnel de un error de enrutamiento cuando lea la alerta más tarde. Derive el intervalo y el umbral de fallo del tiempo de recuperación que promete, y mantenga el tiempo de espera más corto que el intervalo. Una sonda que sigue ejecutándose cuando empieza la siguiente informa de un fallo dos veces y parece un parpadeo.

Paso 4: rompa cada capa y mire si la sonda correcta se pone roja

Detenga el proceso del túnel y confirme que la comprobación del proceso falla mientras el DNS aún puede responder desde la caché. Cambie una ruta y confirme que la petición enrutada falla mientras el proceso y el apretón de manos siguen sanos. Rompa solo el DNS y confirme que la comprobación de la aplicación informa de resolución en lugar de un error de túnel. Si dos sondas se mueven siempre juntas, tiene menos comprobaciones de las que cree.

Pruebe la dirección de recuperación con la misma disciplina. Después de restaurar la capa, la sonda debería despejarse sin un reinicio manual, y la acción que se disparó no debería dejar ningún desvío detrás. Observe un ciclo completo antes de confiar en el estado verde, porque una sonda que solo se despeja a mano esconde una ruta de recuperación rota.

Paso 5: ponga el manual donde apunta la alerta

Una página con cinco filas lleva todo el diseño: capa, comando, resultado esperado, acción ante fallo, responsable. Añada una línea por sonda sobre qué no prueba deliberadamente. Esa línea es lo que impide que la siguiente persona añada una sexta comprobación que mide todo y no distingue nada. Enlace la página desde el texto de la alerta, o nadie la abrirá mientras la incidencia esté activa.

En despliegues de contenedores, una condición de dependencia da forma al arranque y a nada más. Orden de arranque y condición de salud de Compose documentación describe cómo la disponibilidad determina el orden en que arrancan los servicios; nada de eso aplica después una política de salida, y nada de eso falla cerrado cuando el túnel cae. La aplicación continua necesita su propia política y su propia sonda, escritas en la misma página.

El manual está terminado cuando la capa correcta se recupera sin que nadie lea un sitio web no disponible como un túnel roto. Eso pone a prueba el documento, no el túnel.