Déploiement zero-Downtime

(Section : Architecture et protocoles)

1) Qu'est-ce que Zero-Downtime et pourquoi il est nécessaire

• Zéro simple pour les clients et les intégrations.
• Des sorties prévisibles, un retour en arrière rapide et un risque gérable.
• Enregistrement de SLO/SLI (latence, erreurs, disponibilité) dans les limites des arrangements.

La clé du ZDT n'est pas une technique « magique », mais une combinaison de patterns de livraison, de compatibilité des données et de routage du trafic.

2) Principes de base de Zero-Downtime

1. Compatibilité des versions : les nouvelles et les anciennes versions doivent traiter le trafic et les données correctement à la fois.
2. Idempotence des opérations : le traitement répété ne doit pas briser l'état.
3. L'achèvement gracieux (graceful shutdown) et le drainage des composés.
4. Test de santé étape par étape : read..../échantillons liveness, endpoints de santé.
5. Retour en tant que citoyen de première classe : rollback est plus facile et plus rapide que hotfix.
6. Observabilité par design : étiquettes de sortie, dashboards uniques, alertes par SLO.
7. Automatisation : les scripts de sortie et de retour sont du code, pas des instructions manuelles.

3) Modèles de livraison sans downtime

3. 1 Rolling Update

Nous retirons progressivement de la circulation une partie des instances de l'ancienne version, les mettons à jour sur une nouvelle et les renvoyons au pool.

Avantages : économique sur l'infrastructure, juste en k8s/ASG.
Inconvénients : pendant un certain temps, le cluster fonctionne avec deux versions en même temps (version skew).

3. 2 Blue-Green

Deux piles pleines : Active (Blue) et Candidate (Green). Le changement de trafic est un flip atomique.

Avantages : retour instantané, isolation pure.
Inconvénients : Dépenses d'infrastructure ↑, plus difficiles avec stateful.

3. 3 Canary/Rollout progressif

Nous donnons une petite part du trafic (1-5-10-25-50-100 %) à la nouvelle version avec des jeux de métriques.

Avantages : minimum de radius blast, solutions data-driven.
Inconvénients : une observabilité mature et un routage intelligent sont nécessaires.

3. 4 Shadow traffic / Dark launch

Mettez en miroir les requêtes réelles vers la nouvelle version (sans réponse à l'utilisateur) ou exécutez masqué pour collecter les métriques.

Avantages : détection précoce des problèmes.
Inconvénients : double charge de dépendance, vous avez besoin de contrôler les effets secondaires.

4) Gestion du trafic et des connexions

4. 1 Readiness/Liveness

Liveness dit à l'orchestrateur « redémarrez-moi ».
Read....- « ne dirige pas le trafic, je ne suis pas encore prêt ».
Vous ne pouvez pas sortir sans une logique de lecture et un délai corrects.

4. 2 Drainage des joints

• cessons d'accepter de nouveaux composés,
• nous attendons l'achèvement des actifs,
• Nous interrompons les « traînés » par le tymaut.

4. 3 Sticky-sessions et routage de niveau L7

Sticky est utile dans les scripts stateful, mais complique l'équilibre de la charge.
Les règles L7 (chemin, titre, cookie, versions de l'API) sont pratiques pour canary/ring.

4. 4 Composés à longue durée de vie

WebSocket/gRPC streaming : avant de mettre à jour, activez le drain mode + signal « GOAWAY ».
Planifiez Windows pour surpasser les strimes et les retraits backof des clients.

5) Compatibilité des données et migration OBD

5. 1 Expand-Migrate-Contract

1. Expand : nous ajoutons de nouvelles colonnes/index/tables sans casser l'ancienne version.
2. Migrate : nous transférons les données de fond et idempotent (batchi, tchekpoints).
3. Contrat : nous ne retirons l'ancien qu'après stabilisation.

5. 2 Pratiques

Évitez les locks DDL exclusifs dans la fenêtre de sortie.
Versez les contrats API/événements (schema registry, CDC).
Pour les migrations lourdes - outils en ligne, répliques, changements échelonnés.
Enregistrement à deux contours (dual-write) uniquement avec déduplication et idempotent.
Outbox/Inbox pour une intégration fiable via les files d'attente.

6) Caches, sessions et tâches d'arrière-plan

