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

Taiga Learning · Hoja de ejercicios
https://taiga.training/es/lessons/self-healing/

Usa información ficticia o aprobada. No incluyas secretos en esta hoja.

## Objetivos de aprendizaje
- Distinguir la recuperación automática de una corrección permanente del software.
- Definir una política de recuperación limitada y comprobaciones de éxito independientes.
- Reconocer cuándo debe detenerse la automatización y escalar el problema.

## Ejercicio
Diseña una política de recuperación para el worker de exportación ficticio de esta lección. Especifica el activador, las exclusiones, la acción permitida, el límite de reintentos, el tiempo de espera, la comprobación de éxito y el responsable de la escalada. Pruébala ante una caída de la base de datos y un fallo desconocido de integridad de datos.

## Tu respuesta
- Escenario y alcance:
- Suposiciones y preguntas abiertas:
- Respuesta o decisión propuesta, con motivos:

## Verifica tu respuesta
| Afirmación o criterio | Prueba o comprobación | Resultado o carencia | Responsable |
| --- | --- | --- | --- |
| | | | |
| | | | |
| | | | |

## Siguiente acción
- Acción, responsable y fecha:
- ¿Cuándo revisarás esta respuesta?

## Principio que conservar
La recuperación automática necesita un fallo definido, una acción autorizada, un resultado medible y una condición de parada. Repetir una acción sin recuperar el servicio es otro fallo.

## Fuentes
- [Kubernetes: Self-Healing](https://kubernetes.io/docs/concepts/architecture/self-healing/)
- [AWS Builders’ Library: Timeouts, retries, and backoff with jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
- [Google SRE: Automation at Google](https://sre.google/sre-book/automation-at-google/)

Esta hoja apoya el aprendizaje. Completarla no autoriza por sí solo un cambio en producción.