# Fixer des limites sûres au self-healing

Taiga Learning · Fiche d’exercice
https://taiga.training/fr/lessons/self-healing/

Utilisez des informations fictives ou approuvées. Ne placez pas de secrets dans cette fiche.

## Objectifs d’apprentissage
- Distinguer le self-healing d’une correction logicielle durable.
- Définir une politique de reprise bornée et des contrôles indépendants de réussite.
- Reconnaître quand l’automatisation doit s’arrêter et escalader.

## Exercice
Concevez une politique de reprise pour le worker d’export fictif de cette leçon. Précisez le déclencheur, les exclusions, l’action permise, la limite de tentatives, le délai d’attente, le contrôle de réussite et le responsable de l’escalade. Testez-la face à une panne de base de données et à une défaillance d’intégrité inconnue.

## Votre réponse
- Scénario et périmètre :
- Hypothèses et questions ouvertes :
- Réponse ou décision proposée, avec justification :

## Vérifier votre réponse
| Affirmation ou critère | Preuve ou test | Résultat ou lacune | Responsable |
| --- | --- | --- | --- |
| | | | |
| | | | |
| | | | |

## Action suivante
- Action, responsable et date :
- Quand réexaminerez-vous cette réponse ?

## Principe à retenir
Le self-healing nécessite une défaillance définie, une action autorisée, un résultat mesurable et une condition d’arrêt. Répéter une action sans rétablissement constitue une autre défaillance.

## Sources
- [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/)

Cette fiche sert à apprendre. La remplir n’autorise pas à elle seule une modification en production.