Sessions et cache externes (Redis/Memcached) afin que les versions soient interchangeables.
Réchauffer le cache/jit/tempo-index avant de l'inclure dans le pool.
Séparez les files d'attente de fond par version ou utilisez le leadership pour éviter les courses.

7) Observabilité et gates par SLO

Signaux Golden : latence p95/p99, taux d'erreur, RPS, saturation, file d'attente.
SLA d'entreprise : autorisations, conversions, paiements réussis, refus par étapes d'entonnoir.
Gates : rollout n'avance que si canary ≤ baseline + seuils de dégradation et error budget ne brûle pas.

8) Fin et retrait sécurisés

Le retour en arrière est la même pipline, seulement dans le sens inverse : commandes fixes, pas « artisanat manuel ».
Pour le bleu-vert - flip back ; pour canary, le poids est ramené à 0 % ou l'étape précédente est stable.
Données : compensation des transactions, re-traitement, déduplication des événements.

9) Chèques-feuilles Zero-Downtime

Avant la sortie

• Un artefact signé (immutable), un SBOM et un test de dépendance ont été collectés.
• Read..../liveness mis en œuvre et testé.
• Plan de migration expand, réversibilité confirmée.
• Dashboards et alertes pour la nouvelle version sont prêts, les étiquettes de sortie sont maudites.
• Retour vérifié pour staging/pre-prod.

Pendant la sortie

• Drainage des composés inclus, les délais sont adéquats.
• Le trafic se traduit progressivement (canary/ring) ou flip (blue-green).
• Les métriques sont comparées à la baseline, les seuils des gates sont respectés.

Après la sortie

• Post-monitoring N heures, aucun incident.
• Les migrations de contrat sont terminées, les drapeaux temporaires/itinéraires supprimés.
• Rétrospective, mise à jour des playbooks.

10) Anti-modèles

Recreate-deploy sans drainage et read.... ⇒ falaises de requêtes.
Les DDL non préparés ⇒ les blocages et les temporisations en prime time.
Mélange de schémas incompatibles entre les versions du service.
L'absence d'idempotence dans les manipulateurs et les workers.
« On va le faire » sans gates et comparaison avec baseline.
Long DNS-TTL en bleu-vert, ce qui fait que le flip dure des heures.
Sessions locales/cache dans la mémoire de l'instance rolling/canary.

11) Scénarios de mise en œuvre

11. 1 Kubernetes (rolling + canary)

Deployment с `maxUnavailable=0`, `maxSurge=25%`.
Read....attend d'être réchauffé (initialisation du cache, migration mineure).
Service-mesh/Ingress avec routage weighted (1-5-10-25-50-100 %).
Alert : p95, 5xx, lag queue, entonnoir d'affaires.

11. 2 Blue-Green dans le nuage

Deux piles derrière le balancier : 'blue. example. com` и `green. example. com`.
Échauffement vert, smoke/régression, puis listener/route swap (ou basculement DNS avec TTL faible).
En cas de problème, flip back instantané.

11. 3 Service Stateful

Répliques de données + migration en ligne ; double lecture avec validation.
Les jobs d'arrière-plan sont transférés selon la version « leader » ou les files d'attente séparées.
Sessions/cache hors de l'instance ; le sticky n'est inclus que temporairement.

12) Ficheflags et applications clients

Les nouvelles fiches sont activées par des drapeaux (segments : employés → bêta → tout).
Pour les clients mobiles/de bureau, tenez compte des limites de compatibilité du protocole et de la survie des anciennes versions (deprecation policy, server-side fallback).

13) Productivité et coût

Rolling est moins cher, mais nécessite une compatibilité prudente.
Blue-Green est plus cher pendant la sortie, mais le retour est instantané.
Canary équilibre les risques et les coûts, mais exige une forte observabilité.
Économisez via ephemeral-preview et auto-nettoyage des stands.

14) ZDT de référence minimum

1. Build : artefact unique, signature, SBOM.
2. Test: unit/integration/contract + security.
3. Staging : smoke, charge, migration en mode expand, vérification de retour.
4. Prod : shadow → canary (gates) ou blue-green flip.
5. Post-deploy : observation, contract-cleanup, rétro.

15) Bref résumé

Zero-Downtime est une discipline : versions compatibles + routage correct + migrations gérables + observabilité et retour rapide. Choisissez le modèle en fonction du contexte (rolling, blue-green, canary), automatisez les gates SLO, gardez les données idempotentes - et les versions ne seront plus un événement, devenant un processus de routine fiable.