Exécution et rollback¶

Exécuter un changement de manière controlee — checklist, points de vérification, critères go/no-go et procédures de rollback.

Checklist pre-déploiement¶

Avant de toucher à la production, une checklist systematique réduit le risque d'oubli critique. Elle doit être validee par le Change Owner et un second (peer check) pour les changements normaux.

Exécution controlee¶

Un changement en production n'est pas une sequence d'actions techniques — c'est un protocole. Chaque étape doit être journalisee avec horodatage.

Principes d'exécution¶

• Avancer pas a pas : exécuter les étapes une par une, vérifier entre chaque
• Journaliser en temps réel : noter l'heure de chaque action dans le ticket RFC (pas après coup)
• Nommer un coordinateur : une personne pilote l'exécution, les autres exécutent ou surveillent
• Ne pas improviser : si la procédure ne correspond plus à la réalité, s'arrêter et évaluer avant de continuer

Points de vérification intermédiaires¶

Pour les changements longs, définir des checkpoints intermédiaires permettant d'évaluer si on continue ou on s'arrêté.

Un checkpoint inclut :

• métriques attendues (taux d'erreur, latence, connexions actives)
• comportement attendu des logs
• décision : continuer / marquer un warning / rollback immédiat

Critères go/no-go¶

Les critères go/no-go sont des seuils pre-définis qui déterminent objectivement si on continue ou si on déclenche le rollback. Ils doivent être définis avant la fenêtre, pas pendant.

Procédures de rollback¶

Un rollback est une procédure technique, pas une décision de panique. Elle doit être préparée, testée et documentee comme toute autre procédure.

Décision tree rollback¶

graph TD
    A["Changement execute"] --> B{"Criteres go/no-go<br/>OK ?"}
    B -->|Oui| C["Continuer l'execution<br/>ou passer aux smoke tests"]
    B -->|Non| D{"Rollback<br/>possible ?"}
    D -->|Oui| E["Executer le rollback<br/>selon la procedure"]
    D -->|Non| F["Roll forward<br/>correctif pre-prepare"]
    E --> G{"Service restaure ?"}
    G -->|Oui| H["Clore l'incident<br/>PIR obligatoire"]
    G -->|Non| I["Escalade immediate<br/>mobiliser backup"]
    F --> G

Composantes d'une procédure de rollback¶

Smoke tests post-changement¶

Les smoke tests sont des verifications rapides (5-15 minutes) qui confirment que les fonctions critiques du service fonctionnent après le changement.

Principes¶

• Cibler les fonctions critiques : login, transaction principale, API health check — pas un test exhaustif
• Automatiser quand possible : un script de smoke test lance après chaque déploiement est plus fiable qu'une checklist manuelle
• Définir le critère de succès : vert = on clôture la fenêtre, rouge = on évalué go/no-go

Exemple de vérification manuelle structurée¶

Outils¶