Aller au contenu principal

Plan de Reprise d'Activité (PRA)

Architecture Résiliente

Le PRA de Ziosting repose sur une infrastructure résiliente de 3 datacenters. Tous les plans d'actions décrits s'appliquent uniquement dans ce contexte multi-sites.

Vue d'ensemble

Notre Plan de Reprise d'Activité évalue et traite systématiquement les risques pour garantir la continuité de vos services. Cette documentation présente :

  1. L'analyse des risques - Évaluation de chaque scénario
  2. Les plans d'action - Procédures détaillées avec délais d'intervention

Analyse des Risques

Classification des Risques

Le tableau suivant évalue chaque risque selon quatre critères essentiels :

Erreur Humaine

ÉvénementsProbabilitéImpactPlan PréventifPlan d'action Curatif
Suppression de données fortuiteProbableDe nul à critiqueSauvegardes quotidiennesRestauration dernière sauvegarde

Pertes de Workers

ÉvénementsProbabilitéImpactPlan PréventifPlan d'action Curatif
Perte temporaire d'une ressourceProbableDe nul à modéréArchitecture multi-DCAnalyse incident + remise en service
Perte totale d'une ressourceTrès rareDe nul à modéréMulti-DC + infogérance proactiveCommande nouvelle ressource

Pertes de Datacenters (Workers)

ÉvénementsProbabilitéImpactPlan PréventifPlan d'action Curatif
Perte d'1 datacenterTrès rareDe nul à modéréArchitecture multi-DCAnalyse + migration ressources
Perte de 2 datacentersImprobableDe nul¹ à critique²Sauvegardes quotidiennesNouvelles ressources + bootstrap³
Perte de 3 datacentersImprobableCritiqueSauvegardes quotidiennesCluster mono-DC temporaire + restauration

Pertes de Control-Planes

ÉvénementsProbabilitéImpactPlan PréventifPlan d'action Curatif
Perte d'1 control-planeProbableNulArchitecture multi-DCAnalyse + remise en service
Perte de 2 control-planesTrès rareModéré à Fort⁴Sauvegardes quotidiennesNouvelles ressources + synchro
Perte de 3 control-planesTrès rareModéré à Fort⁴Sauvegardes quotidiennesNouveau cluster + redéploiement⁵

Légende des impacts

Notes importantes
  1. ZiElastic : Aucun impact en cas de perte de 2 datacenters
  2. ZiMySQL et ZiPostgres : Services arrêtés en cas de perte de 2 datacenters
  3. Bootstrap : Redémarrage forcé au dernier état intègre pour ZiMySQL
  4. Control-plane : Impact sur déploiements, cronjobs et élection du leader ZiPostgres
  5. Action client requise : Mise à jour des entrées DNS nécessaire

Plans d'Action Détaillés

Délais d'Intervention Garantis

Les actions curatives sont structurées avec des durées d'intervention précises :

Erreur Humaine - Suppression de Données

ActionsDurée
1. Téléchargement sauvegarde (espace client)1 min/Go
2. Restauration des données< 30 min (dump < 2Go)

Perte de 2 Datacenters (services actifs)

ActionsDurée
1. Commande ressources temporaires15 min
2. Identification nœud BDD le plus récent1 min
3. Bootstrap services BDD< 30 min (BDD < 2Go)

Perte de 3 Datacenters ou Perte Totale

ActionsDurée
1. Création cluster mono-DC temporaire15 min
2. Téléchargement sauvegarde1 min/Go
3. Restauration complète< 30 min (dump < 2Go)

Perte de 2 Control-Planes

ActionsDurée
1. Commande nouvelles ressources15 min
2. Synchronisation avec CP actif15 min

Perte de 3 Control-Planes

ActionsDurée
1. Création nouveau cluster MultiKaaS30 min
2. Mise à jour token déploiement5 min
3. Redéploiement depuis Git5 min
Ajustement des délais

Les durées indiquées sont basées sur des volumes standards. Elles seront ajustées lors de l'onboarding selon vos volumes réels de données.

Points Clés à Retenir

Architecture Haute Disponibilité

  • 3 datacenters indépendants garantissent la résilience
  • Sauvegardes quotidiennes systématiques
  • Architecture multi-DC minimise l'impact des incidents

Temps de Récupération

  • Incidents mineurs : < 30 minutes
  • Incidents majeurs : < 1 heure
  • Récupération complète : Dépend du volume de données

Votre Rôle

Dans certains scénarios critiques, votre intervention sera nécessaire :

  • Mise à jour des entrées DNS
  • Modification des tokens de déploiement
  • Validation du retour à la normale