Define límites seguros para la recuperación automática

Recupera una condición conocida

La recuperación automática detecta un fallo definido e intenta ejecutar una acción de recuperación autorizada. Reiniciar un proceso fallido o sustituir una instancia que no funciona son posibles ejemplos. La acción debe corresponder al fallo y al modelo de estado del servicio.

Kubernetes puede sustituir instancias de cargas de trabajo que fallan y reconciliar el estado declarado. Esto no corrige la lógica defectuosa de la aplicación ni todos los fallos de almacenamiento. La recuperación de la infraestructura y la corrección del software necesitan comprobaciones diferentes. Recuperación automática en Kubernetes.

Define el objetivo antes que el mecanismo. Restablecer una exportación significa que el trabajo apto para ejecutarse termina correctamente. Tener un contenedor en ejecución es solo una condición previa.

Distingue tres tipos de cambio

Un agente puede proponer una corrección después de la recuperación. Esa propuesta es un nuevo cambio de software. No debe heredar permisos ilimitados del controlador de recuperación.

El controlador tampoco debe modificar sus propios criterios de éxito cuando falla una comprobación. De lo contrario, el sistema puede comunicar una mejora sin mejorar el servicio.

Escribe la política de recuperación antes de activarla

La siguiente política es ficticia. Sus cifras ilustran decisiones de diseño; no son valores predeterminados recomendados.

Usa una identidad con los mínimos privilegios. Registra la versión de la política, las pruebas del activador, la acción, el recurso y el resultado. Proporciona una forma independiente de desactivar el controlador. Define qué persona responsable recibe la escalada.

Prueba los fallos y la recuperación satisfactoria

Un reintento puede repetir un efecto secundario. Un worker podría guardar un archivo y detenerse antes de confirmar el trabajo. Verifica la idempotencia antes de permitir otra ejecución. Consulta el ejemplo de fallo cloud native.

Los reintentos también pueden agravar la sobrecarga de una dependencia. Usa un número limitado de intentos, tiempos de espera máximos y pausas progresivas adecuadas. Evita reintentos sincronizados en todas las instancias. AWS explica cómo las pausas progresivas y su variación aleatoria ayudan a reducir esta amplificación. Guía sobre reintentos.

Prueba la política ficticia en tres casos. Un único worker detenido debería recuperarse. Una caída de la base de datos debería impedir sustituciones repetidas. Un fallo de integridad incierto debería detener la automatización y solicitar una decisión de respuesta.

Comprueba también la ausencia de telemetría. La falta de una señal de actividad puede indicar un fallo del worker o de la recogida de datos. El controlador necesita pruebas suficientes para su acción, no confianza en una explicación de la IA.

Mide si la política ayuda

Registra las recuperaciones verificadas, los intentos fallidos, las escaladas, el trabajo duplicado y el tiempo con impacto para los usuarios. Compáralos con el método operativo anterior en condiciones similares.

Mantén el defecto subyacente como trabajo de ingeniería pendiente. Reiniciar repetidamente un proceso con una fuga puede reducir el impacto inmediato mientras la fuga continúa. Sigue con la mejora continua para conectar la observación con una corrección duradera.